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

[Sumit Garg]

On Thu, 25 Jan 2024 at 07:36, Marek Vasut <marex at denx.de> wrote:
>
> On 1/24/24 09:16, Sumit Garg wrote:
>
> Hi,
>
> >>>> How do you propose to handle fixes to DTs which are applied to
> >>>> linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which
> >>>> has some defect that is fixed in 6.6.1, how will that fix get into
> >>>> U-Boot DTs ?
> >>>
> >>> This fix would also be in the latest Linux tags, so I think it would
> >>> find its way here - as I understand it patches aren't accepted into
> >>> Linux stable unless they land in torvalds tree.
> >>
> >> See the devicetree-rebasing.git:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/refs/
> >>
> >> That only contains refs for release versions (v6.6-dts, v6.7-dts etc),
> >> not any follow-up updates from linux-stable (like current 6.6.13 etc).
> >>
> >
> > Here we should only consider fixes which are critical to U-Boot. I
> > think -u-boot.dtsi files would be suitable to carry those fixes until
> > next uprev. However, if there is a fix affecting many platforms than
> > we can consider pulling that standalone too.
>
> That would mean extra duplicate work -- the critical fixes have already
> been selected into linux-stable, that work is already done, I don't
> think it makes sense to re-do it again.
>
> Furthermore, I do not like the new necessity to start porting those
> fixes from linux-stable and converting them to adjustments to
> *-u-boot.dtsi files, this is tedious and error prone, so it would have
> to be automated.
>
> But I still think it is much better to simply take the fixes directly
> from linux-stable as-is instead.

That's fair, it would essentially be a DT ABI breakage for U-Boot for
which a fix has to be taken in U-Boot from Linux stable release. So I
am fine with that.

But at this point we have to move away from apprehensions about DT ABI
breakages and provide real examples of the DT ABI breakages in the
past. Are you aware of any DT ABI breaking change backported to Linux
stable releases? This is the sort of information we would like to make
DT bindings maintainers aware about.

>
> >> Would this require syncing in -rc versions of Linux DTs to get the
> >> latest fixes in ?
> >
> > Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So
> > its a chicken and egg problem as per your comments below. However, we
> > can revisit our syncing strategy based on how the current one pans
> > out.
> >
> >>
> >>>> Assume that there is some large breaking change in Linux 6.(n+1),
> >>>> something which would be problematic for specific U-Boot platform
> >>>> (e.g. i.MX) or would require a lot of work to sort out, will there be
> >>>> a way to temporarily pin DTs for specific platform to older DT version
> >>>> until that is resolved (e.g. pin to 6.n) ?
> >>>
> >>> (Upstream) devicetree has to be forwards and backwards compatible, were
> >>> such a breaking change to get merged without prior discussion with DT
> >>> users (i.e. U-Boot) then I think the correct course of action would be
> >>> to revert it.
> >>
> >> Not really, this could be a perfectly valid change, and would work for
> >> Linux just fine, it might simply be pulling in something which is not
> >> supported by U-Boot just yet and therefore syncing the DTs into U-Boot
> >> would break U-Boot on that platform . Using older version of DTs for a
> >> platform could work as a stopgap measure until the functionality is
> >> implemented. Is this possible ?
> >
> > For this particular reason we want to pull once during beginning on
> > U-Boot next window and allow sufficient time for platform maintainers
> > to adapt to it. However, OF_UPSTREAM=n can be an alternative for a
> > stopgap solution.
>
> That pull would break other peoples platforms. It would be no different
> than adding broken patch into the code base.

The platforms which get converted to OF_UPSTREAM=y are the ones which
would be compliant with upstream DT bindings. So any DT ABI change
among major Linux .0 releases would be the reason for that breakage.
And we are happy to accept a revert for that change and feed that
information back to Linux DT bindings maintainers.

Also as above, are you aware of any past DT ABI breakages for U-Boot
since people have already been doing DT syncing from Linux manually.
This series allows to reduce that pain and try to bring DT bindings
compliance in U-Boot.

> What I think would be an
> option is that there is a pull (as in patch) and people should be able
> to test it before it is applied.

We can't modify that pull but rather accept changes on top of it. IMO,
it will get widely tested in U-Boot next branch.

> If one platform is severely affected
> while other platforms are fine, the one platform should be able to use
> the current working version of DTs, while the other platforms should not
> be blocked by it. Is that what OF_UPSTREAM=n does ?
>
> As far as I understand OF_UPSTREAM=n, it would require re-importing DTs
> into the codebase ?

No you don't have to re-import everything but rather import a board
DTS file to the arch/ folder and reuse all the DT includes from
dts/upstream subtree as per this [1] patch.

[1] https://lore.kernel.org/all/20240110103547.719757-5-sumit.garg@linaro.org/

>
> >>> On a tangential note: as I understand it, DTs built from dt-rebasing are
> >>> still subject to U-Boot customisations via the "-u-boot.dtsi" include
> >>> files, this allows for dealing with incompatibilities due to missing
> >>> features in U-Boot.
> >>
> >> Would it be possible to auto-update those -u-boot.dtsi files during
> >> sync, to minimize the resulting DT blob delta before/after update, and
> >> thus also minimize the likelihood of causing breakage ?
> >
> > In the long run the DT community would like to avoid any DT ABI
> > breakages at all. Rob is already working on a DT ABI check tool and
> > seeking inputs for what could be an ABI break [1] from U-Boot
> > perspective too. Feel free to provide your inputs.
> >
> > Along with that we wouldn't need -u-boot.dtsi files once we make
> > U-Boot fully compliant with DT bindings. Until that point U-Boot
> > platform maintainers have to keep their -u-boot.dtsi files updated
> > corresponding to latest DT rebasing releases.
>
> I think upstreaming the bootph* properties would still take a while, but
> is not relevant to the aforementioned question.
>
> Assume there is a sync, would the current in-tree -u-boot.dtsi files get
> updated to work correctly with the newly synced DTs ?

As long as they contain nodes/properties (eg. bootph* etc.) which are
compliant with upstream DT bindings then yes they should work
correctly with the newly synced DTs.

-Sumit