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

[Tom Rini]

On Wed, Dec 27, 2023 at 07:56:26AM +0000, Simon Glass wrote:
> Hi Sumit,
> 
> On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg <sumit.garg at linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Sumit,
> > >
> > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg at linaro.org> wrote:
> > > >
> > > > 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.
> > >
> > > OK good...but that's not quite what I mean. You have a fragment like
> > > this in multiple defconfig files:
> > >
> > > +CONFIG_OF_UPSTREAM=y
> > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
> > >
> > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the
> > > Kconfig.
> >
> > Okay I got your point. It makes sense to me. I will do that for v3.
> >
> > > We should not have to specify the filename like this. It is
> > > laborious and error-prone.
> >
> > The only differentiation in naming here is just silicon vendor prefix
> > addition (amlogic/ in this case). The reason for this being that I
> > just want to mirror the whole silicon vendor directory from DT
> > rebasing rather than mirroring individual DT files. Given this do you
> > have any better alternatives?
> 
> My current opinion is that a better approach would be to move the
> files first (in the U-Boot tree). That would be easier if we could
> just copy the Linux arch/xxx/boot/dts Makefiles but for now that is
> not possible. The Kconfig options for each SoC are similar but there
> are various differences.
> 
> Having a different layout is just a pain and it will get worse, as
> people add new boards, since they need to know to add the correct
> directory.
> 
> I will see if I can devise a small series to point this in what I
> consider to be the right direction, in line with Linux, and the U-Boot
> commit 3284c8b8 ("dts: generate multiple device tree blobs").

I think we should just go with the approach Sumit has already taken, and
encourage SoC maintainers to migrate sooner rather than later. There's
also nothing stopping people from adding vendor directories under arch/
at that point, and will likely have to happen anyhow for the case of
platforms that aren't yet in the devicetree-rebasing tree. I am hopeful
it won't be as much of an issue as my general feedback will change from
"what kernel release is this dts in?" to "why didn't you set
OF_UPSTREAM and use the existing tree?"

-- 
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/20231227/178688c4/attachment.sig>