[PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

[Sumit Garg]

On Wed, 15 May 2024 at 15:09, Jonas Karlman <jonas at kwiboo.se> wrote:
>
> Hi Sumit,
>
> On 2024-05-15 10:49, Sumit Garg wrote:
> > Hi Jonas,
> >
> > On Wed, 15 May 2024 at 13:11, Jonas Karlman <jonas at kwiboo.se> wrote:
> >>
> >> Hi Tom,
> >>
> >> On 2024-05-14 18:42, Tom Rini wrote:>
> >>> git-subtree-dir: dts/upstream
> >>> git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> >>> ---
> >>> This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> >>> -next branch. To test these changes yourself locally, either use my
> >>> "WIP/14May2024-next" branch or run:
> >>> ./dts/update-dts-subtree.sh pull v6.9-dts
> >>> yourself locally. I intend to wait a few days to apply this to -next, to
> >>> give people time to test.
> >>>
> >>
> >> There are currently more boards/SoCs that use OF_UPSTREAM in master
> >> branch than in next branch, a few Rockchip SoCs and other boards/SoCs.
> >
> > Glad to see more OF_UPSTREAM adoption.
> >
> >> Next dts/upstream sync will probably be good to do together with a merge
> >> of master into next :-)
> >
> > I don't have any particular opinion here and rather leave it upto Tom
> > how he would like to merge stuff.
> >
> >>
> >> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
> >> probably be released shortly after U-Boot v2024.07. So will next sync be
> >> to v6.10-dts if that happens in the U-Boot merge window or do we expect
> >> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
> >> U-Boot merge window?
> >>
> >> Linux kernel typically have all major DT changes in -rc1 and fixes in
> >> later -rcX, so for next branch I would suggest an early sync to a
> >> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
> >> gets released. That should give more time for testing, migration and
> >> cleanup using v6.10 DTs in time for a 2024.10 release.
> >
> > I can see the reasoning for an aggressive DT syncing approach, it has
> > been brought up in the past too. And the major reason for the current
> > moderate sync approach [1] is to limit any DT ABI breakages for
> > U-Boot, we are even prone to breakages with syncs against major Linux
> > kernel releases (eg. v6.10-dts etc.). It has been a long time
> > discussion topic where we have been advocating about requirements for
> > DT ABI stability [2].
> >
> > So having DT syncs done during the merge window will shorten the
> > testing window for developers/maintainers. And more syncs means a
> > multiplicative factor for testing. However, time will tell with more
> > and more platforms adopting OF_UPSTREAM, if there are any real DT ABI
> > breakages seen in the future. But surely if they are very rare then I
> > am open to adopting aggressive DT sync approaches.
>
> I agree that syncing multiple rcX tags may not be that helpful, but an
> approach where maybe rc1, rc2 or rc3 and then the final tag is merged or
> something similar. At least when we can foresee when next Linux version
> will be released close to an U-Boot release. At least early in U-Boot
> release cycle know what Linux version dts/upstream will be targeted.
>
> My main concern is how to best handle new boards and features/drivers.
> E.g. for Rockchip the RK3588 SoC is under active development, new boards
> and features/drivers are actively added/fixed in upstream Linux.
>
> New Rockchip boards have typically been added after board DT have been
> merged into linux maintainer tree. Now if we wait until merge window to
> do a dts/upstream sync, the result may be that it may take up to three
> U-Boot releases until a new board is easily added using dts/upstream.
>
> Another approach could be that we add new boards using !OF_UPSTREAM once
> they are merged into linux maintainer tree. And then migrate the board
> to use OF_UPSTREAM once the board finally ends up in dts/upstream.
>
> But that can also be problematic when board .dts-file start referencing
> nodes/symbols not yet added in the soc .dts-file in dts/upstream.
> Adding the "missing" but maintainer merged soc nodes to the soc
> u-boot.dtsi could be one way to work around such issue.

I would suggest you to then maintain the under development soc
.dts-file in U-Boot too. Since with !OF_UPSTREAM, the soc .dts-file
present in the U-Boot DTS tree (arch/${ARCH}/dts/) will be used
instead of one from dts/upstream. This was especially done to support
use-cases like this via the directory include ordering. You can later
switch once you think the board is well supported by dts/upstream.

>
> Anyway, some guidance, predictability and earlier sync related to
> dts/upstream would be much appreciated :-)

IMHO, let's try to provide a stable base to encourage further adoption
of OF_UPSTREAM and have sufficient data regarding DT ABI stability.
IOW, let's stick to the current moderate sync approach for a few more
U-Boot releases. My motivation has really been to reduce
developers/maintainers' pain regarding DT maintenance in U-Boot.

-Sumit

>
> Regards,
> Jonas
>
> >
> > [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing
> > [2] https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg02162.html
> >
> > -Sumit
> >
> >>
> >> Regards,
> >> Jonas
>