incompatible device trees between u-boot and linux

[Rob Herring]

On Tue, Aug 31, 2021 at 9:21 AM Sean Anderson <seanga2 at gmail.com> wrote:
>
> On 8/31/21 9:35 AM, Rob Herring wrote:
> > On Wed, Aug 25, 2021 at 10:12 AM Vladimir Oltean <olteanv at 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