Rob,
Am 04.12.18 um 19:36 schrieb Rob Herring:
I've put together a script to move the dts files and update the makefiles. It doesn't handle files not following a common prefix which isn't many and some includes within the dts files will need some fixups by hand.
MAINTAINERS will also need updating.
A few questions:
Do we want to move absolutely everything to subdirs?
This refactoring is a terrible idea!
While it would've been nice to have more structure from the start, bootloaders like U-Boot expect a flat structure for arm .dtb files now. If you start installing them into subdirs instead, they won't find the files anymore under the hardcoded name.
Doing this only for new platforms would be much less invasive and allow to prepare bootloaders accordingly. Alternatively, white-list which ones are safe to move around. But don't just script a refactoring because it looks nicer in the source tree, without testing what side effects this can have for board/distro users of the compiled files in practice. We already had that discussion for arm64 because Debian chose to ignore the kernel-installed subdirectories and installed .dtb files into a flat directory, which collided with openSUSE sticking to the kernel choice.
This topic becomes even more important with EBBR: There is neither a mechanism in place to sync .dts files into U-Boot or EDK2 source trees, nor are capsule updates implemented in U-Boot for easily deploying such bootloaders with new .dts sources or paths yet. And I can assure you that just getting users to dd the right bootloader can be difficult... Since DT forward and backward compatibility is often being neglected, for example with optional properties or renamed compatibles that break booting with previous drivers, new kernel versions often need updated Device Trees to make use of new/enhanced drivers. Therefore it is unfortunately often enough a necessity to load newer kernel-based .dtb files matching the kernel (as opposed to the dream of kernel-independent hardware descriptions) when working with the latest -rc or -next kernels at least. For examples of DTs needing updates, look no further than Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where .dtb paths may be hardcoded, ditto for arm; and Armada was an example where the upstream bindings for the network IP changed incompatibly.
DT overlays are another topic that is not making any progress upstream according to the ELCE BoF, so beyond the Raspberry Pi the only known working way to apply them is to write a U-Boot boot.scr script, which can either reuse $fdtcontroladdr DT or use the filename $fdtfile or hardcode one, the latter two of which would break with your renaming.
So expect people to be using .dtb files, expect them to be affected by file movements to subdirectories here, and don't expect each user to understand or be able to fix things themselves if they fall apart as result of your changes and they suddenly no longer have Ethernet/Wifi.
Regards, Andreas