Re: SoC-specific device tree aliases?

On Mon, Nov 17, 2025 at 9:44 AM Krzysztof Kozlowski <[email protected]> wrote:
>
> On 17/11/2025 16:23, Sascha Hauer wrote:
> >>
> >> You read from registers booted device MMC 1 (out of MMC 0-2), so instead
> >> of relying on register value that "1" always means MMC1, not MMC0 for
> >> example or whatever else changed in hardware, you can just sort the
> >> nodes by unit address and choose the second device.
> >
> > The instance numbers do not always match the unit address sorting.
> >
> > For example K3 SoCs have:
> >
> > dts/src/arm64/ti/k3-am62-main.dtsi:548: sdhci0: mmc@fa10000 {
> > dts/src/arm64/ti/k3-am62-main.dtsi:566: sdhci1: mmc@fa00000 {
> > dts/src/arm64/ti/k3-am62-main.dtsi:589: sdhci2: mmc@fa20000 {
>
> That's label which is not yet proof that boot source registers have the
> same... I can git grep as well, but wanted actual confirmation, because
> people put to DTS many wonderful mistakes.
>
>
> >
> > Rockchip:
> >
> > dts/src/arm64/rockchip/rk356x-base.dtsi:619:    sdmmc2: mmc@fe000000 {
> > dts/src/arm64/rockchip/rk356x-base.dtsi:994:    sdmmc0: mmc@fe2b0000 {
> > dts/src/arm64/rockchip/rk356x-base.dtsi:1008:   sdmmc1: mmc@fe2c0000 {
> >
> > There are some examples for i.MX as well. To my own surprise not with
> > the mmc nodes, but some SPI instances are not sorted by unit address.
> >
> >>
> >>
> >>>
> >>> Also I don't get whether you are suggesting
> >>>
> >>> A is as fragile as B, so you could equally well do B
> >>
> >> Both are fragile, so I would be happy to see arguments why A is better
> >> than B. Why? Because with B you don't need any binding because all the
> >> information is already in DTS.
> >
> > What do you consider fragile with it?
>
> Only that you rely on a specific register values and their meaning.
>
> Anyway, I would just go with standard aliases, but add a schema for each
> of such cases (SoCs or vendors), so you will define this as an ABI.
>
> One of the reasons why Barebox was affected by all node renames and
> alias reshuffling was that it was never documented that anyone treats
> this as an ABI.
>
> So you want it to be an ABI for barebox, sure, just make it a binding.

What do you have in mind? Other than standard names for the aliases,
what can we check here? That a specific alias points to a specific
path? That would be a bit too much IMO. That would be equivalent to
specifying possible values in 'reg' for all devices.

Documenting standard names was something I started but gave up on with
the mess we had already. And that was several years ago, so it
probably only got worse.

Rob