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

[Rob Herring]

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.

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

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 */
};

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

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.

Rob