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

Tom Rini trini at konsulko.com
Thu Dec 14 21:15:11 CET 2023


On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote:
> On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong at linaro.org wrote:
> > > Hi,
> > >
> > > On 14/12/2023 14:50, Sumit Garg wrote:
> > > > Prerquisite
> > >
> > > s/Prerquisite/Prerequisite/
> > >
> > > > -----------
> > > >
> > > > This patch series requires devicetree-rebasing git repo to be added as a
> > > > subtree to the main U-boot repo via:
> > > >
> > > > $ git subtree add --prefix devicetree-rebasing \
> > > >        git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \
> > > >        v6.6-dts --squash
> > >
> > > So I think the big question is: when should the subtree be updated ?
> > >
> > > Because as we discussed in the previous GH pull request, if a bindings changes
> > > was made in the upstream Linux DT, then the subtree update should wait until
> > > the u-boot support is merged before updating. This could cause a lot of frustration.
> > >
> > > And this could cause a lot of regressions, even more if both Linux and U-boot are
> > > not maintained by the same people.
> >
> > 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.)

I think we'll be fine, but time will tell. And perhaps the more frequent
re-syncing will make any sort of corner cases show up more quickly and
be something we can figure out how to resolve going forward really.

-- 
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/20231214/a8d72778/attachment.sig>


More information about the U-Boot-Custodians mailing list