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

[Sumit Garg]

Hi Marek,

On Mon, 22 Jan 2024 at 05:47, Marek Vasut <marex at denx.de> wrote:
>
> On 1/21/24 23:41, Caleb Connolly 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.

> 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.

>
> > 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.

[1] https://lore.kernel.org/all/CAL_JsqLo4nXrJ93dDsfp3UYLs08V02aMnbCCnsDj0MBBomc35w@mail.gmail.com/

-Sumit