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

[Tom Rini]

On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:

[snip]
> 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.

Well, how far back are we going? There was a serial related one, but it
was probably closer than not to 10 years ago and lessons have been
learned from it already.

The real breakage comes in the form of (from the Linux kernel):
commit 37685f6a63eeca2135d1f704e7638409a071b1f6
Author: Peter Ujfalusi <peter.ujfalusi at ti.com>
Date:   Tue Feb 19 08:46:33 2019 -0800

    ARM: dts: am335x-evm: Fix PHY mode for ethernet

    The PHY must add both tx and rx delay and not only on the tx clock.
    The board uses AR8031_AL1A PHY where the rx delay is enabled by default,
    the tx dealy is disabled.

    The reason why rgmii-txid worked because the rx delay was not disabled by
    the driver so essentially we ended up with rgmii-id PHY mode.

    Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
    Signed-off-by: Tony Lindgren <tony at atomide.com>

And this is of the style "the DTS was wrong before so we can break it".
This is the specific example (as the board is in my lab) that comes most
clearly to mind but there have been similar examples in 2022/2023.

The other just as painful examples I think may be where Marek is
concerned and it's around nodes being renamed for correctness. We've had
a number of cases where a - turned to _ (or vice versa?) and whoops,
platform stops booting. Down the line, tooling would catch that, and
it's a problem of not being able to use better tooling until we have the
updates that might break the boards that need the better tooling.

And really this gets to the crux of the problem, how much testing do we
insist happens prior to a re-sync being merged? Do we want to go with
the whole of the dts files are re-synced, or do we leave it per vendor?
I think it's been noted that a subtree merge commit doesn't really "git
send-email" well.

I really am inclined to start with keeping everyone to the release tags
for everyone and merging them as soon as the next window opens. I
_think__ and we'll be able to find out quickly enough, that we can
cherry-pick fixes from upstream in to our subtree and have subtree Do
The Right Thing in the next merge window.

[snip]
> > 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.

This is a good specific example. The bootph* properties should _now_ be
easier to get accepted upstream as our tooling handles the transitive
property of them correctly and so they don't need to be manually applied
so much (a problem upstream maintainers had, after the binding was
accepted, was the sheer number of them being added, this is now fixed).
But also applying these properties via -u-boot.dtsi was tripped up in
resyncs where the parent node was renamed for correctness and there's no
tooling that we had that complained. In the future, this would have been
caught because we would have been dtbs_check clean, or at least clean
enough that I'd be running it and caring about deltas from before/after.

-- 
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/20240125/83a15c2d/attachment.sig>