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.ujfal...@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.ujfal...@ti.com> > > Signed-off-by: Tony Lindgren <t...@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
signature.asc
Description: PGP signature
