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

[James Hilliard]

On Thu, Feb 12, 2026 at 12:54 PM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Wed, Feb 11, 2026 at 10:01:05AM -0700, James Hilliard wrote:
> > On Wed, Feb 11, 2026 at 1:44 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > >
> > > On 11/02/2026 09:28, James Hilliard wrote:
> > > > On Wed, Feb 11, 2026 at 1:19 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > > >>
> > > >> On 11/02/2026 09:17, Krzysztof Kozlowski wrote:
> > > >>> On 11/02/2026 09:13, James Hilliard wrote:
> > > >>>> Document the gpio-aggregator virtual GPIO controller with a dedicated
> > > >>>> schema and compatible string.
> > > >>>>
> > > >>>> Also extend the GPIO AGGREGATOR MAINTAINERS entry to cover the new
> > > >>>> binding file.
> > > >>>
> > > >>> <form letter>
> > > >>> This is a friendly reminder during the review process.
> > > >>>
> > > >>> It seems my or other reviewer's previous comments were not fully
> > > >>> addressed. Maybe the feedback got lost between the quotes, maybe you
> > > >>> just forgot to apply it. Please go back to the previous discussion and
> > > >>> either implement all requested changes or keep discussing them.
> > > >>>
> > > >>> Thank you.
> > > >>> </form letter>
> > > >>>
> > > >>
> > > >> First thing which was missing (I did not even check the rest in such
> > > >> case): missing rationale for this patch, missing hardware description.
> > > >
> > > > I added some more details to the commit message, this is a
> > >
> > > No... Commit msg is exactly the same.
> >
> > I added the details to this commit message specifically:
> > https://lore.kernel.org/all/20260211081355.3028947-2-james.hilliard1@xxxxxxxxx/
> >
> > >
> > > > virtual gpio driver though so AFAIU it's not hardware specific.
> > >
> > > You can give example of any hardware where this is useful. You need to
> > > make your case with actual arguments.
> >
> > The sunxi h616 board I have has hundreds of GPIOs, only
> > a few of which are needed, I want to map them in device
> > tree overlays since there's some minor variants with different
> > hardware gpio configurations.
> >
> > Setting the gpio names on the parent controller is not practical
> > since doing so would require setting hundreds of values for
> > gpio-line-names, you also can't really combine sets of pin
> > names across device tree overlays AFAIU.
>
> You can do: gpio-line-names = "GPIO0", "", "", "GPIO3", ...;
>
> The clock binding has "clock-indices" which is used with
> "clock-output-names". We could do something similar if
> all the '""' entries are really a problem.

AFAIU this doesn't solve the line name merge issue.

I have some GPIO lines that are common to all control card
variants, as such I would like to put the names for these lines
in the base dts file so the names always get applied.

I also have some lines that that are common to a subset of
control card variants(which I detect via GPIO strapping in uboot),
as such I would like to put the names for these lines in a dtso file
that is conditionally applied by uboot based on the control card
variant. There are actually multiple GPIO groupings, some are
for peripheral connectors and others are for control board
integrated hardware.

So what I want to be able to do is effectively merge all the GPIO
names from a dts file and multiple dtso files, and you can't merge
list properties, you can only override them entirely AFAIU.

> > > > Use case is I have a device with something like 300 gpio
> > > > lines...and I want to name/group a small subset of those
> > > > lines for delegation to a userspace app rather than trying
> > > > to set 300 or something gpio-line-names values, also I'm
> > >
> > > So if I change the approach in user-space or use different user-space
> > > app then I change the DTS?
> >
> > The idea is to make it practical to set gpio-line-names for a
> > subset of the GPIOs that are wired to peripheral boards.
>
> Humm, peripheral boards! So there's a connector. You need a connector
> binding. And the one solved binding for such a thing is GPIO! The
> gpio-map property lets you remap GPIOs from one provider (the connector)
> to a parent provider (soc_gpio). It would look something like this:

Well...some GPIOs are wired to peripheral board connectors...but
some are wired to things like built in LEDs and a few different
on-controller components as well which vary by controller hardware
revisions.

This gpio-map feature doesn't exist in the mainline kernel does it?

Would this work with multiple connectors?

In my device everything I'm wanting to name is off the same gpiochip.

>
> conn_gpio: connector {
>         #gpio-cells = <1>;
>         gpio-map = <0 &soc_gpio 3>,
>                    <1 &soc_gpio 123>;
>         gpio-line-names = "GPIO0", "GPIO1";
>
>         /* in an overlay */
>         device {
>                 foo-gpios = <&conn_gpio 1>; /* soc_gpio 123 */
> };

I think in my case the entire connector would be in the overlay, as
the connector GPIO lines vary by control board hardware revisions.
Would that still work?

Would the gpio-line-names defined here get set on the parent
&soc_gpio gpiochip or would they show up under a virtual
separate gpiochip similar to gpio-aggregator?

> >
> > Say for example I have a control board connected to a few
> > different peripheral boards, there may be different mixtures
> > of peripheral boards, some of which can be used at the same
> > time as they use different GPIOs.
> >
> > The idea is we load device tree overlays for the detected
> > peripheral boards with detection done in uboot based on a
> > GPIO pin strapping based detection.
> >
> > In userspace we want to match the peripheral board GPIOs
> > based on the GPIO line names, but using gpio-line-names
> > on the entire GPIO controller isn't practical as that doesn't
> > allow composing gpio-line-names configurations from
> > multiple device tree overlays and would require a ridiculous
> > number of placeholder entries due to there being no way
> > to configure individual gpio-line-names for non-hog lines.
>
> GPIO lines typically connect to something. Relying on gpio-line-names
> seems like a failure in defining (in DT) that something.

Isn't gpio-line-names intended to describe what they are physically
connected to? At least that's how I'm seeing them often get used
in mainline device trees.

> We would never rely on GPIO pin names in the kernel. Userspace doing
> so is pretty suspect too. More importantly wanting to do something in
> userspace is irrelevant to bindings. What's in userspace today may be in
> the kernel tomorrow. Look at serial attached BT or other h/w.

Why is that suspect for userspace? The userspace tooling for
gpio manipulation largely seems to support flags for name based
lookups as an alternative to gpio numbers.

In terms of userspace vs kernel drivers...the current situation
for my hardware at the moment is that it's effectively a hybrid
situation, some peripheral board components like eeproms and
temperature sensors have proper kernel drivers, these would be
on the i2c lines for the connectors. There's also uart lines as well
for high speed communications and plug detection GPIOs, reset
GPIOs and reset detect GPIOs on the connectors.

Overall management of the peripheral boards is handled by a
userspace application that needs to know which GPIOs are
attached to which physical connector lines, and since this varies
by the hardware revision it seemed logical to use gpio line names
for that rather than implementing the mapping logic in the userspace
application. There isn't really a good way to control reset lines
and such from userspace other than with GPIO based interfaces
right?

I'm trying to push as much logic into the kernel as practical,
hence why I'm trying to use the gpio names instead of having
the userspace application handle the mappings.

For this hardware there are roughly a dozen control card
subvariants and hundreds of peripheral board subvariants,
although the peripheral board subvariants generally don't
require much differences in kernel features/configurations so
the userspace application can largely handle those differences.

>
> Rob