Re: SoC-specific device tree aliases?

Hi,

On 12/3/25 12:08 PM, Krzysztof Kozlowski wrote:
> 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.

How do we move forward here? I don't think we can change the nature of
/aliases being board-specific now without breaking users.

Does this make the addition of /soc-aliases (or /soc/aliases?) more
palatable?

Cheers,
Ahmad

> 
> Best regards,
> Krzysztof
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |