devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: renesas: Document preferred compatible naming
Date: Tue, 28 Nov 2023 10:51:03 +0100	[thread overview]
Message-ID: <deacc7ea-6fad-47d6-978b-3f639aa5da35@linaro.org> (raw)
In-Reply-To: <20231125232821.234631-1-niklas.soderlund+renesas@ragnatech.se>

On 26/11/2023 00:28, 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 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.
> 
> Compared to the RFC I did not use make dt_binding_check and manual
> reading of the bindings to find all compatibles. Instead I generated
> YAML of all renesas related files under arch/arm and arc/arm64 and
> parsed all the compatible values.
> 
> For v6.7-rc2 the hits on each pattern where,
> 
> ^renesas,emev2-[a-z0-9-]+$ = 14
> ^renesas,r7s[0-9]+-[a-z0-9-]+$ = 58
> ^renesas,r8a[a-z0-9]+-[a-z0-9-]+$ = 1661
> ^renesas,r9a[0-9]+g[a-z0-9]+-[a-z0-9-]+$ = 160
> ^renesas,rcar-[a-z0-9-]+$ = 4522
> ^renesas,rz-[a-z0-9-]+$ = 26
> ^renesas,rza-[a-z0-9-]+$ = 4
> ^renesas,rza1-[a-z0-9-]+$ = 10
> ^renesas,rza2-[a-z0-9-]+$ = 6
> ^renesas,rzg2l-[a-z0-9-]+$ = 54
> ^renesas,rzn1[a-z0-9]*-[a-z0-9-]+$ = 22
> ^renesas,rzv2m-[a-z0-9-]+$ = 9
> ^renesas,sh-[a-z0-9-]+$ = 36
> ^renesas,sh7[a-z0-9]+-[a-z0-9-]+$ = 27
> renesas,cpg-div6-clock = 45
> renesas,cpg-mstp-clocks = 49
> renesas,intc-irqpin = 20
> renesas,smp-sram = 20
> ^renesas,can-[a-z0-9]+$ = 136
> ^renesas,dmac-[a-z0-9]+$ = 326
> ^renesas,du-[a-z0-9]+$ = 77
> ^renesas,ether-[a-z0-9]+$ = 21
> ^renesas,etheravb-[a-z0-9]+$ = 84
> ^renesas,etheravb-rcar-gen[0-9]$ = 82
> ^renesas,gether-[a-z0-9]+$ = 4
> ^renesas,gpio-[a-z0-9]+$ = 608
> ^renesas,hscif-[a-z0-9]+$ = 336
> ^renesas,i2c-[a-z0-9]+$ = 517
> ^renesas,iic-[a-z0-9]+$ = 118
> ^renesas,intc-ex-[a-z0-9]+$ = 58
> ^renesas,intc-irqpin-[a-z0-9]+$ = 10
> ^renesas,ipmmu-[a-z0-9]+$ = 828
> ^renesas,irqc-[a-z0-9]+$ = 22
> ^renesas,jpu-[a-z0-9]+$ = 6
> ^renesas,mmcif-[a-z0-9]+$ = 29
> ^renesas,msiof-[a-z0-9]+$ = 290
> ^renesas,pci-[a-z0-9]+$ = 38
> ^renesas,pci-rcar-gen[0-9]$ = 36
> ^renesas,pcie-[a-z0-9]+$ = 105
> ^renesas,pcie-rcar-gen[0-9]$ = 105
> ^renesas,pfc-[a-z0-9]+$ = 84
> ^renesas,pwm-[a-z0-9]+$ = 984
> ^renesas,qspi-[a-z0-9]+$ = 21
> ^renesas,rcar_sound-[a-z0-9]+$ = 136
> ^renesas,riic-[a-z0-9]+$ = 64
> ^renesas,rspi-[a-z0-9]+$ = 48
> ^renesas,sata-[a-z0-9]+(-es1)?$ = 38
> ^renesas,scif-[a-z0-9]+$ = 506
> ^renesas,scifa-[a-z0-9]+$ = 108
> ^renesas,scifb-[a-z0-9]+$ = 57
> ^renesas,sdhi-[a-z0-9]+$ = 294
> ^renesas,thermal-[a-z0-9]+$ = 22
> ^renesas,tmu-[a-z0-9]+$ = 298
> ^renesas,tpu-[a-z0-9]+$ = 44
> ^renesas,usb-phy-[a-z0-9]+$ = 18
> ^renesas,usb2-phy-[a-z0-9]+$ = 118
> ^renesas,usbhs-[a-z0-9]+$ = 86
> ^renesas,vin-[a-z0-9]+$ = 523
> ^renesas,xhci-[a-z0-9]+$ = 59
> renesas,bsc-r8a73a4 = 1
> renesas,bsc-sh73a0 = 1
> renesas,dbsc-r8a73a4 = 2
> renesas,dbsc3-r8a7740 = 1
> renesas,em-gio = 5
> renesas,em-sti = 1
> renesas,em-uart = 5
> renesas,fsi2-r8a7740 = 1
> renesas,fsi2-sh73a0 = 1
> renesas,hspi-r8a7778 = 3
> renesas,hspi-r8a7779 = 3
> renesas,imr-lx4 = 36
> renesas,mtu2-r7s72100 = 3
> renesas,rmobile-iic = 116
> renesas,sbsc-sh73a0 = 2
> renesas,sdhi-mmc-r8a77470 = 1
> renesas,shmobile-flctl-sh7372 = 0
> renesas,sysc-r8a73a4 = 1
> renesas,sysc-r8a7740 = 1
> renesas,sysc-rmobile = 3
> renesas,sysc-sh73a0 = 1
> renesas,usb-dmac = 144
> 
> This do not include the examples in the bindings YAML files. So there is
> on hit, renesas,shmobile-flctl-sh7372, that is not used in an upstream
> DTS.
> ---
>  .../bindings/soc/renesas/renesas-soc.yaml     | 126 ++++++++++++++++++
>  1 file changed, 126 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..4674c1f61c1e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> @@ -0,0 +1,126 @@
> +# 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,r7s[0-9]+-[a-z0-9-]+$"
> +      - pattern: "^renesas,r8a[a-z0-9]+-[a-z0-9-]+$"
> +      - pattern: "^renesas,r9a[0-9]+g[a-z0-9]+-[a-z0-9-]+$"
> +      - pattern: "^renesas,rcar-[a-z0-9-]+$"
> +      - pattern: "^renesas,rz-[a-z0-9-]+$"
> +      - pattern: "^renesas,rza-[a-z0-9-]+$"
> +      - pattern: "^renesas,rza1-[a-z0-9-]+$"
> +      - pattern: "^renesas,rza2-[a-z0-9-]+$"
> +      - pattern: "^renesas,rzg2l-[a-z0-9-]+$"
> +      - pattern: "^renesas,rzn1[a-z0-9]*-[a-z0-9-]+$"
> +      - pattern: "^renesas,rzv2m-[a-z0-9-]+$"
> +      - pattern: "^renesas,sh-[a-z0-9-]+$"
> +      - pattern: "^renesas,sh7[a-z0-9]+-[a-z0-9-]+$"

Why so many different patterns? Why it cannot be for example:
"^renesas,rz[a-z0-9]*-[a-z0-9-]+$" to cover multiple entries?

The point is not to validate the devices. Other bindings do it. The
point is to have one or two patterns to enforce ordering of SoC-block.

The size of this file suggests you either over-complicated the thing or
there is little benefit of adding it.

> +
> +      # SoC agnostic compatibles - new compatibles are OK:

Why new compatibles are ok?

> +      - enum:
> +          - renesas,cpg-div6-clock
> +          - renesas,cpg-mstp-clocks
> +          - renesas,intc-irqpin
> +          - renesas,smp-sram

smp-sram can have new compatibles? I am sorry, but this needs explanation...

> +
> +      # Legacy namings - variations of existing patterns/compatibles are OK,
> +      # but do not add completely new entries to these:
> +      - 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]+$"

No, wait, you basically listed most of the SoC as exceptions. What SoC
blocks exactly are you going to cover in such case with your rules?



Best regards,
Krzysztof


  reply	other threads:[~2023-11-28  9:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-25 23:28 [PATCH] dt-bindings: renesas: Document preferred compatible naming Niklas Söderlund
2023-11-28  9:51 ` Krzysztof Kozlowski [this message]
2023-11-28 10:32   ` Geert Uytterhoeven
2023-11-28 14:32     ` Krzysztof Kozlowski
2023-11-30 14:27       ` Geert Uytterhoeven
2023-11-30 13:17   ` Niklas Söderlund
2023-12-01  9:19     ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=deacc7ea-6fad-47d6-978b-3f639aa5da35@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).