From: Li RongQing lirongqing@baidu.com
[ Upstream commit fc64e0421598aaa87d61184f6777b52614a095be ]
Users may disable HWP in firmware, in which case intel_pstate wouldn't load unless the CPU model is explicitly supported.
Signed-off-by: Li RongQing lirongqing@baidu.com Link: https://patch.msgid.link/20250623105601.3924-1-lirongqing@baidu.com 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:
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's the extensive analysis:
**Nature of the Change:** The commit adds support for Intel Granite Rapids processors (both D and X variants) in the intel_pstate driver when Hardware P-states (HWP) is disabled in firmware. This is a hardware enablement patch that adds two new CPU model IDs to existing lists: - `INTEL_GRANITERAPIDS_D` and `INTEL_GRANITERAPIDS_X` are added to `intel_pstate_cpu_ids[]` table
**Why This Is a Good Backport Candidate:**
1. **Fixes a Real User-Facing Issue**: Without this patch, users who have Granite Rapids CPUs with HWP disabled in firmware cannot use the intel_pstate driver at all. The commit message explicitly states "intel_pstate wouldn't load unless the CPU model is explicitly supported." This means affected systems would fall back to less efficient CPU frequency scaling drivers, significantly impacting performance and power efficiency.
2. **Minimal and Safe Change**: The patch only adds two lines to an existing CPU ID table: ```c + X86_MATCH(INTEL_GRANITERAPIDS_D, core_funcs), + X86_MATCH(INTEL_GRANITERAPIDS_X, core_funcs), ``` These entries follow the exact same pattern as all other CPU entries and use the standard `core_funcs` handler, which is already used by many other Intel CPU models.
3. **No Architectural Changes**: The commit doesn't introduce any new features, modify existing logic, or change any kernel interfaces. It's purely a hardware enablement patch that extends existing functionality to new hardware.
4. **Low Risk of Regression**: - The change is contained entirely within CPU model detection tables - It only affects systems with the specific Granite Rapids CPU models - Uses the well-tested `core_funcs` implementation already used by Sapphire Rapids, Emerald Rapids, and other server CPUs - The code path is only triggered on systems with these specific CPUs
5. **Follows Established Pattern**: Looking at the surrounding code, Granite Rapids entries were already present in the `intel_pstate_cpu_oob_ids[]` table (for out-of-band control), indicating this is completing support that was partially added previously.
6. **Important for Server Deployments**: Granite Rapids is a server CPU platform, and enterprise users often disable HWP for specific workload requirements or compatibility reasons. Without this patch, they lose access to the intel_pstate driver entirely.
The commit meets all the criteria for stable backporting: it fixes a real bug (driver fails to load on supported hardware), the fix is minimal and contained, there's no risk to existing systems, and it provides important functionality for affected users.
drivers/cpufreq/intel_pstate.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index ba9bf06f1c77..48fe6c0fa7c7 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -2656,6 +2656,8 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = { X86_MATCH(INTEL_TIGERLAKE, core_funcs), X86_MATCH(INTEL_SAPPHIRERAPIDS_X, core_funcs), X86_MATCH(INTEL_EMERALDRAPIDS_X, core_funcs), + X86_MATCH(INTEL_GRANITERAPIDS_D, core_funcs), + X86_MATCH(INTEL_GRANITERAPIDS_X, core_funcs), {} }; MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);