From: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: 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>,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: renesas: Document preferred compatible naming
Date: Thu, 30 Nov 2023 14:17:01 +0100 [thread overview]
Message-ID: <ZWiLTYU_Hj0bl1gn@oden.dyn.berto.se> (raw)
In-Reply-To: <deacc7ea-6fad-47d6-978b-3f639aa5da35@linaro.org>
Hi Krzysztof,
On 2023-11-28 10:51:03 +0100, Krzysztof Kozlowski wrote:
> > +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.
As you point out below there is a lot of patterns that use the style not
preferred and the idea to detect future additions of this I thought it a
good idea to make these more specialized. If we think that is a bad idea
I can try to make fewer more generic ones.
>
> > +
> > + # 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...
The intention is to list SoC agnostic compatibles here, or put another
way false positives to the generic pattern "renesas,.*-.*". So no
"renesas,smp-sram" can't have new compatibles but there might be new
renesas compatible strings that hit the pattern that is not related to a
SoC. Does this make sens?
>
> > +
> > + # 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?
As Geert points out these exists for historical reasons, but we don't
want any more of this style.
You ask in your reply to Geert that we should reconsider if this is
still useful. I think it is as it achieves the over all goal, detect if
any new of the not preferred style is added. But I won't press it, if
you or Geert think this is a bad route I won't spend more time on this
work.
@Geert: What do you think?
--
Kind Regards,
Niklas Söderlund
next prev parent reply other threads:[~2023-11-30 13:17 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
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 [this message]
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=ZWiLTYU_Hj0bl1gn@oden.dyn.berto.se \
--to=niklas.soderlund+renesas@ragnatech.se \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-renesas-soc@vger.kernel.org \
--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).