Hello,
I am working on a patch to synchronize the DTS files of the am33xx SoC with those from Linux 4.16.11 (current stable).
After some tiny modifications to the boards am335x-pdu001, am335x-evm, am335x-rut, am437x-gp-evm and am43x-epos-evm buildman passes without any warnings on the 46 am33xx based boards. This is required but not sufficient at all.
As I'm the maintainer of the am335x-pdu001 board I will use it to illustrate a sample problem. The am335x-pdu001 board uses the ns16550 driver which reads the property <reg-shift> from the DT. This property is required and must be set to a value of 2, otherwise it would default to 0. The am33xx.dtsi file currently used by U-Boot sets this property correctly for all 6 uarts. The am33xx.dtsi file from Linux 4.16.11 however does not define this property anymore. For the am335x-pdu001 board the fix is trivial: just add the property <reg-shift> to the board and U-Boot specific am335xx-pdu001-u-boot.dtsi file. But this has a major drawback: only the am335x-pdu001 board gets fixed. What about other boards requiring the <reg-shift> property? The first idea that would probably come into mind is to put the property <reg-shift> into the SoC specific am33xx-u-boot.dtsi file. But this file is ignored if a board specific file already exists. Hence this can not be done.
For the patch I'm working on there is the general question about how to proceed. Should I just fix the board I'm maintaining and then post the patch? This would most certainly break some of the remaining 45 boards which I think is a no-go.
A more specific question dealing with the "missing SoC property" <reg-shift> above is about <>-u-boot.dtsi files: would it be possible, useful and hazard-free to change the build process to use, for example, SoC specific _and_ board specific files? Of course some sort of hierarchy would be necessary to make sure that properties defined in the board specific dtsi file would overwrite the same properties defined in the SoC specific file ect.
I believe that keeping DT files (especially include files) in sync between U-Boot and Linux is of big importance. Maybe there is already a standard solution to problems similar to the one depicted above. Anyway, I would appreciate any feedback.
regards, Felix