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: <20260128200525.GA818373@LNDCL34533.neenah.na.plexus.com>
Date: Wed, 28 Jan 2026 14:05:25 -0600
From: Danny Kaehn <danny.kaehn@...xus.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Benjamin Tissoires <bentiss@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        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 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.
> 

Hi Krzysztof,

Thanks for all of the replies. It's never my intent to waste
maintainers' time, so apologies if due-diligence was missed here on my
part.

When initially writing this binding, I did search around for any kernel
doc or binding that might provide guidance on how the nodes could be    
split, but failed to find anything particularly relevent, aside from
general principles which can be applied to come to the same conclusion
you have about why the gpio and i2c nodes are necessarily different
because of i2c representing a true bus. This is likely a failing on my
part, but I'm not sure exactly where I'd go to find rules like this
which, as you say, have been communicated many times, aside from
querying the mailing lists.

I've started to go through some recent talks to see context there, and
came across "How to Get Your DT Schema Bindings Accepted in Less Than
10 Iterations"... clearly I've failed on that here :)

Thanks,

Danny Kaehn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ