Re: [PATCH v2 1/2] dt-bindings: gpio: add gpio-aggregator binding

[Bartosz Golaszewski]

On Fri, Feb 20, 2026 at 9:24 AM Linus Walleij <linusw@xxxxxxxxxx> wrote:
>
> On Fri, Feb 20, 2026 at 5:57 AM James Hilliard
> <james.hilliard1@xxxxxxxxx> wrote:
>
> > Yeah, I did investigate adding gpio-line-names support to gpio-map,
> > but there was no clear way that I saw to actually implement it in the
> > kernel. Maybe there's some way I missed however.
>
> Check commit bd6f2fd5a1d52198468c5cdc3c2472362dff5aaa
> "of: Support parsing phandle argument lists through a nexus node"
>
> of_parse_phandle_with_args_map() in drivers/of/base.c is where
> the magic happens.
>
> This is called from drivers/gpio/gpiolib-of.c, in of_get_named_gpiod_flags(),
> so as you see mapping doesn't really happen until you use it.
> There is no way we can assign the line name on the mapping
> path itself.
>
> What we would have to do is to add code to gpiolib-of.c to scan the
> whole device tree whenever a new gpiochip from a gpio-controller
> node is added and look for any "gpio-map" with phandles to the provider,
> and if that exist, index and parse gpio-line-names from the nexus
> node to override the default (if any) that is set for the gpio controller.
>
> Not impossible just a bit quirky.
>

Due to the fact that we are not allowed to investigate fw_devlinks
from driver code (as confirmed by Greg KH to me) I implemented this
kind of device-tree scanning in gpiolib-shared. It too checks phandles
in order to detect shared pins. Maybe it makes sense to factor it out
into a piece of common code and cover both use-cases.

Bart