Re: SoC-specific device tree aliases?

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.

And where do we put 'bootsource-map'? That could be either in the node
of the device with the boot source register(s) or alongside bootsource
in chosen. In chosen is a bit weird because that's supposed to be
things the bootloader fills in.

Now I'm pretty annoyed because like what happens many times, I
accepted bootsource and you all turn right around want to add on to
it. IOW, it didn't completely solve the problem or give me the whole
picture. Why does that matter? Because now I might say 'bootsource'
can just be the index into 'bootsource-map', but now we're stuck with
it (forever). Anything else needed in this area?

Rob