Re: SoC-specific device tree aliases?

[Tom Rini <trini@konsulko.com>]

On Wed, Dec 03, 2025 at 11:25:11AM +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?

I swear historically and probably still today at least one major SoC
vendor manuals/etc start numbering from 1 and not 0. And it's not just
iMX where "which one was wired for an SD cage and which is wired for
eMMC" vary from ref (or hobbyist) platform to ref platform. And then, oh
goodness, custom designs. So no, there's no consistency and then "store
UUID/etc in env during install" falls down on other cases starting with
"is there an env to store them to?" and so a common case is "we know
mmcX is ... so read the UUID, pass that to the kernel".

-- 
Tom