Re: [PATCH v2 1/2] dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `#clock-cells` property is missing from the `required` list.
- [Low] The device tree example contains unresolved node labels (`cpufreq_hw`, `rpmcc`, and `gpll0`), which will cause `dt_binding_check` to fail compilation.
--

commit 53ba3920bbb9dfa66228fecc65f7b4a4bc5e9ee2
Author: Imran Shaik <imran.shaik@oss.qualcomm.com>

dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware

The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS, but
supports only up to 12 frequency lookup table (LUT) entries. This commit
introduces Shikra specific bindings to represent this constrained EPSS
variant.

> diff --git a/Documentation/devicetree/bindings/cpufreq/shikra-cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/shikra-cpufreq-qcom-hw.yaml
> new file mode 100644
> index 0000000000000..52079ed661671
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/shikra-cpufreq-qcom-hw.yaml
[ ... ]
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - '#freq-domain-cells'

[Severity: Medium]
Since the Shikra CPUFREQ hardware acts as a clock provider for the CPU
nodes, should #clock-cells be explicitly included in the required list?

Omitting it allows device tree configurations with missing #clock-cells to
pass schema validation, which could lead to runtime failures when dependent
subsystems try to acquire clocks.

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/qcom,rpmcc.h>
> +
> +      cpus {
> +        #address-cells = <2>;
> +        #size-cells = <0>;
> +
> +        cpu0: cpu@0 {
> +          device_type = "cpu";
> +          compatible = "arm,cortex-a55";
> +          reg = <0x0 0x0>;
> +          enable-method = "psci";
> +          qcom,freq-domain = <&cpufreq_hw 0>;
> +          clocks = <&cpufreq_hw 0>;

[Severity: Low]
Are the labels cpufreq_hw, rpmcc, and gpll0 properly defined in this
example?

Multiple CPU nodes reference <&cpufreq_hw 0> for the clocks and
qcom,freq-domain properties, but the cpufreq_hw label is never defined on
the provider node.

[ ... ]
> +      cpufreq@fd91000 {
> +        compatible = "qcom,shikra-cpufreq-epss";
> +        reg = <0x0fd91000 0x1000>, <0x0fd92000 0x1000>;
> +        reg-names = "freq-domain0", "freq-domain1";
> +
> +        clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&gpll0>;

Additionally, the rpmcc and gpll0 labels are referenced here as clock
inputs but are completely missing from the example snippet.

Will this cause dt_binding_check to fail compilation with "Reference to
non-existent node or label" errors?

> +        clock-names = "xo", "alternate";
> +
> +        #freq-domain-cells = <1>;
> +        #clock-cells = <1>;
> +      };
> +    };
> +...

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-shikra-cpufreq-scaling-v2-0-2b09f0e1c9d8@oss.qualcomm.com?part=1