Re: SoC-specific device tree aliases?

["Heiko Stübner" <heiko@sntech.de>]

Am Donnerstag, 13. November 2025, 20:17:40 Mitteleuropäische Normalzeit schrieb Doug Anderson:
> Hi,
> 
> On Thu, Nov 13, 2025 at 10:12 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Thu, Nov 13, 2025 at 2:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> 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.

Yep, especially when everything in the soc documentation _and_ the
board schematics calls i2c4 controller, clocks and data lines ... i2c4-foo.

I do agree that unnumbered controllers (like sdhci, sdmmc, sdio on
recent Rockchip SoCs) should be the responsibility of the boards,
but really don't get the idea of repeating the ever same list of aliases
in each and every board dts.


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

additionally, one would never ever point "serial3" or "i2c4" to anything
else than the uart3 and i2c4 controllers, because that would be completely
confuse everybody.

Like when the board uses i2c0 and i2c4, those should still have the
aliases i2c0 and i2c4, because when you have "i2c1" as alias for the i2c4
controller on the running system, so many heads will explode ;-)