[PATCH AUTOSEL 6.18-6.6] cpufreq: dt-platdev: Add JH7110S SOC to the allowlist

[PATCH AUTOSEL 6.18-6.6] cpufreq: dt-platdev: Add JH7110S SOC to the allowlist

[Sasha Levin]

From: Hal Feng <hal.feng@starfivetech.com>

[ Upstream commit 6e7970cab51d01b8f7c56f120486c571c22e1b80 ]

Add the compatible strings for supporting the generic
cpufreq driver on the StarFive JH7110S SoC.

Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.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

**Subject**: `cpufreq: dt-platdev: Add JH7110S SOC to the allowlist`

**Key observations**:
- Uses "Add" (new hardware support), not "Fix"
- No "Cc: stable@vger.kernel.org" tag
- No "Fixes:" tag
- No bug report references ("Reported-by:", "Link:")
- Reviewed-by from Heinrich Schuchardt (Canonical)
- Signed-off by Viresh Kumar (cpufreq maintainer)

**Commit message**: Adds compatible strings to enable the generic
cpufreq driver on StarFive JH7110S SoC.

### 2. CODE CHANGE ANALYSIS

**Files changed**: 1 file (`drivers/cpufreq/cpufreq-dt-platdev.c`)

**Change**: Single line addition:
```c
+       { .compatible = "starfive,jh7110s", },
```

**Context**: Added to the `allowlist[]` array (line 90), right after
`starfive,jh7110`.

**Code logic** (from `cpufreq_dt_platdev_init()`):
1. If root node matches allowlist → create cpufreq-dt device
2. Else if CPU0 has `operating-points-v2` and root node is not in
   blocklist → create cpufreq-dt device
3. Else → return -ENODEV

**Impact**: Adding `starfive,jh7110s` to the allowlist ensures the
cpufreq-dt platform device is always created, regardless of operating-
points version.

**Root cause**: Without this entry, cpufreq-dt may not be created for
jh7110s devices, breaking CPU frequency scaling.

### 3. CLASSIFICATION

**Is this fixing a bug or adding a feature?**

- No explicit bug report or "Fixes:" tag
- Enables hardware support for a new SoC variant
- Similar to the jh7110 addition (commit `4b4c0d37164c2`, April 2023)

**Exception category check**:

1. Device IDs/compatible strings: Yes — compatible strings are device
   tree device IDs. Stable rules allow "just add a device ID"
   (Documentation/process/stable-kernel-rules.rst line 15).
2. Hardware quirks/workarounds: No
3. Device tree updates: Related — enables DT-based cpufreq support
4. Build fixes: No
5. Documentation: No

**Classification**: Compatible string addition (device tree device ID),
which stable rules explicitly allow.

### 4. SCOPE AND RISK ASSESSMENT

**Lines changed**: 1 line added, 0 removed

**Complexity**: Trivial — single array entry

**Files touched**: 1 file

**Subsystem**: `drivers/cpufreq` — mature, well-tested

**Risk assessment**:
- Low risk: no logic changes, only a list entry
- No dependencies: standalone change
- Driver exists in stable: `cpufreq-dt-platdev.c` added in 2016 (commit
  `f56aad1d98f1c`)
- Pattern matches existing entries (e.g., jh7110)

**Potential issues**:
- None identified — this is a pure addition

### 5. USER IMPACT

**Who is affected**:
- Users with StarFive JH7110S hardware running stable kernels
- Without this, cpufreq may not initialize, disabling CPU frequency
  scaling

**Severity if bug hits**:
- Medium — cpufreq not working means:
  - No dynamic frequency scaling
  - Potential performance/power impact
  - Not a crash, but degraded functionality

**Evidence of user impact**:
- No bug reports found in the commit
- No device tree files for jh7110s in the kernel tree
- Commit is recent (October 2025)

**Assessment**: Enables hardware support; if jh7110s hardware exists on
stable kernels, this fixes missing cpufreq functionality.

### 6. STABILITY INDICATORS

**Tested-by**: None

**Reviewed-by**: Heinrich Schuchardt (Canonical) — positive signal

**Age in mainline**: Very recent (October 2025)

**Maintainer sign-off**: Viresh Kumar (cpufreq maintainer)

### 7. DEPENDENCY CHECK

**Prerequisites**: None — standalone change

**Code existence in stable**: Yes — `cpufreq-dt-platdev.c` exists in
stable trees (added 2016)

**API dependencies**: None — only adds a compatible string

**Backport adjustments**: None — applies cleanly

### 8. HISTORICAL CONTEXT

**Similar commits**:
- `4b4c0d37164c2` (April 2023): Added `starfive,jh7110` — same pattern,
  no stable tag
- Other SoC additions to allowlist follow the same pattern

**Pattern**: SoC additions to cpufreq allowlist typically do not include
"Cc: stable" tags, but many are still acceptable for stable as device ID
additions.

### 9. STABLE KERNEL RULES COMPLIANCE

**Rule 1: Obviously correct and tested**
- Yes — trivial, follows established pattern, maintainer sign-off

**Rule 2: Fixes a real bug**
- Borderline — enables hardware support; if hardware exists, fixes
  broken cpufreq

**Rule 3: Fixes an important issue**
- Medium importance — enables CPU frequency scaling

**Rule 4: Small and contained**
- Yes — 1 line addition

**Rule 5: No new features**
- Borderline — enables new hardware support, but compatible strings are
  explicitly allowed as device IDs

**Rule 6: Applies cleanly**
- Yes — no conflicts expected

**Exception applies**: Yes — compatible string additions are treated
like device ID additions, which stable rules allow.

### 10. FINAL ASSESSMENT

**Arguments for YES**:
1. Compatible strings are device tree device IDs; stable rules allow
   device ID additions
2. Very low risk — single line, no logic changes
3. Follows established pattern (jh7110 precedent)
4. Fixes broken cpufreq for jh7110s hardware on stable kernels
5. Driver exists in stable trees
6. No dependencies
7. Maintainer sign-off

**Arguments for NO**:
1. No "Cc: stable" tag
2. No explicit bug report
3. Enables new hardware support rather than fixing a documented bug
4. Very recent commit (limited testing time)

**Decision rationale**:

This is a compatible string addition, equivalent to a device ID
addition. Stable rules explicitly allow "just add a device ID"
(Documentation/process/stable-kernel-rules.rst line 15). The change is
trivial, low-risk, and fixes broken cpufreq functionality for jh7110s
hardware on stable kernels. The absence of a "Cc: stable" tag is not
disqualifying; many device ID additions are backported without it.

The commit enables hardware support, but compatible string additions are
treated as device ID additions and are acceptable for stable trees. If
jh7110s hardware exists and users run stable kernels, this fixes missing
cpufreq support.

**YES**

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

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index cd1816a12bb99..dc11b62399ad5 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -87,6 +87,7 @@ static const struct of_device_id allowlist[] __initconst = {
 	{ .compatible = "st-ericsson,u9540", },
 
 	{ .compatible = "starfive,jh7110", },
+	{ .compatible = "starfive,jh7110s", },
 
 	{ .compatible = "ti,omap2", },
 	{ .compatible = "ti,omap4", },
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] cpufreq: s5pv210: fix refcount leak

[Sasha Levin]

From: Shuhao Fu <sfual@cse.ust.hk>

[ Upstream commit 2de5cb96060a1664880d65b120e59485a73588a8 ]

In function `s5pv210_cpu_init`, a possible refcount inconsistency has
been identified, causing a resource leak.

Why it is a bug:
1. For every clk_get, there should be a matching clk_put on every
successive error handling path.
2. After calling `clk_get(dmc1_clk)`, variable `dmc1_clk` will not be
freed even if any error happens.

How it is fixed: For every failed path, an extra goto label is added to
ensure `dmc1_clk` will be freed regardlessly.

Signed-off-by: Shuhao Fu <sfual@cse.ust.hk>
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 message describes a refcount leak:
- Subject: "cpufreq: s5pv210: fix refcount leak"
- Explains the bug: `dmc1_clk` is not freed on error paths
- Explains the fix: adds a new `out:` label to ensure cleanup
- Signed-off-by: Shuhao Fu and Viresh Kumar (cpufreq maintainer)

Missing tags:
- No "Cc: stable@vger.kernel.org"
- No "Fixes:" tag pointing to the commit that introduced the bug
  (4911ca1031c2ad from 2011)

### 2. CODE CHANGE ANALYSIS

The bug:
- In `s5pv210_cpu_init()`, after `dmc1_clk = clk_get(...)` succeeds, two
  error paths jump to `out_dmc1`:
  1. `policy->cpu != 0` (line 521)
  2. Unsupported memory type (line 533)
- `out_dmc1` only frees `dmc0_clk` and `policy->clk`, not `dmc1_clk`,
  causing a refcount leak.

The fix:
- Adds a new `out:` label that calls `clk_put(dmc1_clk)`
- Changes the two error paths to `goto out;` instead of `goto out_dmc1;`
- `out:` falls through to `out_dmc1` for the rest of cleanup

Change size: 4 lines added, 2 lines modified (minimal change)

### 3. CLASSIFICATION

- Bug fix: fixes a resource leak
- Not a feature addition
- Not a new API
- Standard error handling pattern

### 4. SCOPE AND RISK ASSESSMENT

- Scope: single function, error paths only
- Risk: low
  - Only affects error paths
  - Standard cleanup pattern
  - No logic changes beyond cleanup
- Subsystem: cpufreq (mature)
- Dependencies: none; self-contained

### 5. USER IMPACT

- Affected users: systems using the S5PV210/S5PC110 cpufreq driver
- Severity: resource leak (not a crash, but still a bug)
- Trigger conditions:
  1. `policy->cpu != 0` (non-zero CPU)
  2. Unsupported memory type (not LPDDR/LPDDR2)
- Impact: clock reference leak on error paths

Historical context:
- Driver introduced in v2.6.37 (2010)
- Bug introduced in commit 4911ca1031c2ad (2011-06-06)
- Present in all stable trees since 2011

### 6. STABILITY INDICATORS

- Tested: no "Tested-by:" tag
- Reviewed: signed by Viresh Kumar (maintainer)
- Age: commit is recent (Oct 2025), but the bug is old

### 7. DEPENDENCY CHECK

- No dependencies
- Code exists in stable trees (driver present since v2.6.37)
- Fix applies cleanly to stable trees

### 8. COMPARISON WITH SIMILAR FIXES

Similar refcount leak fixes in cpufreq:
- `cpufreq: nforce2: fix reference count leak` (9600156bb9985)
- `cpufreq: mediatek: fix device leak on probe failure` (ebc4ed14a4dbf)
- `cpufreq: qcom-nvmem: fix memory leaks in probe error paths`
  (e3fd01a810537)

These follow the same pattern and are appropriate for stable.

### 9. STABLE KERNEL RULES COMPLIANCE

- Obviously correct: yes — standard cleanup pattern
- Fixes a real bug: yes — resource leak
- Important issue: moderate — resource leak, not a crash
- Small and contained: yes — 6 lines changed
- No new features: yes — only fixes cleanup
- Applies cleanly: yes — no dependencies

### 10. RISK VS BENEFIT TRADE-OFF

Benefits:
- Fixes a long-standing bug (14 years)
- Prevents resource leaks
- Low risk, small change
- Standard pattern

Risks:
- Minimal — only touches error paths
- No functional changes

Concerns:
- No explicit stable request tag
- Driver targets older ARM SoCs (may have limited current use)
- Leak only occurs on error paths

### FINAL ASSESSMENT

This is a valid bug fix that meets stable criteria:
1. Fixes a real resource leak
2. Small, contained change
3. Low risk
4. No new features
5. Standard error handling pattern

The lack of a "Cc: stable" tag is not a blocker; maintainers may add it,
or it may have been missed. The fix is appropriate for stable backport.

**YES**

 drivers/cpufreq/s5pv210-cpufreq.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
index 4215621deb3fe..ba8a1c96427a1 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -518,7 +518,7 @@ static int s5pv210_cpu_init(struct cpufreq_policy *policy)
 
 	if (policy->cpu != 0) {
 		ret = -EINVAL;
-		goto out_dmc1;
+		goto out;
 	}
 
 	/*
@@ -530,7 +530,7 @@ static int s5pv210_cpu_init(struct cpufreq_policy *policy)
 	if ((mem_type != LPDDR) && (mem_type != LPDDR2)) {
 		pr_err("CPUFreq doesn't support this memory type\n");
 		ret = -EINVAL;
-		goto out_dmc1;
+		goto out;
 	}
 
 	/* Find current refresh counter and frequency each DMC */
@@ -544,6 +544,8 @@ static int s5pv210_cpu_init(struct cpufreq_policy *policy)
 	cpufreq_generic_init(policy, s5pv210_freq_table, 40000);
 	return 0;
 
+out:
+	clk_put(dmc1_clk);
 out_dmc1:
 	clk_put(dmc0_clk);
 out_dmc0:
-- 
2.51.0