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

[Rob Herring]

On Wed, Oct 14, 2026 at 04:17:25PM -0700, Abdurrahman Hussain wrote:
> /aliases entries added by a device-tree overlay are stored in the live
> tree but never enter the global aliases_lookup list that of_alias_scan()
> builds at boot. As a result, of_alias_get_id() returns -ENODEV for
> aliases declared inside overlays, and any driver that relies on
> alias-based numbering (i2c-xiic, spi, tty, mmc, ...) silently loses its
> pinned id and falls back to auto-assignment.
> 
> The gap has been public since 2015 [1] and reproduces trivially: apply
> an overlay that declares e.g. `i2c99 = &foo;`, ask
> of_alias_get_id(foo, "i2c") -> -ENODEV.

[...]

> Overlay aliases colliding with dynamic ids
> ------------------------------------------
> 
> On v7 you raised the question from the 2024 repost of Geert's series
> [2]: an overlay alias can name an id a subsystem has already handed
> out dynamically, because subsystems may pick any number that has no
> alias. I went through what the of_alias_get_id() users do in that
> case, and in every one of them the collision is a loud registration
> failure, never two devices on one number:
> 
>   i2c      i2c_allocate_adapter_id() does idr_alloc(nr, nr + 1), so a
>            taken index gives -EBUSY plus pr_err("adapter '%s': failed
>            to allocate id") and the adapter is not registered.
>   spi      spi_controller_id_alloc(bus_num, bus_num + 1) likewise:
>            WARN() and -EBUSY, controller not registered.
>   serial   serial_port.c sets port->line from the alias;
>            serial_core_add_one_port() returns -EINVAL if that line is
>            already occupied.
> 
> What this series changes is the failure mode for an overlay asking
> for an index a dynamic allocation already took: today the alias is
> ignored and the device quietly gets some other number, which is the
> bug being fixed, since the pinned number was the point of the alias.
> After it, the probe fails and says why. That seems the right
> contract -- an alias is a request for one specific number, and
> refusing it is more useful than pretending it was honored. It is also
> what already happens in the base DT when two aliases name the same
> index, or when a driver calls i2c_add_numbered_adapter() with a taken
> number.

I'd rather have my added device working than refusing to probe because 
some arbitrary device index couldn't be used. There may be some user 
that has a working system today and then this change would break them. 
We can't really have that. I view aliases as a request, not a 
requirement. It's perfectly valid for an OS to just ignore them 
completely. 

I have no issue if we make the failure to use an alias louder, but I 
guess that's not your main issue.

Rob