[PATCH AUTOSEL 6.19-6.12] powercap: intel_rapl: Add PL4 support for Ice Lake

[Sasha Levin <sashal@kernel.org>]

From: Daniel Tang <danielzgtg.opensource@gmail.com>

[ Upstream commit 54b3cd55a515c7c0fcfa0c1f0b10d62c11d64bcc ]

Microsoft Surface Pro 7 firmware throttles the processor upon
boot/resume. Userspace needs to be able to restore the correct value.

Link: https://github.com/linux-surface/linux-surface/issues/706
Signed-off-by: Daniel Tang <danielzgtg.opensource@gmail.com>
Link: https://patch.msgid.link/6088605.ChMirdbgyp@daniel-desktop3
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have all the information needed for a thorough analysis.

---

## Detailed Analysis

### 1. Commit Message Analysis

**Subject**: `powercap: intel_rapl: Add PL4 support for Ice Lake`

**Body**: States the Microsoft Surface Pro 7 firmware throttles the
processor upon boot/resume, and userspace needs to be able to restore
the correct value. Links to a GitHub issue.

**Key observations**:
- "Add PL4 support" sounds like a feature addition
- But the commit message explains a **concrete hardware problem**:
  firmware incorrectly throttles the CPU
- Links to a well-documented issue with multiple affected users over 4+
  years

### 2. Code Change Analysis

The change is a single line addition:

```c
X86_MATCH_VFM(INTEL_ICELAKE_L, NULL),
```

added to the `pl4_support_ids[]` array. This is a **CPU ID table
addition** to an existing, mature driver feature.

**How it works mechanically**: In `rapl_msr_probe()`, the driver checks
`x86_match_cpu(pl4_support_ids)`. If the running CPU matches, the
driver:
1. Sets `BIT(POWER_LIMIT4)` in the package limits
2. Registers `MSR_VR_CURRENT_CONFIG` (0x601) as the PL4 register
3. This exposes a `peak_power` constraint in the powercap sysfs
   interface

Without ICELAKE_L in the list, there is **no kernel-provided mechanism**
for userspace to read or write MSR 0x601 on Ice Lake systems. The only
workaround is raw MSR access via `wrmsr`, which doesn't work with Secure
Boot/SELinux.

### 3. Real-World Impact Assessment

The linked GitHub issue (#706) documents a severe problem:

- **Affected hardware**: Microsoft Surface Pro 7 (Intel Ice Lake /
  ICELAKE_L, model 0x7E)
- **Symptoms**: CPU throttled to 400-1500 MHz after boot or resume from
  suspend. Devices become essentially unusable.
- **Root cause**: Surface Pro 7 firmware sets MSR_VR_CURRENT_CONFIG to a
  very low value (e.g., 0x78 = ~15A peak current, far too low for normal
  operation)
- **Severity**: Multiple users over 4+ years reported this issue. Some
  users reported getting stuck at 400 MHz even at 100% battery.
- **Affected user base**: The linux-surface project has 7,000+ GitHub
  stars, and Surface Pro 7 was a popular device

The workaround proven by the community (manually writing MSR 0x601)
confirms that exposing PL4 control is the correct fix.

### 4. Classification: Device ID / Hardware Quirk

This commit falls squarely within the **"New Device IDs"** exception
category for stable backports:

- The PL4 infrastructure (`pl4_support_ids`, `POWER_LIMIT4`,
  `MSR_VR_CURRENT_CONFIG`, the sysfs interface) **already exists in all
  current stable trees** (verified: v5.10, v5.15, v6.1, v6.6, v6.12)
- Only the CPU ID (ICELAKE_L) is new
- The driver already supports Ice Lake for all other RAPL functionality;
  PL4 is the only missing piece
- This is analogous to a **hardware quirk/workaround** for broken
  firmware behavior on specific devices

### 5. Scope and Risk Assessment

- **Size**: 1 line added to a static const array
- **Files touched**: 1 (`drivers/powercap/intel_rapl_msr.c`)
- **Risk of regression**: Effectively zero. The change only affects
  systems with INTEL_ICELAKE_L CPUs. All other systems are completely
  unaffected. The PL4 mechanism is well-tested on Tiger Lake, Alder
  Lake, Raptor Lake, Meteor Lake, Arrow Lake, etc.
- **Worst case**: PL4 sysfs interface appears on Ice Lake systems but
  nobody uses it (no harm - it's read-only until userspace writes to it)

### 6. Backport Compatibility

The `pl4_support_ids[]` array exists in all stable trees but uses
different macro formats:

- **v6.12**: Uses `X86_MATCH_VFM()` - **patch applies cleanly**
- **v6.6**: Uses `X86_MATCH_INTEL_FAM6_MODEL()` - trivial adaptation
  needed: `X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_L, NULL)`
- **v6.1, v5.15**: Uses raw struct format - trivial adaptation: `{
  X86_VENDOR_INTEL, 6, INTEL_FAM6_ICELAKE_L, X86_FEATURE_ANY }`

All adaptations are mechanical and `INTEL_FAM6_ICELAKE_L` (0x7E) is
defined in all these stable trees.

### 7. Dependency Check

No dependencies. The entire PL4 infrastructure (commit `8365a898fe53f`
from 2020) is already in all active stable kernels. This is a standalone
one-line addition.

### 8. Summary

| Criterion | Assessment |
|-----------|-----------|
| Fixes real bug | Yes - firmware throttling making devices unusable |
| Obviously correct | Yes - identical pattern to 14 other CPU IDs in
same list |
| Small and contained | Yes - 1 line in 1 file |
| No new features | Correct - enables existing feature for additional
hardware |
| Tested | Yes - author tested on Surface Pro 7, community validated MSR
approach |
| Risk | Extremely low |
| User impact | High - Surface Pro 7 users affected for 4+ years |

This is a textbook CPU ID addition to an existing driver, enabling a
critical workaround for broken firmware behavior on popular hardware. It
meets all stable kernel criteria and falls within the well-established
exception for device ID additions and hardware quirks.

**YES**

 drivers/powercap/intel_rapl_msr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rapl_msr.c
index 9a7e150b3536b..a2bc0a9c1e103 100644
--- a/drivers/powercap/intel_rapl_msr.c
+++ b/drivers/powercap/intel_rapl_msr.c
@@ -162,6 +162,7 @@ static int rapl_msr_write_raw(int cpu, struct reg_action *ra)
 
 /* List of verified CPUs. */
 static const struct x86_cpu_id pl4_support_ids[] = {
+	X86_MATCH_VFM(INTEL_ICELAKE_L, NULL),
 	X86_MATCH_VFM(INTEL_TIGERLAKE_L, NULL),
 	X86_MATCH_VFM(INTEL_ALDERLAKE, NULL),
 	X86_MATCH_VFM(INTEL_ALDERLAKE_L, NULL),
-- 
2.51.0