Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski <krzk@kernel.org>]

On 17/11/2025 17:06, Rob Herring wrote:
>>>>
>>>>>
>>>>> 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.

Binding with pattern or list of needed alias names, referenced by given
soc-platform top-level schema.

One of the points is to make it explicit and obvious (e.g. to Arnd or to
me if I forget, because I follow the same logic of aliases per board)
that these aliases are used outside of kernel.

Just because ufs/mmc/spi can be used that way, does not mean we should
accept any possible alias into soc.dtsi.

Best regards,
Krzysztof