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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/

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@xxxxxxxxx>
> 
> 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