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

Sumit Garg sumit.garg at linaro.org
Fri Dec 15 07:01:31 CET 2023


On Thu, 14 Dec 2023 at 23:53, 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/
> >

Ack.

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

Agree, also per discussion with Linux DT maintainers, they do care for
DT backwards and forward compatibility. I expect the ABI changes to be
rare. In case there is an ABI change then it will be great if Linux DT
maintainers can ask contributors to CC corresponding U-boot platform
maintainers too.

BTW, Rob is already working on a tool to detect ABI changes as he
described here [1]. If U-boot platform maintainers have any ideas
regarding what would constitute an ABI change then feel free to share
those.

[1] https://lore.kernel.org/all/CAL_JsqLo4nXrJ93dDsfp3UYLs08V02aMnbCCnsDj0MBBomc35w@mail.gmail.com/

>
> So I would plan on grabbing only full kernel releases and in to -next as
> soon as possible. Our cadences don't match up exactly, but I think do
> fairly well enough.

I suppose that would give ample time to the U-boot platform/board
maintainer to fix any ABI change regression found in the -next branch.
That being said we aren't completely immune to changes to
devicetree-rebasing subtree. If there is an DT ABI change that will
take significant effort to fix in U-boot then we are open to accepting
a revert given that it will be fixed before next uprev.

-Sumit

>
> --
> Tom


More information about the U-Boot-Custodians mailing list