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@xxxxxxxxxx> wrote:
>
> On 13/02/2026 09:29, Herve Codina wrote:
> > Hi all,
> >
> > On Fri, 13 Feb 2026 08:31:21 +0100
> > Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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@xxxxxxxxx/

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