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

[Tom Rini]

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. Without rehashing history, BSD does use the trees as-is and
for platforms U-Boot supports they are supposed to be re-synced
periodically. 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 :)

-- 
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/attachments/20231215/40bb1e76/attachment.sig>