Message-ID: <CADvTj4oBtO0Yhib1rE8QQwgtJvy-x_hK46C63mjVAydtxHOV8g@mail.gmail.com>
Date: Wed, 11 Feb 2026 10:01:05 -0700
From: James Hilliard <james.hilliard1@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: linux-gpio@...r.kernel.org, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Linus Walleij <linusw@...nel.org>, Bartosz Golaszewski <brgl@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Alexander Stein <linux@...tq-group.com>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Herve Codina <herve.codina@...tlin.com>
Subject: Re: [PATCH v2 1/2] dt-bindings: gpio: add gpio-aggregator binding

On Wed, Feb 11, 2026 at 1:44 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 11/02/2026 09:28, James Hilliard wrote:
> > On Wed, Feb 11, 2026 at 1:19 AM Krzysztof Kozlowski <krzk@...nel.org> 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@gmail.com/

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

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

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.

Maybe there's a better way to fix this limitation by allowing
sparse line name configurations(i.e. the ability to set a name
for gpio line 275 without touching names for lines 0-274)?
Although that would probably leave the access rights issue
described here as an outstanding issue:
https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/

> Well, that's not a valid reason for a binding then.
>
> > supporting multiple board variants and want to be able to
> > better compose the gpio difference with device tree overlays
> > using these virtual gpio groups essentially.
>
> This also should not be used to differently organize DTS, for the sole
> purpose of composing gpio difference. The role of DTS is to represent
> here the hardware.

I'm trying to represent the hardware configuration in the DTS
by naming GPIO pins for userspace, but there's no way to
currently name the relevant pins without setting names for
non-relevant pins at the same time.

The current technique for pin naming is all or nothing and
doesn't really work properly with device tree overlays that
only need to name a subset of pins, especially if there are
other overlays that may need to name a different subset of
pins from the same parent gpiochip which can also be loaded
at the same time as other overlays.

So ultimately the purpose of what I'm trying to do is represent
the connected hardware accurately for userspace, something
which is not currently really possible from device tree AFAIU.

>
>
> Best regards,
> Krzysztof

Powered by blists - more mailing lists