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

Tom Rini <[email protected]> Thu, 25 Jan 2024 18:19:33 -0500
Newsgroups	io.groups.u-boot-amlogic,org.u-boot-project.lists.u-boot
Message-ID	<20240125231933.GY3652023@bill-the-cat>
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.

-- 
Tom
signature.asc (application/pgp-signature, 659 B)