On 1/26/24 03:10, Marek Vasut wrote:
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 <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.
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 .
I would let board owners/custodians to deal with their boards.
There is very high chance that if you do it globally that it is question of time
when something will break.
It make sense to talk about how to do that transition and describe that steps
and having tools/script to help with.
Thanks,
Michal
