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

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

[James Hilliard]

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.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
Changes v1 -> v2:
  - Add MAINTAINERS entry for the new binding file
  - Rewrite binding description without "this binding" wording
    (suggested by Krzysztof Kozlowski)
  - Drop unrelated consumer node from the example
    (suggested by Krzysztof Kozlowski)
  - Add gpio-line-names usage to the example to show named aggregated
    lines
---
 .../bindings/gpio/gpio-aggregator.yaml        | 54 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml

diff --git a/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
new file mode 100644
index 000000000000..e7df266a3d8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-aggregator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO aggregator controller
+
+maintainers:
+  - Alexander Stein <linux@ew.tq-group.com>
+
+description:
+  GPIO aggregator forwards selected GPIO lines from one or more GPIO
+  controllers and exposes them as a virtual GPIO controller.
+
+properties:
+  compatible:
+    const: gpio-aggregator
+
+  "#gpio-cells":
+    description: Specifies the line offset and GPIO flags.
+    const: 2
+
+  gpios:
+    description: Array of GPIOs to aggregate
+    minItems: 1
+    maxItems: 32
+
+  gpio-controller: true
+
+  gpio-line-names:
+    minItems: 1
+    maxItems: 32
+
+required:
+  - compatible
+  - "#gpio-cells"
+  - gpio-controller
+  - gpios
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    gpio_agg: gpio-aggregator {
+        compatible = "gpio-aggregator";
+        #gpio-cells = <2>;
+        gpio-controller;
+        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
+                <&gpio3 1 GPIO_ACTIVE_HIGH>;
+        gpio-line-names = "modem-reset", "modem-enable";
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 13b291d801bc..e1bf9a37f87f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10789,6 +10789,7 @@ M:	Geert Uytterhoeven <geert+renesas@glider.be>
 L:	linux-gpio@vger.kernel.org
 S:	Supported
 F:	Documentation/admin-guide/gpio/gpio-aggregator.rst
+F:	Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
 F:	drivers/gpio/gpio-aggregator.c
 
 GPIO IR Transmitter
-- 
2.43.0

[PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[James Hilliard]

Add an OF match entry for "gpio-aggregator" to support plain GPIO
forwarding from devicetree without delay semantics.

This allows exposing selected lines as a logical GPIO controller with
stable aggregated offsets, so consumers can reference forwarded lines
instead of physical controller offsets. It also allows creating bundled
groups of named lines that can be exposed to userspace as a convenient
virtual gpiochip interface. Using "gpio-delay" for this case is not
suitable because it enables delay features and requires 3-cell GPIO
specifiers.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
Changes v1 -> v2:
  - Split DT schema into a separate patch
    (suggested by Krzysztof Kozlowski)
  - Expand commit message rationale and use-case explanation
    (suggested by Krzysztof Kozlowski)
  - Clarify userspace use case with bundled named line groups
---
 drivers/gpio/gpio-aggregator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpio/gpio-aggregator.c b/drivers/gpio/gpio-aggregator.c
index 416f265d09d0..a09752fc5fe2 100644
--- a/drivers/gpio/gpio-aggregator.c
+++ b/drivers/gpio/gpio-aggregator.c
@@ -1635,6 +1635,9 @@ static int gpio_aggregator_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id gpio_aggregator_dt_ids[] = {
+	{
+		.compatible = "gpio-aggregator",
+	},
 	{
 		.compatible = "gpio-delay",
 		.data = (void *)FWD_FEATURE_DELAY,
-- 
2.43.0

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Bartosz Golaszewski]

On Wed, Feb 11, 2026 at 9:14 AM James Hilliard
<james.hilliard1@gmail.com> wrote:
>
> Add an OF match entry for "gpio-aggregator" to support plain GPIO
> forwarding from devicetree without delay semantics.
>
> This allows exposing selected lines as a logical GPIO controller with
> stable aggregated offsets, so consumers can reference forwarded lines
> instead of physical controller offsets. It also allows creating bundled
> groups of named lines that can be exposed to userspace as a convenient
> virtual gpiochip interface. Using "gpio-delay" for this case is not
> suitable because it enables delay features and requires 3-cell GPIO
> specifiers.
>
> Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> ---
> Changes v1 -> v2:
>   - Split DT schema into a separate patch
>     (suggested by Krzysztof Kozlowski)
>   - Expand commit message rationale and use-case explanation
>     (suggested by Krzysztof Kozlowski)
>   - Clarify userspace use case with bundled named line groups
> ---
>  drivers/gpio/gpio-aggregator.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpio/gpio-aggregator.c b/drivers/gpio/gpio-aggregator.c
> index 416f265d09d0..a09752fc5fe2 100644
> --- a/drivers/gpio/gpio-aggregator.c
> +++ b/drivers/gpio/gpio-aggregator.c
> @@ -1635,6 +1635,9 @@ static int gpio_aggregator_probe(struct platform_device *pdev)
>  }
>
>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
> +       {
> +               .compatible = "gpio-aggregator",
> +       },
>         {
>                 .compatible = "gpio-delay",
>                 .data = (void *)FWD_FEATURE_DELAY,
> --
> 2.43.0
>

Regardless of the DT bindings - this change is perfectly fine. We do
that for other "virtual" devices like gpio-sim, gpio-virtuser, etc. I
would just ask you to document it under
Documentation/admin-guide/gpio/gpio-aggregator.rst.

Bartosz

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Geert Uytterhoeven]

Hi Bartosz,

On Wed, 11 Feb 2026 at 10:47, Bartosz Golaszewski <brgl@kernel.org> wrote:
> On Wed, Feb 11, 2026 at 9:14 AM James Hilliard
> <james.hilliard1@gmail.com> wrote:
> >
> > Add an OF match entry for "gpio-aggregator" to support plain GPIO
> > forwarding from devicetree without delay semantics.
> >
> > This allows exposing selected lines as a logical GPIO controller with
> > stable aggregated offsets, so consumers can reference forwarded lines
> > instead of physical controller offsets. It also allows creating bundled
> > groups of named lines that can be exposed to userspace as a convenient
> > virtual gpiochip interface. Using "gpio-delay" for this case is not
> > suitable because it enables delay features and requires 3-cell GPIO
> > specifiers.
> >
> > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>

> > --- a/drivers/gpio/gpio-aggregator.c
> > +++ b/drivers/gpio/gpio-aggregator.c
> > @@ -1635,6 +1635,9 @@ static int gpio_aggregator_probe(struct platform_device *pdev)
> >  }
> >
> >  static const struct of_device_id gpio_aggregator_dt_ids[] = {
> > +       {
> > +               .compatible = "gpio-aggregator",
> > +       },
> >         {
> >                 .compatible = "gpio-delay",
> >                 .data = (void *)FWD_FEATURE_DELAY,
> > --
> > 2.43.0
> >
>
> Regardless of the DT bindings - this change is perfectly fine. We do
> that for other "virtual" devices like gpio-sim, gpio-virtuser, etc. I
> would just ask you to document it under
> Documentation/admin-guide/gpio/gpio-aggregator.rst.

This is not a pure virtual device, but for use with actual hardware.

Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Bartosz Golaszewski]

On Wed, Feb 11, 2026 at 10:50 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> > >
> > >  static const struct of_device_id gpio_aggregator_dt_ids[] = {
> > > +       {
> > > +               .compatible = "gpio-aggregator",
> > > +       },
> > >         {
> > >                 .compatible = "gpio-delay",
> > >                 .data = (void *)FWD_FEATURE_DELAY,
> > > --
> > > 2.43.0
> > >
> >
> > Regardless of the DT bindings - this change is perfectly fine. We do
> > that for other "virtual" devices like gpio-sim, gpio-virtuser, etc. I
> > would just ask you to document it under
> > Documentation/admin-guide/gpio/gpio-aggregator.rst.
>
> This is not a pure virtual device, but for use with actual hardware.
>
> Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>
>

Well, it is a virtual device in that there's no actual "aggregator"
device on the board. It virtually aggregates GPIOs into a separate
chip for user's convenience. While there's no such device as a
gpio-aggregator - and so we must not put it into bindings nor into
mainline devicetree sources - having a compatible matching in the
driver is perfectly fine IMO. Just like gpio-sim.

Bartosz

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Krzysztof Kozlowski]

On 11/02/2026 11:38, Bartosz Golaszewski wrote:
> On Wed, Feb 11, 2026 at 10:50 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>>
>>>>
>>>>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
>>>> +       {
>>>> +               .compatible = "gpio-aggregator",
>>>> +       },
>>>>         {
>>>>                 .compatible = "gpio-delay",
>>>>                 .data = (void *)FWD_FEATURE_DELAY,
>>>> --
>>>> 2.43.0
>>>>
>>>
>>> Regardless of the DT bindings - this change is perfectly fine. We do
>>> that for other "virtual" devices like gpio-sim, gpio-virtuser, etc. I
>>> would just ask you to document it under
>>> Documentation/admin-guide/gpio/gpio-aggregator.rst.
>>
>> This is not a pure virtual device, but for use with actual hardware.
>>
>> Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
> 
> Well, it is a virtual device in that there's no actual "aggregator"
> device on the board. It virtually aggregates GPIOs into a separate
> chip for user's convenience. While there's no such device as a
> gpio-aggregator - and so we must not put it into bindings nor into
> mainline devicetree sources - having a compatible matching in the
> driver is perfectly fine IMO. Just like gpio-sim.

I already wrote, you cannot have undocumented compatible. There are even
explicit checks for this - in schema and checkpatch - so with your
approach you accept known warnings. Really, no, and fact we need to keep
discussing it:

Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Bartosz Golaszewski]

On Wed, Feb 11, 2026 at 11:49 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 11/02/2026 11:38, Bartosz Golaszewski wrote:
> > On Wed, Feb 11, 2026 at 10:50 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> >>
> >>>>
> >>>>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
> >>>> +       {
> >>>> +               .compatible = "gpio-aggregator",
> >>>> +       },
> >>>>         {
> >>>>                 .compatible = "gpio-delay",
> >>>>                 .data = (void *)FWD_FEATURE_DELAY,
> >>>> --
> >>>> 2.43.0
> >>>>
> >>>
> >>> Regardless of the DT bindings - this change is perfectly fine. We do
> >>> that for other "virtual" devices like gpio-sim, gpio-virtuser, etc. I
> >>> would just ask you to document it under
> >>> Documentation/admin-guide/gpio/gpio-aggregator.rst.
> >>
> >> This is not a pure virtual device, but for use with actual hardware.
> >>
> >> Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>
> >
> > Well, it is a virtual device in that there's no actual "aggregator"
> > device on the board. It virtually aggregates GPIOs into a separate
> > chip for user's convenience. While there's no such device as a
> > gpio-aggregator - and so we must not put it into bindings nor into
> > mainline devicetree sources - having a compatible matching in the
> > driver is perfectly fine IMO. Just like gpio-sim.
>
> I already wrote, you cannot have undocumented compatible. There are even
> explicit checks for this - in schema and checkpatch - so with your
> approach you accept known warnings. Really, no, and fact we need to keep
> discussing it:
>
> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Best regards,
> Krzysztof

Krzysztof disciplined me in private and promised the beatings will
continue until my understanding improves. I retract my statement, this
is of course wrong and NAKed.

Bartosz

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Krzysztof Kozlowski]

On 11/02/2026 10:47, Bartosz Golaszewski wrote:
> On Wed, Feb 11, 2026 at 9:14 AM James Hilliard
> <james.hilliard1@gmail.com> wrote:
>>
>> Add an OF match entry for "gpio-aggregator" to support plain GPIO
>> forwarding from devicetree without delay semantics.
>>
>> This allows exposing selected lines as a logical GPIO controller with
>> stable aggregated offsets, so consumers can reference forwarded lines
>> instead of physical controller offsets. It also allows creating bundled
>> groups of named lines that can be exposed to userspace as a convenient
>> virtual gpiochip interface. Using "gpio-delay" for this case is not
>> suitable because it enables delay features and requires 3-cell GPIO
>> specifiers.
>>
>> Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
>> ---
>> Changes v1 -> v2:
>>   - Split DT schema into a separate patch
>>     (suggested by Krzysztof Kozlowski)
>>   - Expand commit message rationale and use-case explanation
>>     (suggested by Krzysztof Kozlowski)
>>   - Clarify userspace use case with bundled named line groups
>> ---
>>  drivers/gpio/gpio-aggregator.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpio/gpio-aggregator.c b/drivers/gpio/gpio-aggregator.c
>> index 416f265d09d0..a09752fc5fe2 100644
>> --- a/drivers/gpio/gpio-aggregator.c
>> +++ b/drivers/gpio/gpio-aggregator.c
>> @@ -1635,6 +1635,9 @@ static int gpio_aggregator_probe(struct platform_device *pdev)
>>  }
>>
>>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
>> +       {
>> +               .compatible = "gpio-aggregator",
>> +       },
>>         {
>>                 .compatible = "gpio-delay",
>>                 .data = (void *)FWD_FEATURE_DELAY,
>> --
>> 2.43.0
>>
> 
> Regardless of the DT bindings - this change is perfectly fine. We do

You cannot have compatible without DT bindings, so this alone is not
"perfectly fine". Maybe you wanted platform_device_id entry for
ACPI/legacy/MFD devices?

Best regards,
Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Bartosz Golaszewski]

On Wed, Feb 11, 2026 at 11:13 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> >>
> >>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
> >> +       {
> >> +               .compatible = "gpio-aggregator",
> >> +       },
> >>         {
> >>                 .compatible = "gpio-delay",
> >>                 .data = (void *)FWD_FEATURE_DELAY,
> >> --
> >> 2.43.0
> >>
> >
> > Regardless of the DT bindings - this change is perfectly fine. We do
>
> You cannot have compatible without DT bindings, so this alone is not
> "perfectly fine". Maybe you wanted platform_device_id entry for
> ACPI/legacy/MFD devices?
>

Sure you can, you just can't put it into upstream devicetree sources.
We have had a compatible for gpio-sim for testing purposes for years.
Why would it be illegal to enable matching of platform drivers over DT
for testing purposes?

Bartosz

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Krzysztof Kozlowski]

On 11/02/2026 11:36, Bartosz Golaszewski wrote:
> On Wed, Feb 11, 2026 at 11:13 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>>>>
>>>>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
>>>> +       {
>>>> +               .compatible = "gpio-aggregator",
>>>> +       },
>>>>         {
>>>>                 .compatible = "gpio-delay",
>>>>                 .data = (void *)FWD_FEATURE_DELAY,
>>>> --
>>>> 2.43.0
>>>>
>>>
>>> Regardless of the DT bindings - this change is perfectly fine. We do
>>
>> You cannot have compatible without DT bindings, so this alone is not
>> "perfectly fine". Maybe you wanted platform_device_id entry for
>> ACPI/legacy/MFD devices?
>>
> 
> Sure you can, you just can't put it into upstream devicetree sources.

No, you cannot. You cannot have undocumented ABI. That's the rule and
upstream DTS does not matter. ABI is also for non-upstream users.

> We have had a compatible for gpio-sim for testing purposes for years.

And I fixed in it 2024...

> Why would it be illegal to enable matching of platform drivers over DT
> for testing purposes?

You can match. You cannot have undocumented ABI. This is the rule.

Best regards,
Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Krzysztof Kozlowski]

On 11/02/2026 11:42, Krzysztof Kozlowski wrote:
> On 11/02/2026 11:36, Bartosz Golaszewski wrote:
>> On Wed, Feb 11, 2026 at 11:13 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>
>>>>>
>>>>>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
>>>>> +       {
>>>>> +               .compatible = "gpio-aggregator",
>>>>> +       },
>>>>>         {
>>>>>                 .compatible = "gpio-delay",
>>>>>                 .data = (void *)FWD_FEATURE_DELAY,
>>>>> --
>>>>> 2.43.0
>>>>>
>>>>
>>>> Regardless of the DT bindings - this change is perfectly fine. We do
>>>
>>> You cannot have compatible without DT bindings, so this alone is not
>>> "perfectly fine". Maybe you wanted platform_device_id entry for
>>> ACPI/legacy/MFD devices?
>>>
>>
>> Sure you can, you just can't put it into upstream devicetree sources.
> 
> No, you cannot. You cannot have undocumented ABI. That's the rule and
> upstream DTS does not matter. ABI is also for non-upstream users.
> 
>> We have had a compatible for gpio-sim for testing purposes for years.
> 
> And I fixed in it 2024...

Correction:
I fixed other compatibles but gpio-sim was fixed actually by Rob, still
in 2024.

> 
>> Why would it be illegal to enable matching of platform drivers over DT
>> for testing purposes?
> 
> You can match. You cannot have undocumented ABI. This is the rule.
> 
> Best regards,
> Krzysztof


Best regards,
Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Rob Herring]

On Wed, Feb 11, 2026 at 11:36:28AM +0100, Bartosz Golaszewski wrote:
> On Wed, Feb 11, 2026 at 11:13 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > >>
> > >>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
> > >> +       {
> > >> +               .compatible = "gpio-aggregator",
> > >> +       },
> > >>         {
> > >>                 .compatible = "gpio-delay",
> > >>                 .data = (void *)FWD_FEATURE_DELAY,
> > >> --
> > >> 2.43.0
> > >>
> > >
> > > Regardless of the DT bindings - this change is perfectly fine. We do
> >
> > You cannot have compatible without DT bindings, so this alone is not
> > "perfectly fine". Maybe you wanted platform_device_id entry for
> > ACPI/legacy/MFD devices?
> >
> 
> Sure you can, you just can't put it into upstream devicetree sources.
> We have had a compatible for gpio-sim for testing purposes for years.
> Why would it be illegal to enable matching of platform drivers over DT
> for testing purposes?

The primary issue is undocumented ones show up in 'make 
dt_compatible_check'. I would like that to be warning free.

Rob

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[James Hilliard]

On Wed, Feb 11, 2026 at 2:47 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Feb 11, 2026 at 11:36:28AM +0100, Bartosz Golaszewski wrote:
> > On Wed, Feb 11, 2026 at 11:13 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > >>
> > > >>  static const struct of_device_id gpio_aggregator_dt_ids[] = {
> > > >> +       {
> > > >> +               .compatible = "gpio-aggregator",
> > > >> +       },
> > > >>         {
> > > >>                 .compatible = "gpio-delay",
> > > >>                 .data = (void *)FWD_FEATURE_DELAY,
> > > >> --
> > > >> 2.43.0
> > > >>
> > > >
> > > > Regardless of the DT bindings - this change is perfectly fine. We do
> > >
> > > You cannot have compatible without DT bindings, so this alone is not
> > > "perfectly fine". Maybe you wanted platform_device_id entry for
> > > ACPI/legacy/MFD devices?
> > >
> >
> > Sure you can, you just can't put it into upstream devicetree sources.
> > We have had a compatible for gpio-sim for testing purposes for years.
> > Why would it be illegal to enable matching of platform drivers over DT
> > for testing purposes?
>
> The primary issue is undocumented ones show up in 'make
> dt_compatible_check'. I would like that to be warning free.

Would adding it here make sense?
https://github.com/torvalds/linux/blob/v6.19/Documentation/devicetree/bindings/incomplete-devices.yaml#L243-L245

>
> Rob

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Krzysztof Kozlowski]

On 11/02/2026 22:49, James Hilliard wrote:
>>>>>
>>>>> Regardless of the DT bindings - this change is perfectly fine. We do
>>>>
>>>> You cannot have compatible without DT bindings, so this alone is not
>>>> "perfectly fine". Maybe you wanted platform_device_id entry for
>>>> ACPI/legacy/MFD devices?
>>>>
>>>
>>> Sure you can, you just can't put it into upstream devicetree sources.
>>> We have had a compatible for gpio-sim for testing purposes for years.
>>> Why would it be illegal to enable matching of platform drivers over DT
>>> for testing purposes?
>>
>> The primary issue is undocumented ones show up in 'make
>> dt_compatible_check'. I would like that to be warning free.
> 
> Would adding it here make sense?
> https://github.com/torvalds/linux/blob/v6.19/Documentation/devicetree/bindings/incomplete-devices.yaml#L243-L245

What would you like to achieve with that? The binding patch did not have
rationale why do we want it and here is the same question - what sort of
problem is being solved by adding it to incomplete (so wrong) devices?


Best regards,
Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[James Hilliard]

On Thu, Feb 12, 2026 at 12:18 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 11/02/2026 22:49, James Hilliard wrote:
> >>>>>
> >>>>> Regardless of the DT bindings - this change is perfectly fine. We do
> >>>>
> >>>> You cannot have compatible without DT bindings, so this alone is not
> >>>> "perfectly fine". Maybe you wanted platform_device_id entry for
> >>>> ACPI/legacy/MFD devices?
> >>>>
> >>>
> >>> Sure you can, you just can't put it into upstream devicetree sources.
> >>> We have had a compatible for gpio-sim for testing purposes for years.
> >>> Why would it be illegal to enable matching of platform drivers over DT
> >>> for testing purposes?
> >>
> >> The primary issue is undocumented ones show up in 'make
> >> dt_compatible_check'. I would like that to be warning free.
> >
> > Would adding it here make sense?
> > https://github.com/torvalds/linux/blob/v6.19/Documentation/devicetree/bindings/incomplete-devices.yaml#L243-L245
>
> What would you like to achieve with that? The binding patch did not have
> rationale why do we want it and here is the same question - what sort of
> problem is being solved by adding it to incomplete (so wrong) devices?

See details for what I'm trying to accomplish with gpio-aggregator:
https://lore.kernel.org/all/CADvTj4oBtO0Yhib1rE8QQwgtJvy-x_hK46C63mjVAydtxHOV8g@mail.gmail.com/

I'm basically trying to use it for the reasons described here:
https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/

Is there a different device tree mechanism that can be used to
name individual gpio lines on a gpiochip without having to name
all of them for non-hog lines?

I'm confused why a "gpio-delay" compatible is allowed but one
without the delay param is not?

Or is the issue just with the name of the compatible I used being
called "gpio-aggregator"?

> This is not a pure virtual device, but for use with actual hardware.
>
> Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>

I'm trying to use this with actual hardware, I just called it "virtual"
because that's how it was described in the bootlin blog post.

I'm confused about what the issue is here as "gpio-delay" is also
a virtual device in the same way.

> Well, it is a virtual device in that there's no actual "aggregator"
> device on the board. It virtually aggregates GPIOs into a separate
> chip for user's convenience. While there's no such device as a
> gpio-aggregator - and so we must not put it into bindings nor into
> mainline devicetree sources - having a compatible matching in the
> driver is perfectly fine IMO. Just like gpio-sim.

There's no such "gpio-delay" device either right? I'm confused
why that compatible can exist but one without the delay param can
not in the mainline sources. Aren't they both virtual devices?

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Krzysztof Kozlowski]

On 12/02/2026 20:16, James Hilliard wrote:
> On Thu, Feb 12, 2026 at 12:18 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 11/02/2026 22:49, James Hilliard wrote:
>>>>>>>
>>>>>>> Regardless of the DT bindings - this change is perfectly fine. We do
>>>>>>
>>>>>> You cannot have compatible without DT bindings, so this alone is not
>>>>>> "perfectly fine". Maybe you wanted platform_device_id entry for
>>>>>> ACPI/legacy/MFD devices?
>>>>>>
>>>>>
>>>>> Sure you can, you just can't put it into upstream devicetree sources.
>>>>> We have had a compatible for gpio-sim for testing purposes for years.
>>>>> Why would it be illegal to enable matching of platform drivers over DT
>>>>> for testing purposes?
>>>>
>>>> The primary issue is undocumented ones show up in 'make
>>>> dt_compatible_check'. I would like that to be warning free.
>>>
>>> Would adding it here make sense?
>>> https://github.com/torvalds/linux/blob/v6.19/Documentation/devicetree/bindings/incomplete-devices.yaml#L243-L245
>>
>> What would you like to achieve with that? The binding patch did not have
>> rationale why do we want it and here is the same question - what sort of
>> problem is being solved by adding it to incomplete (so wrong) devices?
> 
> See details for what I'm trying to accomplish with gpio-aggregator:
> https://lore.kernel.org/all/CADvTj4oBtO0Yhib1rE8QQwgtJvy-x_hK46C63mjVAydtxHOV8g@mail.gmail.com/

I don't think that putting it into incomplete-devices would help you. I
assume you read the binding... You still could not use that compatible
in any upstreamable DTS code, even if this is only an overlay. You would
have warnings...

> 
> I'm basically trying to use it for the reasons described here:
> https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/
> 
> Is there a different device tree mechanism that can be used to
> name individual gpio lines on a gpiochip without having to name
> all of them for non-hog lines?
> 
> I'm confused why a "gpio-delay" compatible is allowed but one
> without the delay param is not?
> 
> Or is the issue just with the name of the compatible I used being
> called "gpio-aggregator"?

No, the issue is that there is no hardware you are trying represent in DTS.

> 
>> This is not a pure virtual device, but for use with actual hardware.
>>
>> Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> I'm trying to use this with actual hardware, I just called it "virtual"
> because that's how it was described in the bootlin blog post.
> 
> I'm confused about what the issue is here as "gpio-delay" is also
> a virtual device in the same way.

gpio-delay IS NOT a virtual device. You can even touch it. Can I touch
your gpio-aggregator?

> 
>> Well, it is a virtual device in that there's no actual "aggregator"
>> device on the board. It virtually aggregates GPIOs into a separate
>> chip for user's convenience. While there's no such device as a
>> gpio-aggregator - and so we must not put it into bindings nor into
>> mainline devicetree sources - having a compatible matching in the
>> driver is perfectly fine IMO. Just like gpio-sim.
> 
> There's no such "gpio-delay" device either right? I'm confused

There is.

> why that compatible can exist but one without the delay param can
> not in the mainline sources. Aren't they both virtual devices?


Best regards,
Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[James Hilliard]

On Fri, Feb 13, 2026 at 12:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 12/02/2026 20:16, James Hilliard wrote:
> > On Thu, Feb 12, 2026 at 12:18 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On 11/02/2026 22:49, James Hilliard wrote:
> >>>>>>>
> >>>>>>> Regardless of the DT bindings - this change is perfectly fine. We do
> >>>>>>
> >>>>>> You cannot have compatible without DT bindings, so this alone is not
> >>>>>> "perfectly fine". Maybe you wanted platform_device_id entry for
> >>>>>> ACPI/legacy/MFD devices?
> >>>>>>
> >>>>>
> >>>>> Sure you can, you just can't put it into upstream devicetree sources.
> >>>>> We have had a compatible for gpio-sim for testing purposes for years.
> >>>>> Why would it be illegal to enable matching of platform drivers over DT
> >>>>> for testing purposes?
> >>>>
> >>>> The primary issue is undocumented ones show up in 'make
> >>>> dt_compatible_check'. I would like that to be warning free.
> >>>
> >>> Would adding it here make sense?
> >>> https://github.com/torvalds/linux/blob/v6.19/Documentation/devicetree/bindings/incomplete-devices.yaml#L243-L245
> >>
> >> What would you like to achieve with that? The binding patch did not have
> >> rationale why do we want it and here is the same question - what sort of
> >> problem is being solved by adding it to incomplete (so wrong) devices?
> >
> > See details for what I'm trying to accomplish with gpio-aggregator:
> > https://lore.kernel.org/all/CADvTj4oBtO0Yhib1rE8QQwgtJvy-x_hK46C63mjVAydtxHOV8g@mail.gmail.com/
>
> I don't think that putting it into incomplete-devices would help you. I
> assume you read the binding... You still could not use that compatible
> in any upstreamable DTS code, even if this is only an overlay. You would
> have warnings...
>
> >
> > I'm basically trying to use it for the reasons described here:
> > https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/
> >
> > Is there a different device tree mechanism that can be used to
> > name individual gpio lines on a gpiochip without having to name
> > all of them for non-hog lines?
> >
> > I'm confused why a "gpio-delay" compatible is allowed but one
> > without the delay param is not?
> >
> > Or is the issue just with the name of the compatible I used being
> > called "gpio-aggregator"?
>
> No, the issue is that there is no hardware you are trying represent in DTS.

I'm trying to represent the physical board GPIO pin connections in
DTS...so representing hardware is exactly what I'm trying to do AFAIU.

>
> >
> >> This is not a pure virtual device, but for use with actual hardware.
> >>
> >> Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > I'm trying to use this with actual hardware, I just called it "virtual"
> > because that's how it was described in the bootlin blog post.
> >
> > I'm confused about what the issue is here as "gpio-delay" is also
> > a virtual device in the same way.
>
> gpio-delay IS NOT a virtual device. You can even touch it. Can I touch
> your gpio-aggregator?

Sure I guess, the gpio-aggregator would be used to say define the
physical GPIO lines for exposed peripheral connectors in my case.

>
> >
> >> Well, it is a virtual device in that there's no actual "aggregator"
> >> device on the board. It virtually aggregates GPIOs into a separate
> >> chip for user's convenience. While there's no such device as a
> >> gpio-aggregator - and so we must not put it into bindings nor into
> >> mainline devicetree sources - having a compatible matching in the
> >> driver is perfectly fine IMO. Just like gpio-sim.
> >
> > There's no such "gpio-delay" device either right? I'm confused
>
> There is.

I'm not really seeing the difference, both are used to describe
physical circuit layouts, the only difference is a delay configuration
AFAIU.

Should the compatible be named something like "gpio-connector" or
something else to indicate it's for describing physical connections.

>
> > why that compatible can exist but one without the delay param can
> > not in the mainline sources. Aren't they both virtual devices?
>
>
> Best regards,
> Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Krzysztof Kozlowski]

On 13/02/2026 09:02, James Hilliard wrote:
> On Fri, Feb 13, 2026 at 12:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 12/02/2026 20:16, James Hilliard wrote:
>>> On Thu, Feb 12, 2026 at 12:18 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>
>>>> On 11/02/2026 22:49, James Hilliard wrote:
>>>>>>>>>
>>>>>>>>> Regardless of the DT bindings - this change is perfectly fine. We do
>>>>>>>>
>>>>>>>> You cannot have compatible without DT bindings, so this alone is not
>>>>>>>> "perfectly fine". Maybe you wanted platform_device_id entry for
>>>>>>>> ACPI/legacy/MFD devices?
>>>>>>>>
>>>>>>>
>>>>>>> Sure you can, you just can't put it into upstream devicetree sources.
>>>>>>> We have had a compatible for gpio-sim for testing purposes for years.
>>>>>>> Why would it be illegal to enable matching of platform drivers over DT
>>>>>>> for testing purposes?
>>>>>>
>>>>>> The primary issue is undocumented ones show up in 'make
>>>>>> dt_compatible_check'. I would like that to be warning free.
>>>>>
>>>>> Would adding it here make sense?
>>>>> https://github.com/torvalds/linux/blob/v6.19/Documentation/devicetree/bindings/incomplete-devices.yaml#L243-L245
>>>>
>>>> What would you like to achieve with that? The binding patch did not have
>>>> rationale why do we want it and here is the same question - what sort of
>>>> problem is being solved by adding it to incomplete (so wrong) devices?
>>>
>>> See details for what I'm trying to accomplish with gpio-aggregator:
>>> https://lore.kernel.org/all/CADvTj4oBtO0Yhib1rE8QQwgtJvy-x_hK46C63mjVAydtxHOV8g@mail.gmail.com/
>>
>> I don't think that putting it into incomplete-devices would help you. I
>> assume you read the binding... You still could not use that compatible
>> in any upstreamable DTS code, even if this is only an overlay. You would
>> have warnings...
>>
>>>
>>> I'm basically trying to use it for the reasons described here:
>>> https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/
>>>
>>> Is there a different device tree mechanism that can be used to
>>> name individual gpio lines on a gpiochip without having to name
>>> all of them for non-hog lines?
>>>
>>> I'm confused why a "gpio-delay" compatible is allowed but one
>>> without the delay param is not?
>>>
>>> Or is the issue just with the name of the compatible I used being
>>> called "gpio-aggregator"?
>>
>> No, the issue is that there is no hardware you are trying represent in DTS.
> 
> I'm trying to represent the physical board GPIO pin connections in
> DTS...so representing hardware is exactly what I'm trying to do AFAIU.


Sure, then please show me some sort of picture of the board/circuit or
piece of schematics with visible aggregator, if you claim this is the
hardware you represent.

You can also (as exception) send it to me in private, without leaking to
mailing list.

> 
>>
>>>
>>>> This is not a pure virtual device, but for use with actual hardware.
>>>>
>>>> Nacked-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>
>>> I'm trying to use this with actual hardware, I just called it "virtual"
>>> because that's how it was described in the bootlin blog post.
>>>
>>> I'm confused about what the issue is here as "gpio-delay" is also
>>> a virtual device in the same way.
>>
>> gpio-delay IS NOT a virtual device. You can even touch it. Can I touch
>> your gpio-aggregator?
> 
> Sure I guess, the gpio-aggregator would be used to say define the
> physical GPIO lines for exposed peripheral connectors in my case.
> 
>>
>>>
>>>> Well, it is a virtual device in that there's no actual "aggregator"
>>>> device on the board. It virtually aggregates GPIOs into a separate
>>>> chip for user's convenience. While there's no such device as a
>>>> gpio-aggregator - and so we must not put it into bindings nor into
>>>> mainline devicetree sources - having a compatible matching in the
>>>> driver is perfectly fine IMO. Just like gpio-sim.
>>>
>>> There's no such "gpio-delay" device either right? I'm confused
>>
>> There is.
> 
> I'm not really seeing the difference, both are used to describe
> physical circuit layouts, the only difference is a delay configuration
> AFAIU.

I explained you the difference, so again, can you touch gpio-delay? Yes.

Can you touch gpio-aggregator? No (that's my claim, but I wait for
picture of the circuit I can touch).

> 
> Should the compatible be named something like "gpio-connector" or
> something else to indicate it's for describing physical connections.

Rob and Geert already pointed you towards the connector work and this
might solve your case.

Best regards,
Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Herve Codina]

Hi all,

On Fri, 13 Feb 2026 08:31:21 +0100
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> > 
> > Or is the issue just with the name of the compatible I used being
> > called "gpio-aggregator"?  
> 
> No, the issue is that there is no hardware you are trying represent in DTS.

Except if you have a piece of hardware that invert the gpio line.

In that case you need to set GPIO_ACTIVE_LOW somewhere.

The aggregator allows to describe this line inverter.

Of course, if the gpio is connected to a hardware component handled by the
kernel, the DT node describing this hardware can set the flag.

The issue is for GPIOs that are just GPIOs and should by a user-space
application as GPIOs.

Some bindings exist for GPIO and do not describe the hardware but the
feature. For instance:
https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/trigger-source/gpio-trigger.yaml
https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml

Can we consider the gpio-aggregator describing the wires that should be
grouped together.

Industrial board can have some GPIOs grouped together and used as inputs or
ouputs of this industrial board.

As output they command an external system. As input, they get feedback from
this system.

gpio-aggregator describes those lines.

In that sense, it describes hardware.
Maybe the "gpio-aggregator" name doesn't reflect that and a compatible such as
"gpio-equipment" could make sense.


Best regards,
Hervé

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[Krzysztof Kozlowski]

On 13/02/2026 09:29, Herve Codina wrote:
> Hi all,
> 
> On Fri, 13 Feb 2026 08:31:21 +0100
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
>>>
>>> Or is the issue just with the name of the compatible I used being
>>> called "gpio-aggregator"?  
>>
>> No, the issue is that there is no hardware you are trying represent in DTS.
> 
> Except if you have a piece of hardware that invert the gpio line.
> 
> In that case you need to set GPIO_ACTIVE_LOW somewhere.
> 
> The aggregator allows to describe this line inverter.

Of course. And then you could touch that piece of hardware and use it as
an argument here, where I asked show me the piece of hardware being
described.

Anyway, we encode the inverters in the final GPIO flags.

> 
> Of course, if the gpio is connected to a hardware component handled by the
> kernel, the DT node describing this hardware can set the flag.
> 
> The issue is for GPIOs that are just GPIOs and should by a user-space
> application as GPIOs.
> 
> Some bindings exist for GPIO and do not describe the hardware but the
> feature. For instance:
> https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/trigger-source/gpio-trigger.yaml
> https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
> https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml
> 
> Can we consider the gpio-aggregator describing the wires that should be
> grouped together.

No, because the grouping depends on user-space choice (as explained by
the author).

> 
> Industrial board can have some GPIOs grouped together and used as inputs or
> ouputs of this industrial board.
> 
> As output they command an external system. As input, they get feedback from
> this system.
> 
> gpio-aggregator describes those lines.
> 
> In that sense, it describes hardware.
> Maybe the "gpio-aggregator" name doesn't reflect that and a compatible such as
> "gpio-equipment" could make sense.

What is a "GPIO grouped together"? The moment such grouping does not
depend on hardware characteristics, it's the moment it is purely
arbitrary choice thus not suitable for DT.

Comparison to gpio-restart where you have actual component, receiving a
fixed line and then doing restart is not appropriate.


Best regards,
Krzysztof

Re: [PATCH v2 2/2] gpio: aggregator: add gpio-aggregator DT compatible

[James Hilliard]

On Fri, Feb 13, 2026 at 1:49 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 13/02/2026 09:29, Herve Codina wrote:
> > Hi all,
> >
> > On Fri, 13 Feb 2026 08:31:21 +0100
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> >>>
> >>> Or is the issue just with the name of the compatible I used being
> >>> called "gpio-aggregator"?
> >>
> >> No, the issue is that there is no hardware you are trying represent in DTS.
> >
> > Except if you have a piece of hardware that invert the gpio line.
> >
> > In that case you need to set GPIO_ACTIVE_LOW somewhere.
> >
> > The aggregator allows to describe this line inverter.
>
> Of course. And then you could touch that piece of hardware and use it as
> an argument here, where I asked show me the piece of hardware being
> described.
>
> Anyway, we encode the inverters in the final GPIO flags.
>
> >
> > Of course, if the gpio is connected to a hardware component handled by the
> > kernel, the DT node describing this hardware can set the flag.
> >
> > The issue is for GPIOs that are just GPIOs and should by a user-space
> > application as GPIOs.
> >
> > Some bindings exist for GPIO and do not describe the hardware but the
> > feature. For instance:
> > https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/trigger-source/gpio-trigger.yaml
> > https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
> > https://elixir.bootlin.com/linux/v6.18/source/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml
> >
> > Can we consider the gpio-aggregator describing the wires that should be
> > grouped together.
>
> No, because the grouping depends on user-space choice (as explained by
> the author).

More like the grouping would be used to better represent the actual
physical connectors to userspace. I'm not really sure why this would
be so much a user-space choice as the grouping would be aligned
with the physical hardware connections still.

>
> >
> > Industrial board can have some GPIOs grouped together and used as inputs or
> > ouputs of this industrial board.
> >
> > As output they command an external system. As input, they get feedback from
> > this system.
> >
> > gpio-aggregator describes those lines.
> >
> > In that sense, it describes hardware.
> > Maybe the "gpio-aggregator" name doesn't reflect that and a compatible such as
> > "gpio-equipment" could make sense.
>
> What is a "GPIO grouped together"? The moment such grouping does not
> depend on hardware characteristics, it's the moment it is purely
> arbitrary choice thus not suitable for DT.

The groupings would be things like the physical ribbon cable connectors
the peripheral boards plug into for my case. So it would still depend on
the hardware characteristics(i.e. the line to ribbon cable connector routing
and such for the control card subvariant).

I came up with another approach(which could also be used in
combination with an aggregator approach or independently) to better
describe and configure the GPIO lines for use by userspace as well:
https://lore.kernel.org/linux-gpio/20260213223204.2415507-1-james.hilliard1@gmail.com/

> Comparison to gpio-restart where you have actual component, receiving a
> fixed line and then doing restart is not appropriate.
>
>
> Best regards,
> Krzysztof

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

[Krzysztof Kozlowski]

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>


Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

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.

Best regards,
Krzysztof

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

[James Hilliard]

On Wed, Feb 11, 2026 at 1:19 AM Krzysztof Kozlowski <krzk@kernel.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
virtual gpio driver though so AFAIU it's not hardware specific.

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

>
> Best regards,
> Krzysztof

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

[Krzysztof Kozlowski]

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

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

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

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.


Best regards,
Krzysztof

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

[James Hilliard]

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

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

[Geert Uytterhoeven]

Hi James,

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

Sounds like the work being done in "[RFC PATCH 00/77] Add support for
dtb metadata and addon device-trees" [1] can be helpful for you, too.

[1] https://lore.kernel.org/20260112142009.1006236-1-herve.codina@bootlin.com

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[James Hilliard]

On Thu, Feb 12, 2026 at 7:50 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi James,
>
> On Wed, 11 Feb 2026 at 18:01, James Hilliard <james.hilliard1@gmail.com> wrote:
> > On Wed, Feb 11, 2026 at 1:44 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > On 11/02/2026 09:28, James Hilliard wrote:
> > > > 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.
>
> Sounds like the work being done in "[RFC PATCH 00/77] Add support for
> dtb metadata and addon device-trees" [1] can be helpful for you, too.

I think I came across this as well, it did look potentially useful for
moving hardware variant device detection out of uboot, but doesn't
really seem to help with the gpio-line-names definition problem
that I was trying to solve with the gpio-aggregator.

The hardware I'm working with isn't really designed for runtime
hotplugging but the eeprom based detection could be useful
it seems(currently that's mostly done in userspace logic for the
peripheral boards). The line naming is more for dealing with
control card variant detection so that I can pass line names to
a username application via device tree.

Even defining line names for boards without overlays or any
runtime detection seems to require a ridiculous amount of ""
placeholders at the moment, i.e.:
https://github.com/torvalds/linux/blob/v6.19/arch/arm/boot/dts/allwinner/sun7i-a20-bananapi.dts#L227-L276

Is there any work going on to allow offset based gpio-line-names
definitions so that it's not required to set all gpio-line-names at the
same time(essentially making individual line name overrides
in either device tree includes/overlays impossible)?


>
> [1] https://lore.kernel.org/20260112142009.1006236-1-herve.codina@bootlin.com
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

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

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

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

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

[Geert Uytterhoeven]

Hi James,

On Thu, 12 Feb 2026 at 22:22, James Hilliard <james.hilliard1@gmail.com> wrote:
> On Thu, Feb 12, 2026 at 12:54 PM Rob Herring <robh@kernel.org> wrote:
> > 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.

Different controller hardware revisions with different wiring mean
different DTS/DTB files anyway, right?

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

Yes it is.

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

That would depend on the SoC: some SoCs have a single bank,
others have multiple banks. The more generic is supported, the better.

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

Why in the overlay? If the controller hardware differs in wiring,
it needs a different DTS/DTB.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[James Hilliard]

On Fri, Feb 13, 2026 at 1:25 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi James,
>
> On Thu, 12 Feb 2026 at 22:22, James Hilliard <james.hilliard1@gmail.com> wrote:
> > On Thu, Feb 12, 2026 at 12:54 PM Rob Herring <robh@kernel.org> wrote:
> > > 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.
>
> Different controller hardware revisions with different wiring mean
> different DTS/DTB files anyway, right?

Just different dtso files, the primary dts can be the same since the
board designs are similar enough.

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

Oh, where in the mainline kernel is the code for it? I searched and
couldn't find any references to it.

>
> > In my device everything I'm wanting to name is off the same gpiochip.
>
> That would depend on the SoC: some SoCs have a single bank,
> others have multiple banks. The more generic is supported, the better.
>
> > > 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?
>
> Why in the overlay? If the controller hardware differs in wiring,
> it needs a different DTS/DTB.

The differences are relatively minor so creating separate DTS
files for each subversion of the control board doesn't seem ideal,
I use a unified dts for both uboot and linux and only apply
overlays when loading linux as uboot doesn't really care about
the minor differences as uboot doesn't really do anything with
the hardware on those lines.

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

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

[Geert Uytterhoeven]

Hi James,

On Fri, 13 Feb 2026 at 19:34, James Hilliard <james.hilliard1@gmail.com> wrote:
> On Fri, Feb 13, 2026 at 1:25 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, 12 Feb 2026 at 22:22, James Hilliard <james.hilliard1@gmail.com> wrote:
> > > This gpio-map feature doesn't exist in the mainline kernel does it?
> >
> > Yes it is.
>
> Oh, where in the mainline kernel is the code for it? I searched and
> couldn't find any references to it.

git grep -w of_parse_phandle_with_args_map

Note that that does not find interrupt nexi, as that code doesn't use the
of_parse_phandle_with_args_map() helper (perhaps it should?).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Linus Walleij]

On Mon, Feb 16, 2026 at 10:06 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, 13 Feb 2026 at 19:34, James Hilliard <james.hilliard1@gmail.com> wrote:
> > On Fri, Feb 13, 2026 at 1:25 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Thu, 12 Feb 2026 at 22:22, James Hilliard <james.hilliard1@gmail.com> wrote:
> > > > This gpio-map feature doesn't exist in the mainline kernel does it?
> > >
> > > Yes it is.
> >
> > Oh, where in the mainline kernel is the code for it? I searched and
> > couldn't find any references to it.
>
> git grep -w of_parse_phandle_with_args_map
>
> Note that that does not find interrupt nexi, as that code doesn't use the
> of_parse_phandle_with_args_map() helper (perhaps it should?).

I doubt interrupts on nexi works. Which may be a reason they
are not used very much.

And as such it would be pretty half-baked wouldn't it...

Probably Geert's suggestion to use the aggregator is a better
idea.

Yours,
Linus Walleij

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

[Rob Herring]

On Thu, Feb 19, 2026 at 12:00 PM Linus Walleij <linusw@kernel.org> wrote:
>
> On Mon, Feb 16, 2026 at 10:06 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Fri, 13 Feb 2026 at 19:34, James Hilliard <james.hilliard1@gmail.com> wrote:
> > > On Fri, Feb 13, 2026 at 1:25 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Thu, 12 Feb 2026 at 22:22, James Hilliard <james.hilliard1@gmail.com> wrote:
> > > > > This gpio-map feature doesn't exist in the mainline kernel does it?
> > > >
> > > > Yes it is.
> > >
> > > Oh, where in the mainline kernel is the code for it? I searched and
> > > couldn't find any references to it.
> >
> > git grep -w of_parse_phandle_with_args_map
> >
> > Note that that does not find interrupt nexi, as that code doesn't use the
> > of_parse_phandle_with_args_map() helper (perhaps it should?).
>
> I doubt interrupts on nexi works. Which may be a reason they
> are not used very much.

interrupt-map should work just fine. It's only existed since the
1990s. And yes, you need both gpio-map and interrupt-map if your GPIOs
also support interrupts. However, it won't work with
of_parse_phandle_with_args_map() because of the tie-in with
#address-cells and other historical quirks, but that would only ever
be an internal implementation detail. The standard interrupt APIs
should be used and will all just work.

>
> And as such it would be pretty half-baked wouldn't it...
>
> Probably Geert's suggestion to use the aggregator is a better
> idea.

I don't know what that is to comment. (Please don't reply with "you
reviewed it" unless it was more recent than last week. :) )

Rob

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

[Linus Walleij]

On Thu, Feb 19, 2026 at 7:29 PM Rob Herring <robh@kernel.org> wrote:
> On Thu, Feb 19, 2026 at 12:00 PM Linus Walleij <linusw@kernel.org> wrote:

> > And as such it would be pretty half-baked wouldn't it...
> >
> > Probably Geert's suggestion to use the aggregator is a better
> > idea.
>
> I don't know what that is to comment. (Please don't reply with "you
> reviewed it" unless it was more recent than last week. :) )

I only think it's half-baked if IRQs don't work and you say they
do with the right interrupt-map so that's all fine.

I'd say James have a go at gpio-map + interrupt-map for external
connectors and see how that works.

It will certainly be more lightweight.

Yours,
Linus Walleij

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

[James Hilliard]

On Thu, Feb 19, 2026 at 3:14 PM Linus Walleij <linusw@kernel.org> wrote:
>
> On Thu, Feb 19, 2026 at 7:29 PM Rob Herring <robh@kernel.org> wrote:
> > On Thu, Feb 19, 2026 at 12:00 PM Linus Walleij <linusw@kernel.org> wrote:
>
> > > And as such it would be pretty half-baked wouldn't it...
> > >
> > > Probably Geert's suggestion to use the aggregator is a better
> > > idea.
> >
> > I don't know what that is to comment. (Please don't reply with "you
> > reviewed it" unless it was more recent than last week. :) )
>
> I only think it's half-baked if IRQs don't work and you say they
> do with the right interrupt-map so that's all fine.
>
> I'd say James have a go at gpio-map + interrupt-map for external
> connectors and see how that works.

From my testing, gpio-map does not allow renaming lines.

>
> It will certainly be more lightweight.
>
> Yours,
> Linus Walleij

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

[Linus Walleij]

On Thu, Feb 19, 2026 at 11:29 PM James Hilliard
<james.hilliard1@gmail.com> wrote:

> From my testing, gpio-map does not allow renaming lines.

Right, so that is something the aggregator will actually do since it
creates a whole new GPIO chip.

That feels iffy though because aggregator is really heavyweight and was never
used for this purpose (it's more of a GPIO counterpart to a hierarchical
interrupt chip) and the gpio/interrupt-map nexus is really lightweight.

Yours,
Linus Walleij

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

[James Hilliard]

On Thu, Feb 19, 2026 at 4:00 PM Linus Walleij <linusw@kernel.org> wrote:
>
> On Thu, Feb 19, 2026 at 11:29 PM James Hilliard
> <james.hilliard1@gmail.com> wrote:
>
> > From my testing, gpio-map does not allow renaming lines.
>
> Right, so that is something the aggregator will actually do since it
> creates a whole new GPIO chip.
>
> That feels iffy though because aggregator is really heavyweight and was never
> used for this purpose (it's more of a GPIO counterpart to a hierarchical
> interrupt chip) and the gpio/interrupt-map nexus is really lightweight.

That's one reason I came up with the gpio-line alternative method
of configuring line names using a line specific "gpio-line-name".

>
> Yours,
> Linus Walleij

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

[Rob Herring]

On Thu, Feb 19, 2026 at 4:29 PM James Hilliard
<james.hilliard1@gmail.com> wrote:
>
> On Thu, Feb 19, 2026 at 3:14 PM Linus Walleij <linusw@kernel.org> wrote:
> >
> > On Thu, Feb 19, 2026 at 7:29 PM Rob Herring <robh@kernel.org> wrote:
> > > On Thu, Feb 19, 2026 at 12:00 PM Linus Walleij <linusw@kernel.org> wrote:
> >
> > > > And as such it would be pretty half-baked wouldn't it...
> > > >
> > > > Probably Geert's suggestion to use the aggregator is a better
> > > > idea.
> > >
> > > I don't know what that is to comment. (Please don't reply with "you
> > > reviewed it" unless it was more recent than last week. :) )
> >
> > I only think it's half-baked if IRQs don't work and you say they
> > do with the right interrupt-map so that's all fine.
> >
> > I'd say James have a go at gpio-map + interrupt-map for external
> > connectors and see how that works.
>
> From my testing, gpio-map does not allow renaming lines.

I'm pretty sure I said that already. There's no reason we can't
support gpio-line-names alongside a gpio-map property. Whether the
kernel supports that or not is not my problem (as DT maintainer).

Rob

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

[James Hilliard]

On Thu, Feb 19, 2026 at 4:12 PM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Feb 19, 2026 at 4:29 PM James Hilliard
> <james.hilliard1@gmail.com> wrote:
> >
> > On Thu, Feb 19, 2026 at 3:14 PM Linus Walleij <linusw@kernel.org> wrote:
> > >
> > > On Thu, Feb 19, 2026 at 7:29 PM Rob Herring <robh@kernel.org> wrote:
> > > > On Thu, Feb 19, 2026 at 12:00 PM Linus Walleij <linusw@kernel.org> wrote:
> > >
> > > > > And as such it would be pretty half-baked wouldn't it...
> > > > >
> > > > > Probably Geert's suggestion to use the aggregator is a better
> > > > > idea.
> > > >
> > > > I don't know what that is to comment. (Please don't reply with "you
> > > > reviewed it" unless it was more recent than last week. :) )
> > >
> > > I only think it's half-baked if IRQs don't work and you say they
> > > do with the right interrupt-map so that's all fine.
> > >
> > > I'd say James have a go at gpio-map + interrupt-map for external
> > > connectors and see how that works.
> >
> > From my testing, gpio-map does not allow renaming lines.
>
> I'm pretty sure I said that already. There's no reason we can't
> support gpio-line-names alongside a gpio-map property. Whether the
> kernel supports that or not is not my problem (as DT maintainer).

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.

>
> Rob

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

[Linus Walleij]

On Fri, Feb 20, 2026 at 5:57 AM James Hilliard
<james.hilliard1@gmail.com> 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.

Yours,
Linus Walleij

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@kernel.org> wrote:
>
> On Fri, Feb 20, 2026 at 5:57 AM James Hilliard
> <james.hilliard1@gmail.com> 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

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@gmail.com> wrote:
>
> On Thu, Feb 12, 2026 at 12:54 PM Rob Herring <robh@kernel.org> 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@kernel.org> wrote:
> > > >
> > > > On 11/02/2026 09:28, James Hilliard wrote:
> > > > > On Wed, Feb 11, 2026 at 1:19 AM Krzysztof Kozlowski <krzk@kernel.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.
> >
> > 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

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

[James Hilliard]

On Fri, Feb 13, 2026 at 7:34 AM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Feb 12, 2026 at 3:22 PM James Hilliard
> <james.hilliard1@gmail.com> wrote:
> >
> > On Thu, Feb 12, 2026 at 12:54 PM Rob Herring <robh@kernel.org> 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@kernel.org> wrote:
> > > > >
> > > > > On 11/02/2026 09:28, James Hilliard wrote:
> > > > > > On Wed, Feb 11, 2026 at 1:19 AM Krzysztof Kozlowski <krzk@kernel.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.
> > >
> > > 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.

Mostly the base board at the moment, the peripheral boards tend
to be more similar in terms of GPIO configuration despite having more
subvariants.

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

Yeah, I gave that a try but it was problematic, gpio-map also
needs an in kernel consumer to do anything which is not ideal
if one wants the effective consumer to be in userspace in some
cases.

I experimented and came up with an entirely different approach,
I added a gpio-line that's configured like a gpio-hog and then added
a gpio-line-name override property to that, this seems to allow
for setting up the lines for userspace handling and allows for setting
individual line nodes from multiple overlays for the same controller:
https://lore.kernel.org/linux-gpio/20260213223204.2415507-1-james.hilliard1@gmail.com/

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

I'm thinking my gpio-line approach may be a better way to describe
the lines, it also lets one describe the initial GPIO state before
userspace has a chance to touch the lines.

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

Would a connector driver require moving all driver logic to
the kernel? Or would it allow for hybrid architectures like mine
where userspace retains significant control?

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

I just mean the device tree configures the names the kernel exposes
to userspace, so from the userspace point of view it's the kernel that
provides the GPIO mappings in that case.

>
> Rob

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

[Geert Uytterhoeven]

Hi James,

On Fri, 13 Feb 2026 at 23:56, James Hilliard <james.hilliard1@gmail.com> wrote:
> On Fri, Feb 13, 2026 at 7:34 AM Rob Herring <robh@kernel.org> wrote:
> > On Thu, Feb 12, 2026 at 3:22 PM James Hilliard
> > <james.hilliard1@gmail.com> wrote:
> > > 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.
>
> Would a connector driver require moving all driver logic to
> the kernel? Or would it allow for hybrid architectures like mine
> where userspace retains significant control?

That is up to the driver.

BTW, if you connector uses only GPIOs, you can already use the GPIO aggregator:
1. Write DT bindings for your connector, with a real compatible value,
2. Add the real compatible value to gpio_aggregator_dt_ids[].

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Linus Walleij]

On Fri, Feb 13, 2026 at 3:34 PM Rob Herring <robh@kernel.org> wrote:

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

I actually tested this. It works.

It's however a bit annoying that we do not have a single upstream
DTS file using it, so there are no examples to look at other than
in the documentation.

I suppose there would also be greater buy-in to the concept if
we had managed to push the same for at least I2C and SPI,
but it's easy to ask other people to work, I know that.

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

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

James sent a proposal that I think looks good for gpiochips
and I think the same can be used for nexi. But I don't know
the esoteric details of the nexi so I might be wrong...

Yours,
Linus Walleij

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

[Herve Codina]

Hi Linus,

On Thu, 19 Feb 2026 18:57:48 +0100
Linus Walleij <linusw@kernel.org> wrote:

> On Fri, Feb 13, 2026 at 3:34 PM Rob Herring <robh@kernel.org> wrote:
> 
> > > > 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").  
> 
> I actually tested this. It works.
> 
> It's however a bit annoying that we do not have a single upstream
> DTS file using it, so there are no examples to look at other than
> in the documentation.
> 
> I suppose there would also be greater buy-in to the concept if
> we had managed to push the same for at least I2C and SPI,
> but it's easy to ask other people to work, I know that.

Nexus for I2C or SPI will not work.
In fact, busses cannot work with nexus node concept.

A nexus node translate a phandle.

prop = <&nexus X> is, in the end, translated to <&controller Y>.

For busses, you describe devices connected to the bus as sub-nodes of the
bus controller node.

&spi0 {
	my_device@0 {
		reg = 0;
                ...
       };
};

No phandle involved but labels.

With nexus, you cannot translate &spi0.

Also nexus works well when an index is involved. In other word, it works
well with phandle with args.

i2c-bus = <&i2c0>;

In this kind of of definition, no index are present. With nexus node, this
looks like

i2c-bus = <&nexus>;

How to handle multiple i2c busses with nexus node?

Some ways other than nexus have to explored to handle busses.

Best regards,
Hervé

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

[Linus Walleij]

On Fri, Feb 20, 2026 at 9:17 AM Herve Codina <herve.codina@bootlin.com> wrote:

> With nexus, you cannot translate &spi0.
>
> Also nexus works well when an index is involved. In other word, it works
> well with phandle with args.
>
> i2c-bus = <&i2c0>;
>
> In this kind of of definition, no index are present. With nexus node, this
> looks like
>
> i2c-bus = <&nexus>;
>
> How to handle multiple i2c busses with nexus node?

Can't you just use the foo-n suffix trick from the pinctrl etc?

my_nexus: nexus {
   gpio-map = <...>;
   interrupt-map = <...>;
   nexus_i2c0: i2c-bus-0 = <&i2c4>;
   nexus_i2c1: i2c-bus-1 = <&i2c6>;
   nexus_i2c2: i2c-bus-3 = <&i2c8>;
};

&nexus_i2c1 {
     sensor@4c {
          ....
     };
};

Maybe it's not as elegant but I think it could work?

Yours,
Linus Walleij

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

[Geert Uytterhoeven]

Hi Linus,

On Fri, 20 Feb 2026 at 09:35, Linus Walleij <linusw@kernel.org> wrote:
> On Fri, Feb 20, 2026 at 9:17 AM Herve Codina <herve.codina@bootlin.com> wrote:
> > With nexus, you cannot translate &spi0.
> >
> > Also nexus works well when an index is involved. In other word, it works
> > well with phandle with args.
> >
> > i2c-bus = <&i2c0>;
> >
> > In this kind of of definition, no index are present. With nexus node, this
> > looks like
> >
> > i2c-bus = <&nexus>;
> >
> > How to handle multiple i2c busses with nexus node?
>
> Can't you just use the foo-n suffix trick from the pinctrl etc?
>
> my_nexus: nexus {
>    gpio-map = <...>;
>    interrupt-map = <...>;
>    nexus_i2c0: i2c-bus-0 = <&i2c4>;
>    nexus_i2c1: i2c-bus-1 = <&i2c6>;
>    nexus_i2c2: i2c-bus-3 = <&i2c8>;
> };
>
> &nexus_i2c1 {
>      sensor@4c {
>           ....
>      };
> };
>
> Maybe it's not as elegant but I think it could work?

Wasn't that already solved using i2c-parent, cfr. the connectors
discussion at last ELC-E?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Herve Codina]

Hi,

On Fri, 20 Feb 2026 10:15:59 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Linus,
> 
> On Fri, 20 Feb 2026 at 09:35, Linus Walleij <linusw@kernel.org> wrote:
> > On Fri, Feb 20, 2026 at 9:17 AM Herve Codina <herve.codina@bootlin.com> wrote:  
> > > With nexus, you cannot translate &spi0.
> > >
> > > Also nexus works well when an index is involved. In other word, it works
> > > well with phandle with args.
> > >
> > > i2c-bus = <&i2c0>;
> > >
> > > In this kind of of definition, no index are present. With nexus node, this
> > > looks like
> > >
> > > i2c-bus = <&nexus>;
> > >
> > > How to handle multiple i2c busses with nexus node?  
> >
> > Can't you just use the foo-n suffix trick from the pinctrl etc?
> >
> > my_nexus: nexus {
> >    gpio-map = <...>;
> >    interrupt-map = <...>;
> >    nexus_i2c0: i2c-bus-0 = <&i2c4>;
> >    nexus_i2c1: i2c-bus-1 = <&i2c6>;
> >    nexus_i2c2: i2c-bus-3 = <&i2c8>;
> > };
> >
> > &nexus_i2c1 {
> >      sensor@4c {
> >           ....
> >      };
> > };
> >
> > Maybe it's not as elegant but I think it could work?  
> 
> Wasn't that already solved using i2c-parent, cfr. the connectors
> discussion at last ELC-E?

Well, I wouldn't say "solved".

But yeah, the idea is i2c bus extension:
https://lore.kernel.org/all/20250205173918.600037-1-herve.codina@bootlin.com/
https://lore.kernel.org/all/20250618082313.549140-1-herve.codina@bootlin.com/

When DT overlays enter in the loop, the main issue is to reference a
symbol from the overlay.

This issue led to DT addons to replace overlays:
https://lore.kernel.org/all/de02ed8c-0176-4996-ad7a-680a2e115161@beagleboard.org/

All of these is really out of scope of this "dt-bindings: gpio: add
gpio-aggregator binding" series.

I am open to discuss nexus nodes, busses, DT addons but I don't thing this
series is the right place to do this discussions and, on my side, I don't
want to pollute James' work with all that stuff.

Best regards,
Hervé

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

[Geert Uytterhoeven]

Hi Hervé,

On Fri, 20 Feb 2026 at 14:07, Herve Codina <herve.codina@bootlin.com> wrote:
> On Fri, 20 Feb 2026 10:15:59 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, 20 Feb 2026 at 09:35, Linus Walleij <linusw@kernel.org> wrote:
> > > On Fri, Feb 20, 2026 at 9:17 AM Herve Codina <herve.codina@bootlin.com> wrote:
> > > > With nexus, you cannot translate &spi0.
> > > >
> > > > Also nexus works well when an index is involved. In other word, it works
> > > > well with phandle with args.
> > > >
> > > > i2c-bus = <&i2c0>;
> > > >
> > > > In this kind of of definition, no index are present. With nexus node, this
> > > > looks like
> > > >
> > > > i2c-bus = <&nexus>;
> > > >
> > > > How to handle multiple i2c busses with nexus node?
> > >
> > > Can't you just use the foo-n suffix trick from the pinctrl etc?
> > >
> > > my_nexus: nexus {
> > >    gpio-map = <...>;
> > >    interrupt-map = <...>;
> > >    nexus_i2c0: i2c-bus-0 = <&i2c4>;
> > >    nexus_i2c1: i2c-bus-1 = <&i2c6>;
> > >    nexus_i2c2: i2c-bus-3 = <&i2c8>;
> > > };
> > >
> > > &nexus_i2c1 {
> > >      sensor@4c {
> > >           ....
> > >      };
> > > };
> > >
> > > Maybe it's not as elegant but I think it could work?
> >
> > Wasn't that already solved using i2c-parent, cfr. the connectors
> > discussion at last ELC-E?
>
> Well, I wouldn't say "solved".
>
> But yeah, the idea is i2c bus extension:
> https://lore.kernel.org/all/20250205173918.600037-1-herve.codina@bootlin.com/
> https://lore.kernel.org/all/20250618082313.549140-1-herve.codina@bootlin.com/
>
> When DT overlays enter in the loop, the main issue is to reference a
> symbol from the overlay.
>
> This issue led to DT addons to replace overlays:
> https://lore.kernel.org/all/de02ed8c-0176-4996-ad7a-680a2e115161@beagleboard.org/
>
> All of these is really out of scope of this "dt-bindings: gpio: add
> gpio-aggregator binding" series.
>
> I am open to discuss nexus nodes, busses, DT addons but I don't thing this
> series is the right place to do this discussions and, on my side, I don't
> want to pollute James' work with all that stuff.

So true ;-)

If James' connector uses only GPIOs, he can already use the GPIO
aggregator:
  1. Write DT bindings for the "device" (the expansion board) attached
     to the connector, with a real compatible value,
  2. Add the real compatible value to gpio_aggregator_dt_ids[].

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Geert Uytterhoeven]

Hi James,

On Wed, 11 Feb 2026 at 09:14, James Hilliard <james.hilliard1@gmail.com> 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.
>
> Signed-off-by: James Hilliard <james.hilliard1@gmail.com>

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/gpio-aggregator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GPIO aggregator controller
> +
> +maintainers:
> +  - Alexander Stein <linux@ew.tq-group.com>
> +
> +description:
> +  GPIO aggregator forwards selected GPIO lines from one or more GPIO
> +  controllers and exposes them as a virtual GPIO controller.

> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    gpio_agg: gpio-aggregator {
> +        compatible = "gpio-aggregator";
> +        #gpio-cells = <2>;
> +        gpio-controller;
> +        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
> +                <&gpio3 1 GPIO_ACTIVE_HIGH>;
> +        gpio-line-names = "modem-reset", "modem-enable";
> +    };

Looking at the example, it seems you intend to use the gpio-aggregator
as a "Generic GPIO Driver", like in the example in the documentation[1].
Hence I think you should not introduce and abuse the "gpio-aggregator"
compatible value for this, but instead:
  1. Use a proper compatible value that matches your device,
  2. Write proper DT bindings for the device,
  3. Add the proper device's compatible value to the gpio-aggregator
     driver's match table.
The above is very similar to how spidev is handled, which also forbids
using the spidev compatible value in DTS.

[1] https://docs.kernel.org/6.2/admin-guide/gpio/gpio-aggregator.html#generic-gpio-driver
[2] https://docs.kernel.org/spi/spidev.html

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[James Hilliard]

On Wed, Feb 11, 2026 at 1:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi James,
>
> On Wed, 11 Feb 2026 at 09:14, James Hilliard <james.hilliard1@gmail.com> 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.
> >
> > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
> > @@ -0,0 +1,54 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/gpio/gpio-aggregator.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GPIO aggregator controller
> > +
> > +maintainers:
> > +  - Alexander Stein <linux@ew.tq-group.com>
> > +
> > +description:
> > +  GPIO aggregator forwards selected GPIO lines from one or more GPIO
> > +  controllers and exposes them as a virtual GPIO controller.
>
> > +examples:
> > +  - |
> > +    #include <dt-bindings/gpio/gpio.h>
> > +
> > +    gpio_agg: gpio-aggregator {
> > +        compatible = "gpio-aggregator";
> > +        #gpio-cells = <2>;
> > +        gpio-controller;
> > +        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
> > +                <&gpio3 1 GPIO_ACTIVE_HIGH>;
> > +        gpio-line-names = "modem-reset", "modem-enable";
> > +    };
>
> Looking at the example, it seems you intend to use the gpio-aggregator
> as a "Generic GPIO Driver", like in the example in the documentation[1].
> Hence I think you should not introduce and abuse the "gpio-aggregator"
> compatible value for this, but instead:
>   1. Use a proper compatible value that matches your device,
>   2. Write proper DT bindings for the device,
>   3. Add the proper device's compatible value to the gpio-aggregator
>      driver's match table.
> The above is very similar to how spidev is handled, which also forbids
> using the spidev compatible value in DTS.

Isn't this gpio-aggregator driver supposed to be non-hardware
specific?

I'm trying to use it as described here, I noticed the compatible
in the blog post was missing and just needed adding to the
driver: https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/

> [1] https://docs.kernel.org/6.2/admin-guide/gpio/gpio-aggregator.html#generic-gpio-driver
> [2] https://docs.kernel.org/spi/spidev.html
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

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

[Geert Uytterhoeven]

Hi James,

CC Hervé

On Wed, 11 Feb 2026 at 09:35, James Hilliard <james.hilliard1@gmail.com> wrote:
> On Wed, Feb 11, 2026 at 1:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Wed, 11 Feb 2026 at 09:14, James Hilliard <james.hilliard1@gmail.com> 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.
> > >
> > > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> >
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
> > > @@ -0,0 +1,54 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/gpio/gpio-aggregator.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: GPIO aggregator controller
> > > +
> > > +maintainers:
> > > +  - Alexander Stein <linux@ew.tq-group.com>
> > > +
> > > +description:
> > > +  GPIO aggregator forwards selected GPIO lines from one or more GPIO
> > > +  controllers and exposes them as a virtual GPIO controller.
> >
> > > +examples:
> > > +  - |
> > > +    #include <dt-bindings/gpio/gpio.h>
> > > +
> > > +    gpio_agg: gpio-aggregator {
> > > +        compatible = "gpio-aggregator";
> > > +        #gpio-cells = <2>;
> > > +        gpio-controller;
> > > +        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
> > > +                <&gpio3 1 GPIO_ACTIVE_HIGH>;
> > > +        gpio-line-names = "modem-reset", "modem-enable";
> > > +    };
> >
> > Looking at the example, it seems you intend to use the gpio-aggregator
> > as a "Generic GPIO Driver", like in the example in the documentation[1].
> > Hence I think you should not introduce and abuse the "gpio-aggregator"
> > compatible value for this, but instead:
> >   1. Use a proper compatible value that matches your device,
> >   2. Write proper DT bindings for the device,
> >   3. Add the proper device's compatible value to the gpio-aggregator
> >      driver's match table.
> > The above is very similar to how spidev is handled, which also forbids
> > using the spidev compatible value in DTS.
>
> Isn't this gpio-aggregator driver supposed to be non-hardware
> specific?
>
> I'm trying to use it as described here, I noticed the compatible
> in the blog post was missing and just needed adding to the
> driver: https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/

Let's kick Hervé to fix that ;-)

> > [1] https://docs.kernel.org/6.2/admin-guide/gpio/gpio-aggregator.html#generic-gpio-driver
> > [2] https://docs.kernel.org/spi/spidev.html

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Herve Codina]

Hi,

On Wed, 11 Feb 2026 10:47:53 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi James,
> 
> CC Hervé
> 
> On Wed, 11 Feb 2026 at 09:35, James Hilliard <james.hilliard1@gmail.com> wrote:
> > On Wed, Feb 11, 2026 at 1:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:  
> > > On Wed, 11 Feb 2026 at 09:14, James Hilliard <james.hilliard1@gmail.com> 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.
> > > >
> > > > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>  
> > >  
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
> > > > @@ -0,0 +1,54 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/gpio/gpio-aggregator.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: GPIO aggregator controller
> > > > +
> > > > +maintainers:
> > > > +  - Alexander Stein <linux@ew.tq-group.com>
> > > > +
> > > > +description:
> > > > +  GPIO aggregator forwards selected GPIO lines from one or more GPIO
> > > > +  controllers and exposes them as a virtual GPIO controller.  
> > >  
> > > > +examples:
> > > > +  - |
> > > > +    #include <dt-bindings/gpio/gpio.h>
> > > > +
> > > > +    gpio_agg: gpio-aggregator {
> > > > +        compatible = "gpio-aggregator";
> > > > +        #gpio-cells = <2>;
> > > > +        gpio-controller;
> > > > +        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
> > > > +                <&gpio3 1 GPIO_ACTIVE_HIGH>;
> > > > +        gpio-line-names = "modem-reset", "modem-enable";
> > > > +    };  
> > >
> > > Looking at the example, it seems you intend to use the gpio-aggregator
> > > as a "Generic GPIO Driver", like in the example in the documentation[1].
> > > Hence I think you should not introduce and abuse the "gpio-aggregator"
> > > compatible value for this, but instead:
> > >   1. Use a proper compatible value that matches your device,
> > >   2. Write proper DT bindings for the device,
> > >   3. Add the proper device's compatible value to the gpio-aggregator
> > >      driver's match table.
> > > The above is very similar to how spidev is handled, which also forbids
> > > using the spidev compatible value in DTS.  
> >
> > Isn't this gpio-aggregator driver supposed to be non-hardware
> > specific?
> >
> > I'm trying to use it as described here, I noticed the compatible
> > in the blog post was missing and just needed adding to the
> > driver: https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/  
> 
> Let's kick Hervé to fix that ;-)

Where is it missing ?

In the DTS snippet example I see:
--- 8< ---
gpio-aggregator {
    pinctrl-names = "default";
    pinctrl-0 = <&gpio_pins>;
    compatible = "gpio-aggregator";
    ...
};
--- 8< ---

Best regards,
Hervé

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

[Geert Uytterhoeven]

Hi Hervé,

On Wed, 11 Feb 2026 at 10:57, Herve Codina <herve.codina@bootlin.com> wrote:
> On Wed, 11 Feb 2026 10:47:53 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Wed, 11 Feb 2026 at 09:35, James Hilliard <james.hilliard1@gmail.com> wrote:
> > > On Wed, Feb 11, 2026 at 1:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Wed, 11 Feb 2026 at 09:14, James Hilliard <james.hilliard1@gmail.com> 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.
> > > > >
> > > > > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> > > >
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
> > > > > @@ -0,0 +1,54 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/gpio/gpio-aggregator.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: GPIO aggregator controller
> > > > > +
> > > > > +maintainers:
> > > > > +  - Alexander Stein <linux@ew.tq-group.com>
> > > > > +
> > > > > +description:
> > > > > +  GPIO aggregator forwards selected GPIO lines from one or more GPIO
> > > > > +  controllers and exposes them as a virtual GPIO controller.
> > > >
> > > > > +examples:
> > > > > +  - |
> > > > > +    #include <dt-bindings/gpio/gpio.h>
> > > > > +
> > > > > +    gpio_agg: gpio-aggregator {
> > > > > +        compatible = "gpio-aggregator";
> > > > > +        #gpio-cells = <2>;
> > > > > +        gpio-controller;
> > > > > +        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
> > > > > +                <&gpio3 1 GPIO_ACTIVE_HIGH>;
> > > > > +        gpio-line-names = "modem-reset", "modem-enable";
> > > > > +    };
> > > >
> > > > Looking at the example, it seems you intend to use the gpio-aggregator
> > > > as a "Generic GPIO Driver", like in the example in the documentation[1].
> > > > Hence I think you should not introduce and abuse the "gpio-aggregator"
> > > > compatible value for this, but instead:
> > > >   1. Use a proper compatible value that matches your device,
> > > >   2. Write proper DT bindings for the device,
> > > >   3. Add the proper device's compatible value to the gpio-aggregator
> > > >      driver's match table.
> > > > The above is very similar to how spidev is handled, which also forbids
> > > > using the spidev compatible value in DTS.
> > >
> > > Isn't this gpio-aggregator driver supposed to be non-hardware
> > > specific?
> > >
> > > I'm trying to use it as described here, I noticed the compatible
> > > in the blog post was missing and just needed adding to the
> > > driver: https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/
> >
> > Let's kick Hervé to fix that ;-)
>
> Where is it missing ?

In the driver ;-)

DTS must never use 'compatible = "gpio-aggregator"'.
Instead, you must use a suitable compatible value, as described in [1]:

   "Binding a device to the GPIO Aggregator is performed either
    by modifying the gpio-aggregator driver, or by writing to the
    “driver_override” file in Sysfs."

> In the DTS snippet example I see:
> --- 8< ---
> gpio-aggregator {
>     pinctrl-names = "default";
>     pinctrl-0 = <&gpio_pins>;
>     compatible = "gpio-aggregator";
>     ...
> };
> --- 8< ---

> > > > [1] https://docs.kernel.org/6.2/admin-guide/gpio/gpio-aggregator.html#generic-gpio-driver

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Herve Codina]

On Wed, 11 Feb 2026 11:01:24 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Hervé,
> 
> On Wed, 11 Feb 2026 at 10:57, Herve Codina <herve.codina@bootlin.com> wrote:
> > On Wed, 11 Feb 2026 10:47:53 +0100
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:  
> > > On Wed, 11 Feb 2026 at 09:35, James Hilliard <james.hilliard1@gmail.com> wrote:  
> > > > On Wed, Feb 11, 2026 at 1:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:  
> > > > > On Wed, 11 Feb 2026 at 09:14, James Hilliard <james.hilliard1@gmail.com> 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.
> > > > > >
> > > > > > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>  
> > > > >  
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
> > > > > > @@ -0,0 +1,54 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/gpio/gpio-aggregator.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: GPIO aggregator controller
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Alexander Stein <linux@ew.tq-group.com>
> > > > > > +
> > > > > > +description:
> > > > > > +  GPIO aggregator forwards selected GPIO lines from one or more GPIO
> > > > > > +  controllers and exposes them as a virtual GPIO controller.  
> > > > >  
> > > > > > +examples:
> > > > > > +  - |
> > > > > > +    #include <dt-bindings/gpio/gpio.h>
> > > > > > +
> > > > > > +    gpio_agg: gpio-aggregator {
> > > > > > +        compatible = "gpio-aggregator";
> > > > > > +        #gpio-cells = <2>;
> > > > > > +        gpio-controller;
> > > > > > +        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
> > > > > > +                <&gpio3 1 GPIO_ACTIVE_HIGH>;
> > > > > > +        gpio-line-names = "modem-reset", "modem-enable";
> > > > > > +    };  
> > > > >
> > > > > Looking at the example, it seems you intend to use the gpio-aggregator
> > > > > as a "Generic GPIO Driver", like in the example in the documentation[1].
> > > > > Hence I think you should not introduce and abuse the "gpio-aggregator"
> > > > > compatible value for this, but instead:
> > > > >   1. Use a proper compatible value that matches your device,
> > > > >   2. Write proper DT bindings for the device,
> > > > >   3. Add the proper device's compatible value to the gpio-aggregator
> > > > >      driver's match table.
> > > > > The above is very similar to how spidev is handled, which also forbids
> > > > > using the spidev compatible value in DTS.  
> > > >
> > > > Isn't this gpio-aggregator driver supposed to be non-hardware
> > > > specific?
> > > >
> > > > I'm trying to use it as described here, I noticed the compatible
> > > > in the blog post was missing and just needed adding to the
> > > > driver: https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/  
> > >
> > > Let's kick Hervé to fix that ;-)  
> >
> > Where is it missing ?  
> 
> In the driver ;-)
> 
> DTS must never use 'compatible = "gpio-aggregator"'.

Why?

gpio-aggregator can be used as a virtual device to aggregate GPIOs for
user-space.

I think we should have 'compatible = "gpio-aggregator"' in dts.

Best regards,
Hervé

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

[Geert Uytterhoeven]

Hi Hervé,

On Wed, 11 Feb 2026 at 11:58, Herve Codina <herve.codina@bootlin.com> wrote:
> On Wed, 11 Feb 2026 11:01:24 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Wed, 11 Feb 2026 at 10:57, Herve Codina <herve.codina@bootlin.com> wrote:
> > > On Wed, 11 Feb 2026 10:47:53 +0100
> > > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Wed, 11 Feb 2026 at 09:35, James Hilliard <james.hilliard1@gmail.com> wrote:
> > > > > On Wed, Feb 11, 2026 at 1:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > > > On Wed, 11 Feb 2026 at 09:14, James Hilliard <james.hilliard1@gmail.com> 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.
> > > > > > >
> > > > > > > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> > > > > >
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/gpio/gpio-aggregator.yaml
> > > > > > > @@ -0,0 +1,54 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/gpio/gpio-aggregator.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: GPIO aggregator controller
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Alexander Stein <linux@ew.tq-group.com>
> > > > > > > +
> > > > > > > +description:
> > > > > > > +  GPIO aggregator forwards selected GPIO lines from one or more GPIO
> > > > > > > +  controllers and exposes them as a virtual GPIO controller.
> > > > > >
> > > > > > > +examples:
> > > > > > > +  - |
> > > > > > > +    #include <dt-bindings/gpio/gpio.h>
> > > > > > > +
> > > > > > > +    gpio_agg: gpio-aggregator {
> > > > > > > +        compatible = "gpio-aggregator";
> > > > > > > +        #gpio-cells = <2>;
> > > > > > > +        gpio-controller;
> > > > > > > +        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
> > > > > > > +                <&gpio3 1 GPIO_ACTIVE_HIGH>;
> > > > > > > +        gpio-line-names = "modem-reset", "modem-enable";
> > > > > > > +    };
> > > > > >
> > > > > > Looking at the example, it seems you intend to use the gpio-aggregator
> > > > > > as a "Generic GPIO Driver", like in the example in the documentation[1].
> > > > > > Hence I think you should not introduce and abuse the "gpio-aggregator"
> > > > > > compatible value for this, but instead:
> > > > > >   1. Use a proper compatible value that matches your device,
> > > > > >   2. Write proper DT bindings for the device,
> > > > > >   3. Add the proper device's compatible value to the gpio-aggregator
> > > > > >      driver's match table.
> > > > > > The above is very similar to how spidev is handled, which also forbids
> > > > > > using the spidev compatible value in DTS.
> > > > >
> > > > > Isn't this gpio-aggregator driver supposed to be non-hardware
> > > > > specific?
> > > > >
> > > > > I'm trying to use it as described here, I noticed the compatible
> > > > > in the blog post was missing and just needed adding to the
> > > > > driver: https://bootlin.com/blog/gpio-aggregator-a-virtual-gpio-chip/
> > > >
> > > > Let's kick Hervé to fix that ;-)
> > >
> > > Where is it missing ?
> >
> > In the driver ;-)
> >
> > DTS must never use 'compatible = "gpio-aggregator"'.
>
> Why?
>
> gpio-aggregator can be used as a virtual device to aggregate GPIOs for
> user-space.

It can be used for that, but that is not hardware description.

> I think we should have 'compatible = "gpio-aggregator"' in dts.

Proper hardware description requires a proper compatible value.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds