On 9/23/24 15:18, David Gibson wrote:
On Mon, Sep 23, 2024 at 11:12:02AM +0200, Geert Uytterhoeven wrote:
Hi David,
On Mon, Sep 23, 2024 at 10:41 AM David Gibson
<david@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Mon, Sep 23, 2024 at 10:22:03AM +0200, Geert Uytterhoeven wrote:
On Mon, Sep 23, 2024 at 5:41 AM David Gibson
<david@xxxxxxxxxxxxxxxxxxxxx> wrote:
So, essentially you're just adding new labels as aliases to existing
labels?
Ok, I can see at least two ways of doing that which I think are a more
natural fit than allowing symbols to be phandles.
[...]
# Method 2: /aliases
Does the (Linux) DT overlay code support updating aliases?
Last time I needed that (almost a decade ago), it did not.
Huh. I hadn't realised the kernel kept a separate cache of aliases
that wasn't updated. Assuming that's still the case, that would
complicate matters a bit.
Indeed.
Actually, in a sense this is just an aspect of a more general thing:
libfdt's is not the only relevant implementation of overlays. If you
want to extend what overlays can do, you need to consider the kernel
implementation too.
So, I don't think we can go the aliases route. I posted an updated
of_alias patch [0], but as Rob pointed out:
```
Drivers use the non-existent alias numbers for instances without an
alias. So what happens if an index is already in use and then an
overlay uses the same index.
I don't see how this can work reliably unless the alias name doesn't
exist in the base DT.
```
Not really sure how alias overloading can be supported in kernel without
breaking existing drivers.
Overlays are starting to feel more like a hack the longer I work on this.
I guess I can try out implementing `foo = &bar;` approach and see how
that goes.
[0]:
https://lore.kernel.org/all/20241110-of-alias-v2-0-16da9844a93e@xxxxxxxxxxxxxxx/T/#t
Ayush Singh
