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

[Sumit Garg]

On Fri, 26 Jan 2024 at 12:35, Michal Simek <michal.simek at amd.com> wrote:
>
>
> 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.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.

I agree that these sorts of changes should be done in a DT ABI
compatible manner to U-Boot or atleast proactively adapt U-Boot to
those changes. But I am not sure how we can improve here without a
regular DT sync cadence with upstream and a Linux kernel maintainer
profile to say that DT ABI towards U-Boot has to be kept in mind.

The existing ad hoc syncs won't be motivating Linux DT maintainers to
care about U-Boot regressions.

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

AFAIU from this [1], the DT node names aren't part of the ABI. Given
that we should start motivating people to move away from relying on
node names, for eg. using uclass_get_device_by_seq() instead of
uclass_get_device_by_name().

[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-ofw

> >>>>
> >>>> And really this gets to the crux of the problem, how much testing do we
> >>>> insist happens prior to a re-sync being merged?

I am not sure why custodians/maintainers depend on the global re-sync
to be merged for testing purposes. They can very well have their local
vendor directories synced-up and proactively look for any regressions.

> >>>> Do we want to go with
> >>>> the whole of the dts files are re-synced, or do we leave it per vendor?

Leaving it per vendor would be somewhat similar to existing ad hoc
syncs. BTW, what about bindings directory? We won't be able to enforce
binding checks given the different state of per vendor DTS directory.

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

Yeah given that we are conservative about re-syncs with a full U-Boot
release cycle to detect and fix regressions.

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

So I did a demo experiment for this here [1] where cherry picking DT
fixes into subtree just worked fine with the next uprev. Steps
followed:

$ cd <U-Boot tree>/
$ git remote add dt-rebasing
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
$ git fetch dt-rebasing master
$ git cherry-pick -x --strategy=subtree -Xsubtree=dts/upstream/
9de355a75fdeffc26486508107bf644ca2749fdb
$ ./dts/update-dts-subtree.sh v6.8-rc2-dts

If you would like it to be documented then I can do that for the next rev.

[1] https://github.com/b49020/u-boot/commits/v4_dt_demo_fixes/

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

Given my comments above, I think we should at least give U-Boot
owners/custodians a chance to opt for this and see how it pans out. It
will give a better opportunity for the U-Boot community to engage and
be a part of the current DT contribution model.

-Sumit

>
> Thanks,
> Michal