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

[Abdurrahman Hussain]

On Wed Aug 19, 2026 at 4:49 AM PDT, Herve Codina wrote:
> Hi Abdurrahman,
>
> On Tue, 21 Jul 2026 14:36:31 -0700
> Abdurrahman Hussain <abdurrahman@xxxxxxxxxx> 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. Bootlin's ELCE 2025 talk on
>> PCI DT overlays [2] enumerates "i2c muxes" as one of the subsystems
>> broken by dynamic overlays; alias pinning is the underlying cause.
>
> Are you sure aliases were mentioned in the talk and were the cause of issues?
>
> I've got an issue with i2c muxes but it is not related to aliases.
>
> What made you think about aliases issue?
>
> The issue I have is related to fw_devlink consumer/supplier relationship and
> I have sent a fix [0] with nothing related to aliases.
>
> [0] https://lore.kernel.org/all/20260630103010.413688-1-herve.codina@xxxxxxxxxxx/
>
> Best regards,
> Hervé

Hi Hervé,

You're right, and thanks for the correction.

The "alias pinning is the underlying cause" clause was my own inference,
not something your talk claims — I shouldn't have written it as if it
were. I now see the i2c-mux issue you meant is the fw_devlink one you
fixed separately; conflating it with this series in the cover letter was
wrong. Apologies.

This series is narrowly about overlay-declared /aliases never entering
aliases_lookup, so of_alias_get_id() returns -ENODEV and alias-based id
pinning falls back to auto-assignment. It reproduces with no mux involved
and doesn't depend on your talk.

In v4 I'll drop the "underlying cause" clause; I can keep [2] only as
prior-art context or drop it entirely — whichever you'd prefer.

Best regards,
Abdurrahman