* [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
@ 2024-01-27 12:19 Niklas Söderlund
2024-02-05 16:45 ` Rob Herring
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Niklas Söderlund @ 2024-01-27 12:19 UTC (permalink / raw)
To: Geert Uytterhoeven, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-renesas-soc, Niklas Söderlund,
Krzysztof Kozlowski
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
2024-01-27 12:19 [PATCH v2] dt-bindings: renesas: Document preferred compatible naming Niklas Söderlund
@ 2024-02-05 16:45 ` Rob Herring
2024-02-10 13:06 ` Niklas Söderlund
2024-02-12 19:36 ` Geert Uytterhoeven
2 siblings, 0 replies; 9+ messages in thread
From: Rob Herring @ 2024-02-05 16:45 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Krzysztof Kozlowski, Conor Dooley, linux-renesas-soc, devicetree,
Krzysztof Kozlowski, Rob Herring, Geert Uytterhoeven
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>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
2024-01-27 12:19 [PATCH v2] dt-bindings: renesas: Document preferred compatible naming Niklas Söderlund
2024-02-05 16:45 ` Rob Herring
@ 2024-02-10 13:06 ` Niklas Söderlund
2024-02-10 20:45 ` Conor Dooley
2024-02-12 19:36 ` Geert Uytterhoeven
2 siblings, 1 reply; 9+ messages in thread
From: Niklas Söderlund @ 2024-02-10 13:06 UTC (permalink / raw)
To: Geert Uytterhoeven, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-renesas-soc, Krzysztof Kozlowski
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
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
2024-02-10 13:06 ` Niklas Söderlund
@ 2024-02-10 20:45 ` Conor Dooley
0 siblings, 0 replies; 9+ messages in thread
From: Conor Dooley @ 2024-02-10 20:45 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Geert Uytterhoeven, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree, linux-renesas-soc, Krzysztof Kozlowski
[-- Attachment #1: Type: text/plain, Size: 237 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
2024-01-27 12:19 [PATCH v2] dt-bindings: renesas: Document preferred compatible naming Niklas Söderlund
2024-02-05 16:45 ` Rob Herring
2024-02-10 13:06 ` Niklas Söderlund
@ 2024-02-12 19:36 ` Geert Uytterhoeven
2024-02-12 23:38 ` Niklas Söderlund
2 siblings, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2024-02-12 19:36 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-renesas-soc, Krzysztof Kozlowski
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
2024-02-12 19:36 ` Geert Uytterhoeven
@ 2024-02-12 23:38 ` Niklas Söderlund
2024-02-13 8:29 ` Geert Uytterhoeven
0 siblings, 1 reply; 9+ messages in thread
From: Niklas Söderlund @ 2024-02-12 23:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-renesas-soc, Krzysztof Kozlowski
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
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
2024-02-12 23:38 ` Niklas Söderlund
@ 2024-02-13 8:29 ` Geert Uytterhoeven
2024-02-13 12:30 ` Niklas Söderlund
0 siblings, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2024-02-13 8:29 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-renesas-soc, Krzysztof Kozlowski
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
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
2024-02-13 8:29 ` Geert Uytterhoeven
@ 2024-02-13 12:30 ` Niklas Söderlund
2024-02-13 12:40 ` Geert Uytterhoeven
0 siblings, 1 reply; 9+ messages in thread
From: Niklas Söderlund @ 2024-02-13 12:30 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-renesas-soc, Krzysztof Kozlowski
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
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] dt-bindings: renesas: Document preferred compatible naming
2024-02-13 12:30 ` Niklas Söderlund
@ 2024-02-13 12:40 ` Geert Uytterhoeven
0 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2024-02-13 12:40 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-renesas-soc, Krzysztof Kozlowski
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
--
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2024-02-13 12:40 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-27 12:19 [PATCH v2] dt-bindings: renesas: Document preferred compatible naming Niklas Söderlund
2024-02-05 16:45 ` Rob Herring
2024-02-10 13:06 ` Niklas Söderlund
2024-02-10 20:45 ` Conor Dooley
2024-02-12 19:36 ` Geert Uytterhoeven
2024-02-12 23:38 ` Niklas Söderlund
2024-02-13 8:29 ` Geert Uytterhoeven
2024-02-13 12:30 ` Niklas Söderlund
2024-02-13 12:40 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).