Re: SoC-specific device tree aliases?

[Sascha Hauer <s.hauer@pengutronix.de>]

On Wed, Dec 03, 2025 at 11:51:28AM -0600, Rob Herring wrote:
> On Wed, Dec 3, 2025 at 5:37 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> > 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?
> 
> No.
> 
> Thinking about this some more, I'm not sure that something aliases
> based is even the right approach. Let's back up to the original
> problem instead of talking about a problem concerning a possible
> solution.
> 
> You have a platform specific register with values (or from 1 or
> multiple fields) that you need to map to devices in DT. That's it.
> That could be solved like this:
> 
> bootsource-map =
>   <0x2 &mmc0>,
>   <0x3 &mmc1>,
>   <0x10 &spi0>,
>   ...;
> 
> Simple. The first value is platform specific. Maybe it is several
> fields (e.g. device type, instance) merged together. Doesn't matter.

That's an interesting approach and I like it.

I am not sure though how the platform specific value could be composed.

The easiest way would be if it maps to some register values. This works
well when there's a bitfield with only a few bits which specifies the
bootsource, but not so when there are many bits. On TI AM62x for example
we have 4 bits specifying the primary bootsource, 3 bits specifying the
backup bootsource and 1 bit specifying if we are booting from the
primary or from the backup bootsource. This means we have an array with
potentially 256 entries with many holes and many different values
pointing to the same bootsource. We could reduce the number of array
entries by specifying a mask for each value. I am worried also that the
initial contributor might for example forget about the backup bootsource
and only upstreams primary bootsource, so we would have to modify
existing values for the primary bootsource when adding the backup
bootsource.

How about only adding the phandles to bootsource-map, like

bootsource-map = <&mmc0>, <&mmc2>, <&spi0>, ...;

New entries must then only be added at the end, existing entries must
never be changed.

But anyway, as with your approach the bootsource would become just
another driver specific binding SoC contributors would be free to choose
whatever suits best for them.

Sascha

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