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

On 1/25/24 16:04, Tom Rini wrote:
> 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 <[email protected]>
> 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 <[email protected]>
>      Signed-off-by: Tony Lindgren <[email protected]>
> 
> 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'd much prefer to leave it per vendor, with the recommendation to use 
synced DTs. Eventually things will stabilize and vendors will start 
switching over.