Re: SoC-specific device tree aliases?
Doug Anderson <[email protected]> Thu, 13 Nov 2025 11:17:40 -0800
| Newsgroups | org.kernel.vger.devicetree-spec,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <CAD=FV=XMm_SatBN79D6A8aCXSTpJvmgdhXMm84Um5fpq=e66LA@mail.gmail.com> |
Hi, On Thu, Nov 13, 2025 at 10:12 AM Rob Herring <[email protected]> wrote: > > 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). It's been a long time since I was involved in any discussion about this, but I remember Arnd Bergmann being strongly against having numbering aliases in the SoC "dtsi" file. I was always on the opposite side of this argument, but it seems reasonable to include him in the conversation. From my point of view, with the exception of the "serial" alias folks almost always wanted devices to be numbered as per the SoC numbering, as long as there was a well-defined SoC numbering. For instance, if the SoC manual consistently calls a port "i2c12" then it's pretty confusing if the device doesn't end up as "/dev/i2c12". This always led me to the argument that aliases like this should be in the SoC ".dtsi" file. The "serial" alias is a bit of a special case because of historical assumptions. It's often assumed that serial port "0" is the debug port. Luckily there aren't usually so many active serial ports so it's not terribly confusing... > 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. To me it doesn't seem awful to still have the alias pointing to a "disabled" node. The node is still there, so why can't the alias still be there? -Doug