Message ID | 20221129103509.9958-3-hayashi.kunihiko@socionext.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | dt-bidnings: soc: Introduce UniPhier miscelaneous register blocks | expand |
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>; + }; + };
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