Re: SoC-specific device tree aliases?

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.

Best regards,
Krzysztof