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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bb448595-ae60-4497-98ad-040f148af2e5@kernel.org>
Date: Wed, 28 Jan 2026 20:52:50 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: 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 17:05, Andy Shevchenko wrote:
> On Wed, Jan 28, 2026 at 04:48:18PM +0100, Krzysztof Kozlowski wrote:
>> 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:
> 
> ...
> 
>>>> 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).
> 
> That we should represent the HW as is. There is no "rule", there is a common
> sense. Of course, it's possible to have all-in-one node, but this may lead
> to a disaster when there are tons of devices in the Multi Functional HW
> and some of them use the same properties. How would you distinguish HW
> with two GPIO banks, two I²C controllers, et cetera? That's what my common

I do not see problems in these examples. GPIO banks have gpio-cells for
that. i2c controllers are busses, so as I explained in other email, must
have their own node whenever any other node is expected.

And for everything which is more complex, e.g. regulators, we do expect
child nodes.

Still the "MFD" is not a reason itself, we consistently give such review
and we also documented it.


> sense tells to me, putting all eggs into one bucket is just a mine field
> for the future.

Some years passed and I do not remember any mine happening here.
Actually mines appeared when people DID create fake nodes, because then
when the actual true bus node was needed it was violating the rule we
have - not mixing bus and non-bus nodes on the same level.


Best regards,
Krzysztof