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>
---
.../devicetree/bindings/i2c/silabs,cp2112.yaml | 100 +++++++++++++++++++++
1 file changed, 100 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
new file mode 100644
index 000000000000..a204adfe57b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/silabs,cp2112.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CP2112 HID USB to SMBus/I2C Bridge
+
+maintainers:
+ - Danny Kaehn <danny.kaehn@plexus.com>
+
+description:
+ The CP2112 is a USB HID device which includes an integrated I2C controller
+ and 8 GPIO pins. Its GPIO pins can each be configured as inputs, open-drain
+ outputs, or push-pull outputs.
+
+properties:
+ compatible:
+ const: usb10c4,ea90
+
+ reg:
+ maxItems: 1
+ description: The USB port number
+
+ interrupt-controller: true
+ "#interrupt-cells":
+ const: 2
+
+ gpio-controller: true
+ "#gpio-cells":
+ const: 2
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 8
+
+ i2c:
+ description: The SMBus/I2C controller node for the CP2112
+ $ref: /schemas/i2c/i2c-controller.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-frequency:
+ minimum: 10000
+ default: 100000
+ maximum: 400000
+
+patternProperties:
+ "-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cp2112: device@1 {
+ compatible = "usb10c4,ea90";
+ reg = <1>;
+
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #gpio-cells = <2>;
+ gpio-line-names = "CP2112_SDA", "CP2112_SCL", "TEST2",
+ "TEST3","TEST4", "TEST5", "TEST6";
+
+ fan-rst-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "FAN_RST";
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sda-gpios = <&cp2112 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&cp2112 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ temp@48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+ };
+ };
+ };
--
2.25.1On 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.
...
> + gpio-line-names = "CP2112_SDA", "CP2112_SCL", "TEST2",
> + "TEST3","TEST4", "TEST5", "TEST6";
Seems like missing space. Also I would resplit this logically, id est:
gpio-line-names = "CP2112_SDA", "CP2112_SCL",
"TEST2", "TEST3", "TEST4", "TEST5", "TEST6";
--
With Best Regards,
Andy Shevchenko
On Tue, 27 Jan 2026 08:47:48 -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> > --- > .../devicetree/bindings/i2c/silabs,cp2112.yaml | 100 +++++++++++++++++++++ > 1 file changed, 100 insertions(+) > Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
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]. Any context you can provide would be extremely helpful. Apologies about the age of this patch series and the amount of historical context; some is due to my long delays between revisions, but other of it is due to attempting to get the ACPI and DT folks to talk / agree. [1]: https://lore.kernel.org/all/20240213152825.GA1223720-robh@kernel.org/ [2]: https://lore.kernel.org/all/aSdvv3Qss5oz_o6P@smile.fi.intel.com/ Thanks, Danny Kaehn
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. Best regards, Krzysztof
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. > 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
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. -- With Best Regards, Andy Shevchenko
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
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 sense tells to me, putting all eggs into one bucket is just a mine field for the future. -- With Best Regards, Andy Shevchenko
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
On Wed, Jan 28, 2026 at 08:52:50PM +0100, Krzysztof Kozlowski wrote: > 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. Okay, thanks for elaboration. I definitely learnt something new about DT. -- With Best Regards, Andy Shevchenko
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@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. 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 a child is a hog or a i2c device). I would like a rationale provided for why the i2c controller is in a subnode.
On Wed, Jan 28, 2026 at 03:06:58PM +0000, 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: ... > > > 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 > a child is a hog or a i2c device). I would like a rationale provided for > why the i2c controller is in a subnode. I can expect a disaster with such a scheme, splitting multi-functional device to the subdevices (children) sounds to me like the best approach. With this, one may have the same (globally named) property to be different on subdevices. But I will hold my breath to see the outcome of this discussion. -- With Best Regards, Andy Shevchenko
On 28/01/2026 16:51, Andy Shevchenko wrote: > On Wed, Jan 28, 2026 at 03:06:58PM +0000, 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: > > ... > >>>> 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 >> a child is a hog or a i2c device). I would like a rationale provided for >> why the i2c controller is in a subnode. > > I can expect a disaster with such a scheme, splitting multi-functional device So for some years no disaster happened, at least nothing was reported to us. Best regards, Krzysztof
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@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. > > 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
On Wed, Jan 28, 2026 at 04:52:01PM +0100, Krzysztof Kozlowski wrote: > 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@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. > > > > 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. I guess it wasn't clear that I was trying to say that the rationale should be provided by the submitter in their patch, and the first portion of my comment was trying to mention what has to be considered. > 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).
On Wed, Jan 28, 2026 at 05:24:24PM +0000, Conor Dooley wrote: > On Wed, Jan 28, 2026 at 04:52:01PM +0100, Krzysztof Kozlowski wrote: > > 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@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. > > > > > > 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. > > I guess it wasn't clear that I was trying to say that the rationale > should be provided by the submitter in their patch, and the first > portion of my comment was trying to mention what has to be considered. > Hello Conor, Thanks for the comment -- as this binding was created, it was noted that it is somewhat of an oddball compared to existing bindings, so rationale should have been provided somewhere, to justify whether those oddities are needed because of this hardware being odd, or whether I was going out of bounds. Would that have belonged in the initial patch series message? My rationale was this -- as has been mentioned by others, the i2c node seems to be normalized as a separated submode because it does represent a distinct bus, and it make sense to group the devices on that bus such that the context of `reg` is aparrent (i.e. if there were multiple i2c busses, they would necessarily need their own nodes). Initially when creating this binding, I applied the same logic to the gpio chip, observing the presence of the "hog" child nodes, and that their `gpios` property also acts like `reg` on a bus, relating to the parent node. But, now, seeing that that is already something that has been ruled not to be the case, it makes sense to me why i2c busses might need their own nodes while gpio chips might not. Thanks, Danny Kaehn
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. > 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]. > > Any context you can provide would be extremely helpful. Apologies about > the age of this patch series and the amount of historical context; some > is due to my long delays between revisions, but other of it is due to > attempting to get the ACPI and DT folks to talk / agree. I think this is about markers such as "gpio-controller" or "interrupt-controller" in DT for the device in question. With that it might not be required to have a separate child node for the GPIO function. > [1]: https://lore.kernel.org/all/20240213152825.GA1223720-robh@kernel.org/ > [2]: https://lore.kernel.org/all/aSdvv3Qss5oz_o6P@smile.fi.intel.com/ -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.