[PATCH v2 0/2] Add cpufreq scaling support for Qualcomm Shikra SoC

[PATCH v2 0/2] Add cpufreq scaling support for Qualcomm Shikra SoC

[Imran Shaik]

This series adds cpufreq scaling support on Qualcomm Shikra SoC.

Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
Changes in v2:
- Dropped the generic compatible approach, and introduced Shikra
  specific bindings [Krzysztof]
- Updated the driver patch as per the latest bindings changes
- Added R-By tag received in V1.
- Link to v1: https://lore.kernel.org/r/20260501-shikra-cpufreq-scaling-v1-0-c78b95f53b91@oss.qualcomm.com

---
Imran Shaik (1):
      dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware

Taniya Das (1):
      cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC

 .../bindings/cpufreq/shikra-cpufreq-qcom-hw.yaml   | 133 +++++++++++++++++++++
 drivers/cpufreq/qcom-cpufreq-hw.c                  |  23 +++-
 2 files changed, 153 insertions(+), 3 deletions(-)
---
base-commit: 0787c45ea08a13b5482e701fabc741877cf681f6
change-id: 20260430-shikra-cpufreq-scaling-aff690130063

Best regards,
-- 
Imran Shaik <imran.shaik@oss.qualcomm.com>

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

[Imran Shaik]

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

Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
 .../bindings/cpufreq/shikra-cpufreq-qcom-hw.yaml   | 133 +++++++++++++++++++++
 1 file changed, 133 insertions(+)

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 0000000000000000000000000000000000000000..52079ed661671554fcca8677409ee11199f5727b
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/shikra-cpufreq-qcom-hw.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/shikra-cpufreq-qcom-hw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CPUFREQ HW for Qualcomm Shikra SoC
+
+maintainers:
+  - Imran Shaik <imran.shaik@oss.qualcomm.com>
+  - Taniya Das <taniya.das@oss.qualcomm.com>
+
+description: |
+
+  CPUFREQ HW is a hardware engine used by some Qualcomm SoCs to manage
+  frequency in hardware. It is capable of controlling frequency for
+  multiple clusters.
+
+  The Qualcomm Shikra CPUFREQ HW supports up to 12 frequency lookup table
+  (LUT) entries.
+
+properties:
+  compatible:
+    enum:
+      - qcom,shikra-cpufreq-epss
+
+  reg:
+    items:
+      - description: Frequency domain 0 register region
+      - description: Frequency domain 1 register region
+
+  reg-names:
+    items:
+      - const: freq-domain0
+      - const: freq-domain1
+
+  clocks:
+    items:
+      - description: XO Clock
+      - description: GPLL0 Clock
+
+  clock-names:
+    items:
+      - const: xo
+      - const: alternate
+
+  interrupts:
+    items:
+      - description: IRQ line for DCVSH 0
+      - description: IRQ line for DCVSH 1
+
+  interrupt-names:
+    items:
+      - const: dcvsh-irq-0
+      - const: dcvsh-irq-1
+
+  '#freq-domain-cells':
+    const: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - '#freq-domain-cells'
+
+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>;
+        };
+
+        cpu1: cpu@100 {
+          device_type = "cpu";
+          compatible = "arm,cortex-a55";
+          reg = <0x0 0x100>;
+          enable-method = "psci";
+          qcom,freq-domain = <&cpufreq_hw 0>;
+          clocks = <&cpufreq_hw 0>;
+        };
+
+        cpu2: cpu@200 {
+          device_type = "cpu";
+          compatible = "arm,cortex-a55";
+          reg = <0x0 0x200>;
+          enable-method = "psci";
+          qcom,freq-domain = <&cpufreq_hw 0>;
+          clocks = <&cpufreq_hw 0>;
+        };
+
+        cpu3: cpu@300 {
+          device_type = "cpu";
+          compatible = "arm,cortex-a78c";
+          reg = <0x0 0x300>;
+          enable-method = "psci";
+          qcom,freq-domain = <&cpufreq_hw 1>;
+          clocks = <&cpufreq_hw 1>;
+        };
+      };
+
+    soc {
+      #address-cells = <1>;
+      #size-cells = <1>;
+
+      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>;
+        clock-names = "xo", "alternate";
+
+        #freq-domain-cells = <1>;
+        #clock-cells = <1>;
+      };
+    };
+...

-- 
2.34.1

[PATCH v2 2/2] cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC

[Imran Shaik]

From: Taniya Das <taniya.das@oss.qualcomm.com>

The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
but supports only up to 12 frequency lookup table (LUT) entries. Hence,
add shikra_epss_soc_data that reuses EPSS configuration with appropriate
LUT entries limit.

Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index ea9a20d27b8fdceb9341ee53e5fa27b7a6d92483..d50b868dced309cceb7b49b69dff933e4bd9e357 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
  * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
  */
 
 #include <linux/bitfield.h>
@@ -40,6 +41,7 @@ struct qcom_cpufreq_soc_data {
 	u32 reg_intr_clr;
 	u32 reg_current_vote;
 	u32 reg_perf_state;
+	u32 lut_max_entries;
 	u8 lut_row_size;
 };
 
@@ -156,7 +158,7 @@ static unsigned int qcom_cpufreq_get_freq(struct cpufreq_policy *policy)
 	soc_data = qcom_cpufreq.soc_data;
 
 	index = readl_relaxed(data->base + soc_data->reg_perf_state);
-	index = min(index, LUT_MAX_ENTRIES - 1);
+	index = min(index, soc_data->lut_max_entries - 1);
 
 	return policy->freq_table[index].frequency;
 }
@@ -211,7 +213,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 	struct qcom_cpufreq_data *drv_data = policy->driver_data;
 	const struct qcom_cpufreq_soc_data *soc_data = qcom_cpufreq.soc_data;
 
-	table = kzalloc_objs(*table, LUT_MAX_ENTRIES + 1);
+	table = kzalloc_objs(*table, soc_data->lut_max_entries + 1);
 	if (!table)
 		return -ENOMEM;
 
@@ -236,7 +238,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 		icc_scaling_enabled = false;
 	}
 
-	for (i = 0; i < LUT_MAX_ENTRIES; i++) {
+	for (i = 0; i < soc_data->lut_max_entries; i++) {
 		data = readl_relaxed(drv_data->base + soc_data->reg_freq_lut +
 				      i * soc_data->lut_row_size);
 		src = FIELD_GET(LUT_SRC, data);
@@ -405,6 +407,7 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data = {
 	.reg_current_vote = 0x704,
 	.reg_perf_state = 0x920,
 	.lut_row_size = 32,
+	.lut_max_entries = LUT_MAX_ENTRIES,
 };
 
 static const struct qcom_cpufreq_soc_data epss_soc_data = {
@@ -416,11 +419,25 @@ static const struct qcom_cpufreq_soc_data epss_soc_data = {
 	.reg_intr_clr = 0x308,
 	.reg_perf_state = 0x320,
 	.lut_row_size = 4,
+	.lut_max_entries = LUT_MAX_ENTRIES,
+};
+
+static const struct qcom_cpufreq_soc_data shikra_epss_soc_data = {
+	.reg_enable = 0x0,
+	.reg_domain_state = 0x20,
+	.reg_dcvs_ctrl = 0xb0,
+	.reg_freq_lut = 0x100,
+	.reg_volt_lut = 0x200,
+	.reg_intr_clr = 0x308,
+	.reg_perf_state = 0x320,
+	.lut_row_size = 4,
+	.lut_max_entries = 12,
 };
 
 static const struct of_device_id qcom_cpufreq_hw_match[] = {
 	{ .compatible = "qcom,cpufreq-hw", .data = &qcom_soc_data },
 	{ .compatible = "qcom,cpufreq-epss", .data = &epss_soc_data },
+	{ .compatible = "qcom,shikra-cpufreq-epss", .data = &shikra_epss_soc_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);

-- 
2.34.1

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

[sashiko-bot]

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

Re: [PATCH v2 2/2] cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Calling kfree() on an interior pointer of a devm-managed array causes immediate slab corruption.
- [High] Delayed work is cancelled before the threaded IRQ is disabled in `qcom_cpufreq_hw_cpu_offline()`, allowing work to be rescheduled after cancellation and causing a Use-After-Free.
- [High] Missing bounds check on `index` parsed from device tree leads to an out-of-bounds array access.
--

commit f331397a70453ca14a6a369d3ebce1fe9043850e
Author: Taniya Das <taniya.das@oss.qualcomm.com>

cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC
    
The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
but supports only up to 12 frequency lookup table (LUT) entries. Hence,
add shikra_epss_soc_data that reuses EPSS configuration with appropriate
LUT entries limit.

> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index ea9a20d27b8fd..d50b868dced30 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>   */
>  
>  #include <linux/bitfield.h>

[ ... ]

> @@ -416,11 +419,25 @@ static const struct qcom_cpufreq_soc_data epss_soc_data = {
>  	.reg_intr_clr = 0x308,
>  	.reg_perf_state = 0x320,
>  	.lut_row_size = 4,
> +	.lut_max_entries = LUT_MAX_ENTRIES,
> +};
> +
> +static const struct qcom_cpufreq_soc_data shikra_epss_soc_data = {
> +	.reg_enable = 0x0,
> +	.reg_domain_state = 0x20,
> +	.reg_dcvs_ctrl = 0xb0,
> +	.reg_freq_lut = 0x100,
> +	.reg_volt_lut = 0x200,
> +	.reg_intr_clr = 0x308,
> +	.reg_perf_state = 0x320,
> +	.lut_row_size = 4,
> +	.lut_max_entries = 12,
>  };

[Severity: Critical]
This is a pre-existing issue, but calling kfree() on an interior pointer of a
devm-managed array causes immediate slab corruption.

In qcom_cpufreq_hw_driver_probe(), the global array qcom_cpufreq.data is
allocated as a single contiguous block using devm_kzalloc():

    qcom_cpufreq.data = devm_kzalloc(dev, sizeof(struct qcom_cpufreq_data) *
                                     num_domains, GFP_KERNEL);

In qcom_cpufreq_hw_cpu_init(), a CPU policy's driver data is set to point to a
specific element inside this array:

    data = &qcom_cpufreq.data[index];

When a policy is torn down, qcom_cpufreq_hw_cpu_exit() is invoked and
explicitly calls kfree(data):

    static void qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy)
    {
        ...
        kfree(data);
    }

Does calling kfree() on an interior pointer of a devm-managed block violate
slab allocator invariants, and guarantee a kernel panic followed by a
double-free when devres cleans up the block?

[Severity: High]
This is a pre-existing issue, but delayed work is cancelled before the threaded
IRQ is disabled in qcom_cpufreq_hw_cpu_offline(), allowing work to be
rescheduled after cancellation and causing a use-after-free.

In qcom_cpufreq_hw_cpu_offline(), cancel_delayed_work_sync() is called prior to
disable_irq_nosync():

    cancel_delayed_work_sync(&data->throttle_work);
    irq_set_affinity_and_hint(data->throttle_irq, NULL);
    disable_irq_nosync(data->throttle_irq);

The LMh IRQ is registered as a threaded interrupt (IRQF_ONESHOT). If the
threaded handler qcom_lmh_dcvs_handle_irq() runs concurrently with the offline
process, cancel_delayed_work_sync() can return before the handler executes
schedule_delayed_work().

Because disable_irq_nosync() masks the interrupt but does not wait for the
currently executing threaded handler to finish, the handler can successfully
re-queue the delayed work. 

Since qcom_cpufreq_hw_cpu_exit() does not cancel the delayed work before
destroying resources, will the work fire after the driver is unbound, leading
to a use-after-free and the execution of unloaded module code?

[Severity: High]
This is a pre-existing issue, but a missing bounds check on the index parsed
from the device tree leads to an out-of-bounds array access.

In qcom_cpufreq_hw_cpu_init(), the driver parses the qcom,freq-domain property
from the device tree to obtain an index:

    ret = of_parse_phandle_with_args(cpu_np, "qcom,freq-domain",
                                     "#freq-domain-cells", 0, &args);
    ...
    index = args.args[0];

It immediately uses this index to access the dynamically allocated global
array:

    data = &qcom_cpufreq.data[index];

There is no verification that index is strictly less than num_domains (which is
determined during probe by counting available MMIO resources). 

Could a malformed or malicious device tree supplying an out-of-bounds index
cause the driver to read garbage memory for data->base, leading to a page
fault and kernel panic when it subsequently attempts
readl_relaxed(data->base + ...)?

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