Re: Moving ARM dts files

["Andreas Färber" <afaerber@suse.de>]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel