Message ID | 20221129103509.9958-8-hayashi.kunihiko@socionext.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp255374wrr; Tue, 29 Nov 2022 02:40:13 -0800 (PST) X-Google-Smtp-Source: AA0mqf50jqk5jri615IA9JrF/URq21j1+9y1py6sofgtcP7Nk2G3FUtD1XuLRgw1LYXbRHOT8JPj X-Received: by 2002:a17:906:fd57:b0:7be:5c6f:e63c with SMTP id wi23-20020a170906fd5700b007be5c6fe63cmr11517509ejb.253.1669718413009; Tue, 29 Nov 2022 02:40:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669718413; cv=none; d=google.com; s=arc-20160816; b=FtaKlOcQypx/jPOe89VANeJvvHDD0FjEL4REYo2SF9XE1ahHweDRuzZ/jcJA/TFXfR lexU98bTF7C+8S2+smfvYJuxNpe6GiJGK50AGWQaVT1GPpey8KoLqX4PfqxJKWdFjMyJ E4O7lhwet1nIaP5CxRSOt8ZkWuXRwBWHqeDeTMp1Ga3xnwCKxJlrFNV00FdaaCfBHbn9 hHAoLzsnaD1IixCJ1ZDlL4qqCuM6YXCufBenHuUic9BwQsQGX1tBQt1BzyZ/bqdhD3sY Ik9kJjBmRdh5qR/3pIVrC55ieh8zuXett02vnoQPCYL67AcBaxMVg0W7ew1HcAxBPXpX k+NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=4NIriCj249r0VwRnghIyHMCwdGzPyUA4FKe9rMkFcSM=; b=cpKATc7vVMNiftarp9XOVD41tvBiKwCXUwcdVLHfqeTzT8o8HeQWkJeyMkSDZnsgSl OMoMEIlHBOT9H8NQy91EMVFLP76lP2XU0EIAvyYxhpdkFr6gN3EE137XRO0451iPuWt2 4xGEQnM98qMGzK5yCVFUL2tLDbGofajXesTULc//rVGNjzuq4eczcsys6OqZ1iNxXfyd wUi9x/qO5nVoDaK0uaNSB23stT2URzDYs3j1yWPOs9I5xbJ10B1LXyuhXiYpYxRYwkNi FS4N4SKnLx2ZtV0q32D0FwDpHpQ3ZpkQi2AR9yI4caGByNQaQLHOTfTPmTyW422bBRIm fXrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g8-20020a056402320800b0046afbd6c84fsi2632724eda.553.2022.11.29.02.39.48; Tue, 29 Nov 2022 02:40:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232271AbiK2Kft (ORCPT <rfc822;rbbytesnap@gmail.com> + 99 others); Tue, 29 Nov 2022 05:35:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230500AbiK2KfU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 29 Nov 2022 05:35:20 -0500 Received: from mx.socionext.com (mx.socionext.com [202.248.49.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4CAFF14017; Tue, 29 Nov 2022 02:35:18 -0800 (PST) Received: from unknown (HELO iyokan2-ex.css.socionext.com) ([172.31.9.54]) by mx.socionext.com with ESMTP; 29 Nov 2022 19:35:17 +0900 Received: from mail.mfilter.local (m-filter-1 [10.213.24.61]) by iyokan2-ex.css.socionext.com (Postfix) with ESMTP id CA46C205D901; Tue, 29 Nov 2022 19:35:17 +0900 (JST) Received: from 172.31.9.51 (172.31.9.51) by m-FILTER with ESMTP; Tue, 29 Nov 2022 19:35:17 +0900 Received: from plum.e01.socionext.com (unknown [10.212.243.119]) by kinkan2.css.socionext.com (Postfix) with ESMTP id 62B66C1E22; Tue, 29 Nov 2022 19:35:17 +0900 (JST) From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> To: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Masami Hiramatsu <mhiramat@kernel.org>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Subject: [PATCH 7/8] dt-bindings: soc: socionext: Add UniPhier DWC3 USB glue layer Date: Tue, 29 Nov 2022 19:35:08 +0900 Message-Id: <20221129103509.9958-8-hayashi.kunihiko@socionext.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221129103509.9958-1-hayashi.kunihiko@socionext.com> References: <20221129103509.9958-1-hayashi.kunihiko@socionext.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750826654518847099?= X-GMAIL-MSGID: =?utf-8?q?1750826654518847099?= |
Series |
dt-bidnings: soc: Introduce UniPhier miscelaneous register blocks
|
|
Commit Message
Kunihiko Hayashi
Nov. 29, 2022, 10:35 a.m. UTC
Add DT binding schema for components belonging to the platform-specific
DWC3 USB glue layer implemented in UniPhier SoCs.
This USB glue layer works as a sideband logic for the host controller,
including core reset, vbus control, PHYs, and some signals to the
controller.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
.../socionext,uniphier-dwc3-glue.yaml | 106 ++++++++++++++++++
1 file changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml
Comments
On Tue, 29 Nov 2022 19:35:08 +0900, Kunihiko Hayashi wrote: > Add DT binding schema for components belonging to the platform-specific > DWC3 USB glue layer implemented in UniPhier SoCs. > > This USB glue layer works as a sideband logic for the host controller, > including core reset, vbus control, PHYs, and some signals to the > controller. > > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> > --- > .../socionext,uniphier-dwc3-glue.yaml | 106 ++++++++++++++++++ > 1 file changed, 106 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.example.dtb: usb-glue@65b00000: 'reg' is a required property From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.example.dtb: usb-glue@65b00000: 'ss-phy@300' does not match any of the regexes: '^phy@[0-9a-f]+$', '^regulator@[0-9a-f]+$', '^reset-controller@[0-9a-f]+$', 'pinctrl-[0-9]+' From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.example.dtb: usb-glue@65b00000: 'reg' is a required property From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.example.dtb: usb-glue@65b00000: 'hs-phy@200' does not match any of the regexes: '^phy@[0-9a-f]+$', '^regulator@[0-9a-f]+$', '^reset-controller@[0-9a-f]+$', 'pinctrl-[0-9]+' From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20221129103509.9958-8-hayashi.kunihiko@socionext.com This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command.
On 29/11/2022 11:35, Kunihiko Hayashi wrote: > Add DT binding schema for components belonging to the platform-specific > DWC3 USB glue layer implemented in UniPhier SoCs. > > This USB glue layer works as a sideband logic for the host controller, > including core reset, vbus control, PHYs, and some signals to the > controller. > > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> > --- > .../socionext,uniphier-dwc3-glue.yaml | 106 ++++++++++++++++++ > 1 file changed, 106 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml > > diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml > new file mode 100644 > index 000000000000..66f8786dd305 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml > @@ -0,0 +1,106 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-dwc3-glue.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Socionext UniPhier SoC DWC3 USB3.0 glue layer > + > +maintainers: > + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> > + > +description: |+ > + DWC3 USB3.0 glue layer implemented on Socionext UniPhier SoCs is > + a sideband logic handling signals to DWC3 host controller inside > + USB3.0 component. > + > +properties: > + compatible: > + items: > + - enum: > + - socionext,uniphier-pro4-dwc3-glue > + - socionext,uniphier-pro5-dwc3-glue > + - socionext,uniphier-pxs2-dwc3-glue > + - socionext,uniphier-ld20-dwc3-glue > + - socionext,uniphier-pxs3-dwc3-glue > + - socionext,uniphier-nx1-dwc3-glue > + - const: simple-mfd > + > + reg: > + maxItems: 1 > + > + '#address-cells': > + const: 1 > + > + '#size-cells': > + const: 1 > + > + ranges: true > + > +patternProperties: > + "^reset-controller@[0-9a-f]+$": > + $ref: /schemas/reset/socionext,uniphier-glue-reset.yaml# > + > + "^regulator@[0-9a-f]+$": > + $ref: /schemas/regulator/socionext,uniphier-regulator.yaml# > + > + "^phy@[0-9a-f]+$": > + oneOf: > + - $ref: /schemas/phy/socionext,uniphier-usb3hs-phy.yaml# > + - $ref: /schemas/phy/socionext,uniphier-usb3ss-phy.yaml# > + > +required: > + - compatible > + - reg > + > +additionalProperties: false > + > +examples: > + - | > + usb-controller@65b00000 { Node name: usb. There is no usage of "usb-controller". > + compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd"; > + reg = <0x65b00000 0x400>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0x65b00000 0x400>; > + > + reset-controller@0 { > + compatible = "socionext,uniphier-ld20-usb3-reset"; > + reg = <0x0 0x4>; So now I see the unit addresses, which means none of your previous patches needed them. This raises next question - why this device is special and does not use syscon but own unit address? Are the children here - regulator, reset controller and phys - related to the USB? Best regards, Krzysztof
Hi Krzysztof, On 2022/11/29 23:52, Krzysztof Kozlowski wrote: > On 29/11/2022 11:35, Kunihiko Hayashi wrote: >> Add DT binding schema for components belonging to the platform-specific >> DWC3 USB glue layer implemented in UniPhier SoCs. >> >> This USB glue layer works as a sideband logic for the host controller, >> including core reset, vbus control, PHYs, and some signals to the >> controller. >> >> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >> --- >> .../socionext,uniphier-dwc3-glue.yaml | 106 ++++++++++++++++++ >> 1 file changed, 106 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml >> >> diff --git >> a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml >> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml >> new file mode 100644 >> index 000000000000..66f8786dd305 >> --- /dev/null >> +++ >> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml >> @@ -0,0 +1,106 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: >> http://devicetree.org/schemas/soc/socionext/socionext,uniphier-dwc3-glue.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Socionext UniPhier SoC DWC3 USB3.0 glue layer >> + >> +maintainers: >> + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >> + >> +description: |+ >> + DWC3 USB3.0 glue layer implemented on Socionext UniPhier SoCs is >> + a sideband logic handling signals to DWC3 host controller inside >> + USB3.0 component. >> + >> +properties: >> + compatible: >> + items: >> + - enum: >> + - socionext,uniphier-pro4-dwc3-glue >> + - socionext,uniphier-pro5-dwc3-glue >> + - socionext,uniphier-pxs2-dwc3-glue >> + - socionext,uniphier-ld20-dwc3-glue >> + - socionext,uniphier-pxs3-dwc3-glue >> + - socionext,uniphier-nx1-dwc3-glue >> + - const: simple-mfd >> + >> + reg: >> + maxItems: 1 >> + >> + '#address-cells': >> + const: 1 >> + >> + '#size-cells': >> + const: 1 >> + >> + ranges: true >> + >> +patternProperties: >> + "^reset-controller@[0-9a-f]+$": >> + $ref: /schemas/reset/socionext,uniphier-glue-reset.yaml# >> + >> + "^regulator@[0-9a-f]+$": >> + $ref: /schemas/regulator/socionext,uniphier-regulator.yaml# >> + >> + "^phy@[0-9a-f]+$": >> + oneOf: >> + - $ref: /schemas/phy/socionext,uniphier-usb3hs-phy.yaml# >> + - $ref: /schemas/phy/socionext,uniphier-usb3ss-phy.yaml# >> + >> +required: >> + - compatible >> + - reg >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + usb-controller@65b00000 { > > Node name: usb. There is no usage of "usb-controller". I'm confusing about that. This is an interface logic and doesn't have USB functions by itself. Surely there is a USB host controller node "usb@..." in the same SoC. Can this node be renamed to "usb"? I've renamed the dts node name once in commit 4cc752a88ca9 ("arm64: dts: uniphier: Rename usb-glue node for USB3 to usb-controller"). >> + compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd"; >> + reg = <0x65b00000 0x400>; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0 0x65b00000 0x400>; >> + >> + reset-controller@0 { >> + compatible = "socionext,uniphier-ld20-usb3-reset"; >> + reg = <0x0 0x4>; > > So now I see the unit addresses, which means none of your previous > patches needed them. This raises next question - why this device is > special and does not use syscon but own unit address? The glue layer has a fixed register address for each child unlike the previous patch. This layer has also the other registers for USB core outside the child nodes, however, there is no parent device that manages these registers, so this layer node itself should take care of these registers. > Are the children here - regulator, reset controller and phys - related > to the USB? Yes, this "glue layer" is an interface of the USB controller, so these children are only used for the USB controller. Thank you, --- Best Regards Kunihiko Hayashi
On 30/11/2022 10:00, Kunihiko Hayashi wrote: > Hi Krzysztof, > > On 2022/11/29 23:52, Krzysztof Kozlowski wrote: >> On 29/11/2022 11:35, Kunihiko Hayashi wrote: >>> Add DT binding schema for components belonging to the platform-specific >>> DWC3 USB glue layer implemented in UniPhier SoCs. >>> >>> This USB glue layer works as a sideband logic for the host controller, >>> including core reset, vbus control, PHYs, and some signals to the >>> controller. >>> >>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >>> --- >>> .../socionext,uniphier-dwc3-glue.yaml | 106 ++++++++++++++++++ >>> 1 file changed, 106 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml >>> >>> diff --git >>> a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml >>> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml >>> new file mode 100644 >>> index 000000000000..66f8786dd305 >>> --- /dev/null >>> +++ >>> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml >>> @@ -0,0 +1,106 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: >>> http://devicetree.org/schemas/soc/socionext/socionext,uniphier-dwc3-glue.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Socionext UniPhier SoC DWC3 USB3.0 glue layer >>> + >>> +maintainers: >>> + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >>> + >>> +description: |+ >>> + DWC3 USB3.0 glue layer implemented on Socionext UniPhier SoCs is >>> + a sideband logic handling signals to DWC3 host controller inside >>> + USB3.0 component. >>> + >>> +properties: >>> + compatible: >>> + items: >>> + - enum: >>> + - socionext,uniphier-pro4-dwc3-glue >>> + - socionext,uniphier-pro5-dwc3-glue >>> + - socionext,uniphier-pxs2-dwc3-glue >>> + - socionext,uniphier-ld20-dwc3-glue >>> + - socionext,uniphier-pxs3-dwc3-glue >>> + - socionext,uniphier-nx1-dwc3-glue >>> + - const: simple-mfd >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + '#address-cells': >>> + const: 1 >>> + >>> + '#size-cells': >>> + const: 1 >>> + >>> + ranges: true >>> + >>> +patternProperties: >>> + "^reset-controller@[0-9a-f]+$": >>> + $ref: /schemas/reset/socionext,uniphier-glue-reset.yaml# >>> + >>> + "^regulator@[0-9a-f]+$": >>> + $ref: /schemas/regulator/socionext,uniphier-regulator.yaml# >>> + >>> + "^phy@[0-9a-f]+$": >>> + oneOf: >>> + - $ref: /schemas/phy/socionext,uniphier-usb3hs-phy.yaml# >>> + - $ref: /schemas/phy/socionext,uniphier-usb3ss-phy.yaml# >>> + >>> +required: >>> + - compatible >>> + - reg >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + usb-controller@65b00000 { >> >> Node name: usb. There is no usage of "usb-controller". > > I'm confusing about that. > > This is an interface logic and doesn't have USB functions by itself. > Surely there is a USB host controller node "usb@..." in the same SoC. > Can this node be renamed to "usb"? > > I've renamed the dts node name once in commit 4cc752a88ca9 > ("arm64: dts: uniphier: Rename usb-glue node for USB3 to usb-controller"). In (almost?) all other cases it is still called "usb". A bit akward to have usb in usb, but usb-controller did not stick... > >>> + compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd"; >>> + reg = <0x65b00000 0x400>; >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + ranges = <0 0x65b00000 0x400>; >>> + >>> + reset-controller@0 { >>> + compatible = "socionext,uniphier-ld20-usb3-reset"; >>> + reg = <0x0 0x4>; >> >> So now I see the unit addresses, which means none of your previous >> patches needed them. This raises next question - why this device is >> special and does not use syscon but own unit address? > > The glue layer has a fixed register address for each child unlike > the previous patch. > > This layer has also the other registers for USB core outside > the child nodes, however, there is no parent device that manages > these registers, so this layer node itself should take care of these > registers. > >> Are the children here - regulator, reset controller and phys - related >> to the USB? > > Yes, this "glue layer" is an interface of the USB controller, so these > children are only used for the USB controller. OK Best regards, Krzysztof
On 2022/12/01 0:32, Krzysztof Kozlowski wrote: > On 30/11/2022 10:00, Kunihiko Hayashi wrote: >> Hi Krzysztof, >> >> On 2022/11/29 23:52, Krzysztof Kozlowski wrote: >>> On 29/11/2022 11:35, Kunihiko Hayashi wrote: >>>> Add DT binding schema for components belonging to the platform-specific >>>> DWC3 USB glue layer implemented in UniPhier SoCs. >>>> >>>> This USB glue layer works as a sideband logic for the host controller, >>>> including core reset, vbus control, PHYs, and some signals to the >>>> controller. >>>> >>>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> (snip) >>>> +examples: >>>> + - | >>>> + usb-controller@65b00000 { >>> >>> Node name: usb. There is no usage of "usb-controller". >> >> I'm confusing about that. >> >> This is an interface logic and doesn't have USB functions by itself. >> Surely there is a USB host controller node "usb@..." in the same SoC. >> Can this node be renamed to "usb"? >> >> I've renamed the dts node name once in commit 4cc752a88ca9 >> ("arm64: dts: uniphier: Rename usb-glue node for USB3 to usb-controller"). > > In (almost?) all other cases it is still called "usb". A bit akward to > have usb in usb, but usb-controller did not stick... I see. I understand that it is still better to use the generic name "usb" rather than "usb-controller". Thank you, --- Best Regards Kunihiko Hayashi
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml new file mode 100644 index 000000000000..66f8786dd305 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-dwc3-glue.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier SoC DWC3 USB3.0 glue layer + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +description: |+ + DWC3 USB3.0 glue layer implemented on Socionext UniPhier SoCs is + a sideband logic handling signals to DWC3 host controller inside + USB3.0 component. + +properties: + compatible: + items: + - enum: + - socionext,uniphier-pro4-dwc3-glue + - socionext,uniphier-pro5-dwc3-glue + - socionext,uniphier-pxs2-dwc3-glue + - socionext,uniphier-ld20-dwc3-glue + - socionext,uniphier-pxs3-dwc3-glue + - socionext,uniphier-nx1-dwc3-glue + - const: simple-mfd + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true + +patternProperties: + "^reset-controller@[0-9a-f]+$": + $ref: /schemas/reset/socionext,uniphier-glue-reset.yaml# + + "^regulator@[0-9a-f]+$": + $ref: /schemas/regulator/socionext,uniphier-regulator.yaml# + + "^phy@[0-9a-f]+$": + oneOf: + - $ref: /schemas/phy/socionext,uniphier-usb3hs-phy.yaml# + - $ref: /schemas/phy/socionext,uniphier-usb3ss-phy.yaml# + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + usb-controller@65b00000 { + compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd"; + reg = <0x65b00000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x65b00000 0x400>; + + reset-controller@0 { + compatible = "socionext,uniphier-ld20-usb3-reset"; + reg = <0x0 0x4>; + #reset-cells = <1>; + clock-names = "link"; + clocks = <&sys_clk 14>; + reset-names = "link"; + resets = <&sys_rst 14>; + }; + + regulator@100 { + compatible = "socionext,uniphier-ld20-usb3-regulator"; + reg = <0x100 0x10>; + clock-names = "link"; + clocks = <&sys_clk 14>; + reset-names = "link"; + resets = <&sys_rst 14>; + }; + + phy@200 { + compatible = "socionext,uniphier-ld20-usb3-hsphy"; + reg = <0x200 0x10>; + #phy-cells = <0>; + clock-names = "link", "phy"; + clocks = <&sys_clk 14>, <&sys_clk 16>; + reset-names = "link", "phy"; + resets = <&sys_rst 14>, <&sys_rst 16>; + }; + + phy@300 { + compatible = "socionext,uniphier-ld20-usb3-ssphy"; + reg = <0x300 0x10>; + #phy-cells = <0>; + clock-names = "link", "phy"; + clocks = <&sys_clk 14>, <&sys_clk 18>; + reset-names = "link", "phy"; + resets = <&sys_rst 14>, <&sys_rst 18>; + }; + }; +