Thread (8 messages) 8 messages, 4 authors, 2021-03-08

Re: [PATCH] dt-bindings: cpufreq: cpufreq-qcom-hw: Document SM8350 CPUfreq compatible

From: Rob Herring <robh@kernel.org>
Date: 2021-03-05 21:57:56
Also in: linux-arm-msm, linux-devicetree, lkml

On Thu, Feb 18, 2021 at 09:18:20PM +0530, Viresh Kumar wrote:
On 18-02-21, 18:14, Vinod Koul wrote:
quoted
On 17-02-21, 10:19, Viresh Kumar wrote:
quoted
On 16-02-21, 16:42, Vinod Koul wrote:
quoted
Add the CPUfreq compatible for SM8350 SoC along with note for using the
specific compatible for SoCs

Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
index 9299028ee712..3eb3cee59d79 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
@@ -8,7 +8,9 @@ Properties:
 - compatible
 	Usage:		required
 	Value type:	<string>
-	Definition:	must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss".
+	Definition:	must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss"
+			along with SoC specific compatible:
+			  "qcom,sm8350-cpufreq-epss", "qcom,cpufreq-epss"
And why is SoC specific compatible required here ? Is the implementation on
sm8350 any different than the ones using "qcom,cpufreq-epss" compatible ?

FWIW, the same compatible string must be reused until the time there is
difference in the hardware. The compatible string must be considered as a marker
for a particular version of the hardware.
Rob has indicated that we should use a SoC specific compatible and I
agree with that. We are using both soc and generic one here and driver
will be loaded for generic one.
I am not sure of the context, lets see what Rob has to say on this. I
believe we only need 1 compatible string here (whatever it is), as
this is just one version of the hardware we are talking about. We
already have 2 somehow and you are trying to add one more and I don't
fell good about it. :(
The h/w block is the same features and bugs in every single 
implementation? If not sure, better be safe.

I don't know that I'd go back and add SoC ones for everything though.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help