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@xxxxxxxxxx> wrote:
>>
>> 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.
> 
> 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@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?
> 
> 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