From: Rob Herring <robh@kernel.org>
To: Abdurrahman Hussain <abdurrahman@nexthop.ai>
Cc: Saravana Kannan <saravanak@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Shawn Guo <shawnguo@kernel.org>,
Grant Likely <grant.likely@secretlab.ca>,
Grant Likely <grant.likely@linaro.org>,
Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
David Daney <david.daney@cavium.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 0/6] of: teach overlay code to keep /aliases in sync
Date: Thu, 12 Nov 2026 16:12:05 -0600 [thread overview]
Message-ID: <20261112221205.GA1425386-robh@kernel.org> (raw)
In-Reply-To: <DMOE1TFEAB6G.EC2KYRBTZR9@nexthop.ai>
On Fri, Nov 06, 2026 at 11:51:52AM -0800, Abdurrahman Hussain wrote:
> On Fri, Nov 06, 2026 at 07:24:32AM -0600, Rob Herring wrote:
> > What I would like is aliases are not supported in overlays (applied
> > after boot).
> >
> > Don't we already have consistent naming on hotpluggable devices such as
> > network adapters? All that is solved in userspace. Why do we need DT to
> > solve this here?
>
> Netdevs can be renamed, and that is why userspace can solve it for them.
I don't think that was always true, so if it can be added for network
devices, it can be added for anything. But netdev is a bit special...
> i2c adapters can't be renamed.
I didn't say rename. /dev/input/ has unstable indices *and* stable
paths. IIRC, udev creates all the stable symlinks. Disks have links by
uuid and label.
> I'm also not sure "after boot" is a clear boundary.
I mean bootloader applied before Linux is entered.
> Overlays applied by
> drivers such as lan966x_pci, or for an FPGA on an x86 host, are applied
> during probe. They describe fixed, soldered-down hardware in the same
> way a base DT would. The same /aliases node gives stable numbering when
> it is in the base DT and is silently ignored when it comes from an
> overlay, even though it is written to the live tree and visible in
> /proc/device-tree.
How aliases interact with an ACPI system is another aspect I have yet to
consider...
> If an alias is a request, as you said, then honoring it when possible
> and falling back with a warning when it isn't can't break a working
> system. Today such a request is simply never honored. That was the
> regression you were worried about, and the fallback covers it.
Right, but there is no fallback for some cases. Having that is the only
way this could work.
> If you still don't want overlays to set aliases, is there another way
> you'd accept to get stable bus numbers for hardware described by an
> overlay? I'm happy to rework the series in a different direction.
Stable bus numbers is a solution to your problem. What's the problem you
are trying to solve?
Rob
prev parent reply other threads:[~2026-11-12 22:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 23:17 [PATCH v8 0/6] of: teach overlay code to keep /aliases in sync Abdurrahman Hussain
2026-10-14 23:17 ` [PATCH v8 1/6] of/overlay: look up absolute target-paths absolutely Abdurrahman Hussain
2026-10-14 23:17 ` [PATCH v8 2/6] of/overlay: return ERR_PTR from dup_and_fixup_symbol_prop() Abdurrahman Hussain
2026-10-14 23:17 ` [PATCH v8 3/6] of: hold a reference on of_aliases during alias path resolution Abdurrahman Hussain
2026-10-14 23:32 ` sashiko-bot
2026-10-14 23:17 ` [PATCH v8 4/6] of: update /aliases lookup on reconfig notifications Abdurrahman Hussain
2026-10-14 23:29 ` sashiko-bot
2026-10-14 23:17 ` [PATCH v8 5/6] of/overlay: rewrite /aliases path values to live-tree paths Abdurrahman Hussain
2026-10-14 23:27 ` sashiko-bot
2026-10-14 23:17 ` [PATCH v8 6/6] of: unittest: cover /aliases updates from overlay apply/revert Abdurrahman Hussain
2026-11-05 0:09 ` [PATCH v8 0/6] of: teach overlay code to keep /aliases in sync Abdurrahman Hussain
2026-11-05 12:40 ` Rob Herring
2026-11-06 2:11 ` Abdurrahman Hussain
2026-11-06 13:24 ` Rob Herring
2026-11-06 19:51 ` Abdurrahman Hussain
2026-11-12 22:12 ` Rob Herring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261112221205.GA1425386-robh@kernel.org \
--to=robh@kernel.org \
--cc=abdurrahman@nexthop.ai \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=david.daney@cavium.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=grant.likely@linaro.org \
--cc=grant.likely@secretlab.ca \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pantelis.antoniou@konsulko.com \
--cc=saravanak@kernel.org \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.