Re: SoC-specific device tree aliases?

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?

Second, I don't think it is an ABI. We had it ~5 or ~8 years ago where
the mmcblkX was changing based on probe ordering. Many people setups got
broken, many people complained and the consensus reply was: please start
finally using UUID/PARTUIID/LABEL for rootfs. Eventually we got back to
mmcblkX stability but rule is there - if your cmdline has /dev/mmcblkX,
then it is your problem.




Best regards,
Krzysztof