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

Sumit Garg sumit.garg at linaro.org
Fri Dec 22 06:34:33 CET 2023

On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg at chromium.org> wrote:
> Hi,
> On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> >
> > > Prerquisite
> > > -----------
> > >
> > > 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've played with subtree a little and I think this is the right way
> > forward in these cases. If anyone wants to take a look at how this works
> > in practice, take a look at:
> > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > have an example of a normal commit) and then did a merge of each tag
> > until v6.6-dts, so provide some history. And git log looks like what I
> > want to see, the squash commit has clear references to what we are
> > getting and I make a merge commit that says what I did. If you pull the
> > tree and checkout the branch, all the code is right there already,
> > nothing further to do. Same with tarball releases. The only thing I
> > don't like is the size growth there, but we'll reclaim some of it when
> > we delete our obsolete bindings, and then obsolete dts files.
> I spent a bit of time with subtree as well, as part of reviewing this
> series, using the instructions Sumit provided. It seems OK to me. We
> have to accept that it adds code and there will be changes/churn, but
> it is not too different to accepting patches on those files within
> U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> does support a good proportion of the boards supported by Linux, so I
> don't see that as a big cost.
> From my experimentation, subtrees seem to have no impact on buildman,
> which is great. Am I missing anything?

No it shouldn't cause any regression on existing tools/CI/build
systems. It is just a version controlled way of importing third party
source code as a tarball.

> I still worry about the board-level 'switch' between U-Boot DT and
> upstream ones. I believe that should be at the SoC level instead.

Probably I wasn't clear enough in my earlier replies but this series
motivates for a SoC level switch only. Patch #7 is essentially a
switch for Amlogic meson-gxbb SoC and its derived boards.


> >
> > Maxim, please switch (back, sorry!) to subtree for the next lwIP
> > patchset and just not in the prerequisite steps what the subtree command
> > is, and make sure the docs have an example of what future re-sync
> > "subtree pull" commands should look like. For CI testing, you'll have to
> > do that to start with and just not include that patch in the ML part.
> Regards,
> Simon

More information about the U-Boot-Custodians mailing list