[PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot

[Sumit Garg]

Hi Rob, Andre,

On Tue, 23 Jan 2024 at 22:12, Rob Herring <robh+dt at kernel.org> wrote:
>
> On Mon, Jan 22, 2024 at 6:59 PM Andre Przywara <andre.przywara at arm.com> wrote:
> >
> > On Mon, 22 Jan 2024 11:49:59 -0500
> > Tom Rini <trini at konsulko.com> wrote:
> >
> > Hi Tom,
> >
> > > On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote:
> > > > On Wed, 10 Jan 2024 16:05:36 +0530
> > > > Sumit Garg <sumit.garg at linaro.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I certainly welcome this more automatic synchronisation of the DTs,
> > > > however have one comment about the upcoming sync process:
> > > >
> > > > > ...
> > > > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather
> > > > > use devicetree-rebasing repo [3] which is a forked copy from Linux
> > > > > kernel for DT source files as well as bindings. It is tagged at every
> > > > > Linux kernel major release or intermideate release candidates. So here I
> > > > > have tried to reuse that to bring DT bingings compliance as well as a
> > > > > standard way to maintain a regular sync of DT source files with Linux
> > > > > kernel.
> > > > >
> > > > > In order to maintain devicetree files sync, U-Boot will maintains a Git
> > > > > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory.
> > > > > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window
> > > > > opens with the next available kernel major release.
> > > >
> > > > I hope this doesn't need to stay that restricted? Can we either sync more
> > > > often, or at least on the kernel's -rc1, and not only on a "full" release?
> > > >
> > > > The reason I ask is that we have a chicken-egg problem here: without a DT
> > > > merged into the kernel tree, no U-Boot board support can be merged. And
> > > > without U-Boot support, we cannot boot a kernel, at least not in the
> > > > canonical way.
> > > >
> > > > Since the U-Boot and kernel merge windows are not in phase, for sunxi I try
> > > > to sync the kernel DTs either as early as possible (-rc1, sometimes even
> > > > before, when the maintainers have merged them into their tree), or
> > > > sometimes "out of season", if a board defconfig patch is coming up.
> > > >
> > > > Otherwise new board support, which typically has a very low regression risk
> > > > for the rest of the code base, would need to be delayed until the next
> > > > release. In the worst case the U-Boot merge windows opens one week before
> > > > a kernel release, then new boards need to wait three months?
> > >
> > > Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot
> > > release, and then with the next one switch to OF_UPSTREAM=y (and delete
> > > the dts from arch/) for the next release, when we would have gotten back
> > > in sync?
> >
> > Ah, I didn't look into the actual patches, but if this provision is
> > there, that sounds surely acceptable. It might still be good to sync
> > earlier than the .0 kernel release: if it appears in Linus' tree, it
> > had already seen a good share of review and testing. And with the
> > U-Boot releases being always further away than the next kernel release,
> > we could pull fixes still in time. So we could pick the latest -rc (or
> > .0 release, whichever is more recent) when the U-Boot merge window
> > opens?
>
> That should be mostly fine IMO, but there are the occasional "oops,
> let's change/fix the binding before it's released".
>
> Couldn't you pull in the latest rc in the merge window, but only if
> the .0 release will happen before the next u-boot release. And then
> update from rc to .0 before the u-boot release.
>
> Also, from a quick look at the dts changes during rc releases, they
> tend to come in the later rc releases. Probably that's just the
> latency of going to sub-arch maintainer->SoC->Linus.
>

I agree with your intent to keep U-Boot updated with the latest Linux
DT .0 releases. However, we would like to provide sufficient time (a
full U-Boot release cycle) for U-Boot developers/maintainers to adapt,
detect and fix problems for their platforms wrt. to a new Linux DT .0
release. We can always revisit the syncing strategy to be more
aggressive if everything pans out as per plan.

-Sumit

> Rob