On 18-02-21, 18:14, Vinod Koul wrote:

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. :(

-- 
viresh