Re: SoC-specific device tree aliases?

Rob Herring <[email protected]> Thu, 13 Nov 2025 12:04:02 -0600
Newsgroups org.kernel.vger.devicetree-spec,org.kernel.vger.linux-devicetree
Message-ID <CAL_JsqKHqEtYoSuoLd=tR5B+P-_nDyOfpqEUZ_f=ws3yt5qORw@mail.gmail.com>
On Thu, Nov 13, 2025 at 2:29 AM Ahmad Fatoum <[email protected]> wrote:
>
> Hello,
>
> With /chosen/bootsource now part of dt-schema, I would like to raise a
> related point: The need for SoC-specific device tree aliases.
>
> For many SoCs, there is a canonical numbering for peripherals; it's used
> in the datasheet and BootROMs often makes use of it at runtime to report
> the bootsource as a pair:
>
>   - One value to enumerate type of boot medium (e.g. mmc, spi-nor..)
>   - Another value that describes which instance (e.g. SDHC1, SPI3, ...)
>
> Some examples, where this is the case, are AT91, STM32MP or i.MX.
>
> barebox has traditionally used /aliases to translate BootROM information
> to a device tree node to fixup /chosen/bootsource.

So bootsource will be populated "mmc0" or "spinor1" for example?

> This doesn't work out for many newer SoC support, because of different
> expectations: For upstream, aliases are relevant to a board, while
> barebox traditionally expected them to be SoC-specific (because they
> used to be on i.MX, probably).

But usually the numbering follows the SoC numbering. Sometimes it
follows the PCB numbering, but I think that's mainly serial ports.
I've certainly steered people away from vendor specific instance
numbering properties towards aliases (if the need can't be eliminated
entirely).

The board specific part I think is more that the board defines what
devices are present and not present. It would be weird to have a
serial3 alias when that's not wired up. And board .dts files are going
to forget to remove it. Though I guess it is somewhat harmless.

I think the real change here is it would make aliases required when
currently they aren't really. Though I guess populating bootsource is
entirely optional?

Rob