Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge

[Krzysztof Kozlowski <krzk@kernel.org>]

On 28/01/2026 13:49, Andy Shevchenko wrote:
> On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
>> On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:
>>> On Tue, Jan 27, 2026 at 08:47:48AM -0600, Danny Kaehn wrote:
>>>> This is a USB HID device which includes an I2C controller and 8 GPIO pins.
>>>>
>>>> The binding allows describing the chip's gpio and i2c controller in DT,
>>>> with the i2c controller being bound to a subnode named "i2c". This is
>>>> intended to be used in configurations where the CP2112 is permanently
>>>> connected in hardware.
>>>>
>>>> Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
>>>> ---
>>>
>>> Hi Folks (Intended for Rob or Krzysztof),
>>>
>>> Wasn't sure the best way to go about this, but trying to see the best
>>> way to get a message in front of you regarding an ask from Andy S.
>>>
>>> In [1], Rob H initially directed that the gpio chip share a node with
>>> the CP2112 itself, rather than having a subnode named 'gpio'.
>>>
>>> Initially, I did the same thing for both DT and ACPI, but Andy S.
>>> directed that ACPI should not have the node be shared in that way.
>>>
>>> With the last revision of this patch, Andy S. asked that I try to get a
>>> rationalle from Rob (or other DT expert presumably) on why the gpio node
>>> should be combined with the parent, rather than being a named subnode
>>> [2].
>>
>> Because it is explicitly asked in writing bindings. Please read it.
>>
>> Because we do not want Linux driver model affecting design of bindings
>> and DTS, by subnodes present only to instantiate Linux drivers. I do not
>> care about driver model in this review and I do not see any reason it
>> should make DTS less obvious or readable.
>>
>> That's actually rule communicated many times, also documented in writing
>> bindings and in recent talks.
> 
> Does DT represents HW in this case? Shouldn't I²C controller be the same node?
> Why not? This is inconsistent for the device that is multi-functional. And from
> my understanding the firmware description (DT, ACPI, you-name-it) must follow
> the HW. I don't see how it's done in this case.

What is inconsistent exactly? What sort of rule tells that every little
function needs a device node? It's first time I hear about any of such
rule and for all this time we already NAKed it so many times (node per
GPIO, node per clock, node per every little pin).

> 


Best regards,
Krzysztof