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

[Rob Herring]

On Thu, Feb 12, 2026 at 3:22 PM James Hilliard
<james.hilliard1@xxxxxxxxx> wrote:
>
> 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.

IIRC, there was some dtc work to prepend/append to properties.

> > > > > 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?

For at least the last 5 years. It's even defined in the DT spec
(generically as "nexus").

> Would this work with multiple connectors?

Yes.

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

gpio-map completely decouples what the base DT GPIOs look like.

>
> >
> > 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?

You mean you have an overlay for h/w revision of the base board and
then an overlay for the peripheral board? I'm only talking about the
latter.

> 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?

I suspect there's no support for gpio-line-names alongside gpio-map.
You get to define how that works.

There is no gpiochip for the map. It is transparent.

> > >
> > > 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.

No doubt. People want names for everything, so we give them names so
they stop asking.

*-gpios is how you describe what GPIOs are connected to. This works
unless you aren't describing the device/thing the GPIO is connected to
in the DT. The first thing to do there is question could you describe
it?

> > 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.

For starters, once you depend on specific names, it is an ABI. But we
don't document all the names, so it's not an ABI.

> 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.

All that should be in a connector driver IMO. For purposes of the
binding, I don't really care where you handle things. I do care if
where is influencing the binding design.

> 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?

gpio-map is designed exactly for this purpose. GPIO0 on the connector
is always the same thing (or defined by the peripheral board) and what
actual GPIO drives it doesn't matter.

> 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.

Using names is not putting it into the kernel because the kernel
doesn't use the names.

Rob