Message-ID: <a579100b-6c38-4fd1-bab3-b1e7663ab412@kernel.org>
Date: Wed, 28 Jan 2026 16:52:01 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Conor Dooley <conor@...nel.org>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Danny Kaehn <danny.kaehn@...xus.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Benjamin Tissoires <bentiss@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Jiri Kosina <jikos@...nel.org>,
 devicetree@...r.kernel.org, linux-input@...r.kernel.org,
 Dmitry Torokhov <dmitry.torokhov@...il.com>,
 Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
 Ethan Twardy <ethan.twardy@...xus.com>, linux-i2c@...r.kernel.org,
 linux-kernel@...r.kernel.org, Leo Huang <leohu@...dia.com>,
 Arun D Patil <arundp@...dia.com>, Willie Thai <wthai@...dia.com>,
 Ting-Kai Chen <tingkaic@...dia.com>
Subject: Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus
 Bridge

On 28/01/2026 16:06, Conor Dooley wrote:
> On Wed, Jan 28, 2026 at 02:49:39PM +0200, 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@...xus.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.
> 
> The i2c controller should probably be in the same node too, unless it
> would cause conflicts between function (e.g. inability to figure out if

This one is the rationale.

> a child is a hog or a i2c device). I would like a rationale provided for
> why the i2c controller is in a subnode.

I2C controller will have children, because it is a bus, so moving it up
one level would make the entire node I2C bus and that's not only problem
for the kernel but actually for reading DT - we expect consistent choice
for children, instead of mixing nodes with and without bus-addressing.
What's more, if you have two buses you also need separate nodes to group
them (obviously).

Best regards,
Krzysztof

Powered by blists - more mailing lists