devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Danny Kaehn <danny.kaehn@plexus.com>
Cc: krzysztof.kozlowski+dt@linaro.org,
	andriy.shevchenko@linux.intel.com, bentiss@kernel.org,
	jikos@kernel.org, bartosz.golaszewski@linaro.org,
	niyas.sait@linaro.org, dmitry.torokhov@gmail.com,
	devicetree@vger.kernel.org, linux-input@vger.kernel.org,
	ethan.twardy@plexus.com
Subject: Re: [PATCH v10 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
Date: Tue, 13 Feb 2024 09:28:25 -0600	[thread overview]
Message-ID: <20240213152825.GA1223720-robh@kernel.org> (raw)
In-Reply-To: <20240205170920.93499-2-danny.kaehn@plexus.com>

On Mon, Feb 05, 2024 at 11:09:20AM -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
> using the subnodes named "gpio" and "i2c", respectively. 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>
> ---
> 
> Note -- Reviewed-By tags have been removed as suggested by Benjamin, since
> 1. It has been 6+ months since this binding was reviewed, and a lot can
> change upstream in that time
> 2. There has been some contention between using named child nodes to
> identify i2c and gpio nodes, and also making the driver implementing this
> binding compatible with ACPI, since names aren't significant for ACPI
> nodes, and ACPI names are always automatically uppercased. It has been
> suggested that perhaps the DT binding should use child nodes with
> addressable `reg` properties to identify the child nodes, instead of by
> name [1].

'reg' only makes sense if there are values which relate to the h/w. If 
your addresses are indices, that will be suspect.

There's documented nodenames for specific device classes in DT. You have 
to use those whether there's 'reg' and a unit-address or not. I'm not 
really clear what the problem is.

> 
> Of course, I acknowledge that other firmware languages and kernel details
> shouldn't impact DT bindings, but it also seems that there should
> be some consistent way to specify sub-functions like this accross DT
> and ACPI. Some additional commentary / requests for comment about the
> seemingly missing glue here can be found in [2].

I have little interest in worrying about ACPI as I have limited 
knowledge in ACPI requirements, what I do know is the model for bindings 
are fundamentally differ, and no one has stepped up to maintain bindings 
from an ACPI perspective.

> Any comments from Rob/Krzysztof/other DT folks would be greatly appreciated
> 
> [1] https://lore.kernel.org/all/ZBhoHzTr5l38u%2FkX@smile.fi.intel.com/
> [2] https://lore.kernel.org/all/CAP+ZCCd0cD+q7=ngyEzScAte2VT9R00mqCQxB3K2TMbeg8UAfA@mail.gmail.com/
> 
>  .../bindings/i2c/silabs,cp2112.yaml           | 113 ++++++++++++++++++
>  1 file changed, 113 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
> 
> diff --git a/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
> new file mode 100644
> index 000000000000..a27509627804
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
> @@ -0,0 +1,113 @@
> +# 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 <kaehndan@gmail.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 on the host controller
> +
> +  i2c:
> +    description: The SMBus/I2C controller node for the CP2112
> +    $ref: /schemas/i2c/i2c-controller.yaml#
> +    unevaluatedProperties: false
> +
> +    properties:
> +      sda-gpios:
> +        maxItems: 1
> +
> +      scl-gpios:
> +        maxItems: 1

Why do you have GPIOs if this is a proper controller?

> +
> +      clock-frequency:
> +        minimum: 10000
> +        default: 100000
> +        maximum: 400000
> +
> +  gpio:
> +    description: The GPIO controller node for the CP2112

There's no need for a child node here. All these properties can be part 
of the parent.


> +    type: object
> +    unevaluatedProperties: false
> +
> +    properties:
> +      interrupt-controller: true
> +      "#interrupt-cells":
> +        const: 2
> +
> +      gpio-controller: true
> +      "#gpio-cells":
> +        const: 2
> +
> +      gpio-line-names:
> +        minItems: 1
> +        maxItems: 8
> +
> +    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>;
> +
> +      device@1 {
> +        compatible = "usb10c4,ea90";
> +        reg = <1>;
> +
> +        i2c {
> +          #address-cells = <1>;
> +          #size-cells = <0>;
> +          sda-gpios = <&cp2112_gpio 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> +          scl-gpios = <&cp2112_gpio 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> +
> +          temp@48 {
> +            compatible = "national,lm75";
> +            reg = <0x48>;
> +          };
> +        };
> +
> +        cp2112_gpio: gpio {
> +          gpio-controller;
> +          interrupt-controller;
> +          #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";
> +          };
> +        };
> +      };
> +    };
> -- 
> 2.25.1
> 

  reply	other threads:[~2024-02-13 15:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-05 17:09 [PATCH v10 0/3] Firmware Support for USB-HID Devices and CP2112 Danny Kaehn
2024-02-05 17:09 ` [PATCH v10 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge Danny Kaehn
2024-02-13 15:28   ` Rob Herring [this message]
2024-02-14 16:06     ` [PATCH v10 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Danny Kaehn
2024-02-05 17:09 ` [PATCH v10 2/3] HID: usbhid: Share USB device firmware node with child HID device Danny Kaehn
2024-02-05 17:09 ` [PATCH v10 3/3] HID: cp2112: Fwnode Support Danny Kaehn
2024-02-06 14:05   ` Andy Shevchenko
2024-02-06 15:54   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240213152825.GA1223720-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=bentiss@kernel.org \
    --cc=danny.kaehn@plexus.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=ethan.twardy@plexus.com \
    --cc=jikos@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=niyas.sait@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).