diff mbox series

[v2] dt-bindings: renesas: Document preferred compatible naming

Message ID 20240127121937.2372098-1-niklas.soderlund+renesas@ragnatech.se
State Not Applicable
Headers show
Series [v2] dt-bindings: renesas: Document preferred compatible naming | expand

Checks

Context Check Description
robh/checkpatch success
robh/patch-applied success
robh/dtbs-check warning build log
robh/dt-meta-schema success

Commit Message

Niklas Söderlund Jan. 27, 2024, 12:19 p.m. UTC
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

Comments

Rob Herring (Arm) Feb. 5, 2024, 4:45 p.m. UTC | #1
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>
Niklas Söderlund Feb. 10, 2024, 1:06 p.m. UTC | #2
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
>
Conor Dooley Feb. 10, 2024, 8:45 p.m. UTC | #3
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.
Geert Uytterhoeven Feb. 12, 2024, 7:36 p.m. UTC | #4
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
Niklas Söderlund Feb. 12, 2024, 11:38 p.m. UTC | #5
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
Geert Uytterhoeven Feb. 13, 2024, 8:29 a.m. UTC | #6
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
Niklas Söderlund Feb. 13, 2024, 12:30 p.m. UTC | #7
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
Geert Uytterhoeven Feb. 13, 2024, 12:40 p.m. UTC | #8
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 mbox series

Patch

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