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

[Tom Rini]

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.

> 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot-custodians/attachments/20231215/8d069dc4/attachment.sig>