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

On 1/26/24 00:19, Tom Rini wrote:
> On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote:
>> 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.
> 
> To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM
> to start with. With that, I see switching to OF_UPSTREAM meaning that
> there's a commitment to keeping up with dts change in upstream dts that
> might lead to issues within U-Boot. Do you still feel it would be better
> to have the re-sync _also_ be per custodian tree? That might be a bit
> harder to handle.

Maybe the best thing we can do is just give it a try and see how it 
works out, esp. since it is opt-in per board .

It would still be good to solve the part about pulling in fixes from 
linux-stable though .