Message ID | 20221129103509.9958-3-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 q4csp253811wrr; Tue, 29 Nov 2022 02:35:50 -0800 (PST) X-Google-Smtp-Source: AA0mqf6QknpPELLYetmvbSjWnu1LU17UmLXG+QRIgJ9q8kuvzrk4a4VUAwpn6f4U/jqNREihP1lL X-Received: by 2002:a63:2484:0:b0:478:2620:d7ec with SMTP id k126-20020a632484000000b004782620d7ecmr7266665pgk.100.1669718150021; Tue, 29 Nov 2022 02:35:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669718150; cv=none; d=google.com; s=arc-20160816; b=k8LQgRPn8tNSDT04QKH7xJSZfD8hadL1Huq8ED+6oWxaiAOsYVCP9mahM7Z9ZFpE5S EYrZ9loOBhP24B34EB4iqtJkqD2fAQWTryOcBssHQbib7Doj3/UNBVq3kA11Sf8jgjAD +FqJVmtlQlhTwLBbnN58VKgJp9/bWVf+cI1KskhvFEcgJqgS/9SK5Ngk275+raRYn7cx gyAT17DVNYKsnm1nBMkYntDG7EJINhofapBWtNg93CMhHILH9EJpAE0xQ34ppEwvv4kT n+WGBt+SmJFf0MEdHXIzPM3PCOrxUO6ci15CWnX3flLpZp7HuZJo+qraw4Zp+L7YTdHT JDLg== 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=SyDneiBI6EXSTPQ4q3Vub5EMgndrAZh40LaiyegsZlg=; b=V858HL5IJb9x/Im1vsB5XnDKH2MWY+nIfRv4dW3gqus+Hyfe4nu2adsvQOuWrXMzMZ nZ8u1fczCH1Y01jDtML8IDHTx3Z+HO1SHhpZ+zJH86A96i+L+GXmnF2CmjmBR4Zng8Ku Yc4VTilmyKI/7KYNfjjTigTA0KRlL18eBXPAQcJvopTOwIqgxWp1lZwz4WSIAi6/z3qD kAuIYHRt9aZAhau52Miv//dTHEqdSnR7x58cCp8hsfVK5uszq2O97rrJCz2eoR9R8W1Q Bz5s2eWkzKVvFEqZxtdNLKkrQHniiL8senkN0mKUTT/BQ3c/Kw1aLQbL4IWcTae2BzGK wahg== 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 k8-20020a170902c40800b00189957dd8f1si3243931plk.343.2022.11.29.02.35.36; Tue, 29 Nov 2022 02:35:50 -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 S230274AbiK2KfW (ORCPT <rfc822;rbbytesnap@gmail.com> + 99 others); Tue, 29 Nov 2022 05:35:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230217AbiK2KfS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 29 Nov 2022 05:35:18 -0500 Received: from mx.socionext.com (mx.socionext.com [202.248.49.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5786AB97; Tue, 29 Nov 2022 02:35:17 -0800 (PST) Received: from unknown (HELO kinkan2-ex.css.socionext.com) ([172.31.9.52]) by mx.socionext.com with ESMTP; 29 Nov 2022 19:35:17 +0900 Received: from mail.mfilter.local (m-filter-2 [10.213.24.62]) by kinkan2-ex.css.socionext.com (Postfix) with ESMTP id 1A6132059054; 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 A2F8CA8556; Tue, 29 Nov 2022 19:35:16 +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 2/8] dt-bindings: soc: socionext: Add UniPhier SoC-glue logic Date: Tue, 29 Nov 2022 19:35:03 +0900 Message-Id: <20221129103509.9958-3-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?1750826378957584415?= X-GMAIL-MSGID: =?utf-8?q?1750826378957584415?= |
Series |
dt-bidnings: soc: Introduce UniPhier miscelaneous register blocks
|
|
Commit Message
Kunihiko Hayashi
Nov. 29, 2022, 10:35 a.m. UTC
Add devicetree binding schema for the SoC-glue logic implemented on
Socionext Uniphier SoCs.
This SoC-glue logic is a set of miscellaneous function registers
handling signals for specific devices outside system components,
and also has multiple functions such as I/O pinmux, usb-phy, debug,
clock-mux for a specific SoC, and so on.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
.../socionext,uniphier-soc-glue.yaml | 94 +++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml
Comments
On 29/11/2022 11:35, Kunihiko Hayashi wrote: > Add devicetree binding schema for the SoC-glue logic implemented on > Socionext Uniphier SoCs. > > This SoC-glue logic is a set of miscellaneous function registers > handling signals for specific devices outside system components, > and also has multiple functions such as I/O pinmux, usb-phy, debug, > clock-mux for a specific SoC, and so on. > > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> > --- > .../socionext,uniphier-soc-glue.yaml | 94 +++++++++++++++++++ > 1 file changed, 94 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml > > diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml > new file mode 100644 > index 000000000000..3f571e3e1339 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml > @@ -0,0 +1,94 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Socionext UniPhier SoC-glue logic > + > +maintainers: > + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> > + > +description: |+ > + SoC-glue logic implemented on Socionext UniPhier SoCs is a collection of > + miscellaneous function registers handling signals outside system components. > + > +properties: > + compatible: > + items: > + - enum: > + - socionext,uniphier-ld4-soc-glue > + - socionext,uniphier-pro4-soc-glue > + - socionext,uniphier-pro5-soc-glue > + - socionext,uniphier-pxs2-soc-glue > + - socionext,uniphier-ld6b-soc-glue > + - socionext,uniphier-sld8-soc-glue > + - socionext,uniphier-ld11-soc-glue > + - socionext,uniphier-ld20-soc-glue > + - socionext,uniphier-pxs3-soc-glue > + - socionext,uniphier-nx1-soc-glue > + - socionext,uniphier-soc-glue This one looks generic - why having it next to specific ones? Same question for your previous patch - socionext,uniphier-sysctrl. And similarly to previous patch, do you expect child nodes everywhere? > + - const: simple-mfd > + - const: syscon > + > + reg: > + maxItems: 1 > + > +patternProperties: > + "^pinctrl(@[0-9a-f]+)?$": > + $ref: /schemas/pinctrl/socionext,uniphier-pinctrl.yaml# > + > + "^usb-controller(@[0-9a-f]+)?$": > + $ref: /schemas/phy/socionext,uniphier-usb2-phy.yaml# > + > + "^clock-controller(@[0-9a-f]+)?$": > + $ref: /schemas/clock/socionext,uniphier-clock.yaml# > + Best regards, Krzysztof
Hi Krzysztof, On 2022/11/29 23:43, Krzysztof Kozlowski wrote: > On 29/11/2022 11:35, Kunihiko Hayashi wrote: >> Add devicetree binding schema for the SoC-glue logic implemented on >> Socionext Uniphier SoCs. >> >> This SoC-glue logic is a set of miscellaneous function registers >> handling signals for specific devices outside system components, >> and also has multiple functions such as I/O pinmux, usb-phy, debug, >> clock-mux for a specific SoC, and so on. >> >> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >> --- >> .../socionext,uniphier-soc-glue.yaml | 94 +++++++++++++++++++ >> 1 file changed, 94 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >> >> diff --git >> a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >> new file mode 100644 >> index 000000000000..3f571e3e1339 >> --- /dev/null >> +++ >> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >> @@ -0,0 +1,94 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: >> http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Socionext UniPhier SoC-glue logic >> + >> +maintainers: >> + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >> + >> +description: |+ >> + SoC-glue logic implemented on Socionext UniPhier SoCs is a collection >> of >> + miscellaneous function registers handling signals outside system >> components. >> + >> +properties: >> + compatible: >> + items: >> + - enum: >> + - socionext,uniphier-ld4-soc-glue >> + - socionext,uniphier-pro4-soc-glue >> + - socionext,uniphier-pro5-soc-glue >> + - socionext,uniphier-pxs2-soc-glue >> + - socionext,uniphier-ld6b-soc-glue >> + - socionext,uniphier-sld8-soc-glue >> + - socionext,uniphier-ld11-soc-glue >> + - socionext,uniphier-ld20-soc-glue >> + - socionext,uniphier-pxs3-soc-glue >> + - socionext,uniphier-nx1-soc-glue >> + - socionext,uniphier-soc-glue > > This one looks generic - why having it next to specific ones? SoC-glue has the same register set, but different implementations for each SoC. I thought of defining the same register set as a common specs, but each compatibles are sufficient. I'll remove it. > Same question for your previous patch - socionext,uniphier-sysctrl. > > And similarly to previous patch, do you expect child nodes everywhere? In case of this SoC-glue logic, all SoCs has pinctrl, however, only SoCs with USB2 host has usb-controller (phy-hub). And only legacy SoCs implement clock-controller (clk-mux) here. Should child nodes that exist only in a specific "compatible" be defined conditionally? >> + - const: simple-mfd >> + - const: syscon >> + >> + reg: >> + maxItems: 1 >> + >> +patternProperties: >> + "^pinctrl(@[0-9a-f]+)?$": >> + $ref: /schemas/pinctrl/socionext,uniphier-pinctrl.yaml# >> + >> + "^usb-controller(@[0-9a-f]+)?$": >> + $ref: /schemas/phy/socionext,uniphier-usb2-phy.yaml# >> + >> + "^clock-controller(@[0-9a-f]+)?$": >> + $ref: /schemas/clock/socionext,uniphier-clock.yaml# >> + Thank you, --- Best Regards Kunihiko Hayashi
On 30/11/2022 09:59, Kunihiko Hayashi wrote: > Hi Krzysztof, > > On 2022/11/29 23:43, Krzysztof Kozlowski wrote: >> On 29/11/2022 11:35, Kunihiko Hayashi wrote: >>> Add devicetree binding schema for the SoC-glue logic implemented on >>> Socionext Uniphier SoCs. >>> >>> This SoC-glue logic is a set of miscellaneous function registers >>> handling signals for specific devices outside system components, >>> and also has multiple functions such as I/O pinmux, usb-phy, debug, >>> clock-mux for a specific SoC, and so on. >>> >>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >>> --- >>> .../socionext,uniphier-soc-glue.yaml | 94 +++++++++++++++++++ >>> 1 file changed, 94 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >>> >>> diff --git >>> a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >>> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >>> new file mode 100644 >>> index 000000000000..3f571e3e1339 >>> --- /dev/null >>> +++ >>> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >>> @@ -0,0 +1,94 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: >>> http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Socionext UniPhier SoC-glue logic >>> + >>> +maintainers: >>> + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >>> + >>> +description: |+ >>> + SoC-glue logic implemented on Socionext UniPhier SoCs is a collection >>> of >>> + miscellaneous function registers handling signals outside system >>> components. >>> + >>> +properties: >>> + compatible: >>> + items: >>> + - enum: >>> + - socionext,uniphier-ld4-soc-glue >>> + - socionext,uniphier-pro4-soc-glue >>> + - socionext,uniphier-pro5-soc-glue >>> + - socionext,uniphier-pxs2-soc-glue >>> + - socionext,uniphier-ld6b-soc-glue >>> + - socionext,uniphier-sld8-soc-glue >>> + - socionext,uniphier-ld11-soc-glue >>> + - socionext,uniphier-ld20-soc-glue >>> + - socionext,uniphier-pxs3-soc-glue >>> + - socionext,uniphier-nx1-soc-glue >>> + - socionext,uniphier-soc-glue >> >> This one looks generic - why having it next to specific ones? > > SoC-glue has the same register set, but different implementations > for each SoC. Sure, but you did not model it as a compatible fallback, but like one of variants. It is not tied to specific SoC, thus too generic. > I thought of defining the same register set as a common specs, > but each compatibles are sufficient. I'll remove it. > >> Same question for your previous patch - socionext,uniphier-sysctrl. >> >> And similarly to previous patch, do you expect child nodes everywhere? > > In case of this SoC-glue logic, all SoCs has pinctrl, however, > only SoCs with USB2 host has usb-controller (phy-hub). > And only legacy SoCs implement clock-controller (clk-mux) here. > > Should child nodes that exist only in a specific "compatible" be defined > conditionally? No, rather define them in top level but disallow for specific compatibles: allOf: - if: .... then: patternProperties: ...: false Assuming that this does not over-complicate schema. Best regards, Krzysztof
On 2022/12/01 0:27, Krzysztof Kozlowski wrote: > On 30/11/2022 09:59, Kunihiko Hayashi wrote: >> Hi Krzysztof, >> >> On 2022/11/29 23:43, Krzysztof Kozlowski wrote: >>> On 29/11/2022 11:35, Kunihiko Hayashi wrote: >>>> Add devicetree binding schema for the SoC-glue logic implemented on >>>> Socionext Uniphier SoCs. >>>> >>>> This SoC-glue logic is a set of miscellaneous function registers >>>> handling signals for specific devices outside system components, >>>> and also has multiple functions such as I/O pinmux, usb-phy, debug, >>>> clock-mux for a specific SoC, and so on. >>>> >>>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >>>> --- >>>> .../socionext,uniphier-soc-glue.yaml | 94 +++++++++++++++++++ >>>> 1 file changed, 94 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >>>> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >>>> new file mode 100644 >>>> index 000000000000..3f571e3e1339 >>>> --- /dev/null >>>> +++ >>>> b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml >>>> @@ -0,0 +1,94 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: >>>> http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Socionext UniPhier SoC-glue logic >>>> + >>>> +maintainers: >>>> + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >>>> + >>>> +description: |+ >>>> + SoC-glue logic implemented on Socionext UniPhier SoCs is a collection >>>> of >>>> + miscellaneous function registers handling signals outside system >>>> components. >>>> + >>>> +properties: >>>> + compatible: >>>> + items: >>>> + - enum: >>>> + - socionext,uniphier-ld4-soc-glue >>>> + - socionext,uniphier-pro4-soc-glue >>>> + - socionext,uniphier-pro5-soc-glue >>>> + - socionext,uniphier-pxs2-soc-glue >>>> + - socionext,uniphier-ld6b-soc-glue >>>> + - socionext,uniphier-sld8-soc-glue >>>> + - socionext,uniphier-ld11-soc-glue >>>> + - socionext,uniphier-ld20-soc-glue >>>> + - socionext,uniphier-pxs3-soc-glue >>>> + - socionext,uniphier-nx1-soc-glue >>>> + - socionext,uniphier-soc-glue >>> >>> This one looks generic - why having it next to specific ones? >> >> SoC-glue has the same register set, but different implementations >> for each SoC. > > Sure, but you did not model it as a compatible fallback, but like one of > variants. It is not tied to specific SoC, thus too generic. I understand. It should be placed in parallel with enum. item: - enum: - ... - ... - const: socionext,uniphier-soc-glue >> I thought of defining the same register set as a common specs, >> but each compatibles are sufficient. I'll remove it. So currently drop it. >> >>> Same question for your previous patch - socionext,uniphier-sysctrl. >>> >>> And similarly to previous patch, do you expect child nodes everywhere? >> >> In case of this SoC-glue logic, all SoCs has pinctrl, however, >> only SoCs with USB2 host has usb-controller (phy-hub). >> And only legacy SoCs implement clock-controller (clk-mux) here. >> >> Should child nodes that exist only in a specific "compatible" be defined >> conditionally? > > No, rather define them in top level but disallow for specific compatibles: > > allOf: > - if: > .... > then: > patternProperties: > ...: false > > Assuming that this does not over-complicate schema. OK. Some properties are applied for a few compatibles, so I think it is available to use "else:". allOf: - if: ... else: patternProperties: ...: false Thank you, --- Best Regards Kunihiko Hayashi
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml new file mode 100644 index 000000000000..3f571e3e1339 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier SoC-glue logic + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +description: |+ + SoC-glue logic implemented on Socionext UniPhier SoCs is a collection of + miscellaneous function registers handling signals outside system components. + +properties: + compatible: + items: + - enum: + - socionext,uniphier-ld4-soc-glue + - socionext,uniphier-pro4-soc-glue + - socionext,uniphier-pro5-soc-glue + - socionext,uniphier-pxs2-soc-glue + - socionext,uniphier-ld6b-soc-glue + - socionext,uniphier-sld8-soc-glue + - socionext,uniphier-ld11-soc-glue + - socionext,uniphier-ld20-soc-glue + - socionext,uniphier-pxs3-soc-glue + - socionext,uniphier-nx1-soc-glue + - socionext,uniphier-soc-glue + - const: simple-mfd + - const: syscon + + reg: + maxItems: 1 + +patternProperties: + "^pinctrl(@[0-9a-f]+)?$": + $ref: /schemas/pinctrl/socionext,uniphier-pinctrl.yaml# + + "^usb-controller(@[0-9a-f]+)?$": + $ref: /schemas/phy/socionext,uniphier-usb2-phy.yaml# + + "^clock-controller(@[0-9a-f]+)?$": + $ref: /schemas/clock/socionext,uniphier-clock.yaml# + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + syscon@5f800000 { + compatible = "socionext,uniphier-pro4-soc-glue", + "simple-mfd", "syscon"; + reg = <0x5f800000 0x2000>; + + pinctrl { + compatible = "socionext,uniphier-pro4-pinctrl"; + }; + + usb-controller { + compatible = "socionext,uniphier-pro4-usb2-phy"; + #address-cells = <1>; + #size-cells = <0>; + + phy@0 { + reg = <0>; + #phy-cells = <0>; + }; + + phy@1 { + reg = <1>; + #phy-cells = <0>; + }; + + phy@2 { + reg = <2>; + #phy-cells = <0>; + }; + + phy@3 { + reg = <3>; + #phy-cells = <0>; + }; + }; + + clock-controller { + compatible = "socionext,uniphier-pro4-sg-clock"; + #clock-cells = <1>; + }; + };