[PATCH AUTOSEL 6.19-6.6] cpufreq: dt-platdev: Block the driver from probing on more QC platforms

[Sasha Levin <sashal@kernel.org>]

From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

[ Upstream commit 7b781899072c5701ef9538c365757ee9ab9c00bd ]

Add a number of QC platforms to the blocklist, they all use either the
qcom-cpufreq-hw driver.

Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### 1. Commit Message Analysis

The commit adds three Qualcomm platform compatible strings
(`qcom,sm6125`, `qcom,sm6150`, `qcom,sm7125`) to the cpufreq-dt-platdev
blocklist. The message states these platforms all use the `qcom-cpufreq-
hw` driver and should not use the generic `cpufreq-dt` driver. The same
author (Konrad Dybcio from Qualcomm) made a nearly identical batch
blocklist addition in commit `0aea7a2f88a5` in 2023.

### 2. Code Change Analysis

The change adds exactly 3 lines to the `blocklist[]` table in `cpufreq-
dt-platdev.c`:

```c
{ .compatible = "qcom,sm6125", },
{ .compatible = "qcom,sm6150", },
{ .compatible = "qcom,sm7125", },
```

The logic in `cpufreq_dt_platdev_init()` (line 220-238) works as
follows:
1. If platform matches `allowlist` → create cpufreq-dt device (OPPv1
   platforms)
2. If CPU0 has `operating-points-v2` AND platform is NOT in `blocklist`
   → create cpufreq-dt device
3. Otherwise → don't create the device

Without the blocklist entries, a platform that has `operating-points-v2`
on CPU nodes but uses a dedicated cpufreq driver (like `qcom-cpufreq-
hw`) will get a spurious `cpufreq-dt` platform device created, leading
to driver conflict.

### 3. Impact Analysis for Each Platform

**SM7125 (the most important for stable):**
- `sm7125.dtsi` includes `sc7180.dtsi`, which defines CPU nodes with
  `operating-points-v2` and `qcom,freq-domain = <&cpufreq_hw>`.
- SC7180 is already blocklisted, but SM7125 boards declare `compatible =
  "xiaomi,curtana", "qcom,sm7125"` — NOT `"qcom,sc7180"`.
- Therefore `of_machine_device_match(blocklist)` doesn't match, but
  `cpu0_node_has_opp_v2_prop()` returns true (inherited from sc7180).
- Result: `cpufreq-dt` platform device is incorrectly registered.
- SM7125 DTS was added in v6.7, so this bug affects stable 6.12+.
- Real devices affected: Xiaomi Redmi Note 9S (Curtana), Xiaomi Redmi
  Note 9 Pro (Joyeuse).

**SM6150:**
- Used by QCS615 platform (talos.dtsi), which has `cpufreq_hw` and
  `operating-points-v2` on CPU nodes.
- The cpufreq-hw OPP tables were only added in v6.19-rc1, so this only
  affects very new kernels.

**SM6125:**
- CPU nodes in `sm6125.dtsi` do NOT currently have `operating-
  points-v2`, so `cpu0_node_has_opp_v2_prop()` returns false and the bug
  doesn't trigger. This is a proactive addition.

### 4. Real-World Symptom

The SM8650 blocklist commit (`fc5414a4774e`) documents the exact
symptom:

```
[    0.388525] cpufreq-dt cpufreq-dt: failed register driver: -17
[    0.388537] cpufreq-dt cpufreq-dt: probe with driver cpufreq-dt
failed with error -17
```

Error `-17` is `-EEXIST` — the `qcom-cpufreq-hw` driver (registered at
`postcore_initcall`) is already in place when `cpufreq-dt` tries to
register (at `device_initcall` level). If module loading order changes
(e.g., one is built as a module), the wrong driver could actually handle
CPU frequency scaling.

### 5. Precedent

This exact type of change (adding platform compatible strings to the
blocklist) has been done **20+ times** in the file's history:
- `032b149bcc547` - SDM670 blocklist (2024-02-09)
- `b14ceb82c3a1b` - SM7325 blocklist (2024-08-08)
- `fc5414a4774e1` - SM8650 blocklist (2025-04-05)
- `0aea7a2f88a55` - Batch QC blocklist (2023-08-09) — same author

All of these are structurally identical 1-3 line table additions.

### 6. Risk Assessment

- **Risk: Essentially zero.** Adding entries to a blocklist table cannot
  introduce regressions. The only conceivable failure mode would be
  blocking a platform that actually needs cpufreq-dt, but these
  platforms are confirmed to use qcom-cpufreq-hw.
- **Scope:** 3 lines, 1 file, pure data table change.
- **No dependencies:** The change is completely self-contained.

### 7. Stable Applicability

- SM7125 exists in stable 6.12 (DTS added in v6.7, board files in v6.9).
  The bug is active there.
- SM6150 is too new for current stable trees (cpufreq-hw support only in
  v6.19).
- SM6125 is proactive and harmless.
- The patch applies cleanly to any stable tree that has the surrounding
  blocklist entries (which all current stable trees do).

### Conclusion

This is a trivial, safe blocklist addition that prevents incorrect
driver probing on Qualcomm SM7125 devices. It follows a pattern that has
been applied 20+ times before, fixes a real dmesg error (and potential
wrong-driver issue) on actual consumer hardware (Xiaomi phones), and has
zero risk of regression. The SM7125 fix is relevant for 6.12 stable.

**YES**

 drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index b06a43143d23c..2fecab989dacc 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -169,8 +169,11 @@ static const struct of_device_id blocklist[] __initconst = {
 	{ .compatible = "qcom,sdm845", },
 	{ .compatible = "qcom,sdx75", },
 	{ .compatible = "qcom,sm6115", },
+	{ .compatible = "qcom,sm6125", },
+	{ .compatible = "qcom,sm6150", },
 	{ .compatible = "qcom,sm6350", },
 	{ .compatible = "qcom,sm6375", },
+	{ .compatible = "qcom,sm7125", },
 	{ .compatible = "qcom,sm7225", },
 	{ .compatible = "qcom,sm7325", },
 	{ .compatible = "qcom,sm8150", },
-- 
2.51.0