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

[PATCH v3 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 v3:
- Updated bindings as per the review comments [Krzysztof]
- Updated driver patch commit text [Dmitry]
- Updated compatible in driver patch as per the bindings
- Link to v2: https://lore.kernel.org/r/20260519-shikra-cpufreq-scaling-v2-0-2b09f0e1c9d8@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/qcom,shikra-epss.yaml         | 96 ++++++++++++++++++++++
 drivers/cpufreq/qcom-cpufreq-hw.c                  | 23 +++++-
 2 files changed, 116 insertions(+), 3 deletions(-)
---
base-commit: 0787c45ea08a13b5482e701fabc741877cf681f6
change-id: 20260430-shikra-cpufreq-scaling-aff690130063

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

[PATCH v3 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/qcom,shikra-epss.yaml         | 96 ++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..8543fd00d82acdbb3422bde462417118aa4c49d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/qcom,shikra-epss.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-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
+  - interrupts
+  - interrupt-names
+  - '#freq-domain-cells'
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,rpmcc.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    soc {
+      #address-cells = <1>;
+      #size-cells = <1>;
+
+      cpufreq@fd91000 {
+        compatible = "qcom,shikra-epss";
+        reg = <0x0fd91000 0x1000>, <0x0fd92000 0x1000>;
+        reg-names = "freq-domain0", "freq-domain1";
+        clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&gpll0>;
+        clock-names = "xo", "alternate";
+        interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+        interrupt-names = "dcvsh-irq-0", "dcvsh-irq-1";
+        #freq-domain-cells = <1>;
+        #clock-cells = <1>;
+      };
+    };
+...

-- 
2.34.1

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

[Krzysztof Kozlowski]

On Thu, May 21, 2026 at 07:36:04PM +0530, Imran Shaik wrote:
> 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/qcom,shikra-epss.yaml         | 96 ++++++++++++++++++++++
>  1 file changed, 96 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..8543fd00d82acdbb3422bde462417118aa4c49d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpufreq/qcom,shikra-epss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: CPUFREQ HW for Qualcomm Shikra SoC

Qualcomm Shikra SoC EPSS

> +
> +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

EPSS is a ....

> +  frequency in hardware. It is capable of controlling frequency for
> +  multiple clusters.
> +
> +  The Qualcomm Shikra CPUFREQ HW supports up to 12 frequency lookup table

here as well, like I mentioned last time. cpufreq is linuxism and I
asked you about name of actual device.

With above:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

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

[Imran Shaik]

On 22-05-2026 12:04 pm, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 07:36:04PM +0530, Imran Shaik wrote:
>> 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/qcom,shikra-epss.yaml         | 96 ++++++++++++++++++++++
>>   1 file changed, 96 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..8543fd00d82acdbb3422bde462417118aa4c49d1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/qcom,shikra-epss.yaml
>> @@ -0,0 +1,96 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/cpufreq/qcom,shikra-epss.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: CPUFREQ HW for Qualcomm Shikra SoC
> 
> Qualcomm Shikra SoC EPSS
> 
>> +
>> +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
> 
> EPSS is a ....
> 
>> +  frequency in hardware. It is capable of controlling frequency for
>> +  multiple clusters.
>> +
>> +  The Qualcomm Shikra CPUFREQ HW supports up to 12 frequency lookup table
> 
> here as well, like I mentioned last time. cpufreq is linuxism and I
> asked you about name of actual device.
> 

Sure, will drop CPUFREQ and use EPSS as you mentioned, and post next series.

Thanks,
Imran

> With above:
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> 
> Best regards,
> Krzysztof
> 

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

[Krzysztof Kozlowski]

On Thu, May 21, 2026 at 07:36:04PM +0530, Imran Shaik wrote:
> 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/qcom,shikra-epss.yaml         | 96 ++++++++++++++++++++++
>  1 file changed, 96 insertions(+)

Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters

There is no "qcom-hw" schema, so no clue from where did you get this
one.

Best regards,
Krzysztof

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

[Imran Shaik]

On 22-05-2026 12:05 pm, Krzysztof Kozlowski wrote:
> On Thu, May 21, 2026 at 07:36:04PM +0530, Imran Shaik wrote:
>> 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/qcom,shikra-epss.yaml         | 96 ++++++++++++++++++++++
>>   1 file changed, 96 insertions(+)
> 
> Please use subject prefixes matching the subsystem. You can get them for
> example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
> your patch is touching. For bindings, the preferred subjects are
> explained here:
> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
> 
> There is no "qcom-hw" schema, so no clue from where did you get this
> one.
> 

Actually, I picked the reference from latest Eliza/Milos commits. Will 
drop the qcom-hw prefix, and update as blow for Shikra and post next series.

dt-bindings: cpufreq: Document Qualcomm Shikra SoC EPSS

Thanks,
Imran

> Best regards,
> Krzysztof
> 

[PATCH v3 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. When all
12 entries are populated, the existing repetitive LUT entry check may read
beyond valid entries and expose incorrect frequencies. Hence, introduce
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..3d5a865fb8a35e112cb4d040fb519e2c122a91dc 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-epss", .data = &shikra_epss_soc_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);

-- 
2.34.1

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

[sashiko-bot]

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

Pre-existing issues:
- [Critical] Invalid `kfree()` on a `devm_kzalloc`-managed interior pointer in `qcom_cpufreq_hw_cpu_exit()` leads to a guaranteed SLUB BUG and kernel panic.
- [High] Boost/Turbo frequency is lost and incorrectly reported as invalid (~0u) when the hardware frequency LUT is completely populated.
- [High] Memory and OPP entries are permanently leaked in the error paths of `qcom_cpufreq_hw_cpu_init()`.
- [High] An unbalanced `disable_irq_nosync()` during CPU offline leaves the LMh hardware throttle IRQ permanently disabled.
- [Medium] Unhandled `request_threaded_irq()` failure leaves `throttle_irq` populated, leading to invalid IRQ operations and kernel warnings.
--

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

cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC

This commit introduces cpufreq scaling support for the Qualcomm Shikra SoC by
adding the shikra_epss_soc_data structure. It dynamically limits the frequency
lookup table based on the new lut_max_entries field, replacing the hardcoded
LUT_MAX_ENTRIES limit to prevent out-of-bounds reads.

> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index ea9a20d27b8fd..3d5a865fb8a35 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
[ ... ]
> @@ -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);

[Severity: High]
This is a pre-existing issue, but if the hardware frequency lookup table is
completely populated up to soc_data->lut_max_entries with unique
frequencies, doesn't the loop terminate without processing a duplicate
entry? 

If so, it appears the fix-up block is bypassed, leaving the highest
performance state marked as CPUFREQ_ENTRY_INVALID (~0u). Could this cause
qcom_cpufreq_get_freq() to return ~0u and potentially break the scaling
governors?

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but looking at
qcom_cpufreq_hw_cpu_init(), if steps fail after policy->freq_table is
allocated via kzalloc_objs (such as a failure in qcom_cpufreq_hw_lmh_init),
the function directly returns an error code. 

Since the cpufreq core doesn't invoke the exit() callback on an init()
failure, does this permanently leak the dynamically allocated memory and opp
entries?

[Severity: Critical]
This is a pre-existing issue, but in qcom_cpufreq_hw_cpu_exit(), the code
calls kfree(data) on policy->driver_data. 

Given that qcom_cpufreq.data was originally allocated using devm_kzalloc()
in qcom_cpufreq_hw_driver_probe(), won't passing this interior pointer
directly to kfree() cause a slab allocator bug and kernel panic?

[Severity: High]
This is a pre-existing issue, but when hardware throttling occurs,
qcom_lmh_dcvs_handle_irq() calls disable_irq_nosync() and schedules
throttle_work to re-enable it. 

If the cpu is offlined before the work executes,
qcom_cpufreq_hw_cpu_offline() cancels the work and calls
disable_irq_nosync() again. 

Will this bring the irq disable depth to 2, so that when the cpu is brought
back online, qcom_cpufreq_ready() calling enable_irq() only reduces the
depth to 1 and leaves the thermal throttling interrupt permanently disabled?

[Severity: Medium]
This isn't a bug introduced by this patch, but in qcom_cpufreq_hw_lmh_init(),
if request_threaded_irq() fails, it logs an error and returns 0. 

However, it doesn't seem to invalidate data->throttle_irq. Because it is
still populated with a valid irq number, will subsequent cpufreq callbacks
like qcom_cpufreq_ready() and qcom_cpufreq_hw_lmh_exit() erroneously attempt
to call enable_irq() and free_irq() on it?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-shikra-cpufreq-scaling-v3-0-883c13d1e514@oss.qualcomm.com?part=2