Re: SoC-specific device tree aliases?

On 03/12/2025 12:20, Marc Kleine-Budde wrote:
> On 03.12.2025 11:25:11, 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?
>>
>> 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.
> 
> In order to use UUID/PARTUIID/LABEL in the kernel command line, the
> firmware/bootloader/... has to map from the register value to the
> instance to read the UUID/PARTUIID/LABEL from the media.

Or have it stored when flashing/configuring the board as part of
firmware configuration like U-Boot env.

Best regards,
Krzysztof