On Tue, Aug 31, 2021 at 9:21 AM Sean Anderson <sean...@gmail.com> wrote: > > On 8/31/21 9:35 AM, Rob Herring wrote: > > On Wed, Aug 25, 2021 at 10:12 AM Vladimir Oltean <olte...@gmail.com> wrote: > >> > >> On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote: > >>> On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote: > >>>> On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote: > >>>>> On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I noticed that there is a fallback to the u-boot device tree for linux > >>>>>> (esp. EFI boot) if no other device tree was found, see [1]. It seems > >>>>>> this > >>>>>> is working fine for imx devices, for example, where you can just boot a > >>>>>> stock installer iso via EFI. It will just work and it is quite a nice > >>>>>> feature as a fallback. > >>>>>> > >>>>>> Now for the layerscape architecture, the ls1028a in my case, things are > >>>>>> more difficult because the bindings differ between u-boot and linux - > >>>>>> one > >>>>>> which comes to mind is DSA and ethernet. > >>>>>> > >>>>>> Which begs the general question, is it encouraged to have both bindings > >>>>>> diverge? To me it seems, that most bindings in u-boot are ad-hoc and > >>>>>> there > >>>>>> is no real review or alignment but just added as needed, which is ok if > >>>>>> they are local to u-boot. But since they are nowadays passed to linux > >>>>>> (by default!) I'm not so sure anymore. > >>>>>> > >>>>>> OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like > >>>>>> they should (could?) be shared between linux and u-boot. > >>>>>> > >>>>>> -michael > >>>>>> > >>>>>> [1] > >>>>>> https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471 > >>>>> > >>>>> The U-Boot device tree is supposed to be able to be passed on to Linux > >>>>> and Just Work. The bindings are not supposed to be different between > >>>>> the two (except for when we take the binding while it's being hashed out > >>>>> upstream BUT THEN RESYNCED). > >>>> > >>>> You might need to spell that out a bit clearer. > >>>> > >>>> You are saying that both U-Boot and Linux are allowed to have their own > >>>> custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed = > >>>> "in-band-status"' > >>>> for Linux), as long as the device tree files themselves are in sync, and > >>>> the subset of the device tree blob understood by Linux (i.e. the U-Boot > >>>> blob sans the U-Boot specifics) is compatible with the Linux DT blob? > >>> > >>> I don't know what about the Linux example makes it Linux specific. But > >>> yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored > >>> by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in > >>> logic (as much as it can be used is that device trees are device trees > >> ^ > >> I don't think this parenthesis ever closes... > >> > >>> and describe the hardware and developers don't need to write a device > >>> tree for Linux and a device tree for U-Boot and a device tree for > >>> FreeBSD and ... So yes, you're supposed to use the device tree for a > >> ^ > >> so I never get the answer to "the whole reason is...". > >> > >>> platform and it works here and there and every where. > >> > >> The fact that only Linux uses it makes it Linux specific. > >> > >>>> To expand even further on that, it means we should put 'managed = > >>>> "in-band-status"' > >>>> in U-Boot, which is a Linux phylink device tree property, even if U-Boot > >>>> does not use phylink? > >>> > >>> We should be able to drop in the device trees from Linux and use them. > >>> Custodians should be re-syncing them periodically. Some are, even. > >> > >> Are you ready to take up device tree bindings for PTP timers, PCIe root > >> complex event collectors, cascaded interrupt controllers, things which > >> U-Boot will never ever need to support? > >> > >> At least in Linux there is a policy to not add device tree nodes that do > >> not have drivers. > > > > That is not the policy. The policy is DT nodes must have binding > > (schema) documentation and the binding should be complete as possible > > (not what some driver currently uses). However, for complex bindings, > > it might be difficult to write the binding in absence of a driver. > > It is effective policy for some arches... > > When the K210 patches were submitted, any bindings for devices without > enabled drivers were requested to be (and subsequently were) removed, > even though many of those bindings were based off of existing > documentation. This is the primary cause of divergence between the Linux > and U-Boot devicetrees for this platform. It is also the main reason > that I have not bothered putting together a sync patch.
Well, that's a perfect example of why it shouldn't be policy. We need to make sync'ing easier, not harder. Rob