Re: SoC-specific device tree aliases?

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.

Best,
Matthias


> 
> 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
> 

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/