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