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