Advice in system/driver architecture

Hi, may I ask for your advice.

I have an Embedded-System with a PowerPC P2020 running a Kernel 4.1.x which is build on an ELDK5.4.
In ELDK we create a uimage and dtb file which is flashed with uboot.

This System is connected to a bunch of peripheral cards containing i2c chips and other stuff.
We have a custom driver to communicate with these peripheral cards and monitor different states in the i2c chips. Lately the hardware designers found a critical "bug" in the hardware which lead to a changed set of i2c chips on the peripherals.
The driver modification is not the problem, but the system needs to support the old and the new peripheral boards, because the hardware is costly and we can't just trash the old peripherals.
(There is now way to get the peripheral revision number and distinguish between the old and new version.)

I’m not very experienced with Linux and don't know if this is the correct approach to solve the problem:
- Branch the driver to create one version for the old hardware and one version for the new hardware
- Create a dtb file for both hardware configurations. (This bugs me most. I would be easy to load one or the other module at start-up, but to flash the dtb file for every hardware change feels strange)

Is there a better way to solve this problem?


Summary:
Embedded system with Kernel 4.1.xx (uimage, dtb, module support on)
Needs to support different hardware configurations.

Regards,
Knarzos

To implement the approach you mention, you could either manually install the correct dtb for each board (but that is fallible) or enhance U-Boot with some mechanism to detect the HW version, and then load the proper dtb. Of course your kernel image would have both driver versions available.

> to flash the dtb file for every hardware change feels strange

There are methods for storing multiple dtb files and kernel images.
Instead of raw flash partitions, these files should be stored in the /boot directory of the root filesystem.


If the HW differences aren't too extreme (or you want to conceal these differences), then you could have one composite driver for both HW versions, and at runtime (e.g. starting at probe) handle the differences. In theory this could isolate the HW differences to just one driver.
For marketed chips/devices, this is the typical approach. The kernel source tree has driver files for specific chips/devices or families of chips/devices, and not files per each version/variation.

In general you would want to avoid having a human decide/install the correct soft/firmware. The pros and cons for any approach would also depend on the scope of those HW differences and the amount of effort for development and maintainability you expect to provide.

Regards

It is also possible for a single driver to handle a family of interfaces.

It all depends on how complex the change is as to whether a separate driver should be done. If it is impossible to identify the differences based on PNP identification (model/version), then the driver itself must determine the differences using internal data. If the differences are relatively minor, then the driver should make the determination on its own - a simpler result.