Re: [PATCH v2 4/5] dt-bindings: clock: uniphier: Add clock binding for SoC-glue

[Rob Herring]

On Thu, Oct 7, 2021 at 3:50 AM Kunihiko Hayashi
<hayashi.kunihiko@xxxxxxxxxxxxx> wrote:
>
> Hi Rob,
>
> On 2021/10/07 4:49, Rob Herring wrote:
> > On Wed, Oct 06, 2021 at 08:09:14PM +0900, Kunihiko Hayashi wrote:
> >> Update binding document for clocks implemented in SoC-glue.
> >>
> >> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@xxxxxxxxxxxxx>
> >> ---
> >>   .../bindings/clock/socionext,uniphier-clock.yaml         | 16
> > ++++++++++++++++
> >>   1 file changed, 16 insertions(+)
> >>
> >> diff --git
> > a/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
> > b/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
> >> index ee8d16a8019e..05a9d1f89756 100644
> >> ---
> > a/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
> >> +++
> > b/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
> >> @@ -46,6 +46,9 @@ properties:
> >>             - socionext,uniphier-ld20-peri-clock
> >>             - socionext,uniphier-pxs3-peri-clock
> >>             - socionext,uniphier-nx1-peri-clock
> >> +      - description: SoC-glue clock
> >> +        enum:
> >> +          - socionext,uniphier-pro4-sg-clock
> >>
> >>     "#clock-cells":
> >>       const: 1
> >> @@ -95,3 +98,16 @@ examples:
> >>
> >>           // other nodes ...
> >>       };
> >> +
> >> +  - |
> >> +    soc-glue@5f800000 {
> >> +        compatible = "socionext,uniphier-sysctrl", "simple-mfd",
> > "syscon";
> >> +        reg = <0x5f800000 0x2000>;
> >> +
> >> +        clock {
> >> +            compatible = "socionext,uniphier-pro4-sg-clock";
> >> +            #clock-cells = <1>;
> >> +        };
> >> +
> >> +        // other nodes ...
> >> +    };
> >
> > What's the value of this 2nd example? It's just a different compatible
> > string.
> Following the previous three examples in the document, it describes the
> difference between the parent nodes that place the clock.
>
> They are common to be child nodes of "syscon", and the definition of the
> parent node is not in this document.
> Should I put them together in a common example?

I'd just drop the example.

Rob