Re: [PATCH v8 0/6] of: teach overlay code to keep /aliases in sync

["Abdurrahman Hussain" <abdurrahman@nexthop.ai>]

On Thu, Nov 12, 2026 at 04:12:05PM -0600, Rob Herring wrote:
> Stable bus numbers is a solution to your problem. What's the problem you
> are trying to solve?

Labeling hwmon channels on an embedded Linux system.

The board has an x86 host with ACPI firmware and a PCIe FPGA that
provides a dozen or so I2C masters, with muxes behind them leading to
PSUs, fan controllers, voltage regulators and temperature sensors. The
FPGA driver applies an overlay at probe time that describes all of this.
Userspace labels the hwmon channels with libsensors, and sensors.conf
picks a chip by its bus and address, e.g. "pmbus-i2c-12-40".

The same parts sit at the same address behind different mux channels
(PSU1 and PSU2 are both at 0x58, for example). Their hwmon "name" and
their address are identical, so the bus is the only thing that tells
them apart.

libsensors has a "bus" statement that maps a bus number in the config
to an adapter name, which would avoid relying on numbers. It doesn't
work here, because the adapter names aren't stable either. Mux channels
are named "i2c-%d-mux (chan_id %d)" after the parent's dynamic number,
and the xiic masters are named after their platform device, which comes
from the MMIO address the PCI BAR ended up at. A udev by-path symlink
for /dev/i2c-N wouldn't help, since libsensors doesn't use /dev/i2c-N
at all. It reads /sys/class/hwmon, where the bus number is part of the
parent device name ("12-0058").

> How aliases interact with an ACPI system is another aspect I have yet to
> consider...

On these systems the base DT is drivers/of/empty_root.dts, which has no
/aliases node. So no alias is honored from the base DT, every bus is
numbered dynamically starting at 0, and the overlay is the only place
an alias could come from.

> Right, but there is no fallback for some cases. Having that is the only
> way this could work.

Can you spell out what that would take? Does every subsystem that
hands out ids from aliases need its own fallback, i.e. the i2c, i3c,
spi and mmc cores, plus mtd and the serial drivers, before overlay
aliases could go in? And if so, would you want each of those as a
separate series through its own tree, landing ahead of the OF patches,
or all together in one series?

Thanks,
Abdurrahman