From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31BE4C43334 for ; Tue, 28 Jun 2022 10:28:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344307AbiF1K2W (ORCPT ); Tue, 28 Jun 2022 06:28:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237103AbiF1K2W (ORCPT ); Tue, 28 Jun 2022 06:28:22 -0400 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDA2512AAD for ; Tue, 28 Jun 2022 03:28:20 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id v14so16981250wra.5 for ; Tue, 28 Jun 2022 03:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=p/DPfFSM3jMKKRZmtfjvPDQnkcVkhnWQ37ffkh65f6Y=; b=kbqssuFbstijiBxN6ukx6bRt4t+S2ydyiIOa+5yRebAeQDj9rv1637vsz8qbYjSvzY 1prScvFpP1aja07+ePjJLLSe0tcobzljhMEsQQ4HI4HrLoN+1E0WP6QJkMZpQm+3RqRt JMAZ52JEFjzGjqKjextdPoPKNm+4ScuxsFvfA8DtYvRhIH/Owjmmn7p3+A4mJqESf8JM JWK00NjnN3UGfMeOLoqNz6sHkONVnRBi+zWo7civeBkmuNb37qef44uOR0eVq136DO8y TK16/3aXaOchaTNSlk8X7o51ojZvqdjD8HNrP+HOx6/ygJ5IDjTv31qhrwLbb4ePzLV/ lKSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=p/DPfFSM3jMKKRZmtfjvPDQnkcVkhnWQ37ffkh65f6Y=; b=jJ5XwG/+/u3aUVqxthwb4KZs/UjMCrDPofbhtl6aJNKwUefgWcNWfiRY50dj/drv4Y pTqF5fqWBL4bsKYnQTB5x/xqJLfQQYfcixZOqjrPnvbC6sD8nF3lWksxUlNYRZR6F8KJ O9Bk3n0jrm2vC1QIck7vhYMQQiad3KC+DTshTeiPEh2Fwp+RlXoYM6UkchLj8pMHrv7U L7fwPoOzvIWx/UR0oj5+zx3lfZ80OIrKpH5/m/SJjf/z+qC0pjVqFM2TG5Ta9QIxysu/ ajhViVdfAty+q93Krnj736QLvMVa+vh5YJYt3lvPdN6MLwDRs+hSW281M0GXq19wt5nG 6xwA== X-Gm-Message-State: AJIora9ZtVDjP9KTpplrluwnrbCZJPprXWQU4rD6CMHRTwTW4Ohd/rQG quqQzbsPMr3VVzVzrKRauKhOYQ== X-Google-Smtp-Source: AGRyM1uVApxImBBVLBU8ZUemhn0pYLASxjCLbV2ScD5PAtjEBQfdswOb8laC00d1cYSYxMIRRCoQjQ== X-Received: by 2002:a5d:5483:0:b0:21b:88d5:e725 with SMTP id h3-20020a5d5483000000b0021b88d5e725mr17344077wrv.82.1656412099281; Tue, 28 Jun 2022 03:28:19 -0700 (PDT) Received: from [192.168.0.252] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id 4-20020a1c1904000000b0039c4506bd25sm19611110wmz.14.2022.06.28.03.28.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jun 2022 03:28:18 -0700 (PDT) Message-ID: <286633b2-43d2-655e-b3f1-54bf5c7a4a21@linaro.org> Date: Tue, 28 Jun 2022 12:28:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 1/4] dt-bindings: usb: typec: add bindings for stm32g0 controller Content-Language: en-US To: Fabrice Gasnier , robh+dt@kernel.org, heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org Cc: krzysztof.kozlowski+dt@linaro.org, devicetree@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, amelie.delaunay@foss.st.com, alexandre.torgue@foss.st.com References: <20220624155413.399190-1-fabrice.gasnier@foss.st.com> <20220624155413.399190-2-fabrice.gasnier@foss.st.com> <845d6817-d2e4-7925-f7f5-da1102514636@foss.st.com> From: Krzysztof Kozlowski In-Reply-To: <845d6817-d2e4-7925-f7f5-da1102514636@foss.st.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 27/06/2022 16:21, Fabrice Gasnier wrote: > On 6/24/22 18:16, Krzysztof Kozlowski wrote: >> On 24/06/2022 17:54, Fabrice Gasnier wrote: >>> This patch adds DT schema documentation for the STM32G0 Type-C controller. >> >> No "This patch" > > Hi Krzysztof, > > ack, > >> >> https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95 >> >>> STM32G0 provides an integrated USB Type-C and power delivery interface. >>> It can be programmed with a firmware to handle UCSI protocol over I2C >>> interface. A GPIO is used as an interrupt line. >>> It may be used as a wakeup source, so use optional "wakeup-source" and >>> "power-domains" properties to support wakeup. >>> >>> Signed-off-by: Fabrice Gasnier >>> --- >>> .../bindings/usb/st,typec-stm32g0.yaml | 83 +++++++++++++++++++ >>> 1 file changed, 83 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/usb/st,typec-stm32g0.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/usb/st,typec-stm32g0.yaml b/Documentation/devicetree/bindings/usb/st,typec-stm32g0.yaml >>> new file mode 100644 >>> index 0000000000000..b2729bd015a1a >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/usb/st,typec-stm32g0.yaml >>> @@ -0,0 +1,83 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: "http://devicetree.org/schemas/usb/st,typec-stm32g0.yaml#" >>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#" >> >> No quotes. > > ack, > >> >>> + >>> +title: STMicroelectronics STM32G0 Type-C controller bindings >> >> s/bindings// > > ack, > >> >>> + >>> +description: | >>> + The STM32G0 MCU can be programmed to control Type-C connector(s) through I2C >>> + typically using the UCSI protocol over I2C, with a dedicated alert >>> + (interrupt) pin. >>> + >>> +maintainers: >>> + - Fabrice Gasnier >>> + >>> +properties: >>> + compatible: >>> + const: st,stm32g0-typec >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + interrupts: >>> + maxItems: 1 >>> + >>> + connector: >>> + type: object> + allOf: >>> + - $ref: ../connector/usb-connector.yaml# >> >> Full path, so /schemas/connector/... >> >> unevaluatedProperties: false > > ack, > >> >>> + >>> + firmware-name: >>> + description: | >>> + Should contain the name of the default firmware image >>> + file located on the firmware search path >>> + >>> + wakeup-source: true >>> + power-domains: true >> >> maxItems > > Do you mean maxItems regarding the "power-domains" property ? Yes. > This will depend on the user platform, where it's used as an I2C device. > So I'm not sure this can / should be specified here. > Could please you clarify ? Then maybe this property is not valid here. Power domains usually are used for blocks of a SoC, having common power source and power gating. In your case it looks much more like a regulator supply. > >> >>> + >>> +required: >>> + - compatible >>> + - reg >>> + - interrupts >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + #include >>> + i2c5 { >> >> Just "i2c" > > ack, > >> >>> + #address-cells = <1>; >>> + #size-cells = <0>; >>> + >>> + stm32g0@53 { >> >> Generic node name describing class of the device. > > > I wasn't aware of generic node name for an I2C device (not talking of > the controller). I may have missed it. > > Could you please clarify ? The class of a device is not a I2C device. I2C is just a bus. For example the generic name for Power Management IC connected over I2C (quite common case) is "pmic". For USB HCD controllers the generic name is "usb". For USB ports/connectors this is "connector". So what is your hardware? "interface" is a bit too unspecific to figure it out. > >> >>> + compatible = "st,stm32g0-typec"; >>> + reg = <0x53>; >>> + /* Alert pin on GPIO PE12 */ >>> + interrupts = <12 IRQ_TYPE_EDGE_FALLING>; >>> + interrupt-parent = <&gpioe>; >>> + >>> + /* Example with one type-C connector */ >>> + connector { >>> + compatible = "usb-c-connector"; >>> + label = "USB-C"; >>> + >>> + port { >> >> This does not look like proper schema of connector.yaml. > > This refers to graph.yaml [1], where similar example is seen [2]. > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/graph.yaml#L79 > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/graph.yaml#L207 Just look at the usb-conector schema. It's different. You miss ports. Maybe other properties as well. > > device-1 { > port { > device_1_output: endpoint { > remote-endpoint = <&device_2_input>; > }; > }; > }; > device-2 { > port { > device_2_input: endpoint { > remote-endpoint = <&device_1_output>; > }; > }; > }; > > > Could you please clarify this point too ? > >> >>> + con_usb_c_ep: endpoint { >>> + remote-endpoint = <&usbotg_hs_ep>; >>> + }; >>> + }; >>> + }; >>> + }; >>> + }; >>> + >>> + usbotg_hs { >> >> Generic node names, no underscores in node names. > > ack, I guess you'd recommend "usb" here. I'll update it. Yes, looks like usb. Best regards, Krzysztof