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

[Sumit Garg]

Hi Tony,

On Wed, 27 Dec 2023 at 10:11, Tony Dinh <mibodhi at gmail.com> wrote:
>
> Hi Sumit
> Hi Simon,
>
> On Tue, Dec 26, 2023 at 2:13 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?
> >
>
> So how do we handle the case where the DTS exists in u-boot, but not
> in Linux? For example, the DTS was developed for u-boot first and has
> not been accepted in the Linux device tree yet. Can we set in the
> board defconfig like:
>
> # CONFIG_OF_UPSTREAM is not set
>
> Would that allow the DTS to remain in arch/<architecture>/dts?

Yeah that is expected until DTS becomes available in the DT rebasing tree.

-Sumit

>
> Thanks,
> Tony