[PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Sumit Garg]

On Sat, 16 Dec 2023 at 00:49, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Dec 15, 2023 at 02:45:11PM +0000, Conor Dooley wrote:
> > On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote:
> > > On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
> > > > On 14/12/2023 20:48, Rob Herring wrote:
> > > > >>
> > > > >> I think some of the important questions to ask are, how often / likely
> > > > >> are the breakages to occur? It seems like these days it's either:
> > > > >> - U-Boot had an early version of the binding and we already state we
> > > > >>   don't support backwards compatibility here. It should be on the
> > > > >>   maintainer to be proactive in this case.
> > > > >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
> > > > >>   incompatible DTS change now". This too is hopefully the kind of thing
> > > > >>   that at least board maintainers will be more actively aware of needing
> > > > >>   to deal with in U-Boot, if it's really a problem.
> > > > >
> > > > > A common issue in the kernel is with forward compatibility when
> > > > > platforms add new resources from a new provider. Then the kernel
> > > > > expects a driver for the provider and waits for the dependency. Of
> > > > > course, older kernels don't have that provider driver and so the
> > > > > dependency is never met. Not sure if u-boot will have similar issues?
> > > > > At least you should/could know if the provider driver exists or not.
> > > > > (The kernel doesn't because modules.)
> > > >
> > > > If some U-Boot platform decides to aggressively sync with kernel DTS,
> > > > then probably the kernel subarch maintainer should be aware of it.
> > > > Mentioned forward compatibility issue is a result of assumption that
> > > > there are no out-of-tree upstream consumers of our DTS. I am certainly
> > > > not aware of any such consumer for Samsung. If someone told me (me
> > > > wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
> > > >
> > > > The usual argument of contributors wanting to break the backward and
> > > > forward compatibility, is "there is no other OS depending on this"
> > > > (recent discussion with Johan about order of interrupts:
> > > > https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ).
> > > > You need to tell the maintainers of that platform, that now they have
> > > > other OS/firmware/bootloader depending on DTS compatibility.
> > >
> > > I think this hints at one of the bigger impacts this might have.
> > > Reminding everyone that other projects do use the device trees and have
> > > for years.
> >
> > TBF, we do try to ask these questions as much as possible, usually (for
> > me at least) citing U-Boot or the BSDs as users. It largely seems to me
> > like we are all bark and no bite though, so a project like U-Boot having
> > a defined "schedule" as you suggest below would add more meaning to our
> > questioning.
> >
> > > Without rehashing history, BSD does use the trees as-is and
> > > for platforms U-Boot supports they are supposed to be re-synced
> > > periodically.
> >
> > I know this is the theory, but I also know that how well this is
> > implemented varies wildly per-platform. I generally don't pay all
> > that much attention to the various arm platforms, but I do pay
> > attention to what's going on for RISC-V and there appear to be no
> > active maintainers of individual platforms and the architecture
> > maintainers are not aware of the status of the equivalent patches
> > for Linux when they apply patches.
> >
> > In recent memory, this has lead to the clock indices in the DT
> > differing between U-Boot and Linux for one such platform, which, IMO,
> > is an insidious difference that is hard to spot during review and highly
> > unlikely to crop up while comparing dts files, since the defines were named
> > identically. To be clear, I am not expecting the architecture code
> > maintainers to be aware of the minutiae of the various RISC-V platforms,
> > but rather suggesting they might have an easier time reviewing if both
> > projects' dts files and binding headers were tied together.
> >
> > That said, automatically synced devicetrees will, as has been pointed out,
> > require the platform maintainers in Linux to be more aware of the affect of
> > what they accept on other users, but it will also require the equivalent
> > maintainers on the U-Boot side to engage too, so that the "upstream" dts
> > files do not change in a way that screws the usecase in U-Boot.
>
> Yeah, it will hopefully lead to better coordination between maintainers
> in some places. There are SoCs where the kernel DTS people are the
> U-Boot DTS people too. All in all, I should probably CC more people than
> I usually do on these resync patches just to try and head off any
> tricky changes like you've mentioned above.

Makes sense.

>
> > Also, if people send fixes to the U-Boot copies of these devicetrees,
> > would the plan be to request that these are sent to Linux and the fixes
> > pulled in via a resync after each -rc release of Linux (or similar, just
> > throwing some example schedule out there)?
>
> The way we've always tried to operate is that changes should be pushed
> to Linux and resynced down, or at least submitted simultaneously. If
> there's some specific bugfixes that need to come in out of cycle I
> _think_ subtree handles cherry picked commits in a reasonable fashion.
>

Agree.

-Sumit

> --
> Tom