Hi Stephen, Thanks for your comments! On Tue, Feb 25, 2020 at 6:02 PM Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > Quoting Geert Uytterhoeven (2020-02-24 07:26:40) > > diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml > > new file mode 100644 > > index 0000000000000000..dfbd1933f1bc56de > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml > > @@ -0,0 +1,204 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: "http://devicetree.org/schemas/clock/renesas,cpg-mssr.yaml#"; > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > > + > > +title: Renesas Clock Pulse Generator / Module Standby and Software Reset > > + > > +maintainers: > > + - Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > > + > > +description: | > > + On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse Generator) > > + and MSSR (Module Standby and Software Reset) blocks are intimately connected, > > + and share the same register block. > > + > > + They provide the following functionalities: > > + - The CPG block generates various core clocks, > > + - The MSSR block provides two functions: > > + 1. Module Standby, providing a Clock Domain to control the clock supply > > + to individual SoC devices, > > + 2. Reset Control, to perform a software reset of individual SoC devices. > > + > > +properties: > > + compatible: > > + enum: > > + - renesas,r7s9210-cpg-mssr # RZ/A2 > > + - renesas,r8a7743-cpg-mssr # RZ/G1M > > + - renesas,r8a7744-cpg-mssr # RZ/G1N > > + - renesas,r8a7745-cpg-mssr # RZ/G1E > > + - renesas,r8a77470-cpg-mssr # RZ/G1C > > + - renesas,r8a774a1-cpg-mssr # RZ/G2M > > + - renesas,r8a774b1-cpg-mssr # RZ/G2N > > + - renesas,r8a774c0-cpg-mssr # RZ/G2E > > + - renesas,r8a7790-cpg-mssr # R-Car H2 > > + - renesas,r8a7791-cpg-mssr # R-Car M2-W > > + - renesas,r8a7792-cpg-mssr # R-Car V2H > > + - renesas,r8a7793-cpg-mssr # R-Car M2-N > > + - renesas,r8a7794-cpg-mssr # R-Car E2 > > + - renesas,r8a7795-cpg-mssr # R-Car H3 > > + - renesas,r8a7796-cpg-mssr # R-Car M3-W > > + - renesas,r8a77961-cpg-mssr # R-Car M3-W+ > > + - renesas,r8a77965-cpg-mssr # R-Car M3-N > > + - renesas,r8a77970-cpg-mssr # R-Car V3M > > + - renesas,r8a77980-cpg-mssr # R-Car V3H > > + - renesas,r8a77990-cpg-mssr # R-Car E3 > > + - renesas,r8a77995-cpg-mssr # R-Car D3 > > + > > + reg: > > + maxItems: 1 > > + > > + clocks: > > + minItems: 1 > > + maxItems: 2 > > + > > + clock-names: > > + minItems: 1 > > + maxItems: 2 > > Do we need this here and also below? Why can't it just be below with the > more specific constraints? With the above removed: Documentation/devicetree/bindings/clock/renesas,cpg-mssr.example.dt.yaml: clock-controller@e6150000: 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+' while the "if" below overriding minItems did trigger, as removing entries from clocks/clock-names in the example causes more errors. So it seems all properties must be listed in the main, unconditional, properties section at the top. > > +allOf: > > + - if: > > + properties: > > + compatible: > > + items: > > + enum: > > + - renesas,r7s9210-cpg-mssr > > + - renesas,r8a774c0-cpg-mssr > > + - renesas,r8a7792-cpg-mssr > > + - renesas,r8a77990-cpg-mssr > > + - renesas,r8a77995-cpg-mssr > > + > > + then: > > + properties: > > + clock: > > + maxItems: 1 > > + clock-names: > > + maxItems: 1 > > + items: > > + - const: extal > > + > > + - if: > > + properties: > > + compatible: > > + contains: > > + enum: > > + - renesas,r8a7743-cpg-mssr > > + - renesas,r8a7744-cpg-mssr > > + - renesas,r8a7745-cpg-mssr > > + - renesas,r8a77470-cpg-mssr > > + - renesas,r8a7790-cpg-mssr > > + - renesas,r8a7791-cpg-mssr > > + - renesas,r8a7793-cpg-mssr > > + - renesas,r8a7794-cpg-mssr > > + > > + then: > > + properties: > > + clock: > > + minItems: 2 > > + clock-names: > > + minItems: 2 > > + items: > > + - const: extal > > + - const: usb_extal > > + > > + - if: > > + properties: > > + compatible: > > + items: > > + enum: > > + - renesas,r8a774a1-cpg-mssr > > + - renesas,r8a774b1-cpg-mssr > > + - renesas,r8a7795-cpg-mssr > > + - renesas,r8a7796-cpg-mssr > > + - renesas,r8a77961-cpg-mssr > > + - renesas,r8a77965-cpg-mssr > > + - renesas,r8a77970-cpg-mssr > > + - renesas,r8a77980-cpg-mssr > > + > > + then: > > + properties: > > + clock: > > + minItems: 2 > > + clock-names: > > + minItems: 2 > > + items: > > + - const: extal > > + - const: extalr > > + > > + - if: > > + not: > > + properties: > > + compatible: > > + items: > > + enum: > > + - renesas,r7s9210-cpg-mssr > > + then: > > + required: > > + - '#reset-cells' > > It may make sense to split this binding up into multiple bindings so > that we don't have deeply nested if/else/then. Note that the above is not a nested if, but the yaml-equivalent of a switch() statement. If this is to be split, how to split it? Each if contains SoCs from multiple families, and each family of SoCs is split across multiple ifs. > > +examples: > > + - | > > + // CPG device node: > > + > > + cpg: clock-controller@e6150000 { > > + compatible = "renesas,r8a7795-cpg-mssr"; > > + reg = <0xe6150000 0x1000>; > > + clocks = <&extal_clk>, <&extalr_clk>; > > + clock-names = "extal", "extalr"; > > + #clock-cells = <2>; > > + #power-domain-cells = <0>; > > + #reset-cells = <1>; > > + }; > > + > > + - | > > + // CPG/MSSR Clock Domain member device node: > > + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> > > + #include <dt-bindings/interrupt-controller/arm-gic.h> > > + > > + scif2: serial@e6e88000 { > > + compatible = "renesas,scif-r8a7795", "renesas,rcar-gen3-scif", > > + "renesas,scif"; > > + reg = <0xe6e88000 64>; > > + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; > > + clocks = <&cpg CPG_MOD 310>, <&cpg CPG_CORE R8A7795_CLK_S3D1>, > > + <&scif_clk>; > > + clock-names = "fck"; > > + dmas = <&dmac1 0x13>, <&dmac1 0x12>, <&dmac2 0x13>, <&dmac2 0x12>; > > + dma-names = "tx", "rx", "tx", "rx"; > > + power-domains = <&cpg>; > > + resets = <&cpg 310>; > > + }; > > I'm not sure we need this in the example. OK, the second example can be removed. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
