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

On 13/02/2026 09:02, James Hilliard wrote:

On Fri, Feb 13, 2026 at 12:31 AM Krzysztof Kozlowski [off-list ref] wrote:

quoted

On 12/02/2026 20:16, James Hilliard wrote:

quoted

On Thu, Feb 12, 2026 at 12:18 AM Krzysztof Kozlowski [off-list ref] wrote:

quoted

On 11/02/2026 22:49, James Hilliard wrote:

quoted

quoted

quoted

quoted

quoted

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/ (local)

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

quoted

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.

quoted

quoted

quoted

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

Nacked-by: Geert Uytterhoeven [off-list ref]

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.

quoted

quoted

quoted

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