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

[Tom Rini]

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

-- 
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/attachments/20240125/1f3cd8be/attachment.sig>