Re: SoC-specific device tree aliases?

On Thu, Dec 4, 2025 at 1:59 AM Sascha Hauer <[email protected]> wrote:
>
> On Wed, Dec 03, 2025 at 11:51:28AM -0600, Rob Herring wrote:
> > On Wed, Dec 3, 2025 at 5:37 AM Ahmad Fatoum <[email protected]> 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.

It's platform specific, so however it wants and not my problem.

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

It's a map, not an array so there should be no holes. The entry index
is not significant. In this example, the platform just defines the
cell as:

<primary_or_sec:16><sec_source:15:8><primary_source:7:0>

You could fit it all in 8-bits, but I spaced it out in case the next
SoC needs another bit.

A mask value would be okay until you have 2 different registers and
then you need a variable number of cells. And then I could imagine
someone will want to define the register address for each cell in the
name of a 'generic binding'. That's not what I want to see.

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

That would work too. Then you just have the index to register value
lookup in code. Doesn't matter to me too much. The only downside I see
is having to enforce that people don't try to insert entries in the
middle.

Rob