[PATCH AUTOSEL 7.0-5.10] tools/power/x86/intel-speed-select: Avoid current base freq as maximum

[PATCH AUTOSEL 7.0-5.10] tools/power/x86/intel-speed-select: Avoid current base freq as maximum

[Sasha Levin]

From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

[ Upstream commit ae67f582398611b9f67c06961e292e3a2612346d ]

SST-PP level change results in online/offline of CPUs with -o option.
The Linux intel-pstate driver internally stores the current HWP_REQ MSR
value during offline and restores them during online.

It is possible that during SST-PP level change, the new HWP_CAP limits
can be updated. So, when a CPU is online, the HWP_REQ MSR should be
updated to new values based on HWP_CAP values.

This is particularly problematic when either turbo is disabled or the
current HWP_REQ value (stored before online) is less than the base
frequency from the updated HWP_CAP MSR guaranteed value. If the HWP_REQ
MSR is not updated, then the performance will be limited to the value
before perf level change.

Hence the tool updates cpufreq scaling_max_freq to the newer
base_frequency value in this case. This step is not required when HWP
interrupts are enabled, as the perf level change should result in a new
interrupt with HWP_GUARANTEED_PERF_CHANGE_STATUS and the intel_pstate
driver will update to new limits.

But the tool needs to handle the case when HWP interrupts are not
enabled but there is no way for the tool to know that HWP interrupts are
enabled or not. So, it has to still update the scaling_max_freq.

With the QOS changes in the kernel, user space writes to scaling_max_freq
are treated as hard limits. So, when base frequency is increased with
SST-BF enabled, the cpufreq subsystem will still not allow setting to the
SST-BF high priority core frequency. So, the HWP_REQ MSR will still be
capped to the user-set scaling_max_freq after SST-PP level change.

To address this, instead of setting scaling_max_freq to the current HWP_CAP
highest frequency, set it to the maximum integer value to set the QOS limit
as unconstrained. In this case, the actual HWP_REQ maximum frequency will
still be capped to HWP_CAP highest performance by the intel-pstate driver.
So, it will not result in invalid HWP_REQ values.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to provide a comprehensive analysis.

## Analysis: tools/power/x86/intel-speed-select: Avoid current base freq
as maximum

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Parse the subject line**
Record: Subsystem: `tools/power/x86/intel-speed-select` (userspace
tool). Action verb: "Avoid" (indicates behavior fix). Summary: Don't use
current base frequency as maximum when writing to cpufreq
scaling_max_freq.

**Step 1.2: Parse all commit message tags**
Record:
- No `Fixes:` tag
- No `Reported-by:` tag
- No `Tested-by:` tag
- No `Reviewed-by:` tag
- No `Acked-by:` tag
- No `Link:` tag
- No `Cc: stable@vger.kernel.org`
- Only author `Signed-off-by: Srinivas Pandruvada
  <srinivas.pandruvada@linux.intel.com>` (the tool maintainer)

Notable: no user-facing bug report, no reviewer feedback, no explicit
stable nomination. This is a solo fix by the maintainer.

**Step 1.3: Analyze the commit body text**
Record: Bug: When SST-PP level change triggers CPU online/offline
cycling (via `-o` option), intel_pstate saves HWP_REQ MSR on offline and
restores on online. But the new HWP_CAP limits may be different than
before; if turbo is disabled or stored HWP_REQ value is less than new
base_frequency, performance is limited. The tool's fix was to update
`scaling_max_freq` to the new `base_frequency`. However, kernel QoS
changes treat userspace writes to `scaling_max_freq` as HARD LIMITS.
When SST-BF is enabled and base_freq increases, SST-BF high priority
cores can no longer reach their high frequency because the
scaling_max_freq QoS limit is too low. The fix writes S32_MAX
(effectively unconstrained) so intel_pstate's actual HWP_CAP highest
performance acts as the cap.

**Step 1.4: Detect hidden bug fixes**
Record: Title uses "Avoid" which is the pattern indicator for a bug fix.
This IS fixing a real functional bug where SST-BF performance is limited
after SST-PP level transitions.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory the changes**
Record: 1 file modified: `tools/power/x86/intel-speed-select/isst-
config.c`. ~4 lines added (2 `#define`s + blank line), 1 line changed.
Total scope: ~5 lines. Single-file, surgical fix.

**Step 2.2: Understand the code flow change**
Record: In `adjust_scaling_max_from_base_freq()`: when `scaling_max_freq
< base_freq || no_turbo()`, BEFORE the fix it wrote `base_freq` to
cpufreq sysfs; AFTER the fix it writes `S32_MAX`. Kernel QoS interprets
this as "no userspace limit", allowing intel_pstate to cap at HWP_CAP
instead.

**Step 2.3: Identify the bug mechanism**
Record: Category: Logic/correctness fix (g). Mechanism: The tool was
capping CPU frequency at base_freq, but this was interacting with kernel
QoS semantics to prevent SST-BF high priority cores from reaching their
higher frequency. Fix: Use INT_MAX to indicate "unconstrained" QoS
request.

**Step 2.4: Assess the fix quality**
Record: Fix is obviously correct on reading — writing INT_MAX sets QoS
to default (unconstrained). Cannot cause regression because the kernel's
intel_pstate driver will still cap to HWP_CAP.highest_performance. One
minor note: the file defines U32_MAX/S32_MAX locally rather than using
`<limits.h>` (INT_MAX), but this is a stylistic choice not a correctness
concern.

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame the changed lines**
Record: `adjust_scaling_max_from_base_freq` was introduced by
`f981dc171c04c` ("tools/power/x86/intel-speed-select: Set
scaling_max_freq to base_frequency", 2020-12-20) and later touched by
`bbaa2e95e23e7` ("Set higher of cpuinfo_max_freq or base_frequency",
2020-12-20). The function has existed since v5.11.

**Step 3.2: Follow the Fixes: tag**
Record: No Fixes: tag. However, the "original commit that made this
broken" can be inferred: the conflict arose when kernel QoS changes
(da5c504c7aae9 "cpufreq: intel_pstate: Implement QoS supported freq
constraints" v5.4, and 3000ce3c52f8b "cpufreq: Use per-policy frequency
QoS" v5.5) made scaling_max_freq writes become hard QoS limits. This
means the tool's original behavior has been subtly broken since the QoS
infrastructure landed. Alternatively, the tool's own commit
f981dc171c04c added the problematic logic assuming old behavior.

**Step 3.3: Check file history for related changes**
Record: Related history shows `adjust_scaling_max_from_base_freq` was
last substantively modified in 2020. No intermediate fixes. This is not
part of a patch series — verified via lore mailing list pull request
showing it as one of two Srinivas patches (the other being v1.26 version
bump).

**Step 3.4: Check the author's other commits**
Record: Srinivas Pandruvada is the primary maintainer of intel-speed-
select and intel_pstate. He has authored dozens of commits to this file.
Highly authoritative source for the fix.

**Step 3.5: Check for dependent/prerequisite commits**
Record: The fix is standalone. It doesn't reference new APIs or
structures. The kernel-side QoS behavior it depends on (treating
scaling_max_freq as hard limit) has been in place since v5.5, well
before any active stable tree's branch point.

### PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: Find the original patch discussion**
Record: `b4 dig -c ae67f58239861` returned "Nothing matching that query"
— patch was apparently committed to the maintainer's tree without
posting as a separate patch submission on lore. Manual lore.kernel.org
search for "Avoid current base freq as maximum" found only the Pull
Request messages (not a submission thread). This confirms this commit
was NOT posted to a public mailing list for review — it went directly
through the maintainer's github branch into the pdx86 pull request.

**Step 4.2: Check who reviewed the patch**
Record: No public review. Found the pull request from Srinivas to Ilpo
Järvinen (pdx86 maintainer) on lore.kernel.org: `https://lore.kernel.org
/all/0b288f7a7024f896a1699ac3609c7da39c588d03.camel@intel.com/`, which
went into `review-ilpo-next` then to 7.1-rc1. Pull request lists it as
one of two Srinivas patches for v1.26 release. No review comments, no
stable nomination in the pull request.

**Step 4.3: Search for the bug report**
Record: No Reported-by tag. No syzbot, bugzilla, or user bug report
linked. No evidence this was discovered through a user report or
automated tooling.

**Step 4.4: Check for related patches and series**
Record: This is a standalone patch, not part of a series. Pull request
shows only 2 patches from Srinivas (this + version bump).

**Step 4.5: Check stable mailing list history**
Record: No discussion found on lore.kernel.org/stable for this fix.
However, historical precedent: `f981dc171c04c` (the commit that
introduced this same function) WAS backported to stable 5.10.14. This
establishes that fixes to this tool function have been considered
stable-worthy before.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Identify key functions in the diff**
Record: `adjust_scaling_max_from_base_freq(int cpu)` — the modified
function.

**Step 5.2: Trace callers**
Record: Called from 3 sites:
- Line 1581: In SST-PP `set_tdp_level` path when bringing CPUs online
  after level change (`use_offline:` label)
- Line 1864: In `set_scaling_max_to_cpuinfo_max`
- Line 1884: In `set_scaling_min_to_cpuinfo_min`
All are in the main SST-PP/SST-BF configuration code paths invoked when
user runs `intel-speed-select` commands.

**Step 5.3: Trace callees**
Record: Calls `parse_int_file()`, `get_cpufreq_base_freq()`,
`no_turbo()`, `set_cpufreq_scaling_min_max()` — standard sysfs
operations.

**Step 5.4: Follow the call chain**
Record: Reachable from: user running `intel-speed-select perf-profile
set-config-level -o` (SST-PP level change with CPU online/offline).
Triggered specifically when SST-BF is enabled and new level has
different HWP_CAP.

**Step 5.5: Search for similar patterns**
Record: The function `adjust_scaling_min_from_base_freq` follows a
similar pattern but for minimum freq and was NOT modified (the min-freq
case doesn't have the same hard-limit issue because minimum is supposed
to be set).

### PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

**Step 6.1: Does the buggy code exist in stable trees?**
Record: VERIFIED — the identical function exists in stable trees: 5.10,
5.15, 6.1, 6.6, 6.12, 6.18. The code has been unchanged since 2020.

**Step 6.2: Check for backport complications**
Record: Applies cleanly. The function signature and surrounding code are
identical in all stable trees. Verified by showing the function in for-
greg/5.10-200, 5.15-200, 6.6-200, 6.12-200 — all have exactly the same
body as mainline before this fix.

**Step 6.3: Check if related fixes are already in stable**
Record: The original function-introducing commit `f981dc171c04c` is in
stable (backported to 5.10.14). No different fix for this same bug has
been applied. The kernel-side QoS behavior is present in all stable
trees.

### PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Identify the subsystem and its criticality**
Record: `tools/power/x86/intel-speed-select/` — Intel Speed Select
Technology userspace utility. Criticality: PERIPHERAL. This is a
userspace tool, not kernel code. Affects only users of specific Intel
server CPUs (Xeon Scalable) using SST-PP/SST-BF features. Not a core
subsystem.

**Step 7.2: Assess subsystem activity**
Record: Active subsystem. The tool is regularly updated (v1.26 release
just announced). Srinivas is an active maintainer.

### PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Determine who is affected**
Record: Narrow user population: users of Intel Xeon Scalable CPUs with
SST-BF enabled who run `intel-speed-select` to change SST-PP levels with
`-o` (online/offline) option. Enterprise server administrators. Not
universal, not common consumer kernels.

**Step 8.2: Determine the trigger conditions**
Record: Specific conditions must all be met: (1) supported Intel CPU,
(2) user invokes SST-PP level change with `-o` option, (3) SST-BF
enabled, (4) HWP interrupts are NOT enabled, (5) new level has different
HWP_CAP values. User-initiated configuration tool, not triggered
spontaneously.

**Step 8.3: Determine the failure mode severity**
Record: Failure mode = CPU performance limited to base frequency (SST-BF
high priority cores cannot reach their intended higher frequency after
SST-PP level change). Severity: LOW-MEDIUM. No crash, no data
corruption, no security issue. It's a "feature doesn't work correctly"
bug.

**Step 8.4: Risk-benefit ratio**
Record:
- BENEFIT: LOW-MEDIUM. Fixes functional issue for SST-BF users. Affects
  only specific user scenarios.
- RISK: VERY LOW. 5-line change to a userspace tool. No kernel changes.
  Writing INT_MAX to scaling_max_freq is the documented way to indicate
  "no limit" in the QoS system. Cannot cause crashes.
- Ratio: Favorable. Low risk + some benefit = reasonable candidate.

### PHASE 9: FINAL SYNTHESIS

**Step 9.1: Compile the evidence**

Evidence FOR backporting:
- Fixes a real user-visible functional bug (SST-BF performance
  limitation)
- Very small, contained fix (5 lines, 1 file, userspace tool)
- From the authoritative tool maintainer (Srinivas)
- Applies cleanly to all active stable trees
- Function exists unmodified in all stable trees (5.10, 5.15, 6.1, 6.6,
  6.12, 6.18)
- Low regression risk (cannot cause crash since it's a userspace tool
  change)
- Precedent: the commit that introduced this function was backported to
  5.10.14
- intel-speed-select historically has many fixes backported to stable

Evidence AGAINST backporting:
- No `Fixes:` tag
- No `Cc: stable@vger.kernel.org`
- No `Reported-by:` (no user bug report evidence)
- No public review — went directly through maintainer tree
- Userspace tool, not kernel code
- Narrow use case (specific hardware + specific tool invocation)
- Failure mode is performance limitation, not crash/security/corruption
- The kernel QoS behavior it adapts to has been present for years, so
  this isn't a recent regression

Unresolved questions:
- UNVERIFIED: Whether any actual users have hit this (no user reports
  cited)
- UNVERIFIED: Whether the commit author considered stable backporting
  (no evidence either way)

**Step 9.2: Apply the stable rules checklist**
1. Obviously correct and tested? Correct by inspection. Testing unknown
   but from the maintainer.
2. Fixes a real bug? Yes — SST-BF performance not reaching target
   frequency after SST-PP level change.
3. Important issue? Borderline — not crash/security/corruption.
   Performance limitation in specific scenarios.
4. Small and contained? Yes — ~5 lines, single file.
5. No new features or APIs? Correct — fixes existing functionality.
6. Can apply to stable trees? Yes — verified clean apply across
   5.10-6.18.

**Step 9.3: Exception categories**
Not a device ID addition, quirk, DT update, build fix, or documentation
fix. It's a plain bug fix.

**Step 9.4: Decision**

This is a borderline case. The fix is small, safe, from the maintainer,
applies cleanly, and addresses a real functional issue. On the other
hand, it's a userspace tool with no explicit stable nomination, no
Fixes: tag, no Reported-by, and the failure mode is performance (not
crash/corruption/security). The narrow use case and lack of stable
markers argue against.

Weighing the factors: the fix is very low risk and fixes a real
functional issue for SST-BF users. Historically, intel-speed-select
fixes get backported. The code path exists in all stable trees and the
fix applies cleanly. The author is the maintainer.

### Verification:
- [Phase 1] Parsed tags: NO Fixes, NO Cc stable, NO Reported-by, NO
  Link, NO Reviewed-by — only author SoB (verified via `git show`)
- [Phase 2] Diff analysis: 4 lines added (U32_MAX/S32_MAX defines), 1
  line changed (base_freq → S32_MAX) in
  `adjust_scaling_max_from_base_freq()` (verified via `git show
  ae67f58239861`)
- [Phase 3] git log on file history: `adjust_scaling_max_from_base_freq`
  introduced by `f981dc171c04c` in Dec 2020 (verified via `git log
  --oneline --follow`)
- [Phase 3] kernel QoS commits traced: `da5c504c7aae9` (Aug 2019),
  `3000ce3c52f8b` (Oct 2019), `521223d8b3ec0` (Dec 2021) — QoS
  infrastructure in kernel for years (verified via `git log --format`)
- [Phase 3] Author is Srinivas Pandruvada, primary maintainer of intel-
  speed-select and intel_pstate (verified via `git log --author`
  history)
- [Phase 4] `b4 dig -c ae67f58239861`: returned "Nothing matching" — no
  public patch submission on lore
- [Phase 4] lore search found pull request from Srinivas to pdx86
  maintainer
  (`0b288f7a7024f896a1699ac3609c7da39c588d03.camel@intel.com`) dated
  2026-04-05 — grouped with v1.26 version bump, no explicit stable
  nomination
- [Phase 4] lore search confirmed `f981dc171c04c` was backported to
  stable 5.10.14 (found in Linux 5.10.14 announcement)
- [Phase 5] find_callers: 3 call sites in isst-config.c (lines 1581,
  1864, 1884), all in SST configuration paths invoked by user commands
  (verified via grep)
- [Phase 6] Function body verified unchanged in stable trees 5.10, 5.15,
  6.1, 6.6, 6.12, 6.18 (verified via `git show for-greg/X:tools/...`)
- [Phase 6] No Fixes: tag, so no "introduced by" commit to verify is in
  stable
- [Phase 7] Subsystem: intel-speed-select userspace tool, PERIPHERAL
  criticality
- [Phase 8] Failure mode: performance limitation (CPU capped at
  base_freq), not crash/corruption
- UNVERIFIED: Whether real users have reported hitting this bug (no
  Reported-by in commit)
- UNVERIFIED: Whether Srinivas consciously chose not to Cc stable

### Summary

This is a legitimate small bug fix for a userspace tool that addresses a
real functional issue: when using SST-PP level changes with SST-BF
enabled, the `intel-speed-select` tool was writing `base_freq` to
`scaling_max_freq`, which (due to kernel QoS semantics treating this as
a hard limit) prevented SST-BF high-priority cores from reaching their
target frequency. The fix changes to `INT_MAX` so the kernel's
intel_pstate driver (which caps at HWP_CAP.highest_performance) is the
effective limiter.

The fix is minimal (~5 lines), from the tool maintainer, and applies
cleanly to all active stable trees where the function exists unchanged
since 2020. The kernel QoS behavior it adapts to is present in all
stable trees. Precedent exists: the commit that introduced this function
(`f981dc171c04c`) was backported to 5.10.14.

Arguments against include: no Fixes: tag, no stable Cc, no Reported-by,
userspace tool (not kernel), narrow use case (SST-BF + SST-PP change +
no HWP interrupts), and the failure mode is performance rather than
crash/corruption/security. The patch also went directly through the
maintainer's tree without a public mailing list review.

On balance, the fix is surgical, correct, safe, addresses a real
functional bug, and stable trees have historically accepted intel-speed-
select fixes with similar characteristics. The very low risk combined
with concrete (if narrow) benefit favors backporting.

**YES**

 tools/power/x86/intel-speed-select/isst-config.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/intel-speed-select/isst-config.c b/tools/power/x86/intel-speed-select/isst-config.c
index dd9056ddb016e..652ef1f567ad8 100644
--- a/tools/power/x86/intel-speed-select/isst-config.c
+++ b/tools/power/x86/intel-speed-select/isst-config.c
@@ -1744,6 +1744,9 @@ static int no_turbo(void)
 	return parse_int_file(0, "/sys/devices/system/cpu/intel_pstate/no_turbo");
 }
 
+#define U32_MAX		((unsigned int)~0U)
+#define S32_MAX		((int)(U32_MAX >> 1))
+
 static void adjust_scaling_max_from_base_freq(int cpu)
 {
 	int base_freq, scaling_max_freq;
@@ -1751,7 +1754,7 @@ static void adjust_scaling_max_from_base_freq(int cpu)
 	scaling_max_freq = parse_int_file(0, "/sys/devices/system/cpu/cpu%d/cpufreq/scaling_max_freq", cpu);
 	base_freq = get_cpufreq_base_freq(cpu);
 	if (scaling_max_freq < base_freq || no_turbo())
-		set_cpufreq_scaling_min_max(cpu, 1, base_freq);
+		set_cpufreq_scaling_min_max(cpu, 1, S32_MAX);
 }
 
 static void adjust_scaling_min_from_base_freq(int cpu)
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] platform/x86: hp-wmi: Add support for Omen 16-wf1xxx (8C77)

[Sasha Levin]

From: Krishna Chomal <krishna.chomal108@gmail.com>

[ Upstream commit 344bf523d441d44c75c429ea6cdcfa8f12efde4d ]

The HP Omen 16-wf1xxx (board ID: 8C77) has the same WMI interface as
other Victus S boards, but requires quirks for correctly switching
thermal profile.

Add the DMI board name to victus_s_thermal_profile_boards[] table and
map it to omen_v1_thermal_params.

Testing on board 8C77 confirmed that platform profile is registered
successfully and fan RPMs are readable and controllable.

Tested-by: Thomas Arici <absolute3d86@gmail.com>
Reported-by: Thomas Arici <absolute3d86@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221300
Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
Link: https://patch.msgid.link/20260410191039.125659-5-krishna.chomal108@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to complete my analysis.

## Phase 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject line parsing**
- Record: Subsystem `platform/x86: hp-wmi:`, action verb `Add`, summary
  = adding DMI board ID quirk for HP Omen 16-wf1xxx board 8C77.

**Step 1.2: Commit message tags**
- Record:
  - `Reported-by: Thomas Arici <absolute3d86@gmail.com>` — real user
    reported the issue
  - `Tested-by: Thomas Arici <absolute3d86@gmail.com>` — tested by the
    reporter on actual hardware
  - `Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221300` —
    bugzilla report
  - `Link: https://patch.msgid.link/20260410191039.125659-5-...` — lore
    reference (PATCH v2 4/4)
  - `Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>` —
    subsystem maintainer reviewed
  - `Signed-off-by: Ilpo Järvinen` — same maintainer committed it
  - No Fixes:/Cc:stable (expected for this review)

**Step 1.3: Commit body analysis**
- Record: Body explains HP Omen 16-wf1xxx (board 8C77) uses the same WMI
  interface as other Victus S boards but needs thermal profile quirks.
  Without this entry, the laptop's platform profile won't register
  correctly and fan RPMs won't be readable/controllable. Tester
  confirmed platform profile registers and fan RPMs work after fix.

**Step 1.4: Hidden bug fix detection**
- Record: This isn't disguised; it's explicitly a quirk/device
  enablement for a specific laptop model. Per stable rules, DMI/device-
  ID/quirk additions to existing drivers are an EXCEPTION category
  that's allowed for stable.

## Phase 2: DIFF ANALYSIS

**Step 2.1: Change inventory**
- Record: One file changed — `drivers/platform/x86/hp/hp-wmi.c`, +4
  lines, -0 lines, single `dmi_system_id` entry added to
  `victus_s_thermal_profile_boards[]` table. Single-file surgical
  change.

**Step 2.2: Code flow change**
- Record: Before: board `8C77` was not in the DMI match table →
  `dmi_first_match()` in `setup_active_thermal_profile_params()`
  returned NULL → `is_victus_s_board` stayed false → thermal profile/fan
  quirk paths never activated. After: `8C77` matches →
  `is_victus_s_board=true`, `active_thermal_profile_params =
  omen_v1_thermal_params` → full thermal/fan support works.

**Step 2.3: Bug mechanism**
- Record: Hardware workaround (category h from checklist). Adds DMI
  match entry for a specific board, analogous to adding a PCI/USB ID or
  an entry to a DMI quirk table.

**Step 2.4: Fix quality**
- Record: Obviously correct - table entry inserted in sorted order
  between 8C76 and 8C78; driver_data points to `omen_v1_thermal_params`
  (same as sibling boards 8C76, 8C78). Zero risk to any board that
  doesn't match `8C77`; DMI match is exact-string, so no spillover.
  Tested by the hardware owner.

## Phase 3: GIT HISTORY INVESTIGATION

**Step 3.1: blame the changed lines**
- Record: The `victus_s_thermal_profile_boards[]` table was restructured
  to use `struct dmi_system_id` and `driver_data` in recent commits
  (appeared in the mainline around v6.18-era development). The table has
  been actively extended.

**Step 3.2: Fixes: tag follow-up**
- Record: No Fixes: tag (expected for hardware enablement; this is not a
  regression from a specific commit).

**Step 3.3: File history / series**
- Record: `git log -- drivers/platform/x86/hp/hp-wmi.c` shows a steady
  stream of similar board-ID additions: 8A4D, 8C76, 8BCA, 8E41,
  16-d0xxx, 16-wf0xxx, 16-xd0xxx, 16-wf1xxx fan support, etc. This
  commit is part of series "PATCH v2 0/4 platform/x86: hp-wmi: Improve
  support for some HP boards" but the 8C77 entry is self-contained.

**Step 3.4: Author's other commits**
- Record: Krishna Chomal is an active hp-wmi contributor (8C76 in Feb
  2026, 8BCA earlier, and now the 4/4 series in April 2026). Maintainer
  Ilpo Järvinen routinely reviews these.

**Step 3.5: Dependencies**
- Record: Self-contained. `omen_v1_thermal_params` already exists in
  stable trees (referenced by 8BCA, 8BCD, 8C78, etc.). No dependency on
  any sibling patch in the v2 series.

## Phase 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: Find original patch discussion**
- Record: `b4 dig -c 344bf523d441d` found the submission at https://lore
  .kernel.org/all/20260410191039.125659-5-krishna.chomal108@gmail.com/ —
  this is PATCH v2 4/4 of the series "platform/x86: hp-wmi: Improve
  support for some HP boards".

**Step 4.2: Patch evolution**
- Record: `b4 dig -a` shows v1 (April 1, 2026) and v2 (April 11, 2026);
  the applied commit corresponds to v2, the latest revision. No dangling
  newer revision.

**Step 4.3: Recipients**
- Record: `b4 dig -w` shows patch was sent to Ilpo Järvinen
  (maintainer), Hans de Goede (maintainer), platform-
  driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, plus the
  reporter/tester Thomas Arici. Proper audience.

**Step 4.4: Thread contents**
- Record: Saved full thread to mbox; grep for
  "stable@|NAK|objection|regression|concern" showed none — no NAKs, no
  stable nominations, no concerns raised.

**Step 4.5: Bug report**
- Record: bugzilla.kernel.org/show_bug.cgi?id=221300 is referenced
  (Anubis protection prevented fetch content, but the Closes: tag
  confirms a real user-filed bug). Reporter is also the tester — real-
  world impact verified.

## Phase 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Key functions**
- Record: The only code affected is the
  `victus_s_thermal_profile_boards[]` table, consumed by
  `setup_active_thermal_profile_params()` (line 2605 of hp-wmi.c), which
  is invoked from `hp_wmi_init()`. On any board not named `8C77`,
  behavior is identical to before.

**Step 5.5: Similar patterns**
- Record: The table currently has 13 sibling entries (8A4D, 8BAB, 8BBE,
  8BCA, 8BCD, 8BD4, 8BD5, 8C76, 8C78, 8C99, 8C9C, 8D41, 8D87), each a
  4-line addition. Pattern is well-established.

## Phase 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

**Step 6.1: Buggy code in stable?**
- Record:
  - `stable/linux-6.19.y`: `victus_s_thermal_profile_boards[]` is
    present with identical `struct dmi_system_id` format; 8C77 missing
    (as is 8C76). HP Omen 16-wf1xxx (8C77) owners running 6.19.y lack
    working thermal/fan support.
  - `stable/linux-6.18.y`: Same as 6.19.y — table format matches, 8C77
    missing.
  - `stable/linux-6.17.y`: Table exists but uses older string-only array
    format — would need trivial adaptation to backport.
  - `stable/linux-6.12.y`, `6.6.y`: Table doesn't exist — not
    applicable.

**Step 6.2: Backport complications**
- Record: For 6.18.y and 6.19.y the diff applies cleanly (modulo the
  absence of the 8C76 entry — the insertion point is just between 8BD5
  and 8C78 or wherever sorted order dictates). For 6.17.y would need
  format conversion. Difficulty: trivial.

**Step 6.3: Related fixes already in stable**
- Record: Multiple sibling commits (Add Omen 16-xd0xxx, Add Omen
  16-wf0xxx, fix platform profile values for Omen 16-wf1xxx, Add Omen
  MAX 16-ah0xx, Fn+P hotkey, Add Victus 16-d0xxx, Omen 14-fb1xxx, mark
  Victus 16-r0/s0) are already in `stable/linux-6.17.y`, `6.18.y`,
  and/or `6.19.y`. This establishes a clear precedent for backporting
  hp-wmi board-ID additions.

## Phase 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem criticality**
- Record: `drivers/platform/x86/hp/` — PERIPHERAL (driver-specific), but
  affects real users of HP Omen/Victus laptops. Fan control and thermal
  profile are user-visible features.

**Step 7.2: Activity**
- Record: Actively developed; maintainer routinely accepts board-ID
  additions.

## Phase 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is affected**
- Record: Owners of HP Omen 16-wf1xxx laptops with board 8C77.

**Step 8.2: Trigger conditions**
- Record: Triggered on every boot on matching hardware: thermal profile
  doesn't register, fan RPM readback/control unavailable. Not a security
  issue.

**Step 8.3: Failure mode**
- Record: Missing functionality (no thermal profile switching, no
  controllable fan) on the specific laptop model. Severity: MEDIUM
  (functional defect, not a crash/corruption).

**Step 8.4: Risk-benefit**
- Record:
  - Benefit: Enables working thermal/fan control for owners of a
    specific HP laptop model — a real user confirmed it fixes their
    system.
  - Risk: Near-zero. The change only runs on boards matching the exact
    DMI string `8C77`, which is currently a no-op entry. Cannot regress
    any other hardware. 4-line addition to a well-understood table.

## Phase 9: FINAL SYNTHESIS

**Step 9.1: Evidence compilation**

FOR:
- Pure hardware quirk/DMI match addition — a documented stable exception
  category
- 4-line change, surgical, no logic modification
- Tested on actual hardware by the reporter
- Reviewed and committed by subsystem maintainer
- Real user-facing bug (bugzilla 221300)
- Patchwork precedent: many similar hp-wmi board additions already in
  stable 6.17.y / 6.18.y / 6.19.y
- Zero regression risk (only activates on exact-string DMI match of
  "8C77")

AGAINST:
- The sibling 8C76 commit isn't yet in stable 6.19.y (easily resolved —
  8C77 can be inserted between 8BD5 and 8C78 on backport)
- Older stable branches (6.17.y, 6.12.y, 6.6.y) may need adaptation or
  the hardware is simply newer than the tree

**Step 9.2: Stable rules checklist**
1. Obviously correct & tested? YES (tested on hardware, maintainer-
   reviewed)
2. Fixes real bug affecting users? YES (user-reported via bugzilla)
3. Important issue? MEDIUM (broken fan/thermal on a specific laptop)
4. Small and contained? YES (4 lines, 1 file)
5. No new features/APIs? YES (no new API; DMI quirk addition, explicitly
   allowed)
6. Applies to stable trees? YES for 6.18.y/6.19.y cleanly; minor
   adaptation for 6.17.y

**Step 9.3: Exception category**
- Record: Matches the "QUIRKS and WORKAROUNDS" and "NEW DEVICE IDs"
  exception categories — adding DMI match entry to an existing driver's
  quirk table.

**Step 9.4: Decision**
- Record: Clear YES — stable-appropriate hardware enablement matching
  established backport precedent.

## Verification

- [Phase 1] Parsed tags: Reported-by/Tested-by same person (Thomas
  Arici), Closes: bugzilla 221300, Reviewed-by/SOB from maintainer Ilpo
  Järvinen. No Fixes:/Cc:stable (expected).
- [Phase 2] Diff: +4 lines, 1 file, a single `dmi_system_id` entry
  between `8C76` and `8C78`. Verified with `git show 344bf523d441d
  --stat`.
- [Phase 3] Author history: `git log` shows Krishna Chomal has authored
  similar additions (8C76, 8BCA). Verified via `git log --oneline --
  drivers/platform/x86/hp/hp-wmi.c`.
- [Phase 4] `b4 dig -c 344bf523d441d` found thread at lore.kernel.org/al
  l/20260410191039.125659-5-krishna.chomal108@gmail.com/
- [Phase 4] `b4 dig -a`: v1 (2026-04-01) → v2 (2026-04-11); applied
  version is v2 (latest).
- [Phase 4] `b4 dig -w`: maintainers Ilpo Järvinen, Hans de Goede, and
  platform-driver-x86 list were recipients.
- [Phase 4] `b4 dig -m /tmp/8c77_thread.mbox` + grep confirmed no NAK,
  no concerns, no stable nomination in thread.
- [Phase 5] `rg victus_s_thermal_profile_boards` in hp-wmi.c: referenced
  only at lines 184 (table) and 2613 (consumed in
  `setup_active_thermal_profile_params()`).
- [Phase 6] `git show stable/linux-6.18.y:drivers/platform/x86/hp/hp-
  wmi.c` and `stable/linux-6.19.y`: both have the `struct dmi_system_id`
  table format — backport applies cleanly. `stable/linux-6.17.y` uses
  older string-array format — needs trivial adaptation.
- [Phase 6] `git log stable/linux-6.18.y -- drivers/platform/x86/hp/hp-
  wmi.c`: many sibling hp-wmi board additions are already backported
  (Fn+P, 16-wf0xxx, 16-xd0xxx, 16-ah0xx, fix platform profile values,
  Victus 16-r0/s0, Victus 16-r1, etc.).
- [Phase 8] Failure mode: confirmed via reading
  `setup_active_thermal_profile_params()` at lines 2605-2627 — without a
  match, `is_victus_s_board` stays false and
  `active_thermal_profile_params` is NULL, disabling thermal/fan
  functionality.
- UNVERIFIED: bugzilla.kernel.org/show_bug.cgi?id=221300 content (Anubis
  protection blocked WebFetch); Closes: tag and Reported-by/Tested-by
  confirm the bug is real.
- UNVERIFIED: Whether the sibling 8C76 commit is already queued for
  autosel in 6.19.y (doesn't affect this commit's decision — 8C77 can be
  applied independently).

The change is a textbook hardware-quirk / DMI match-table addition,
which is one of the explicit stable exception categories. It is tiny,
maintainer-reviewed, user-tested, has zero collateral risk, and follows
a strong precedent of similar hp-wmi board-enablement commits already
accepted in stable trees.

**YES**

 drivers/platform/x86/hp/hp-wmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/hp/hp-wmi.c b/drivers/platform/x86/hp/hp-wmi.c
index 988a0acc9622b..c1dcc1e9038b7 100644
--- a/drivers/platform/x86/hp/hp-wmi.c
+++ b/drivers/platform/x86/hp/hp-wmi.c
@@ -214,6 +214,10 @@ static const struct dmi_system_id victus_s_thermal_profile_boards[] __initconst
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8C76") },
 		.driver_data = (void *)&omen_v1_thermal_params,
 	},
+	{
+		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8C77") },
+		.driver_data = (void *)&omen_v1_thermal_params,
+	},
 	{
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8C78") },
 		.driver_data = (void *)&omen_v1_thermal_params,
-- 
2.53.0