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

[Conor Dooley]

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.

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)?

Cheers,
Conor.

> This series moves us from an ad-hoc method to a defined
> schedule.
> 
> And presumably some of the Samsung platforms will get moved over to this
> framework, especially the newer ones being submitted recently :)



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