Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski <krzk@kernel.org>]

On 03/12/2025 11:36, Matthias Schiffer wrote:
> On Wed, 2025-12-03 at 11:25 +0100, Krzysztof Kozlowski wrote:
>> On 03/12/2025 11:16, Ahmad Fatoum wrote:
>>> Hello Krzysztof,
>>>
>>> On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
>>>> On 17/11/2025 17:06, Rob Herring wrote:
>>>>>> 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.
>>>
>>> I can't see how this could work. A number of boards renumber MMC devices
>>> in a different manner than the SoC reference manual:
>>>
>>> - Changing the alias numbering is an ABI break, because Linux derives
>>> its /dev/mmcblkX numbering from it
>>
>> First, why the alias would change? Isn't the board following the SoC
>> numbering in 99.9% cases?
> 
> At least for our TQ-Systems boards, we have a convention based on usage (mmc0:
> eMMC, mmc1: SD card; serial0 is often the console) rather than following the SoC
> numbering; that is, we're using the aliases as a form of hardware abstraction
> rather than hardware description.

Huh, does it even match numbering on the schematics / board / user-guides?

I would prefer not to create bindings purely because some existing DTS
code is not matching our expectations. However there could be a case
where board numbering is different than soc number and we want to keep
aliases configured for board.

Basically what you propose here is the discouraged instance ID disguised
under one more 'alias' which is not really alias. It's just an instance
ID. There is no other use of soc-aliases beside instance ID.

I see the problem you want to solve, I agree it is worth solving and I
agree that DT is the place for this mapping between register value and
device node. However solution of discouraged instance ID is just...
well, discouraged, so not optimal. I don't have particular advice expect
a dedicated property for each device in such case.

Best regards,
Krzysztof