| Message ID | 20240127121937.2372098-1-niklas.soderlund+renesas@ragnatech.se (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | [v2] dt-bindings: renesas: Document preferred compatible naming | expand |
On Sat, 27 Jan 2024 13:19:37 +0100, Niklas Söderlund wrote: > Compatibles can come in two formats. Either "vendor,ip-soc" or > "vendor,soc-ip". Add a DT schema file documenting Renesas preferred > policy and enforcing it for all new compatibles, except few existing > patterns. > > Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > --- > * Changes since v1 > - Split the "SoC agnostic compatibles" section into two to make it's > intent clearer. > - Improved the documentation for each group of compatibles. > - Reduced the number of regexp to create a larger target area. As > suggested by Krzysztof the goal is not to validate each SoC name but > check for the correct order of SoC-IP. > > * Changes since RFC > - Moved to Documentation/devicetree/bindings/soc/renesas. > - Changed the pattern in the initial select to match on .*-.*. > - Added a lot of missing compatible values. > --- > .../bindings/soc/renesas/renesas-soc.yaml | 135 ++++++++++++++++++ > 1 file changed, 135 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > Acked-by: Rob Herring <robh@kernel.org>
Hi, I'm unsure who to ping for this patch. It have been acked by Rob so is the intention this can go thru Geert's Renesas tree? On 2024-01-27 13:19:37 +0100, Niklas Söderlund wrote: > Compatibles can come in two formats. Either "vendor,ip-soc" or > "vendor,soc-ip". Add a DT schema file documenting Renesas preferred > policy and enforcing it for all new compatibles, except few existing > patterns. > > Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > --- > * Changes since v1 > - Split the "SoC agnostic compatibles" section into two to make it's > intent clearer. > - Improved the documentation for each group of compatibles. > - Reduced the number of regexp to create a larger target area. As > suggested by Krzysztof the goal is not to validate each SoC name but > check for the correct order of SoC-IP. > > * Changes since RFC > - Moved to Documentation/devicetree/bindings/soc/renesas. > - Changed the pattern in the initial select to match on .*-.*. > - Added a lot of missing compatible values. > --- > .../bindings/soc/renesas/renesas-soc.yaml | 135 ++++++++++++++++++ > 1 file changed, 135 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > > diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > new file mode 100644 > index 000000000000..91310d23cf0b > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > @@ -0,0 +1,135 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/renesas/renesas-soc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Renesas SoC compatibles naming convention > + > +maintainers: > + - Geert Uytterhoeven <geert+renesas@glider.be> > + - Niklas Söderlund <niklas.soderlund@ragnatech.se> > + > +description: | > + Guidelines for new compatibles for SoC blocks/components. > + When adding new compatibles in new bindings, use the format:: > + renesas,SoC-IP > + > + For example:: > + renesas,r8a77965-csi2 > + > + When adding new compatibles to existing bindings, use the format in the > + existing binding, even if it contradicts the above. > + > +select: > + properties: > + compatible: > + pattern: "^renesas,.*-.*$" > + required: > + - compatible > + > +properties: > + compatible: > + oneOf: > + # Preferred naming style for compatibles of SoC components > + - pattern: "^renesas,emev2-[a-z0-9-]+$" > + - pattern: "^renesas,r(7s|8a|9a)[a-z0-9]+-[a-z0-9-]+$" > + - pattern: "^renesas,rcar-[a-z0-9-]+$" > + - pattern: "^renesas,rz[a-z0-9]*-[a-z0-9-]+$" > + - pattern: "^renesas,sh-[a-z0-9-]+$" > + - pattern: "^renesas,sh7[a-z0-9]+-[a-z0-9-]+$" > + > + # Fallback compatibles > + # > + # Some SoC components in addition to a specific SoC compatible have a > + # generic fallback compatible. For example the Interrupt Controller, > + # > + # compatible = "renesas,intc-irqpin-r8a7740", "renesas,intc-irqpin"; > + # > + # This is OK and new fallback compatibles are allowed. > + - enum: > + - renesas,cpg-div6-clock > + - renesas,cpg-mstp-clocks > + - renesas,intc-irqpin > + > + # Legacy compatibles > + # > + # New compatibles are not allowed but new variations of existing > + # patterns/compatibles are. > + - pattern: "^renesas,can-[a-z0-9]+$" > + - pattern: "^renesas,dmac-[a-z0-9]+$" > + - pattern: "^renesas,du-[a-z0-9]+$" > + - pattern: "^renesas,ether-[a-z0-9]+$" > + - pattern: "^renesas,etheravb-[a-z0-9]+$" > + - pattern: "^renesas,etheravb-rcar-gen[0-9]$" > + - pattern: "^renesas,gether-[a-z0-9]+$" > + - pattern: "^renesas,gpio-[a-z0-9]+$" > + - pattern: "^renesas,hscif-[a-z0-9]+$" > + - pattern: "^renesas,i2c-[a-z0-9]+$" > + - pattern: "^renesas,iic-[a-z0-9]+$" > + - pattern: "^renesas,intc-ex-[a-z0-9]+$" > + - pattern: "^renesas,intc-irqpin-[a-z0-9]+$" > + - pattern: "^renesas,ipmmu-[a-z0-9]+$" > + - pattern: "^renesas,irqc-[a-z0-9]+$" > + - pattern: "^renesas,jpu-[a-z0-9]+$" > + - pattern: "^renesas,mmcif-[a-z0-9]+$" > + - pattern: "^renesas,msiof-[a-z0-9]+$" > + - pattern: "^renesas,pci-[a-z0-9]+$" > + - pattern: "^renesas,pci-rcar-gen[0-9]$" > + - pattern: "^renesas,pcie-[a-z0-9]+$" > + - pattern: "^renesas,pcie-rcar-gen[0-9]$" > + - pattern: "^renesas,pfc-[a-z0-9]+$" > + - pattern: "^renesas,pwm-[a-z0-9]+$" > + - pattern: "^renesas,qspi-[a-z0-9]+$" > + - pattern: "^renesas,rcar_sound-[a-z0-9]+$" > + - pattern: "^renesas,riic-[a-z0-9]+$" > + - pattern: "^renesas,rspi-[a-z0-9]+$" > + - pattern: "^renesas,sata-[a-z0-9]+(-es1)?$" > + - pattern: "^renesas,scif-[a-z0-9]+$" > + - pattern: "^renesas,scifa-[a-z0-9]+$" > + - pattern: "^renesas,scifb-[a-z0-9]+$" > + - pattern: "^renesas,sdhi-[a-z0-9]+$" > + - pattern: "^renesas,thermal-[a-z0-9]+$" > + - pattern: "^renesas,tmu-[a-z0-9]+$" > + - pattern: "^renesas,tpu-[a-z0-9]+$" > + - pattern: "^renesas,usb-phy-[a-z0-9]+$" > + - pattern: "^renesas,usb2-phy-[a-z0-9]+$" > + - pattern: "^renesas,usbhs-[a-z0-9]+$" > + - pattern: "^renesas,vin-[a-z0-9]+$" > + - pattern: "^renesas,xhci-[a-z0-9]+$" > + > + # Fixed legacy compatibles > + # > + # List cannot grow with new bindings. > + - enum: > + - renesas,bsc-r8a73a4 > + - renesas,bsc-sh73a0 > + - renesas,dbsc-r8a73a4 > + - renesas,dbsc3-r8a7740 > + - renesas,em-gio > + - renesas,em-sti > + - renesas,em-uart > + - renesas,fsi2-r8a7740 > + - renesas,fsi2-sh73a0 > + - renesas,hspi-r8a7778 > + - renesas,hspi-r8a7779 > + - renesas,imr-lx4 > + - renesas,mtu2-r7s72100 > + - renesas,rmobile-iic > + - renesas,sbsc-sh73a0 > + - renesas,sdhi-mmc-r8a77470 > + - renesas,shmobile-flctl-sh7372 > + - renesas,sysc-r8a73a4 > + - renesas,sysc-r8a7740 > + - renesas,sysc-rmobile > + - renesas,sysc-sh73a0 > + - renesas,usb-dmac > + > + # None SoC component compatibles > + # > + # Compatibles with the Renesas vendor prefix that do not relate to any SoC > + # component are OK. New compatibles are allowed. > + - enum: > + - renesas,smp-sram > + > +additionalProperties: true > -- > 2.43.0 >
On Sat, Feb 10, 2024 at 02:06:19PM +0100, Niklas Söderlund wrote: > I'm unsure who to ping for this patch. It have been acked by Rob so is > the intention this can go thru Geert's Renesas tree? That would be the expectation, yes.
Hi Niklas, On Sat, Jan 27, 2024 at 1:20 PM Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> wrote: > Compatibles can come in two formats. Either "vendor,ip-soc" or > "vendor,soc-ip". Add a DT schema file documenting Renesas preferred > policy and enforcing it for all new compatibles, except few existing > patterns. > > Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > --- > * Changes since v1 > - Split the "SoC agnostic compatibles" section into two to make it's > intent clearer. > - Improved the documentation for each group of compatibles. > - Reduced the number of regexp to create a larger target area. As > suggested by Krzysztof the goal is not to validate each SoC name but > check for the correct order of SoC-IP. Thanks for the update! > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > @@ -0,0 +1,135 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/renesas/renesas-soc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Renesas SoC compatibles naming convention > + > +maintainers: > + - Geert Uytterhoeven <geert+renesas@glider.be> > + - Niklas Söderlund <niklas.soderlund@ragnatech.se> > + > +description: | > + Guidelines for new compatibles for SoC blocks/components. > + When adding new compatibles in new bindings, use the format:: > + renesas,SoC-IP or renesas,Family-IP? > + > + For example:: > + renesas,r8a77965-csi2 > + > + When adding new compatibles to existing bindings, use the format in the > + existing binding, even if it contradicts the above. > + > +select: > + properties: > + compatible: > + pattern: "^renesas,.*-.*$" > + required: > + - compatible > + > +properties: > + compatible: > + oneOf: > + # Preferred naming style for compatibles of SoC components > + - pattern: "^renesas,emev2-[a-z0-9-]+$" > + - pattern: "^renesas,r(7s|8a|9a)[a-z0-9]+-[a-z0-9-]+$" > + - pattern: "^renesas,rcar-[a-z0-9-]+$" > + - pattern: "^renesas,rz[a-z0-9]*-[a-z0-9-]+$" > + - pattern: "^renesas,sh-[a-z0-9-]+$" > + - pattern: "^renesas,sh7[a-z0-9]+-[a-z0-9-]+$" I guess it's not worth adding rmobile and shmobile prefixes? > + # Fixed legacy compatibles > + # > + # List cannot grow with new bindings. > + - enum: > + - renesas,bsc-r8a73a4 > + - renesas,bsc-sh73a0 > + - renesas,dbsc-r8a73a4 > + - renesas,dbsc3-r8a7740 > + - renesas,em-gio > + - renesas,em-sti > + - renesas,em-uart Perhaps combine these three: "renesas,em-(gpio|sti|usrt)"? > + - renesas,fsi2-r8a7740 > + - renesas,fsi2-sh73a0 Likewise > + - renesas,hspi-r8a7778 > + - renesas,hspi-r8a7779 Etc. ;-) Now, how do I trigger violations? I added the following to a binding file: - enum: - renesas,bogus-r8a7778 - renesas,bogus-r8a7779 - const: renesas,bogus but nothing happened with "make dt_binding_check". I added the following to a DTS file: compatible = "renesas,bogus-r8a7778", "renesas,bogus"; again, nothing happened with "make dtbs_check". What am I missing? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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
Hi Geert, Thanks for your feedback. On 2024-02-12 20:36:12 +0100, Geert Uytterhoeven wrote: > Hi Niklas, > > On Sat, Jan 27, 2024 at 1:20 PM Niklas Söderlund > <niklas.soderlund+renesas@ragnatech.se> wrote: > > Compatibles can come in two formats. Either "vendor,ip-soc" or > > "vendor,soc-ip". Add a DT schema file documenting Renesas preferred > > policy and enforcing it for all new compatibles, except few existing > > patterns. > > > > Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > --- > > * Changes since v1 > > - Split the "SoC agnostic compatibles" section into two to make it's > > intent clearer. > > - Improved the documentation for each group of compatibles. > > - Reduced the number of regexp to create a larger target area. As > > suggested by Krzysztof the goal is not to validate each SoC name but > > check for the correct order of SoC-IP. > > Thanks for the update! > > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > > @@ -0,0 +1,135 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/soc/renesas/renesas-soc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Renesas SoC compatibles naming convention > > + > > +maintainers: > > + - Geert Uytterhoeven <geert+renesas@glider.be> > > + - Niklas Söderlund <niklas.soderlund@ragnatech.se> > > + > > +description: | > > + Guidelines for new compatibles for SoC blocks/components. > > + When adding new compatibles in new bindings, use the format:: > > + renesas,SoC-IP > > or renesas,Family-IP? > > > + > > + For example:: > > + renesas,r8a77965-csi2 > > + > > + When adding new compatibles to existing bindings, use the format in the > > + existing binding, even if it contradicts the above. > > + > > +select: > > + properties: > > + compatible: > > + pattern: "^renesas,.*-.*$" > > + required: > > + - compatible > > + > > +properties: > > + compatible: > > + oneOf: > > + # Preferred naming style for compatibles of SoC components > > + - pattern: "^renesas,emev2-[a-z0-9-]+$" > > + - pattern: "^renesas,r(7s|8a|9a)[a-z0-9]+-[a-z0-9-]+$" > > + - pattern: "^renesas,rcar-[a-z0-9-]+$" > > + - pattern: "^renesas,rz[a-z0-9]*-[a-z0-9-]+$" > > + - pattern: "^renesas,sh-[a-z0-9-]+$" > > + - pattern: "^renesas,sh7[a-z0-9]+-[a-z0-9-]+$" > > I guess it's not worth adding rmobile and shmobile prefixes? Maybe we start with this and see how it goes? > > > + # Fixed legacy compatibles > > + # > > + # List cannot grow with new bindings. > > + - enum: > > + - renesas,bsc-r8a73a4 > > + - renesas,bsc-sh73a0 > > + - renesas,dbsc-r8a73a4 > > + - renesas,dbsc3-r8a7740 > > + - renesas,em-gio > > + - renesas,em-sti > > + - renesas,em-uart > > Perhaps combine these three: "renesas,em-(gpio|sti|usrt)"? Will do. > > > + - renesas,fsi2-r8a7740 > > + - renesas,fsi2-sh73a0 > > Likewise Will do. > > > + - renesas,hspi-r8a7778 > > + - renesas,hspi-r8a7779 > > Etc. ;-) Will do :-) > > Now, how do I trigger violations? > > I added the following to a binding file: > > - enum: > - renesas,bogus-r8a7778 > - renesas,bogus-r8a7779 > - const: renesas,bogus > > but nothing happened with "make dt_binding_check". > > I added the following to a DTS file: > > compatible = "renesas,bogus-r8a7778", "renesas,bogus"; > > again, nothing happened with "make dtbs_check". > > What am I missing? Hum, this is odd. I have confirmed your finding that compatible = "renesas,bogus-r8a7778", "renesas,bogus"; or compatible = "renesas,bogus-r8a7778", "renesas,bogus-bar"; Do not trigger an issue, but a single compatible, compatible = "renesas,bogus-r8a7778"; Do trigger. I tested this before I reduced the regexp and IIRC it worked as expected for the RFC. Not sure if I have updated dt-schema since, but I know I rebased the branch for v2. I will try to figure out what have gone wrong, if anyone know if something changed in this area pleas let me know. > Thanks! > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > 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
Hi Niklas, On Tue, Feb 13, 2024 at 12:38 AM Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> wrote: > On 2024-02-12 20:36:12 +0100, Geert Uytterhoeven wrote: > > On Sat, Jan 27, 2024 at 1:20 PM Niklas Söderlund > > <niklas.soderlund+renesas@ragnatech.se> wrote: > > > Compatibles can come in two formats. Either "vendor,ip-soc" or > > > "vendor,soc-ip". Add a DT schema file documenting Renesas preferred > > > policy and enforcing it for all new compatibles, except few existing > > > patterns. > > > > > > Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > > --- > > > * Changes since v1 > > > - Split the "SoC agnostic compatibles" section into two to make it's > > > intent clearer. > > > - Improved the documentation for each group of compatibles. > > > - Reduced the number of regexp to create a larger target area. As > > > suggested by Krzysztof the goal is not to validate each SoC name but > > > check for the correct order of SoC-IP. > > > > Thanks for the update! > > > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > > > +properties: > > > + compatible: > > > + oneOf: > > > + # Preferred naming style for compatibles of SoC components > > > + - pattern: "^renesas,emev2-[a-z0-9-]+$" > > > + - pattern: "^renesas,r(7s|8a|9a)[a-z0-9]+-[a-z0-9-]+$" > > > + - pattern: "^renesas,rcar-[a-z0-9-]+$" > > > + - pattern: "^renesas,rz[a-z0-9]*-[a-z0-9-]+$" > > > + - pattern: "^renesas,sh-[a-z0-9-]+$" > > > + - pattern: "^renesas,sh7[a-z0-9]+-[a-z0-9-]+$" > > > > I guess it's not worth adding rmobile and shmobile prefixes? > > Maybe we start with this and see how it goes? Sure. > > > > > > + # Fixed legacy compatibles > > > + # > > > + # List cannot grow with new bindings. > > > + - enum: > > > + - renesas,bsc-r8a73a4 > > > + - renesas,bsc-sh73a0 > > > + - renesas,dbsc-r8a73a4 > > > + - renesas,dbsc3-r8a7740 > > > + - renesas,em-gio > > > + - renesas,em-sti > > > + - renesas,em-uart > > > > Perhaps combine these three: "renesas,em-(gpio|sti|usrt)"? > > Will do. That does mean these lines need to use - pattern: "^renesas,em-(gpio|sti|uart)$" right? > > Now, how do I trigger violations? > > > > I added the following to a binding file: > > > > - enum: > > - renesas,bogus-r8a7778 > > - renesas,bogus-r8a7779 > > - const: renesas,bogus > > > > but nothing happened with "make dt_binding_check". > > > > I added the following to a DTS file: > > > > compatible = "renesas,bogus-r8a7778", "renesas,bogus"; > > > > again, nothing happened with "make dtbs_check". > > > > What am I missing? > > Hum, this is odd. I have confirmed your finding that > > compatible = "renesas,bogus-r8a7778", "renesas,bogus"; > > or > > compatible = "renesas,bogus-r8a7778", "renesas,bogus-bar"; > > Do not trigger an issue, but a single compatible, > > compatible = "renesas,bogus-r8a7778"; > > Do trigger. > > I tested this before I reduced the regexp and IIRC it worked as expected > for the RFC. Not sure if I have updated dt-schema since, but I know I > rebased the branch for v2. I will try to figure out what have gone > wrong, if anyone know if something changed in this area pleas let me > know. Thanks for confirming, and for looking into this! Gr{oetje,eeting}s, Geert
Hi Geert, On 2024-02-13 09:29:55 +0100, Geert Uytterhoeven wrote: > Hi Niklas, > > On Tue, Feb 13, 2024 at 12:38 AM Niklas Söderlund > <niklas.soderlund+renesas@ragnatech.se> wrote: > > On 2024-02-12 20:36:12 +0100, Geert Uytterhoeven wrote: > > > On Sat, Jan 27, 2024 at 1:20 PM Niklas Söderlund > > > <niklas.soderlund+renesas@ragnatech.se> wrote: > > > > Compatibles can come in two formats. Either "vendor,ip-soc" or > > > > "vendor,soc-ip". Add a DT schema file documenting Renesas preferred > > > > policy and enforcing it for all new compatibles, except few existing > > > > patterns. > > > > > > > > Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > > > --- > > > > * Changes since v1 > > > > - Split the "SoC agnostic compatibles" section into two to make it's > > > > intent clearer. > > > > - Improved the documentation for each group of compatibles. > > > > - Reduced the number of regexp to create a larger target area. As > > > > suggested by Krzysztof the goal is not to validate each SoC name but > > > > check for the correct order of SoC-IP. > > > > > > Thanks for the update! > > > > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > > > > > +properties: > > > > + compatible: > > > > + oneOf: > > > > + # Preferred naming style for compatibles of SoC components > > > > + - pattern: "^renesas,emev2-[a-z0-9-]+$" > > > > + - pattern: "^renesas,r(7s|8a|9a)[a-z0-9]+-[a-z0-9-]+$" > > > > + - pattern: "^renesas,rcar-[a-z0-9-]+$" > > > > + - pattern: "^renesas,rz[a-z0-9]*-[a-z0-9-]+$" > > > > + - pattern: "^renesas,sh-[a-z0-9-]+$" > > > > + - pattern: "^renesas,sh7[a-z0-9]+-[a-z0-9-]+$" > > > > > > I guess it's not worth adding rmobile and shmobile prefixes? > > > > Maybe we start with this and see how it goes? > > Sure. > > > > > > > > > > + # Fixed legacy compatibles > > > > + # > > > > + # List cannot grow with new bindings. > > > > + - enum: > > > > + - renesas,bsc-r8a73a4 > > > > + - renesas,bsc-sh73a0 > > > > + - renesas,dbsc-r8a73a4 > > > > + - renesas,dbsc3-r8a7740 > > > > + - renesas,em-gio > > > > + - renesas,em-sti > > > > + - renesas,em-uart > > > > > > Perhaps combine these three: "renesas,em-(gpio|sti|usrt)"? > > > > Will do. > > That does mean these lines need to use > > - pattern: "^renesas,em-(gpio|sti|uart)$" > > right? Yes, a pattern is needed. I will try to condense the lists as much as possible at the cost of strictness as this seems to be the common theme in reviewer. This will be, pattern: "^renesas,em-[a-z0-9]+$" Or pattern: "^renesas,(em|foo|bar|baz)-[a-z0-9]+$" > > > > Now, how do I trigger violations? > > > > > > I added the following to a binding file: > > > > > > - enum: > > > - renesas,bogus-r8a7778 > > > - renesas,bogus-r8a7779 > > > - const: renesas,bogus > > > > > > but nothing happened with "make dt_binding_check". > > > > > > I added the following to a DTS file: > > > > > > compatible = "renesas,bogus-r8a7778", "renesas,bogus"; > > > > > > again, nothing happened with "make dtbs_check". > > > > > > What am I missing? > > > > Hum, this is odd. I have confirmed your finding that > > > > compatible = "renesas,bogus-r8a7778", "renesas,bogus"; > > > > or > > > > compatible = "renesas,bogus-r8a7778", "renesas,bogus-bar"; > > > > Do not trigger an issue, but a single compatible, > > > > compatible = "renesas,bogus-r8a7778"; > > > > Do trigger. > > > > I tested this before I reduced the regexp and IIRC it worked as expected > > for the RFC. Not sure if I have updated dt-schema since, but I know I > > rebased the branch for v2. I will try to figure out what have gone > > wrong, if anyone know if something changed in this area pleas let me > > know. > > Thanks for confirming, and for looking into this! I figured it out, the error is in the yaml file and I have a fix. Not sure why it ever worked in the RFC without it. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > 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
Hi Niklas, On Tue, Feb 13, 2024 at 1:30 PM Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> wrote: > On 2024-02-13 09:29:55 +0100, Geert Uytterhoeven wrote: > > On Tue, Feb 13, 2024 at 12:38 AM Niklas Söderlund > > <niklas.soderlund+renesas@ragnatech.se> wrote: > > > On 2024-02-12 20:36:12 +0100, Geert Uytterhoeven wrote: > > > > On Sat, Jan 27, 2024 at 1:20 PM Niklas Söderlund > > > > <niklas.soderlund+renesas@ragnatech.se> wrote: > > > > > Compatibles can come in two formats. Either "vendor,ip-soc" or > > > > > "vendor,soc-ip". Add a DT schema file documenting Renesas preferred > > > > > policy and enforcing it for all new compatibles, except few existing > > > > > patterns. > > > > > > > > > > Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > > > > --- > > > > > * Changes since v1 > > > > > - Split the "SoC agnostic compatibles" section into two to make it's > > > > > intent clearer. > > > > > - Improved the documentation for each group of compatibles. > > > > > - Reduced the number of regexp to create a larger target area. As > > > > > suggested by Krzysztof the goal is not to validate each SoC name but > > > > > check for the correct order of SoC-IP. > > > > > > > > Thanks for the update! > > > > > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml > > > > > + # Fixed legacy compatibles > > > > > + # > > > > > + # List cannot grow with new bindings. > > > > > + - enum: > > > > > + - renesas,bsc-r8a73a4 > > > > > + - renesas,bsc-sh73a0 > > > > > + - renesas,dbsc-r8a73a4 > > > > > + - renesas,dbsc3-r8a7740 > > > > > + - renesas,em-gio > > > > > + - renesas,em-sti > > > > > + - renesas,em-uart > > > > > > > > Perhaps combine these three: "renesas,em-(gpio|sti|usrt)"? > > > > > > Will do. > > > > That does mean these lines need to use > > > > - pattern: "^renesas,em-(gpio|sti|uart)$" > > > > right? > > Yes, a pattern is needed. I will try to condense the lists as much as > possible at the cost of strictness as this seems to be the common theme > in reviewer. This will be, > > pattern: "^renesas,em-[a-z0-9]+$" > > Or > pattern: "^renesas,(em|foo|bar|baz)-[a-z0-9]+$" I'd rather keep these as strict as possible, to make sure no new ones pop up accidentally. I.e. I prefer "^renesas,em-(gpio|sti|uart)$" over "^renesas,em-[a-z0-9-]+$". Gr{oetje,eeting}s, Geert
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml new file mode 100644 index 000000000000..91310d23cf0b --- /dev/null +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/renesas/renesas-soc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas SoC compatibles naming convention + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Niklas Söderlund <niklas.soderlund@ragnatech.se> + +description: | + Guidelines for new compatibles for SoC blocks/components. + When adding new compatibles in new bindings, use the format:: + renesas,SoC-IP + + For example:: + renesas,r8a77965-csi2 + + When adding new compatibles to existing bindings, use the format in the + existing binding, even if it contradicts the above. + +select: + properties: + compatible: + pattern: "^renesas,.*-.*$" + required: + - compatible + +properties: + compatible: + oneOf: + # Preferred naming style for compatibles of SoC components + - pattern: "^renesas,emev2-[a-z0-9-]+$" + - pattern: "^renesas,r(7s|8a|9a)[a-z0-9]+-[a-z0-9-]+$" + - pattern: "^renesas,rcar-[a-z0-9-]+$" + - pattern: "^renesas,rz[a-z0-9]*-[a-z0-9-]+$" + - pattern: "^renesas,sh-[a-z0-9-]+$" + - pattern: "^renesas,sh7[a-z0-9]+-[a-z0-9-]+$" + + # Fallback compatibles + # + # Some SoC components in addition to a specific SoC compatible have a + # generic fallback compatible. For example the Interrupt Controller, + # + # compatible = "renesas,intc-irqpin-r8a7740", "renesas,intc-irqpin"; + # + # This is OK and new fallback compatibles are allowed. + - enum: + - renesas,cpg-div6-clock + - renesas,cpg-mstp-clocks + - renesas,intc-irqpin + + # Legacy compatibles + # + # New compatibles are not allowed but new variations of existing + # patterns/compatibles are. + - pattern: "^renesas,can-[a-z0-9]+$" + - pattern: "^renesas,dmac-[a-z0-9]+$" + - pattern: "^renesas,du-[a-z0-9]+$" + - pattern: "^renesas,ether-[a-z0-9]+$" + - pattern: "^renesas,etheravb-[a-z0-9]+$" + - pattern: "^renesas,etheravb-rcar-gen[0-9]$" + - pattern: "^renesas,gether-[a-z0-9]+$" + - pattern: "^renesas,gpio-[a-z0-9]+$" + - pattern: "^renesas,hscif-[a-z0-9]+$" + - pattern: "^renesas,i2c-[a-z0-9]+$" + - pattern: "^renesas,iic-[a-z0-9]+$" + - pattern: "^renesas,intc-ex-[a-z0-9]+$" + - pattern: "^renesas,intc-irqpin-[a-z0-9]+$" + - pattern: "^renesas,ipmmu-[a-z0-9]+$" + - pattern: "^renesas,irqc-[a-z0-9]+$" + - pattern: "^renesas,jpu-[a-z0-9]+$" + - pattern: "^renesas,mmcif-[a-z0-9]+$" + - pattern: "^renesas,msiof-[a-z0-9]+$" + - pattern: "^renesas,pci-[a-z0-9]+$" + - pattern: "^renesas,pci-rcar-gen[0-9]$" + - pattern: "^renesas,pcie-[a-z0-9]+$" + - pattern: "^renesas,pcie-rcar-gen[0-9]$" + - pattern: "^renesas,pfc-[a-z0-9]+$" + - pattern: "^renesas,pwm-[a-z0-9]+$" + - pattern: "^renesas,qspi-[a-z0-9]+$" + - pattern: "^renesas,rcar_sound-[a-z0-9]+$" + - pattern: "^renesas,riic-[a-z0-9]+$" + - pattern: "^renesas,rspi-[a-z0-9]+$" + - pattern: "^renesas,sata-[a-z0-9]+(-es1)?$" + - pattern: "^renesas,scif-[a-z0-9]+$" + - pattern: "^renesas,scifa-[a-z0-9]+$" + - pattern: "^renesas,scifb-[a-z0-9]+$" + - pattern: "^renesas,sdhi-[a-z0-9]+$" + - pattern: "^renesas,thermal-[a-z0-9]+$" + - pattern: "^renesas,tmu-[a-z0-9]+$" + - pattern: "^renesas,tpu-[a-z0-9]+$" + - pattern: "^renesas,usb-phy-[a-z0-9]+$" + - pattern: "^renesas,usb2-phy-[a-z0-9]+$" + - pattern: "^renesas,usbhs-[a-z0-9]+$" + - pattern: "^renesas,vin-[a-z0-9]+$" + - pattern: "^renesas,xhci-[a-z0-9]+$" + + # Fixed legacy compatibles + # + # List cannot grow with new bindings. + - enum: + - renesas,bsc-r8a73a4 + - renesas,bsc-sh73a0 + - renesas,dbsc-r8a73a4 + - renesas,dbsc3-r8a7740 + - renesas,em-gio + - renesas,em-sti + - renesas,em-uart + - renesas,fsi2-r8a7740 + - renesas,fsi2-sh73a0 + - renesas,hspi-r8a7778 + - renesas,hspi-r8a7779 + - renesas,imr-lx4 + - renesas,mtu2-r7s72100 + - renesas,rmobile-iic + - renesas,sbsc-sh73a0 + - renesas,sdhi-mmc-r8a77470 + - renesas,shmobile-flctl-sh7372 + - renesas,sysc-r8a73a4 + - renesas,sysc-r8a7740 + - renesas,sysc-rmobile + - renesas,sysc-sh73a0 + - renesas,usb-dmac + + # None SoC component compatibles + # + # Compatibles with the Renesas vendor prefix that do not relate to any SoC + # component are OK. New compatibles are allowed. + - enum: + - renesas,smp-sram + +additionalProperties: true
Compatibles can come in two formats. Either "vendor,ip-soc" or "vendor,soc-ip". Add a DT schema file documenting Renesas preferred policy and enforcing it for all new compatibles, except few existing patterns. Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> --- * Changes since v1 - Split the "SoC agnostic compatibles" section into two to make it's intent clearer. - Improved the documentation for each group of compatibles. - Reduced the number of regexp to create a larger target area. As suggested by Krzysztof the goal is not to validate each SoC name but check for the correct order of SoC-IP. * Changes since RFC - Moved to Documentation/devicetree/bindings/soc/renesas. - Changed the pattern in the initial select to match on .*-.*. - Added a lot of missing compatible values. --- .../bindings/soc/renesas/renesas-soc.yaml | 135 ++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml