[PATCH AUTOSEL 6.18] platform/x86: hp-wmi: Add thermal support for board 8B2F

[PATCH AUTOSEL 6.18] platform/x86: hp-wmi: Add thermal support for board 8B2F

[Sasha Levin]

From: yahia ahmed <yahia.a.abdrabou@gmail.com>

[ Upstream commit abefbbfc71f5ee50f9e549a2d143f23694d65fc2 ]

Added thermal support for board ID 8B2F.

Signed-off-by: yahia ahmed <yahia.a.abdrabou@gmail.com>
Link: https://patch.msgid.link/20260522203418.28784-1-yahia.a.abdrabou@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:

## Phase 1: Commit Message Forensics

### Step 1.1: Parse the Subject Line
**Record:** `[platform/x86: hp-wmi]` `[Add]` — Add thermal support for
HP WMI board ID `8B2F` in the existing Victus S thermal-profile DMI
table.

### Step 1.2: Parse All Commit Message Tags
**Record:**
- **Fixes:** — none
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** Ilpo Järvinen `<ilpo.jarvinen@linux.intel.com>`
  (platform/x86 maintainer)
- **Acked-by:** — none
- **Link:** https://patch.msgid.link/20260522203418.28784-1-
  yahia.a.abdrabou@gmail.com
- **Cc: stable:** — none (expected for manual review)
- **Signed-off-by:** yahia ahmed, Ilpo Järvinen (ignore pipeline-added
  SOBs)

Notable: maintainer Reviewed-by; no syzbot/crash reports.

### Step 1.3: Analyze Commit Body
**Record:**
- **Bug description:** Board `8B2F` is missing from
  `victus_s_thermal_profile_boards`, so Victus S thermal-profile
  handling is not activated.
- **Symptom:** On `8B2F` hardware, platform_profile thermal switching
  and Victus S fan/thermal WMI paths do not engage; generic fallback is
  used instead.
- **Version info:** None in message.
- **Root cause:** Missing DMI board-name entry in an existing quirk
  table.

### Step 1.4: Detect Hidden Bug Fixes
**Record:** Not disguised cleanup. This is explicit hardware-enablement:
a DMI quirk entry for a laptop board that needs the existing Victus S
thermal path. Without it, thermal/fan behavior is wrong or absent, not
merely cosmetic.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory the Changes
**Record:**
- **Files:** `drivers/platform/x86/hp/hp-wmi.c` (+4 lines)
- **Functions/areas:** `victus_s_thermal_profile_boards[]` init table
- **Scope:** Single-file, surgical DMI table addition

### Step 2.2: Code Flow Change
**Record:**
- **Before:** `setup_active_thermal_profile_params()` does not match
  board `8B2F`; `is_victus_s_board` stays false.
- **After:** Board `8B2F` matches; `is_victus_s_board = true`,
  `active_thermal_profile_params = &victus_s_thermal_params`.
- **Affected path:** Module init →
  `setup_active_thermal_profile_params()` → `thermal_profile_setup()` /
  `is_victus_s_thermal_profile()` consumers (platform_profile, hwmon fan
  paths).

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Hardware quirk / missing device (DMI board) ID
- **Mechanism:** Wrong code path for known hardware needing Victus S WMI
  thermal commands and GPU thermal settings

### Step 2.4: Fix Quality
**Record:** Obviously correct — one DMI entry pointing at existing
`victus_s_thermal_params`. Minimal risk; no API/locking changes.
Maintainer-reviewed.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame Changed Lines
**Record:** `victus_s_thermal_profile_boards` table
introduced/refactored in `d9aefb386fdc4` (Jan 2026, "fix platform
profile values for Omen 16-wf1xxx"). Prior entries added by commits like
`54afb047cd7eb`, `94b2a56fd4b1c`, `d4ff92dd98ad1`. The missing-board
pattern is longstanding; this extends the same table.

### Step 3.2: Follow Fixes Tag
**Record:** N/A — no `Fixes:` tag.

### Step 3.3: Related File History
**Record:** Recent related commits are the same pattern (add board IDs
for Victus/Omen thermal support): `54afb047cd7eb`, `748f897511446`,
`6e4ab59b8391a`, `d9aefb386fdc4`, etc. Standalone one-entry addition;
not part of a multi-patch series.

### Step 3.4: Author Context
**Record:** yahia ahmed — no other hp-wmi commits in this tree.
Reviewed/committed by Ilpo Järvinen (subsystem maintainer).

### Step 3.5: Dependencies
**Record:** Requires Victus S thermal infrastructure already in tree
(`victus_s_thermal_params`, `victus_s_thermal_profile_boards`,
`setup_active_thermal_profile_params()`). **Present in this 6.18.44
tree.** Commit diff context (e.g. `omen_v1_legacy_thermal_params`,
boards `8902`/`8A44`) does not match current tree; backport needs a one-
entry addition to the current `dmi_system_id` table, not a literal
apply.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:** `b4 dig -c` unavailable (commit not in this checkout). `b4
shazam` and curl/lore fetch blocked (403/Anubis). Link present but
thread content unverified.

### Step 4.2: Reviewers
**Record:** Reviewed-by and Signed-off-by: Ilpo Järvinen (platform/x86
maintainer). Full recipient list unverified.

### Step 4.3: Bug Report
**Record:** No external bug report or syzbot link.

### Step 4.4: Related Patches/Series
**Record:** Same pattern as prior Victus board additions
(`54afb047cd7eb` added `8BBE`/`8BD4`/`8BD5`). Standalone patch.

### Step 4.5: Stable List History
**Record:** Not searched successfully (lore blocked). Similar hp-wmi
stable backports in this tree are crash/ACPI fixes, not board-ID-only
additions.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `victus_s_thermal_profile_boards[]`,
`setup_active_thermal_profile_params()`,
`is_victus_s_thermal_profile()`, `thermal_profile_setup()`,
`platform_profile_victus_s_set_ec()`, hwmon fan read/write paths.

### Step 5.2: Callers
**Record:** `setup_active_thermal_profile_params()` called from
`hp_wmi_init()` before probe. `is_victus_s_thermal_profile()` used in
thermal profile setup, hwmon fan visibility/read/write, powersource
handler registration/cleanup.

### Step 5.3: Callees
**Record:** `dmi_first_match()`, `omen_thermal_profile_set()`,
`victus_s_gpu_thermal_profile_set()`,
`devm_platform_profile_register()`.

### Step 5.4: Reachability
**Record:** Runs at boot on HP WMI laptops. Affects any user of
`platform_profile` sysfs and hwmon fan interfaces on board `8B2F`.
Userspace-reachable on affected hardware.

### Step 5.5: Similar Patterns
**Record:** Same table pattern as `8BBE`, `8BD4`, `8BD5`, `8C99`, etc.
Board `8B2F` also appears in `sound/soc/amd/yc/acp6x-mach.c` (HP OMEN
Gaming Laptop 16-ap0xxx audio quirk, commit `65aabf8896687`), confirming
real hardware in the ecosystem.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Does Buggy Code Exist?
**Record:** **Yes.** Local tree is **v6.18.44** (`VERSION=6`,
`PATCHLEVEL=18`, `SUBLEVEL=44`). `victus_s_thermal_profile_boards`
exists; **`8B2F` is absent.** Victus S infrastructure present since
`d9aefb386fdc4` and related commits.

### Step 6.2: Backport Complications
**Record:** Minor adaptation needed — commit diff context differs from
current tree (no `omen_v1_legacy_thermal_params`; fewer/different
entries). Actual backport: add one `dmi_system_id` entry with
`victus_s_thermal_params`. Clean, low conflict risk.

### Step 6.3: Related Fixes Already Present?
**Record:** No existing `8B2F` entry in hp-wmi or grep across tree
(except unrelated nls/audio entries).

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** `drivers/platform/x86/hp/` — **IMPORTANT** (laptop platform
driver; thermal/fan/power management for HP hardware).

### Step 7.2: Subsystem Activity
**Record:** Actively developed — multiple hp-wmi thermal/board commits
in 2025–2026 in this tree.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Owners of HP laptops with DMI board name `8B2F` (HP
OMEN/Victus family; corroborated by audio quirk for 16-ap0xxx line).

### Step 8.2: Trigger Conditions
**Record:** Boot on matching hardware with `CONFIG_HP_WMI`. Common for
affected laptop owners; not a race or rare error path.

### Step 8.3: Failure Mode Severity
**Record:** Without fix: wrong thermal profile path — no Victus S
platform_profile modes, incorrect fan WMI path, no GPU thermal mode
control via driver. **Severity: MEDIUM** (functional/hardware issue;
BIOS still provides baseline thermal management; not a kernel crash).

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Enables correct thermal/fan behavior on real hardware for
  stable users who cannot upgrade kernels.
- **Risk:** Very low — 4 lines, existing data structure, no behavior
  change for other boards.
- **Ratio:** Favorable.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Explicit device/quirk ID addition to existing driver (stable-
  rules.rst: "just add a device ID" or "hardware quirk")
- Trivial, obviously correct, maintainer-reviewed
- Real hardware (`8B2F` confirmed in tree via audio DMI quirk)
- Required infrastructure exists in v6.18.44
- Enables platform_profile and hwmon fan control on affected laptops

**AGAINST backport:**
- Not a crash/security/corruption fix
- No user bug report or syzbot evidence
- Commit diff does not apply literally to current tree (needs minor
  adaptation)
- Mailing list discussion unverified

**UNRESOLVED:**
- Exact laptop model and user testing details from lore thread
- Whether reviewers nominated `Cc: stable`

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** (maintainer reviewed; pattern
   proven by sibling board entries)
2. Fixes real bug affecting users? **PASS** (hardware quirk —
   wrong/missing thermal path on `8B2F`)
3. Important issue? **PASS** (hardware quirk per stable rules;
   functional thermal/fan management)
4. Small and contained? **PASS** (4 lines, one file)
5. No new features/APIs? **PASS** (DMI table entry only; no new APIs)
6. Can apply to local tree? **PASS** (minor one-entry adaptation to
   current table)

### Step 9.3: Exception Category
**Record:** Hardware quirk / device ID addition (DMI board ID in
existing hp-wmi driver). Matches `Documentation/process/stable-kernel-
rules.rst` line 15: "just add a device ID" and line 19: "hardware
quirk."

### Step 9.4: Decision Rationale
For **v6.18.44**, the Victus S thermal framework is present but board
`8B2F` is missing. This is the same class of change as prior Victus
board additions — a DMI quirk entry enabling correct thermal and fan
behavior on real HP hardware. It is small, maintainer-reviewed, low
risk, and explicitly within stable policy for device-ID/quirk additions.
The commit should be adapted (not cherry-picked verbatim) to the current
`dmi_system_id` table layout.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body; no Fixes/Reported-by/syzbot
- **[Phase 2]** Diff: +4 lines, one DMI entry with
  `victus_s_thermal_params`
- **[Phase 3]** `git describe HEAD`: v6.18.44; `git blame` on table:
  `d9aefb386fdc4` refactor; related commits `54afb047cd7eb`,
  `6e4ab59b8391a`
- **[Phase 3]** `git log --grep="8B2F"`: no hp-wmi commit in tree
- **[Phase 4]** `b4 dig -c`: failed (commit not in checkout); `b4
  shazam`: message-id unknown; lore/patch.msgid.link: blocked
  (403/Anubis)
- **[Phase 5]** Read `setup_active_thermal_profile_params()`,
  `is_victus_s_thermal_profile()`, `thermal_profile_setup()`, hwmon
  paths
- **[Phase 5]** `grep 8B2F`: found in `acp6x-mach.c` (HP OMEN 16-ap0xxx
  audio quirk, `65aabf8896687`)
- **[Phase 6]** `grep 8B2F` in hp-wmi.c: absent;
  `victus_s_thermal_params` and table exist
- **[Phase 6]** Commit diff context (`omen_v1_legacy_thermal_params`,
  boards `8902`/`8A44`) not in current tree — adaptation required
- **[Phase 7]** hp-wmi actively maintained; Ilpo Järvinen is maintainer
- **[Phase 8]** Impact: thermal/fan/platform_profile on board `8B2F`;
  severity MEDIUM; risk very low
- **[Phase 9]** `Documentation/process/stable-kernel-rules.rst` line 15
  confirms device-ID additions are stable-appropriate

**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 550d4b39a92af..3f9c718123a85 100644
--- a/drivers/platform/x86/hp/hp-wmi.c
+++ b/drivers/platform/x86/hp/hp-wmi.c
@@ -158,6 +158,10 @@ static const struct dmi_system_id victus_s_thermal_profile_boards[] __initconst
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BAB") },
 		.driver_data = (void *)&omen_v1_thermal_params,
 	},
+	{
+		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8B2F") },
+		.driver_data = (void *)&victus_s_thermal_params,
+	},
 	{
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BBE") },
 		.driver_data = (void *)&victus_s_thermal_params,
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] platform/x86: sel3350-platform: Retain LED state on load and unload

[Sasha Levin]

From: Brodie Abrew <brodie_abrew@selinc.com>

[ Upstream commit 18bc6ce6bb618e1dff4473d7dd528d22519abbd7 ]

When the platform driver is loaded or unloaded, it overwrites the
existing LED states. This can cause a loss of early boot state when the
driver loads, and it can cause the ALARM contact to change state or
flicker.

Explicitly retain the existing LED state to prevent overwriting on
driver load and unload.

Tested-By: Robert Joslyn <robert.joslyn@redrectangle.org>
Reviewed-by: Robert Joslyn <robert.joslyn@redrectangle.org>
Signed-off-by: Brodie Abrew <brodie_abrew@selinc.com>
Link: https://patch.msgid.link/20260507004916.6710-1-brodie_abrew@selinc.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:

# Stable Backport Analysis: `platform/x86: sel3350-platform: Retain LED
state on load and unload`

**Local tree:** Linux **6.18.43** (`git describe HEAD` →
`v6.18.43-1-gc7f0dac02d232`)

**Upstream commit:** `18bc6ce6bb618`
**Stable-series commit (not in this HEAD):** `d2b26d4859502`

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[platform/x86: sel3350-platform]` `[retain]` — Keep
existing LED GPIO states when the SEL-3350 platform driver is loaded or
unloaded.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Tested-by:** Robert Joslyn `<robert.joslyn@redrectangle.org>`
- **Reviewed-by:** Robert Joslyn `<robert.joslyn@redrectangle.org>`
- **Reviewed-by:** Ilpo Järvinen `<ilpo.jarvinen@linux.intel.com>`
  (platform/x86 maintainer)
- **Signed-off-by:** Brodie Abrew `<brodie_abrew@selinc.com>` (SEL
  author)
- **Signed-off-by:** Ilpo Järvinen
- **Link:**
  https://patch.msgid.link/20260507004916.6710-1-brodie_abrew@selinc.com
- **Notable:** Hardware-tested on real SEL-3350; maintainer-reviewed; no
  syzbot/sanitizer signals.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** Driver load/unload overwrites existing LED GPIO states.
- **Symptoms:** Loss of early-boot LED state; ALARM contact may change
  state or flicker.
- **Root cause (author):** LEDs were initialized without preserving
  current GPIO values.
- **Version info:** None in the message.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not disguised cleanup — explicit hardware-behavior fix. The
GPIO/ALARM contact behavior is functional, not cosmetic.

---

## PHASE 2: DIFF ANALYSIS — LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **File:** `drivers/platform/x86/sel3350-platform.c` (+103 / −33)
- **Functions modified:** `sel3350_probe()`, `sel3350_remove()`;
  LED/GPIO tables and constants
- **Scope:** Single-file, driver-local refactor + behavioral fix

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**

| Hunk | Before | After |
|------|--------|-------|
| LED table | Most LEDs default OFF; `sel:green:enabled` forced ON | All
LEDs use `LEDS_GPIO_DEFSTATE_KEEP`, `retain_state_suspended`,
`retain_state_shutdown` |
| GPIO lookup | Separate `sel3350_leds_table` for `"leds-gpio"` | LED
GPIOs merged into `sel3350_gpios_table` under ACPI device `SEL0003` |
| `sel3350_probe()` | Only adds lookup tables, registers `leds-gpio`
child | Pre-acquires each LED GPIO with `GPIOD_ASIS`, sets consumer
names, passes `gpiod` into `gpio_led` structs |
| Error path | Removes only `sel3350_leds_table` on failure | Adds
`err_gpio_loop` cleanup for pre-acquired GPIOs |
| `sel3350_remove()` | Removes both lookup tables | Removes only unified
`sel3350_gpios_table` |

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:**
- **Category:** Logic / hardware-behavior correctness (GPIO state
  preservation)
- **Mechanism:** Without the fix, `leds-gpio` acquires GPIOs via
  `gpio_led_get_gpiod()` using `GPIOD_OUT_LOW` and initializes
  brightness from `default_state` (OFF unless explicitly ON). That
  forces outputs on probe. On unload, `gpio_led_shutdown()` turns off
  LEDs lacking `LED_RETAIN_AT_SHUTDOWN`. Together this overwrites early-
  boot and runtime GPIO states, including the ALARM line.

Verified in this tree:

```223:223:drivers/leds/leds-gpio.c
        gpiod = devm_gpiod_get_index_optional(dev, NULL, idx,
GPIOD_OUT_LOW);
```

```97:111:drivers/leds/leds-gpio.c
        if (template->default_state == LEDS_GPIO_DEFSTATE_KEEP) {
                state = gpiod_get_value_cansleep(led_dat->gpiod);
                ...
        }
        ...
        if (template->retain_state_shutdown)
                led_dat->cdev.flags |= LED_RETAIN_AT_SHUTDOWN;
```

```300:310:drivers/leds/leds-gpio.c
static void gpio_led_shutdown(struct platform_device *pdev)
{
        ...
                if (!(led->cdev.flags & LED_RETAIN_AT_SHUTDOWN))
                        gpio_led_set(&led->cdev, LED_OFF);
```

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- **Quality:** Sound — uses existing `gpio_led` fields (`gpiod`,
  `LEDS_GPIO_DEFSTATE_KEEP`, retain flags) supported in
  `include/linux/leds.h`.
- **Regression risk:** Low. `sel:green:enabled` changes from forced-ON
  to KEEP (intentional per commit message). Pre-acquire with
  `GPIOD_ASIS` is the correct pattern to avoid clobbering hardware
  state.
- **Red flags:** Moderate diff size, but confined to one niche driver.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:** Current LED definitions blame to `5d324e5159d9e` (2025-11-28
merge). Repo is shallow (`git rev-parse --is-shallow-repository` →
`true`), limiting deep history. Driver file is present at 249 lines in
HEAD and in `18bc6ce6bb618^`, confirming the pre-fix code exists in this
tree.

### Step 3.2: FOLLOW THE FIXES: TAG
**Record:** No `Fixes:` tag — N/A.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:** Only one visible history entry for this file in the shallow
tree (`5d324e5159d9e`). Fix commit `18bc6ce6bb618` is standalone (not
part of a multi-patch series). Mbox thread shows v1→v2→v3 evolution; v3
is what landed.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Author is Brodie Abrew (SEL). Maintainer Ilpo Järvinen
reviewed and applied. Limited shallow-history visibility for broader
author history.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:** No dependencies. Required APIs (`LEDS_GPIO_DEFSTATE_KEEP`,
`struct gpio_led.gpiod`, `retain_state_*`) are present in this 6.18.43
tree. Fix is self-contained.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:**
- **URL:**
  https://patch.msgid.link/20260507004916.6710-1-brodie_abrew@selinc.com
  (`b4 dig -c 18bc6ce6bb618`)
- **Series:** v1 → v2 → v3; committed version is v3
- **Key feedback:** Ilpo Järvinen: “The code change seemed fine now.”
  Applied as `18bc6ce6bb618`.
- **Stable nomination:** None found in thread.
- **NAKs:** None found.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** `b4 dig -w` → thread on `platform-
driver-x86@vger.kernel.org`. Reviewed/tested by hardware user Robert
Joslyn; applied by maintainer Ilpo Järvinen.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** No external bug tracker link. Robert Joslyn reported testing
v1/v2 on SEL-3350 hardware in the mbox thread.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** Single-patch series; standalone.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** Not searched separately; no stable discussion found in the
patch thread.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** `sel3350_probe()`, `sel3350_remove()`, plus static data
tables.

### Step 5.2: TRACE CALLERS
**Record:**
- `sel3350_probe()` — platform driver probe on ACPI match `SEL0003`
  (SEL-3350 mainboard).
- Triggered at boot when `CONFIG_SEL3350_PLATFORM` is enabled and
  hardware is present.
- Not a syscall path; ACPI/platform enumeration only.

### Step 5.3: TRACE CALLEES
**Record:** `devm_gpiod_get()` (GPIOD_ASIS),
`platform_device_register_data("leds-gpio")`,
`gpiod_add/remove_lookup_table()`, power-supply registration.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:** ACPI probe → GPIO pre-acquire (preserve state) → register
`leds-gpio` child with pre-filled `gpiod` → `gpio_led_probe()` →
`create_gpio_led()` reads KEEP state. Reachable on every boot/module
load for SEL-3350 systems.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** `LEDS_GPIO_DEFSTATE_KEEP` used elsewhere (e.g.
`drivers/net/wireless/ath/ath10k/leds.c`, `arch/arm/mach-
sa1100/assabet.c`) for the same “don’t clobber GPIO state” pattern.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:** **Yes.** `drivers/platform/x86/sel3350-platform.c` in HEAD
matches pre-fix code:
- Separate `sel3350_leds_table`
- LEDs without `LEDS_GPIO_DEFSTATE_KEEP`
- `sel:green:enabled` forced `LEDS_GPIO_DEFSTATE_ON`
- No pre-acquired `gpiod` in probe

Fix commits `18bc6ce6bb618` and `d2b26d4859502` are **not** ancestors of
HEAD (`git merge-base --is-ancestor` exit code 1).

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** Expected **clean apply**. Pre-fix file index
(`02e2081e2333`) matches current tree structure. Required headers and
`struct gpio_led` fields exist.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** No duplicate or alternate fix found in this tree.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** `drivers/platform/x86/` — **PERIPHERAL** (SEL-3350
industrial platform driver, `CONFIG_SEL3350_PLATFORM`).

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** Active subsystem, but this driver is niche industrial
hardware (Schweitzer Engineering Laboratories protection/automation
equipment).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** **Driver-specific** — systems with SEL-3350 hardware and
`CONFIG_SEL3350_PLATFORM` enabled (built-in or module load/unload).

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:**
- **Trigger:** Driver probe at boot, or `modprobe`/`rmmod` of
  `sel3350-platform`.
- **Likelihood:** Every boot/load on affected hardware.
- **Unprivileged trigger:** No direct userspace trigger; normal system
  boot/module management.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:**
- **Failure mode:** GPIO lines (including ALARM contact) forced to wrong
  state or flicker; early-boot LED state lost.
- **Severity:** **MEDIUM** for kernel stability (no crash/oops);
  **HIGH** for operational correctness on SEL-3350 — spurious or missed
  alarm signaling on a physical contact output used in industrial
  monitoring/protection contexts.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Medium — small user population, but every affected user
  hits the bug on each load/unload; ALARM integrity matters on this
  hardware.
- **Risk:** Low — uses established LED/GPIO APIs; hardware-tested;
  maintainer-reviewed; single driver file.
- **Ratio:** Benefit outweighs risk for this tree where the driver and
  bug both exist.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backport:**
- Real, reproducible hardware bug on every driver load/unload
- Hardware-tested (`Tested-by`) on SEL-3350
- Maintainer-reviewed and applied
- Driver and buggy code present in Linux 6.18.43
- Fix uses existing APIs; no new userspace surface
- Hardware-workaround pattern (preserve GPIO/ALARM state)
- Functional ALARM-contact impact, not cosmetic LEDs

**AGAINST backport:**
- No kernel crash, security issue, data corruption, or deadlock
- Very narrow hardware scope (`CONFIG_SEL3350_PLATFORM`)
- Diff is ~70 net lines (larger than a one-liner)
- Shallow git history limits full introduction-date verification

**Unresolved:** Exact kernel version when `sel3350-platform` was first
merged (shallow clone); not needed — driver is confirmed present in this
6.18.43 tree.

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — maintainer + hardware
   Tested-by; mechanism verified in `leds-gpio.c`.
2. Fixes a real bug affecting users? **PASS** — verified GPIO-clobber
   behavior on SEL-3350.
3. Important issue? **PASS (operational/hardware)** — ALARM contact
   state change on industrial equipment; not a kernel crash but
   materially affects deployed systems using this driver.
4. Small and contained? **PASS** — one file, one driver; moderate size
   but focused.
5. No new features or APIs? **PASS** — behavioral fix using existing
   `gpio_led` fields.
6. Can apply to the local tree? **PASS** — pre-fix code matches; APIs
   present; fix not yet in HEAD.

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
**Record:** **Hardware quirk/workaround** — preserves correct GPIO/ALARM
state on a specific platform where default `leds-gpio` initialization is
wrong.

### Step 9.4: DECISION RATIONALE
For **this** 6.18.43 tree, the driver exists, the bug exists, the fix is
technically sound and hardware-validated, and it prevents incorrect
ALARM-contact behavior on SEL-3350 systems. It fits stable’s hardware-
workaround exception and carries low regression risk.

---

## Verification

- [Phase 1] Parsed subject, tags, and body from provided commit message
  and `git show 18bc6ce6bb618`
- [Phase 1] Confirmed Tested-by, Reviewed-by (Joslyn, Järvinen), Link
  tag; no Fixes:/syzbot tags
- [Phase 2] Read full current `sel3350-platform.c` (249 lines, pre-fix
  state)
- [Phase 2] Read `leds-gpio.c` lines 97–111, 223, 273–277, 300–310 for
  bug mechanism
- [Phase 2] Read `include/linux/leds.h` `struct gpio_led` — `gpiod`,
  `LEDS_GPIO_DEFSTATE_KEEP`, retain flags present
- [Phase 2] Counted diff: +104/−34 lines via `git show`
- [Phase 3] `git blame` on LED table → all lines from `5d324e5159d9e`
- [Phase 3] `git rev-parse --is-shallow-repository` → `true`
- [Phase 3] `git show 18bc6ce6bb618^:...` → 249-line pre-fix file exists
- [Phase 3] No Fixes: tag to follow
- [Phase 4] `b4 dig -c 18bc6ce6bb618` → lore URL found
- [Phase 4] `b4 dig -m /tmp/sel3350_thread.mbox` → downloaded thread; v3
  series, maintainer approval, hardware testing noted
- [Phase 4] `b4 dig -w` → platform-driver-x86 list recipients confirmed
- [Phase 4] No stable nomination or NAK found in mbox
- [Phase 5] Traced probe path: ACPI → `sel3350_probe()` → `leds-gpio`
  registration
- [Phase 5] Grep found `LEDS_GPIO_DEFSTATE_KEEP` usage in ath10k,
  assabet
- [Phase 6] `git describe HEAD` → v6.18.43; `make kernelversion` →
  6.18.43
- [Phase 6] `git merge-base --is-ancestor 18bc6ce6bb618 HEAD` → exit 1
  (fix not in HEAD)
- [Phase 6] `git merge-base --is-ancestor d2b26d4859502 HEAD` → exit 1
  (stable commit not in HEAD)
- [Phase 6] Confirmed `CONFIG_SEL3350_PLATFORM` in
  `drivers/platform/x86/Kconfig`
- [Phase 7] Driver is peripheral/platform-specific
- [Phase 8] Assessed trigger (every boot/load) and severity (operational
  ALARM contact)
- [UNVERIFIED] Exact upstream merge commit that first introduced
  `sel3350-platform.c` (shallow history; `-S` searches timed out)

**YES**The background git jobs mostly matched what we already had from
the main review.

**Confirmed**
- The repo is a **shallow clone**, so deep history searches are slow or
  incomplete.
- The fix commits (`18bc6ce6bb618`, `d2b26d4859502`) are **not** in the
  current 6.18.43 HEAD.
- The pre-fix `sel3350-platform.c` is present in this tree.

**Failed / incomplete**
- `git log -S` searches for when `SEL3350_PLATFORM` / `sel3350-platform`
  were introduced timed out or produced no extra history.
- `git branch --contains` on the fix commit hung and was killed.

That doesn’t change the conclusion: for this 6.18.43 tree, the driver
and buggy code are present, the fix is hardware-validated and should
apply cleanly, and the backport recommendation remains **YES**.

 drivers/platform/x86/sel3350-platform.c | 136 ++++++++++++++++++------
 1 file changed, 103 insertions(+), 33 deletions(-)

diff --git a/drivers/platform/x86/sel3350-platform.c b/drivers/platform/x86/sel3350-platform.c
index 02e2081e2333b..f3a3142356325 100644
--- a/drivers/platform/x86/sel3350-platform.c
+++ b/drivers/platform/x86/sel3350-platform.c
@@ -9,6 +9,8 @@
  */
 
 #include <linux/acpi.h>
+#include <linux/array_size.h>
+#include <linux/err.h>
 #include <linux/gpio/consumer.h>
 #include <linux/gpio/machine.h>
 #include <linux/leds.h>
@@ -30,19 +32,82 @@
 #define SEL_PS_B_DETECT "sel_ps_b_detect"
 #define SEL_PS_B_GOOD   "sel_ps_b_good"
 
+#define AUX_LED_GRN1        "sel_aux_led_grn1"
+#define AUX_LED_GRN2        "sel_aux_led_grn2"
+#define AUX_LED_GRN3        "sel_aux_led_grn3"
+#define AUX_LED_GRN4        "sel_aux_led_grn4"
+#define ALARM_STATE_USER    "sel_alarm_state_user"
+#define ENABLE_STATE_USER   "sel_enable_state_user"
+#define AUX_LED_RED1        "sel_aux_led_red1"
+#define AUX_LED_RED2        "sel_aux_led_red2"
+#define AUX_LED_RED3        "sel_aux_led_red3"
+#define AUX_LED_RED4        "sel_aux_led_red4"
+
+static const char *const sel3350_leds_gpio_names[] = {
+	AUX_LED_GRN1,
+	AUX_LED_GRN2,
+	AUX_LED_GRN3,
+	AUX_LED_GRN4,
+	ALARM_STATE_USER,
+	ENABLE_STATE_USER,
+	AUX_LED_RED1,
+	AUX_LED_RED2,
+	AUX_LED_RED3,
+	AUX_LED_RED4,
+};
+
 /* LEDs */
-static const struct gpio_led sel3350_leds[] = {
-	{ .name = "sel:green:aux1" },
-	{ .name = "sel:green:aux2" },
-	{ .name = "sel:green:aux3" },
-	{ .name = "sel:green:aux4" },
-	{ .name = "sel:red:alarm" },
+static struct gpio_led sel3350_leds[] = {
+	{ .name = "sel:green:aux1",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
+	{ .name = "sel:green:aux2",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
+	{ .name = "sel:green:aux3",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
+	{ .name = "sel:green:aux4",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
+	{ .name = "sel:red:alarm",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
 	{ .name = "sel:green:enabled",
-	  .default_state = LEDS_GPIO_DEFSTATE_ON },
-	{ .name = "sel:red:aux1" },
-	{ .name = "sel:red:aux2" },
-	{ .name = "sel:red:aux3" },
-	{ .name = "sel:red:aux4" },
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
+	{ .name = "sel:red:aux1",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
+	{ .name = "sel:red:aux2",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
+	{ .name = "sel:red:aux3",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
+	{ .name = "sel:red:aux4",
+	  .default_state = LEDS_GPIO_DEFSTATE_KEEP,
+	  .retain_state_suspended = 1,
+	  .retain_state_shutdown = 1,
+	},
 };
 
 static const struct gpio_led_platform_data sel3350_leds_pdata = {
@@ -50,25 +115,6 @@ static const struct gpio_led_platform_data sel3350_leds_pdata = {
 	.leds = sel3350_leds,
 };
 
-/* Map GPIOs to LEDs */
-static struct gpiod_lookup_table sel3350_leds_table = {
-	.dev_id = "leds-gpio",
-	.table = {
-		GPIO_LOOKUP_IDX(BXT_NW, 49, NULL, 0, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_NW, 50, NULL, 1, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_NW, 51, NULL, 2, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_NW, 52, NULL, 3, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_W,  20, NULL, 4, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_W,  21, NULL, 5, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_SW, 37, NULL, 6, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_SW, 38, NULL, 7, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_SW, 39, NULL, 8, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX(BXT_SW, 40, NULL, 9, GPIO_ACTIVE_HIGH),
-		{},
-	}
-};
-
-/* Map GPIOs to power supplies */
 static struct gpiod_lookup_table sel3350_gpios_table = {
 	.dev_id = B2093_GPIO_ACPI_ID ":00",
 	.table = {
@@ -76,6 +122,16 @@ static struct gpiod_lookup_table sel3350_gpios_table = {
 		GPIO_LOOKUP(BXT_NW, 45, SEL_PS_A_GOOD,   GPIO_ACTIVE_LOW),
 		GPIO_LOOKUP(BXT_NW, 46, SEL_PS_B_DETECT, GPIO_ACTIVE_LOW),
 		GPIO_LOOKUP(BXT_NW, 47, SEL_PS_B_GOOD,   GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP(BXT_NW, 49, AUX_LED_GRN1, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_NW, 50, AUX_LED_GRN2, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_NW, 51, AUX_LED_GRN3, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_NW, 52, AUX_LED_GRN4, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_W,  20, ALARM_STATE_USER, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_W,  21, ENABLE_STATE_USER, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_SW, 37, AUX_LED_RED1, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_SW, 38, AUX_LED_RED2, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_SW, 39, AUX_LED_RED3, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP(BXT_SW, 40, AUX_LED_RED4, GPIO_ACTIVE_HIGH),
 		{},
 	}
 };
@@ -149,6 +205,7 @@ struct sel3350_data {
 static int sel3350_probe(struct platform_device *pdev)
 {
 	int rs;
+	int i;
 	struct sel3350_data *sel3350;
 	struct power_supply_config ps_cfg = {};
 
@@ -158,9 +215,19 @@ static int sel3350_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, sel3350);
 
-	gpiod_add_lookup_table(&sel3350_leds_table);
 	gpiod_add_lookup_table(&sel3350_gpios_table);
 
+	for (i = 0; i < ARRAY_SIZE(sel3350_leds); ++i) {
+		sel3350_leds[i].gpiod = devm_gpiod_get(&pdev->dev,
+						       sel3350_leds_gpio_names[i],
+						       GPIOD_ASIS);
+		if (IS_ERR_OR_NULL(sel3350_leds[i].gpiod)) {
+			rs = -EPROBE_DEFER;
+			goto err_gpio_loop;
+		}
+		gpiod_set_consumer_name(sel3350_leds[i].gpiod, sel3350_leds[i].name);
+	}
+
 	sel3350->leds_pdev = platform_device_register_data(
 			NULL,
 			"leds-gpio",
@@ -209,11 +276,15 @@ static int sel3350_probe(struct platform_device *pdev)
 
 	return 0;
 
+err_gpio_loop:
+	while (i--)
+		devm_gpiod_put(&pdev->dev, sel3350_leds[i].gpiod);
+	goto err_platform;
+
 err_ps:
 	platform_device_unregister(sel3350->leds_pdev);
 err_platform:
 	gpiod_remove_lookup_table(&sel3350_gpios_table);
-	gpiod_remove_lookup_table(&sel3350_leds_table);
 
 	return rs;
 }
@@ -224,7 +295,6 @@ static void sel3350_remove(struct platform_device *pdev)
 
 	platform_device_unregister(sel3350->leds_pdev);
 	gpiod_remove_lookup_table(&sel3350_gpios_table);
-	gpiod_remove_lookup_table(&sel3350_leds_table);
 }
 
 static const struct acpi_device_id sel3350_device_ids[] = {
-- 
2.53.0

[PATCH AUTOSEL 6.18] modpost: Handle malformed WMI GUID strings

[Sasha Levin]

From: Armin Wolf <W_Armin@gmx.de>

[ Upstream commit 3429ae7b2f02a4a6ad40d36ee06641d433d75a1b ]

Some WMI GUIDs found inside binary MOF files contain both
uppercase and lowercase characters. Blindly copying such
GUIDs will prevent the associated WMI driver from loading
automatically because the WMI GUID found inside WMI device ids
always contains uppercase characters.

Avoid this issue by always converting WMI GUID strings to
uppercase. Also verify that the WMI GUID string actually looks
like a valid GUID.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260610203453.816254-10-W_Armin@gmx.de
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:

The background git searches finished. They didn’t turn up the modpost
WMI GUID commit in this 6.18.44 tree — it’s still only a candidate. The
closest related in-tree commit is `97b726eb1dc2b` (msi-wmi-platform
lowercase GUID typo), which lines up with the modpost fix but doesn’t
replace it.

That doesn’t change the earlier conclusion: backport **YES** for 6.18.y.

 .../wmi/driver-development-guide.rst          |  2 +-
 scripts/mod/file2alias.c                      | 28 ++++++++++++++++++-
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/Documentation/wmi/driver-development-guide.rst b/Documentation/wmi/driver-development-guide.rst
index 5680303ae314e..ae577a290afc3 100644
--- a/Documentation/wmi/driver-development-guide.rst
+++ b/Documentation/wmi/driver-development-guide.rst
@@ -54,7 +54,7 @@ to matching WMI devices using a struct wmi_device_id table:
 ::
 
   static const struct wmi_device_id foo_id_table[] = {
-         /* Only use uppercase letters! */
+         /* Using only uppercase letters is recommended */
          { "936DA01F-9ABD-4D9D-80C7-02AF85C822A8", NULL },
          { }
   };
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 4e99393a35f15..20e542a888c49 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1253,6 +1253,8 @@ static void do_tee_entry(struct module *mod, void *symval)
 static void do_wmi_entry(struct module *mod, void *symval)
 {
 	DEF_FIELD_ADDR(symval, wmi_device_id, guid_string);
+	char result[sizeof(*guid_string)];
+	int i;
 
 	if (strlen(*guid_string) != UUID_STRING_LEN) {
 		warn("Invalid WMI device id 'wmi:%s' in '%s'\n",
@@ -1260,7 +1262,31 @@ static void do_wmi_entry(struct module *mod, void *symval)
 		return;
 	}
 
-	module_alias_printf(mod, false, WMI_MODULE_PREFIX "%s", *guid_string);
+	for (i = 0; i < UUID_STRING_LEN; i++) {
+		char value = (*guid_string)[i];
+		bool valid = false;
+
+		if (i == 8 || i == 13 || i == 18 || i == 23) {
+			if (value == '-')
+				valid = true;
+		} else {
+			if (isxdigit(value))
+				valid = true;
+		}
+
+		if (!valid) {
+			warn("Invalid character %c inside WMI GUID string '%s' in '%s'\n",
+			     value, *guid_string, mod->name);
+			return;
+		}
+
+		/* Some GUIDs from BMOF definitions contain lowercase characters */
+		result[i] = toupper(value);
+	}
+
+	result[i] = '\0';
+
+	module_alias_printf(mod, false, WMI_MODULE_PREFIX "%s", result);
 }
 
 /* Looks like: mhi:S */
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] platform/x86: intel-hid: Add HP ProBook x360 440 G1 to button_array_table

[Sasha Levin]

From: Nikolay Metchev <nikolaymetchev@gmail.com>

[ Upstream commit c39023ca9a447f09c072080efc84d6874c2275c9 ]

The volume rocker buttons on the HP ProBook x360 440 G1 convertible emit
events 0xc4-0xc7 via the intel-hid ACPI device (INT33D5). These codes are
only present in intel_array_keymap, which is used when the "5 button
array" input device exists. On this machine button_array_present()
returns false because the firmware does not advertise the array through
the HEBC method, so notify_handler() routes the events to a NULL
priv->array and they are dropped as "unknown event 0xc4". As a result
the side volume keys do nothing.

Add the machine to button_array_table so the array device is created and
the volume rocker emits KEY_VOLUMEUP / KEY_VOLUMEDOWN. This is equivalent
to booting with the enable_5_button_array=1 module parameter, which was
used to confirm the fix on the affected hardware.

Signed-off-by: Nikolay Metchev <nikolaymetchev@gmail.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://patch.msgid.link/20260609213309.445019-1-nikolaymetchev@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:

## Phase 1: Commit Message Forensics

**Step 1.1 — Subject line**
Record: `[platform/x86: intel-hid] [add] Add HP ProBook x360 440 G1 to
button_array_table`

**Step 1.2 — Tags**
Record:
- Fixes: — none
- Reported-by: — none
- Tested-by: — none (hardware testing described in v1 body text)
- Reviewed-by: Hans de Goede `<johannes.goede@oss.qualcomm.com>`, Ilpo
  Järvinen `<ilpo.jarvinen@linux.intel.com>`
- Acked-by: — none
- Link: https://patch.msgid.link/20260609213309.445019-1-
  nikolaymetchev@gmail.com
- Cc: stable@vger.kernel.org — none (expected)
- Signed-off-by: Nikolay Metchev (author), Ilpo Järvinen (committer)

Notable: Reviewed by the platform-x86 maintainer (Hans de Goede) and
intel-hid maintainer (Ilpo Järvinen).

**Step 1.3 — Body analysis**
Record:
- Bug: Side volume rocker on HP ProBook x360 440 G1 sends ACPI events
  0xc4–0xc7 via INT33D5, but firmware does not advertise the 5-button
  array via HEBC, so `button_array_present()` returns false,
  `priv->array` is never created, and volume events are dropped.
- Symptom: Volume keys do nothing; kernel logs "unknown event 0xc4" (per
  v1 submission).
- Root cause: Missing DMI quirk entry; events require
  `intel_array_keymap` which is only wired when the 5-button array input
  device exists.
- Verification: Equivalent to `enable_5_button_array=1`, tested on real
  hardware.

**Step 1.4 — Hidden bug fix?**
Record: Not disguised — this is an explicit hardware-enablement quirk,
not cleanup. It fixes broken input functionality on a specific laptop
model.

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**
Record:
- Files: `drivers/platform/x86/intel/hid.c` (+7 lines, 0 removed)
- Functions touched: `button_array_table[]` static data only
- Scope: Single-file, surgical DMI table entry

**Step 2.2 — Code flow change**
Record:
- Before: On HP ProBook x360 440 G1, `button_array_present()` returns
  false → probe skips `intel_button_array_input_setup()` → `priv->array`
  stays NULL → `notify_handler()` drops 0xc4–0xc7 events.
- After: DMI match forces `button_array_present()` true → 5-button array
  input device created with `intel_array_keymap` → volume rocker emits
  `KEY_VOLUMEUP` / `KEY_VOLUMEDOWN`.

**Step 2.3 — Bug mechanism**
Record: [Hardware quirk / logic correctness] Firmware reports volume-
button ACPI events but does not advertise the 5-button array capability.
Driver relies on DMI fallback table (`button_array_table`) for such
machines. Missing entry = non-functional hardware keys.

**Step 2.4 — Fix quality**
Record: Obviously correct — identical pattern to existing entries (HP
Spectre x2, Surface Go 3/4, ThinkPad models). Minimal regression risk:
only affects DMI-matched HP ProBook x360 440 G1 systems. Uses existing,
tested code path (`enable_5_button_array=1` confirmed equivalent).

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**
Record: `button_array_table[]` introduced in c454a99d4ce1 (2017). DMI
fallback mechanism extended with `enable_5_button_array` in
e32354bb8fe33. Bug is longstanding pattern — machines with
broken/missing HEBC advertisement need DMI entries. HP ProBook was never
added until this commit.

**Step 3.2 — Fixes: tag**
Record: N/A — no Fixes: tag present.

**Step 3.3 — Related commits in this tree**
Record: Direct precedents already in 6.18.y:
- `2738d06fb4f01` — Surface Go 4 volume buttons (identical fix)
- `75a978bd604b5` — ThinkPad X12 volume buttons (identical fix)
- `05bc9939b501f` — ThinkPad X1 Fold 16 Gen 1 (identical fix)

Standalone — not part of a multi-patch series.

**Step 3.4 — Author context**
Record: Nikolay Metchev is an external contributor (not subsystem
maintainer). Patch went through normal maintainer review by Hans de
Goede and Ilpo Järvinen.

**Step 3.5 — Dependencies**
Record: None. All required infrastructure (`button_array_table`,
`intel_array_keymap`, `enable_5_button_array`, `button_array_present()`,
`notify_handler()`) exists in this tree. Applies standalone.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**
Record:
- Lore URL: https://patch.msgid.link/20260609213309.445019-1-
  nikolaymetchev@gmail.com
- Series: v1 (2026-06-02, attachment) → v2 (2026-06-09, inline) —
  committed version is v2 (latest)
- Hans de Goede: "Thanks, patch looks good to me" + Reviewed-by
- Ilpo Järvinen: Applied to review branch; v1 feedback was formatting
  only ("send inline")
- No NAKs or objections
- No explicit "Cc: stable" nomination in thread

**Step 4.2 — Reviewers**
Record: CC'd to Hans de Goede, Ilpo Järvinen, Alex Hung, platform-
driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org — appropriate
subsystem maintainers included.

**Step 4.3 — Bug report**
Record: User-reported on real hardware (HP ProBook x360 440 G1). v1
describes testing with `enable_5_button_array=1` confirming fix. No
syzbot/bugzilla.

**Step 4.4 — Related patches**
Record: Part of ongoing intel-hid DMI quirk additions; each machine
entry is independent.

**Step 4.5 — Stable list history**
Record: Not searched separately; no stable discussion found in mbox
thread.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**
Record: Data change only in `button_array_table[]`. Affects runtime
behavior via `button_array_present()` → `intel_hid_probe()` →
`intel_button_array_input_setup()` → `notify_handler()`.

**Step 5.2 — Callers**
Record:
- `dmi_check_system(button_array_table)` called from
  `button_array_present()` (line 682)
- `button_array_present()` called from `intel_hid_probe()` (line 743)
- `intel_hid_probe()` registered as platform driver probe — runs at boot
  on matching ACPI INT33D5 devices

**Step 5.3 — Callees**
Record: When matched, probe calls `intel_button_array_input_setup()`
which allocates input device, sets up `intel_array_keymap`, registers
"Intel HID 5 button array" device.

**Step 5.4 — Reachability**
Record: Triggered automatically at boot on HP ProBook x360 440 G1 with
CONFIG_INTEL_HID (common on Intel x86 laptops). Volume key presses are
normal user interaction — highly reachable for affected owners.

**Step 5.5 — Similar patterns**
Record: Same file contains 8 existing `button_array_table` entries for
machines with identical firmware quirk pattern. This tree already
backported Surface Go 4 and ThinkPad fixes of the same nature.

---

## Phase 6: Cross-Reference Against Local Tree

**Step 6.1 — Buggy code exists?**
Record: **YES.** Local tree is **v6.18.44** (`stable/linux-6.18.y`).
`button_array_table[]` exists without HP ProBook entry. Bug affects any
6.18.y user with this laptop. Commit `c39023ca9a447` is on master but
**NOT** in current HEAD.

**Step 6.2 — Backport complications**
Record: **Clean apply confirmed** (`git apply --check` succeeded).
Insertion point after Surface Go 4 entry matches current file layout
exactly.

**Step 6.3 — Related fixes already present?**
Record: Surface Go 4 (`2738d06fb4f01`), ThinkPad X12, X1 Fold 16 fixes
are already in 6.18.y. HP ProBook entry is the missing piece — not
duplicated elsewhere.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1 — Subsystem criticality**
Record: `drivers/platform/x86/intel/hid.c` — platform driver, IMPORTANT
for Intel x86 convertible/tablet users, PERIPHERAL in global kernel
scope but critical for affected hardware.

**Step 7.2 — Subsystem activity**
Record: Actively maintained — multiple DMI quirk additions in 2024–2026,
including several already backported to 6.18.y.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**
Record: Owners of HP ProBook x360 440 G1 convertibles running intel-hid
(Intel ACPI INT33D5). Config-specific (`CONFIG_INTEL_HID`), platform-
specific (x86, specific DMI).

**Step 8.2 — Trigger conditions**
Record: Every boot + every volume button press on affected hardware.
Common, deterministic. Unprivileged users trigger via normal key use.

**Step 8.3 — Failure mode severity**
Record: Non-functional volume rocker buttons. Severity: **LOW** (no
crash, corruption, or security impact). Functional hardware regression
for affected users.

**Step 8.4 — Risk-benefit**
Record:
- Benefit: **MEDIUM** for affected users (restores expected laptop
  input); **LOW** globally (single DMI match)
- Risk: **VERY LOW** (7-line DMI entry, established pattern, hardware-
  tested, maintainer-reviewed)
- Ratio: Strong benefit for affected users at negligible risk — matches
  stable precedent for intel-hid DMI quirks

---

## Phase 9: Final Synthesis

**Step 9.1 — Evidence summary**

FOR backport:
- Fixes real, reproducible hardware bug (volume keys dead)
- Hardware-tested on affected machine
- Reviewed by subsystem and driver maintainers
- Identical to Surface Go 4 / ThinkPad fixes already in 6.18.y
- Falls under stable "quirks/workarounds" exception (DMI table for
  broken firmware)
- 7 lines, single file, applies cleanly
- All infrastructure present in local tree

AGAINST backport:
- Not crash/security/corruption — functional input regression only
- Affects narrow hardware population
- No explicit stable nomination in mailing list

UNRESOLVED: None affecting decision.

**Step 9.2 — Stable rules checklist**
1. Obviously correct and tested? **PASS** — maintainers reviewed;
   hardware verified via `enable_5_button_array=1`
2. Fixes real bug affecting users? **PASS** — volume buttons non-
   functional
3. Important issue? **PASS** (hardware quirk exception) — real-world
   broken hardware on a business laptop; same category as prior stable
   backports in this driver
4. Small and contained? **PASS** — 7 lines, one DMI entry
5. No new features/APIs? **PASS** — DMI quirk only
6. Can apply to local tree? **PASS** — verified clean apply to v6.18.44

**Step 9.3 — Exception category**
Record: **Hardware quirk/workaround** — DMI-based enablement of 5-button
array for firmware that fails to advertise capability via HEBC.
Explicitly allowed per stable rules.

**Step 9.4 — Decision rationale**
This commit restores volume rocker functionality on HP ProBook x360 440
G1 by adding a DMI entry to an existing quirk table. The 6.18.y tree
already carries nearly identical fixes for Surface Go 4, ThinkPad X12,
and ThinkPad X1 Fold 16. The patch is minimal, maintainer-reviewed,
hardware-tested, and applies cleanly. While not a crash fix, it matches
the well-established stable pattern for intel-hid DMI quirks that fix
broken laptop input hardware.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Hans de Goede, Ilpo Järvinen; Link
  to patch submission; no Fixes/Reported-by/syzbot
- [Phase 2] Diff: +7 lines, DMI entry in `button_array_table[]`;
  verified event drop path in `notify_handler()` lines 646–649 when
  `!priv->array`
- [Phase 3] `git describe HEAD`: v6.18.44; commit NOT ancestor of HEAD;
  `button_array_table` since 2017
- [Phase 3] Precedent commits in tree: 2738d06fb4f01 (Surface Go 4),
  75a978bd604b5 (ThinkPad X12), 05bc9939b501f (X1 Fold 16)
- [Phase 4] `b4 dig -c c39023ca9a447`: lore URL found; v1→v2 series;
  Hans de Goede Reviewed-by; no NAKs
- [Phase 4] `b4 dig -w`: CC'd Hans de Goede, Ilpo Järvinen, platform-
  driver-x86, LKML
- [Phase 4] Mbox: v1 tested on HP ProBook x360 440 G1 with
  `enable_5_button_array=1`
- [Phase 5] Call chain: probe → `button_array_present()` →
  `intel_button_array_input_setup()` → `notify_handler()` with
  `priv->array`
- [Phase 6] `git apply --check` on commit diff: **clean apply**
- [Phase 6] HP ProBook entry absent from current `hid.c`; infrastructure
  present
- [Phase 8] Failure mode: dropped input events, severity LOW; hardware
  quirk category

**YES**The background checks finished and match the earlier analysis:

- **Commit location:** `c39023ca9a447` (HP ProBook x360 440 G1 DMI
  quirk) is on **master**, not in the current **v6.18.44** stable
  checkout.
- **b4 dig:** Found the v1→v2 lore thread; Hans de Goede and Ilpo
  Järvinen reviewed it, with hardware testing on the affected laptop.

**Verdict for this tree (6.18.y): YES** — same pattern as the Surface Go
4 / ThinkPad volume-button fixes already in 6.18.y; 7-line DMI quirk,
applies cleanly.

 drivers/platform/x86/intel/hid.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/intel/hid.c b/drivers/platform/x86/intel/hid.c
index 0dcf3a68a3355..f97f7f111319e 100644
--- a/drivers/platform/x86/intel/hid.c
+++ b/drivers/platform/x86/intel/hid.c
@@ -158,6 +158,13 @@ static const struct dmi_system_id button_array_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "Surface Go 4"),
 		},
 	},
+	{
+		.ident = "HP ProBook x360 440 G1",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook x360 440 G1"),
+		},
+	},
 	{ }
 };
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk table

[Sasha Levin]

From: Gleb Sonichev <sonichev555@gmail.com>

[ Upstream commit bfe91a80b13f8068f6fa07aa8c468d284150d4ad ]

The Inspiron N5110 needs the touchpad LED quirk (Vostro V130 quirk)
to properly control the touchpad LED. Add its DMI identifier
to the existing quirk table, next to the similar Inspiron M5110 entry.

Tested on Dell Inspiron N5110.
The touchpad LED works correctly with this quirk enabled.

Signed-off-by: Gleb Sonichev <sonichev555@gmail.com>
Acked-by: Pali Rohár <pali@kernel.org>
Link: https://patch.msgid.link/20260525100047.20046-1-sonichev555@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:

The background git searches finished; they don't change the earlier
**YES** verdict.

- **N5110/M5110 grep:** No commit for this N5110 quirk in the tree.
  Broad `--grep="N5110"`/`"M5110"` hits were unrelated (WM5110 codec,
  `dell-wmi` on M5110). The touchpad LED quirk for M5110 is still only
  `2a748853ca395c` (2011).
- **Author search:** Gleb Sonichev has no other commits in this checkout
  — this looks like a one-off hardware report.
- **Similar quirk history:** Found the usual precedent commits
  (`a2174ba29a302` typo fix, `89a8f23fee5ef` Latitude 7520 quirk), which
  matches the established pattern for these DMI table additions.

 drivers/platform/x86/dell/dell-laptop.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/dell/dell-laptop.c b/drivers/platform/x86/dell/dell-laptop.c
index 053f40572bf6e..89e85c7f7132a 100644
--- a/drivers/platform/x86/dell/dell-laptop.c
+++ b/drivers/platform/x86/dell/dell-laptop.c
@@ -222,6 +222,15 @@ static const struct dmi_system_id dell_quirks[] __initconst = {
 		},
 		.driver_data = &quirk_dell_vostro_v130,
 	},
+	{
+		.callback = dmi_matched,
+		.ident = "Dell Inspiron N5110",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron N5110"),
+		},
+		.driver_data = &quirk_dell_vostro_v130,
+	},
 	{
 		.callback = dmi_matched,
 		.ident = "Dell Vostro 3360",
-- 
2.53.0

[PATCH AUTOSEL 6.18] platform/x86/amd/hsmp: Clamp ioctl/send_message indices (Spectre v1)

[Sasha Levin]

From: Muralidhara M K <muralidhara.mk@amd.com>

[ Upstream commit d20457b46eca76b9bb716dd31af591cad21607b5 ]

Although validate_message() checks msg_id, a mispredicted branch can
still allow speculative indexing into hsmp_msg_desc_table[]. Clamp
msg.msg_id with array_index_nospec() at entry to hsmp_ioctl_msg() so
downstream dereferences (including via is_get_msg() and
hsmp_send_message()) see a bounded index.

Similarly, hsmp_send_message() bounds-checks msg->sock_ind before
indexing hsmp_pdev.sock[], but a mispredicted branch can still
speculatively use the raw index (Spectre v1, CVE-2017-5753). Apply
array_index_nospec() after the check so every caller that reaches
hsmp_pdev.sock[] through this helper sees a clamped socket
index—including hsmp_ioctl_msg() and any other path that hands a
user-derived struct hsmp_message to hsmp_send_message().

Reviewed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260612042610.1629037-7-muralidhara.mk@amd.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:

# Stable Backport Analysis: `platform/x86/amd/hsmp: Clamp
ioctl/send_message indices (Spectre v1)`

**Local tree:** Linux **6.18.44** (`v6.18.44-1-g2736c32da98b9`)
**Commit under review:** `d5be735237be5` (upstream: `d20457b46eca`) —
present on `autosel` branch, **not** in current `HEAD`

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1 — Subject parse**
Record: `[platform/x86/amd/hsmp]` `[Clamp]` — Spectre v1 mitigation for
user-controlled array indices in HSMP ioctl/send_message paths.

**Step 1.2 — Tags**
Record:
- `Reviewed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>`
  (AMD)
- `Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>`
  (platform-drivers-x86 maintainer)
- `Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>` (author)
- `Link: https://patch.msgid.link/20260612042610.1629037-7-
  muralidhara.mk@amd.com`
- No `Fixes:`, `Reported-by:`, `Cc: stable@vger.kernel.org`, or syzbot
  tags
- `[Upstream commit d20457b46eca...]` marker present (pipeline artifact
  — ignored per instructions)

**Step 1.3 — Body analysis**
Record:
- **Bug:** After bounds checks on `msg_id` and `sock_ind`, a
  mispredicted branch (Spectre v1 / CVE-2017-5753) can still cause
  speculative indexing into `hsmp_msg_desc_table[]` and
  `hsmp_pdev.sock[]`, leaking kernel memory into cache.
- **Symptom:** Side-channel information disclosure (not a direct crash).
- **Root cause:** Missing `array_index_nospec()` after bounds checks on
  user-controlled indices.
- **Fix:** Clamp `msg.msg_id` in `hsmp_ioctl()` before downstream use;
  clamp `sock_ind` in `hsmp_send_message()` before socket array access.
- Note: commit message refers to `hsmp_ioctl_msg()` but the actual
  function is `hsmp_ioctl()` (verified in source).

**Step 1.4 — Hidden bug fix?**
Record: No — this is an explicit Spectre v1 security fix, not disguised
cleanup.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1 — Inventory**
Record:
- **Files:** `drivers/platform/x86/amd/hsmp/hsmp.c` (+23 / -1)
- **Functions:** `hsmp_send_message()`, `hsmp_ioctl()`
- **Scope:** Single-file, surgical security fix

**Step 2.2 — Code flow changes**

| Hunk | Before | After |
|------|--------|-------|
| `hsmp_send_message()` | Bounds-check `sock_ind`, then directly index
`hsmp_pdev.sock[msg->sock_ind]` | After bounds check, `sock_ind =
array_index_nospec(msg->sock_ind, hsmp_pdev.num_sockets)` then index
with clamped value |
| `hsmp_ioctl()` | Bounds-check `msg_id`, then call `is_get_msg()` /
`hsmp_send_message()` with raw `msg_id` | After bounds check,
`msg.msg_id = array_index_nospec(msg.msg_id, HSMP_MSG_ID_MAX)` before
any table dereference |

Record: Both hunks affect the userspace ioctl hot path and the shared
`hsmp_send_message()` helper used by ioctl.

**Step 2.3 — Bug mechanism**
Record: **Memory safety / Spectre v1 speculative out-of-bounds read.**
User-supplied `msg_id` and `sock_ind` pass explicit bounds checks, but
CPU speculation can bypass those checks and index past array ends into
adjacent kernel memory. `array_index_nospec()` masks the index so
speculative execution cannot use out-of-range values.

**Step 2.4 — Fix quality**
Record: Fix is minimal, follows the established kernel Spectre-
mitigation pattern (`array_index_nospec` after bounds check). No new
locking or API changes. Regression risk is very low. Compiles
successfully in this tree without additional includes (verified).

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1 — Blame**
Record: Vulnerable ioctl/send_message logic dates to `91f410aa679a03`
("platform/x86: Add AMD system management interface", Feb 2022, first in
**v6.0**). Bounds checks on `sock_ind` added in `8e75dff56e003` (Oct
2024 refactor). Bug has been present since driver introduction.

**Step 3.2 — Fixes: tag**
Record: N/A — no `Fixes:` tag present.

**Step 3.3 — Related file history**
Record: Recent `hsmp.c` changes in this tree include timeout/semaphore
fixes (`784e48a82976e`, `f8afb12a2d750`) and `2c78fb287e1f4` (NULL check
for `metric_tbl_addr`). No prior Spectre/nospec fix for HSMP in `HEAD`.

**Step 3.4 — Author context**
Record: Muralidhara M K (AMD). Patch is part of v6 series "Family 1Ah
Model 50h-5Fh HSMP and metrics" but this specific commit only touches
existing ioctl/send paths — no dependency on new message IDs from other
series patches.

**Step 3.5 — Dependencies**
Record: **Standalone.** Applies cleanly (`git apply --check` passed). No
prerequisite commits required. `array_index_nospec` and
`include/linux/nospec.h` exist in this tree.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1 — Original discussion**
Record: `b4 dig -c d5be735237be5` found thread at
https://patch.msgid.link/20260612042610.1629037-7-muralidhara.mk@amd.com
— `[PATCH v6 6/8]`. Series revisions: v5 and v6 exist; committed version
matches v6. Full lore thread fetch blocked by Anubis bot protection
(could not read inline review text).

**Step 4.2 — Reviewers**
Record: `b4 dig -w` shows CC to `platform-driver-x86@vger.kernel.org`,
`linux-kernel@vger.kernel.org`, AMD reviewer, and Ilpo Järvinen.

**Step 4.3 — Bug report**
Record: N/A — no external bug report or syzbot link. Security issue
identified by code review in patch series context.

**Step 4.4 — Series context**
Record: Patch 6/8 in Family 1Ah HSMP series. The Spectre fix is
independent of patches 1–5 and 7–8 (new hardware messages/metrics). Safe
to backport alone.

**Step 4.5 — Stable list**
Record: Not searched on lore stable list (thread content unavailable).
No evidence against backport found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1 — Key functions**
Record: `hsmp_ioctl()`, `hsmp_send_message()`, `validate_message()`,
`is_get_msg()`

**Step 5.2 — Callers**
Record:
- `hsmp_ioctl()` — registered as `.unlocked_ioctl` / `.compat_ioctl` in
  `hsmp_fops`, exposed via misc device `/dev/hsmp` (mode **0644**)
- `hsmp_send_message()` — called from `hsmp_ioctl()`,
  `hsmp_msg_get_nargs()`, `hsmp_test()`, internal metric/proto paths,
  and `hwmon.c` (kernel-constructed messages with trusted indices)

**Step 5.3 — Callees**
Record: `copy_struct_from_user()`, `is_get_msg()` →
`hsmp_msg_desc_table[]`, `validate_message()` → `hsmp_msg_desc_table[]`,
`down_interruptible()`, `__hsmp_send_message()`

**Step 5.4 — Reachability**
Record: **Userspace-reachable.** Any local user can open `/dev/hsmp`
(world-readable/writable) and issue ioctl with crafted
`msg_id`/`sock_ind`. This is the primary attack surface.
`hsmp_send_message()` is also exported (`EXPORT_SYMBOL_NS_GPL`) for
other kernel modules.

**Step 5.5 — Similar patterns**
Record: Kernel has extensive precedent for `array_index_nospec` Spectre
fixes (e.g., `c2178ff1c70eb` ipv4/icmp, `f0e441be08a2e` drm/ioc32,
`1f5f94c6c6b2e` vhost/vdpa). No similar fix yet in
`drivers/platform/x86/`.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

**Step 6.1 — Buggy code present?**
Record: **YES.** Current `HEAD` at
`drivers/platform/x86/amd/hsmp/hsmp.c` lines 213–215 and 308–338 contain
bounds checks without `array_index_nospec`. Driver present since v6.0;
fully present in 6.18.44.

**Step 6.2 — Backport complications**
Record: **Clean apply.** `git apply --check` succeeded. Patch compiles
(`make drivers/platform/x86/amd/hsmp/hsmp.o` succeeded). No conflicts
with recent hsmp changes in this tree.

**Step 6.3 — Fix already present?**
Record: **NO.** `grep array_index_nospec drivers/platform/x86/amd/hsmp/`
returns nothing on `HEAD`. Fix exists only on `autosel` branch
(`d5be735237be5`), not merged into current `HEAD`.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1 — Subsystem**
Record: `drivers/platform/x86/amd/hsmp` — AMD HSMP platform driver.
**Criticality: IMPORTANT** (peripheral driver, but security-sensitive
when `CONFIG_AMD_HSMP` is enabled on AMD EPYC/MI300A servers).

**Step 7.2 — Activity**
Record: Actively maintained — recent commits for protocol v7 messages,
telemetry sysfs, semaphore/timeout fixes in 6.16–6.18 timeframe.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1 — Who is affected**
Record: Systems with `CONFIG_AMD_HSMP` / `CONFIG_AMD_HSMP_ACPI` /
`CONFIG_AMD_HSMP_PLAT` on AMD EPYC and MI300A platforms. Not universal,
but real production server hardware.

**Step 8.2 — Trigger conditions**
Record: Local user opens `/dev/hsmp` and issues ioctl with out-of-range
`msg_id` or `sock_ind` crafted to exploit branch misprediction.
**Unprivileged local users can trigger** (device mode 0644). Trigger
requires Spectre v1 exploitation techniques but the vulnerable code
pattern is confirmed present.

**Step 8.3 — Failure mode severity**
Record: **Speculative kernel memory disclosure** (Spectre v1 side
channel). Severity: **HIGH** from security perspective (CVE-2017-5753
class). No direct crash or data corruption, but information leak from
kernel to userspace.

**Step 8.4 — Risk-benefit**
Record:
- **Benefit:** Closes a known Spectre v1 gadget on a world-accessible
  device node; aligns with established kernel security policy.
- **Risk:** Very low — 23 lines, standard `array_index_nospec` pattern,
  compiles and applies cleanly.
- **Ratio:** Strong benefit, minimal risk → backport warranted.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1 — Evidence summary**

**FOR backport:**
- Real Spectre v1 security vulnerability (CVE-2017-5753)
- User-controlled indices via ioctl on world-accessible `/dev/hsmp`
- Standard, obviously-correct mitigation pattern
- Small, single-file, standalone fix
- Reviewed by AMD engineer and platform-x86 maintainer
- Applies and compiles cleanly on 6.18.44
- Bug present since driver introduction (v6.0)
- Strong kernel precedent for identical fixes in stable

**AGAINST backport:**
- Limited to AMD HSMP-enabled systems (not all kernels/users)
- No syzbot report or user crash report (side-channel, hard to observe)
- Part of larger patch series (but this commit is self-contained)

**Unresolved:** Full lore review thread content unavailable (bot
protection). Does not affect technical assessment.

**Step 9.2 — Stable rules checklist**
1. Obviously correct and tested? **PASS** — standard
   `array_index_nospec`; compiles in this tree; reviewed by AMD +
   maintainer.
2. Fixes a real bug? **PASS** — Spectre v1 speculative OOB read on user-
   controlled indices.
3. Important issue? **PASS** — security vulnerability (information
   disclosure).
4. Small and contained? **PASS** — 23 lines, 1 file, 2 functions.
5. No new features/APIs? **PASS** — pure hardening, no behavior change
   for valid inputs.
6. Can apply to local tree? **PASS** — clean apply, successful compile
   on 6.18.44.

**Step 9.3 — Exception categories**
Record: N/A (security hardening, not device ID/quirk/build/doc
exception).

**Step 9.4 — Decision rationale**
This fix closes a Spectre v1 gadget in the AMD HSMP driver where local
users can pass crafted indices through a world-accessible ioctl
interface. The vulnerable code exists in Linux 6.18.44, the patch is
minimal and self-contained, and it follows the same pattern routinely
accepted for stable backports. The limited hardware scope does not
outweigh the security nature of the fix.

---

## Verification

- [Phase 1] Parsed commit `d5be735237be5` / upstream `d20457b46eca`:
  subject, tags, body; noted `hsmp_ioctl_msg` vs `hsmp_ioctl` naming
  discrepancy
- [Phase 2] Diff: +23/-1 in `hsmp.c`; two hunks in `hsmp_send_message()`
  and `hsmp_ioctl()`
- [Phase 3] `git describe HEAD`: v6.18.44; `git blame`: vulnerable code
  from `91f410aa679a03` (v6.0)
- [Phase 3] `git log -20 -- drivers/platform/x86/amd/hsmp/hsmp.c`: no
  prior nospec fix in HEAD
- [Phase 3] `git merge-base --is-ancestor d5be735 HEAD`: commit NOT in
  HEAD; on `autosel` branch
- [Phase 4] `b4 dig -c d5be735237be5`: lore URL found, patch 6/8 of v6
  series
- [Phase 4] `b4 dig -a`: v5 and v6 revisions exist
- [Phase 4] `b4 dig -w`: platform-driver-x86@, AMD reviewer CC'd
- [Phase 4] WebFetch lore thread: blocked by Anubis (UNVERIFIED: inline
  reviewer stable nominations)
- [Phase 5] `grep hsmp_send_message`: ioctl path + kernel-internal
  callers identified
- [Phase 5] Read `hsmp.c:439-446`: misc device mode 0644 confirmed
- [Phase 5] Read `arch/x86/include/uapi/asm/amd_hsmp.h`: `HSMP_TEST=1`,
  `HSMP_MSG_ID_MAX`, `hsmp_msg_desc_table[]` confirmed
- [Phase 6] `grep array_index_nospec drivers/platform/x86/amd/hsmp/`: no
  matches on HEAD (bug present)
- [Phase 6] `git apply --check`: patch applies cleanly
- [Phase 6] `make drivers/platform/x86/amd/hsmp/hsmp.o` with patch:
  compile succeeded
- [Phase 7] Read `drivers/platform/x86/amd/hsmp/Kconfig`: AMD_HSMP
  targets EPYC/MI300A
- [Phase 8] Device mode 0644: unprivileged local access confirmed

**YES**The background lookups are done and match what we already used in
the review:

- **Commit hash:** `d5be735237be5` — `platform/x86/amd/hsmp: Clamp
  ioctl/send_message indices (Spectre v1)`
- **`hsmp.c` history:** ioctl/send paths go back to the original HSMP
  driver (`91f410aa679a03`, v6.0); recent churn is mostly refactors,
  protocol v7, and timeout/semaphore fixes
- **Fix in tree:** not in current `HEAD` (6.18.44); only on `autosel`

Verdict for this tree is still **YES** — small Spectre v1 hardening on
`/dev/hsmp`, applies and builds cleanly.

 drivers/platform/x86/amd/hsmp/hsmp.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/amd/hsmp/hsmp.c b/drivers/platform/x86/amd/hsmp/hsmp.c
index 19f82c1d30905..008a02ace4842 100644
--- a/drivers/platform/x86/amd/hsmp/hsmp.c
+++ b/drivers/platform/x86/amd/hsmp/hsmp.c
@@ -202,6 +202,7 @@ static int validate_message(struct hsmp_message *msg)
 int hsmp_send_message(struct hsmp_message *msg)
 {
 	struct hsmp_socket *sock;
+	unsigned int sock_ind;
 	int ret;
 
 	if (!msg)
@@ -212,7 +213,15 @@ int hsmp_send_message(struct hsmp_message *msg)
 
 	if (!hsmp_pdev.sock || msg->sock_ind >= hsmp_pdev.num_sockets)
 		return -ENODEV;
-	sock = &hsmp_pdev.sock[msg->sock_ind];
+
+	/*
+	 * Sanitize sock_ind after the bounds check.  A mispredicted branch can
+	 * still let the CPU speculatively use msg->sock_ind as an index into
+	 * hsmp_pdev.sock[] (Spectre v1, CVE-2017-5753), including for callers
+	 * other than hsmp_ioctl_msg() that pass a user-derived socket index.
+	 */
+	sock_ind = array_index_nospec(msg->sock_ind, hsmp_pdev.num_sockets);
+	sock = &hsmp_pdev.sock[sock_ind];
 
 	ret = down_interruptible(&sock->hsmp_sem);
 	if (ret < 0)
@@ -308,6 +317,19 @@ long hsmp_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
 	if (msg.msg_id < HSMP_TEST || msg.msg_id >= HSMP_MSG_ID_MAX)
 		return -ENOMSG;
 
+	/*
+	 * Sanitize the user-controlled msg_id against speculative
+	 * execution.  The bounds check above retires the out-of-range
+	 * case with -ENOMSG, but a mispredicted branch can still let the
+	 * CPU speculatively use msg_id as an index into
+	 * hsmp_msg_desc_table[] (here and in validate_message() /
+	 * is_get_msg() called downstream via hsmp_send_message()), and
+	 * pull arbitrary kernel memory into the cache (Spectre v1,
+	 * CVE-2017-5753).  Clamp once into msg.msg_id so every downstream
+	 * dereference sees the sanitized value.
+	 */
+	msg.msg_id = array_index_nospec(msg.msg_id, HSMP_MSG_ID_MAX);
+
 	switch (fp->f_mode & (FMODE_WRITE | FMODE_READ)) {
 	case FMODE_WRITE:
 		/*
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] platform/x86: msi-ec: Add support for MSI Pulse GL66 12th Gen

[Sasha Levin]

From: Luis de Carlos <reskoldo73@gmail.com>

[ Upstream commit ab7be7ed913086e076bfd8aba79f614f415cd6dc ]

Add the firmware string '1583EMS1.109' to the ALLOWED_FW_10 array.
This enables Embedded Controller support, including battery charge
thresholds, for the MSI Pulse GL66 12UEK (MS-1583) laptop.

Signed-off-by: Luis de Carlos <reskoldo73@gmail.com>
Link: https://patch.msgid.link/20260527134750.25263-1-reskoldo73@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:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject Line
**Record:** `[platform/x86: msi-ec]` `[Add]` — Add firmware whitelist
entry to enable EC support for MSI Pulse GL66 12th Gen (MS-1583).

### Step 1.2: Commit Message Tags
**Record:**
- **Signed-off-by:** Luis de Carlos `<reskoldo73@gmail.com>` (author)
- **Link:**
  https://patch.msgid.link/20260527134750.25263-1-reskoldo73@gmail.com
- **Reviewed-by:** Ilpo Järvinen `<ilpo.jarvinen@linux.intel.com>`
  (subsystem maintainer)
- **Signed-off-by:** Ilpo Järvinen (committer/maintainer)
- No Fixes:, Reported-by:, Tested-by:, Cc: stable@vger.kernel.org, or
  syzbot tags
- Notable: Reviewed and committed by platform/x86 maintainer Ilpo
  Järvinen

### Step 1.3: Commit Body Analysis
**Record:**
- **Bug description:** Not a crash/corruption bug. The `msi-ec` driver
  refuses to load on firmware `1583EMS1.109` because it is absent from
  `ALLOWED_FW_10`.
- **Symptom:** Driver init returns `-EOPNOTSUPP` with "Firmware version
  is not supported"; battery charge thresholds and other EC extras
  unavailable on MSI Pulse GL66 12UEK (MS-1583).
- **Root cause:** Missing firmware string in the whitelist for existing
  `CONF10` configuration.
- **Version info:** None stated; laptop is 12th Gen (Alder Lake era).

### Step 1.4: Hidden Bug Fix Detection
**Record:** Not a hidden bug fix. This is explicit hardware enablement —
adding a firmware identification string so an existing, tested
configuration (`CONF10`) is selected for a new laptop variant.
Functionally equivalent to adding a device ID.

---

## Phase 2: Diff Analysis

### Step 2.1: Change Inventory
**Record:**
- **Files:** `drivers/platform/x86/msi-ec.c` (+1 line)
- **Functions/areas:** `ALLOWED_FW_10[]` firmware whitelist array
- **Scope:** Single-file, single-line surgical change

### Step 2.2: Code Flow Change
**Record:**
- **Before:** `load_configuration()` iterates `CONFIGS[]`, calls
  `match_string()` on each `allowed_fw` list. Firmware `1583EMS1.109`
  matches nothing → warning + `-EOPNOTSUPP` → `msi_ec_init()` fails →
  module does not load.
- **After:** `1583EMS1.109` matches `ALLOWED_FW_10` → `CONF10` is copied
  into `conf` → `battery_hook_register()` succeeds → charge threshold
  sysfs attributes become available.
- **Path affected:** Module initialization (`__init`), normal boot path
  for matching MSI hardware.

### Step 2.3: Bug Mechanism
**Record:** Category: **Hardware enablement / device identification**
(not memory safety, race, or crash). The driver deliberately whitelists
firmware versions before exposing EC register addresses. Missing entry =
safe refusal to load, not a kernel defect.

### Step 2.4: Fix Quality
**Record:** Obviously correct — reuses existing `CONF10` already used
for `1582EMS1.107` (GF66 11UC), a closely related MS-158x platform.
Minimal change. Regression risk very low: only affects systems reporting
exactly this firmware string; no API, locking, or memory management
changes.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** `ALLOWED_FW_10` and `CONF10` introduced in `8abba08944663`
("platform/x86: msi-ec: Add more EC configs", 2023-10-06, v6.6 era).
Present in this tree since driver merge.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag present.

### Step 3.3: Related File History
**Record:** Recent `msi-ec.c` history in this tree (v6.18.44):
- `59fff63cc2b75` Merge platform-drivers-x86 v6.7-1
- `6284e67aa6cb3` Fix the 3rd config
- `8abba08944663` Add more EC configs
- `392cacf2aa10d` Add new msi-ec driver (v6.4)

On master but not in this stable tree:
- `ab7be7ed91308` — this commit (Pulse GL66)
- `4c8f323b9e151` — unrelated include fix for future acpi.h change

**Standalone:** Yes. No series dependency.

### Step 3.4: Author Context
**Record:** Luis de Carlos is a hardware reporter/user contributor. Ilpo
Järvinen is the platform/x86 maintainer who reviewed and committed the
patch.

### Step 3.5: Prerequisites
**Record:** No prerequisites. `CONF10`, `CONFIGS[]`,
`load_configuration()`, and `ALLOWED_FW_10` all exist in v6.18.44. The
`4c8f323b9e151` dmi.h include commit is independent and not needed for
this one-line addition.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:**
- **b4 dig URL:**
  https://patch.msgid.link/20260527134750.25263-1-reskoldo73@gmail.com
- **Series revisions:** v1 → v2 (v2 is what was committed)
- **Reviewer feedback:** Ilpo Järvinen applied to his review branch with
  acknowledgment ("Thank you for your contribution, it has been
  applied")
- **No NAKs, no stable nomination** in thread
- **No objections** raised

### Step 4.2: Reviewers
**Record:** CC'd: `platform-driver-x86@vger.kernel.org`, `linux-
kernel@vger.kernel.org`, teackot@gmail.com (driver author),
hansg@kernel.org. Reviewed/committed by Ilpo Järvinen.

### Step 4.3: Bug Report
**Record:** No external bug report, syzbot, or bugzilla link. User-
submitted hardware enablement from laptop owner.

### Step 4.4: Related Patches
**Record:** Standalone 1/1 patch. No multi-patch series dependencies.

### Step 4.5: Stable Mailing List
**Record:** Not searched separately; no stable nomination found in the
patch thread itself.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `ALLOWED_FW_10[]` (data), `load_configuration()`,
`msi_ec_init()`.

### Step 5.2: Callers
**Record:** `msi_ec_init()` → `load_configuration()` at module init.
`msi_ec` is a loadable module (`CONFIG_MSI_EC`, tristate) probed on MSI
laptops matching DMI vendor table. Called once at boot/module load.

### Step 5.3: Callees
**Record:** `ec_get_firmware_version()` reads EC register 0xa0;
`match_string()` compares against whitelist; on match,
`battery_hook_register()` exposes charge threshold sysfs via ACPI
battery hook.

### Step 5.4: Reachability
**Record:** Triggered when `CONFIG_MSI_EC=m/y` on MSI laptop with
firmware `1583EMS1.109`. Requires root to load module (or built-in at
boot). Not a syscall path; hardware-specific platform driver init.

### Step 5.5: Similar Patterns
**Record:** The driver has 14 `ALLOWED_FW_*` arrays with the same
pattern. Adding entries to existing arrays is the established mechanism
for new hardware variants (e.g., `8abba08944663` added many configs at
once).

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Exists?
**Record:** **YES.** Local tree is **v6.18.44** (6.18.y stable).
`ALLOWED_FW_10` exists with only `"1582EMS1.107"`. Firmware
`1583EMS1.109` is not whitelisted. Commit `ab7be7ed91308` is on master
but not in this tree.

### Step 6.2: Backport Complications
**Record:** **Clean apply expected.** Single-line insertion into
existing array at line 825. No conflicts with local modifications. Index
in commit (`f19504dbf164c`) matches current tree structure around
`CONF9`/`ALLOWED_FW_10`.

### Step 6.3: Related Fixes Already Present?
**Record:** No. `git grep 1583EMS1` returns no matches. No alternative
fix for Pulse GL66 in this tree.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** `drivers/platform/x86/` — **PERIPHERAL** platform driver for
MSI laptop EC extras. Optional module; laptop functions without it (no
crash), but battery charge threshold control is unavailable.

### Step 7.2: Subsystem Activity
**Record:** Driver added v6.4 (2023), configs expanded v6.6. Mature but
still receiving firmware whitelist additions. Low churn in stable tree.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** **Hardware-specific** — owners of MSI Pulse GL66 12UEK
(MS-1583) with firmware `1583EMS1.109` who build/load `CONFIG_MSI_EC`.
Small population.

### Step 8.2: Trigger Conditions
**Record:** Boot or `modprobe msi-ec` on matching MSI laptop with this
exact firmware. Not timing-dependent. Requires `CONFIG_MSI_EC` enabled.
Unprivileged users cannot trigger module load.

### Step 8.3: Failure Mode Severity
**Record:** Without patch: driver refuses to load (`-EOPNOTSUPP`),
charge thresholds unavailable. **Severity: LOW** — missing
functionality, not crash, corruption, hang, or security issue. Laptop
otherwise works.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Enables battery charge threshold and EC extras for a real
  laptop on stable kernel; matches official stable rule allowing device
  ID additions
- **Risk:** Very low — 1 line, whitelist-only, reuses proven `CONF10`
  config
- **Ratio:** Moderate benefit for affected users, negligible risk

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backporting:**
- Explicitly allowed by `Documentation/process/stable-kernel-rules.rst`:
  "just add a device ID"
- Firmware string is this driver's device-identification mechanism
- 1 line, obviously correct, maintainer-reviewed
- Driver and `CONF10` already exist in v6.18.44
- Clean apply, no dependencies
- Enables real hardware functionality for stable-kernel users

**AGAINST backporting:**
- Not a crash/corruption/security/deadlock fix
- Affects one laptop model with small user base
- Optional module — system works without it
- No user bug reports beyond patch author

**Unresolved:** Whether `CONF10` register map is fully validated on
MS-1583 (author and maintainer accepted it; no independent test reports
in thread).

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — maintainer
   reviewed/committed; trivial whitelist addition
2. Fixes real bug affecting users? **PASS** — per stable rules, "just
   add a device ID" is sufficient; missing ID prevents driver from
   loading on real hardware
3. Important issue? **PASS (by exception)** — not crash-level, but
   device ID additions are explicitly permitted
4. Small and contained? **PASS** — 1 line, 1 file
5. No new features or APIs? **PASS** — no new APIs; enables existing
   `CONF10` on new hardware variant
6. Can apply to local tree? **PASS** — driver infrastructure present,
   clean 1-line apply

### Step 9.3: Exception Category
**Record:** **NEW DEVICE ID** — firmware version string added to
existing driver's whitelist, enabling existing `CONF10` configuration.
Directly matches stable-kernel-rules.rst line 15 and the user's "NEW
DEVICE IDs" exception.

### Step 9.4: Decision Rationale

This commit adds firmware `1583EMS1.109` to the `ALLOWED_FW_10`
whitelist so the existing `msi-ec` driver loads on the MSI Pulse GL66
12UEK. The local tree (v6.18.44) has the driver and `CONF10` but lacks
this string, so affected laptops cannot use kernel-managed battery
charge thresholds.

Per the stable rules in this tree's own documentation, patches that
"just add a device ID" are explicitly acceptable for stable. The
firmware string serves as the device identifier for `msi-ec`. The change
is one line, maintainer-reviewed, applies cleanly, and carries
negligible regression risk.

---

## Verification

- [Phase 1] Parsed subject, tags, body; identified hardware enablement
  intent
- [Phase 1] No syzbot/Fixes:/Cc: stable tags found
- [Phase 2] Diff: +1 line to `ALLOWED_FW_10[]` in
  `drivers/platform/x86/msi-ec.c`
- [Phase 2] Read `load_configuration()` at lines 1306–1337: confirms
  `-EOPNOTSUPP` without whitelist match
- [Phase 3] `git describe HEAD`: v6.18.44
- [Phase 3] `git blame -L 824,827`: `ALLOWED_FW_10` from `8abba08944663`
  (2023-10-06)
- [Phase 3] `git show ab7be7ed91308`: confirmed commit hash and 1-line
  diff
- [Phase 3] `git log HEAD..master -- drivers/platform/x86/msi-ec.c`: 2
  commits (this + unrelated include fix)
- [Phase 3] `git show 4c8f323b9e151`: confirmed NOT a prerequisite
- [Phase 4] `b4 dig -c ab7be7ed91308`: found v2 thread at
  patch.msgid.link
- [Phase 4] `b4 dig -a`: v1→v2 series, v2 committed
- [Phase 4] `b4 dig -w`: Ilpo Järvinen, platform-driver-x86 list CC'd
- [Phase 4] Read `/tmp/msi-ec-pulse.mbox`: maintainer applied patch, no
  NAKs, no stable CC
- [Phase 5] `grep match_string`: used in `load_configuration()` line
  1319
- [Phase 5] Read `Kconfig` MSI_EC help text: confirms charge threshold
  purpose
- [Phase 6] `grep 1583EMS1`: not present in local tree
- [Phase 6] `grep 1582EMS1`: present at line 825, confirming target
  array exists
- [Phase 6] Read `Documentation/process/stable-kernel-rules.rst` line
  15: "just add a device ID" explicitly allowed
- [Phase 8] Confirmed failure mode is `-EOPNOTSUPP` (LOW severity), not
  crash

**YES**The MSI Pulse GL66 `msi-ec` commit is a good stable backport
candidate for this tree (v6.18.44).

It adds one firmware string (`1583EMS1.109`) to the existing
`ALLOWED_FW_10` whitelist so the already-present `CONF10` config can
load on the MSI Pulse GL66 12UEK. Without it, `msi-ec` returns
`-EOPNOTSUPP` and battery charge thresholds stay unavailable.

This fits the stable rule for device ID additions: one line, maintainer-
reviewed, clean apply, and the driver infrastructure is already in
6.18.y. It is hardware enablement, not a crash fix, but that is
explicitly allowed for this kind of change.

**YES**

 drivers/platform/x86/msi-ec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/msi-ec.c b/drivers/platform/x86/msi-ec.c
index f19504dbf164c..0157e233e4300 100644
--- a/drivers/platform/x86/msi-ec.c
+++ b/drivers/platform/x86/msi-ec.c
@@ -823,6 +823,7 @@ static struct msi_ec_conf CONF9 __initdata = {
 
 static const char * const ALLOWED_FW_10[] __initconst = {
 	"1582EMS1.107", // GF66 11UC
+	"1583EMS1.109", // Pulse GL66 12UEK
 	NULL
 };
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] platform/x86: oxpec: add support for OneXPlayer Super X

[Sasha Levin]

From: Alexander Egorov <begeebe@gmail.com>

[ Upstream commit 0b6573e23acc7bca808e539e3edea49683f106de ]

OneXPlayer Super X identifies itself via DMI as:

  board vendor: ONE-NETBOOK
  board name:   ONEXPLAYER SUPER X
  product name: ONEXPLAYER SUPER X

Current mainline oxpec does not contain a matching DMI entry for this
system, so the in-tree driver is not auto-loaded.

The tested Super X fan, PWM, turbo-toggle, and battery charge-control EC
layout matches the existing ONEXPLAYER G1 A handling.

Add a DMI match for OneXPlayer Super X and reuse the oxp_g1_a board data.

Reviewed-by: Derek J Clark <derekjohn.clark@gmail.com>
Reviewed-by: Antheas Kapenekakis <lkml@antheas.dev>
Signed-off-by: Alexander Egorov <begeebe@gmail.com>
Link: https://patch.msgid.link/20260519155124.3240359-1-begeebe@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:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject Line
**Record:** `[platform/x86: oxpec]` `[add]` — Add DMI match so the
existing oxpec driver auto-loads on OneXPlayer Super X hardware.

### Step 1.2: Tags
**Record:**
- **Reviewed-by:** Derek J. Clark, Antheas Kapenekakis, Ilpo Järvinen
  (subsystem maintainer)
- **Signed-off-by:** Alexander Egorov (author), Ilpo Järvinen
  (maintainer commit)
- **Link:**
  https://patch.msgid.link/20260519155124.3240359-1-begeebe@gmail.com
- No Fixes:, Reported-by:, Tested-by:, Cc: stable@vger.kernel.org, or
  syzbot tags
- Notable: Three Reviewed-by lines including the x86 platform maintainer
  — strong review signal

### Step 1.3: Body Analysis
**Record:**
- **Bug:** OneXPlayer Super X reports DMI `ONE-NETBOOK` / `ONEXPLAYER
  SUPER X`, but no matching `dmi_table` entry exists, so
  `oxp_platform_init()` returns `-ENODEV` and the driver never loads.
- **Symptom:** No fan control (PWM/hwmon), no turbo-toggle sysfs, no
  battery charge-control EC features on Super X.
- **Root cause:** Missing DMI quirk entry; EC layout matches existing
  `oxp_g1_a` profile.
- **Version info:** None stated; hardware is a new OneXPlayer variant.

### Step 1.4: Hidden Bug Fix?
**Record:** Not disguised — this is explicit hardware enablement.
Functionally it fixes “driver doesn’t bind on this machine,” which is a
real usability defect for Super X owners, though not a crash or security
issue.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/platform/x86/oxpec.c` only (+7 lines)
- **Functions modified:** `dmi_table[]` static data only; no function
  logic changed
- **Scope:** Single-file, surgical DMI table addition

### Step 2.2: Code Flow Change
**Record:**
- **Before:** `dmi_first_match(dmi_table)` fails for Super X →
  `oxp_platform_init()` returns `-ENODEV` → no platform device, no
  hwmon/battery EC sysfs.
- **After:** Super X matches new entry → `board = oxp_g1_a` → driver
  probes and exposes fan PWM, turbo toggle, charge control identical to
  G1 A.
- **Path affected:** Module init / DMI matching only (normal boot path
  for matching hardware).

### Step 2.3: Bug Mechanism
**Record:** **Hardware workaround / DMI quirk** — same category as
PCI/USB ID additions. Missing DMI match prevents driver binding on
known-compatible hardware.

### Step 2.4: Fix Quality
**Record:** Obviously correct — reuses tested `oxp_g1_a` board data per
author hardware validation. Minimal diff, no logic changes. Regression
risk: very low (only affects machines with exact DMI string `ONEXPLAYER
SUPER X`).

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** Adjacent G1 A entry introduced in `b369395c895bf` (“Add
support for the OneXPlayer G1”, Apr 2025); `driver_data = oxp_g1_a` set
in `232b41d3c2ce8` (Jul 2025). G1 A support is an ancestor of HEAD and
present in `v6.18`.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag.

### Step 3.3: Related File History
**Record:** Recent oxpec DMI additions already backported to this 6.18.y
tree:
- `43c40bfb85038` — OneXPlayer APEX
- `1faaa81aabab7` — OneXPlayer X1z
- `ba6af12e600bf` — Aokzoe A2 Pro
- `0a4e44eb4b0c1` — OneXPlayer X1 Air (committed by Greg K-H with
  upstream marker)

Same pattern, same file, same driver. Standalone one-commit change.

### Step 3.4: Author Context
**Record:** Alexander Egorov authored this patch; Antheas Kapenekakis is
the primary oxpec maintainer (authored most recent device additions).
Ilpo Järvinen is x86 platform maintainer and committed the patch.

### Step 3.5: Dependencies
**Record:** Requires `oxp_g1_a` enum and its EC handling — **present in
this tree** since v6.18. No other commits needed. Patch inserts cleanly
between G1 A and G1 i entries.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:** `b4 dig -c <commit>` not possible — commit is not in local
tree. Lore/patch.msgid.link fetch blocked (Anubis bot protection).
**UNVERIFIED:** full mailing-list thread content and any explicit stable
nominations in replies.

### Step 4.2: Reviewers
**Record:** From commit message — Derek J. Clark (oxpec co-maintainer),
Antheas Kapenekakis (oxpec maintainer), Ilpo Järvinen (x86 platform
maintainer). Appropriate reviewers CC’d per commit metadata.

### Step 4.3: Bug Report
**Record:** N/A — no Reported-by or external bug link beyond patch
submission.

### Step 4.4: Related Patches
**Record:** Standalone; not part of a multi-patch series. Same class as
other oxpec DMI additions already in 6.18.y.

### Step 4.5: Stable List History
**Record:** **UNVERIFIED** (lore blocked). However, four analogous oxpec
DMI additions are already in `v6.18..v6.18.44`, establishing precedent
in this tree.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** Only `dmi_table[]` modified. Relevant init path:
`oxp_platform_init()` → `dmi_first_match()` →
`platform_create_bundle()`.

### Step 5.2: Callers
**Record:** `oxp_platform_init()` is `module_init` — runs at module load
/ built-in init. Affects every boot on matching DMI hardware when
`CONFIG_OXP_EC` is enabled.

### Step 5.3: Callees
**Record:** `dmi_first_match()`, `platform_create_bundle()`,
`oxp_platform_probe()` — standard platform driver init. `oxp_g1_a` path
uses existing `read_from_ec`/`write_to_ec` for fan, turbo, battery.

### Step 5.4: Reachability
**Record:** Triggered automatically at boot on OneXPlayer Super X with
`CONFIG_OXP_EC=y/m`. No userspace syscall needed; affects all Super X
users on this kernel.

### Step 5.5: Similar Patterns
**Record:** Nine+ prior DMI entries in same table for other
OneXPlayer/AOKZOE models; four similar additions already backported to
6.18.y.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Present?
**Record:** **YES.** Local tree is **v6.18.44**.
`drivers/platform/x86/oxpec.c` exists with `oxp_g1_a` and G1 A DMI
entry, but **no** `ONEXPLAYER SUPER X` entry (verified by grep and
reading lines 267–280). Super X owners on 6.18.44 get no oxpec support.

### Step 6.2: Backport Complications
**Record:** **Clean apply expected** — 7-line insertion between existing
G1 A and G1 i blocks; no structural divergence in that region.

### Step 6.3: Related Fixes Already Present?
**Record:** G1 A support (`b369395c895bf`) and G1 AMD turbo fix
(`232b41d3c2ce8`) already in tree. Super X fix not present.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem Criticality
**Record:** `drivers/platform/x86/` — **PERIPHERAL** (handheld gaming
device EC driver). Important to Super X users; not core kernel.

### Step 7.2: Activity
**Record:** Actively maintained — four oxpec DMI additions backported to
6.18.y in the last few months.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** OneXPlayer Super X owners running Linux 6.18.y with
`CONFIG_OXP_EC` enabled (typical on distro kernels for x86 handhelds).

### Step 8.2: Trigger Conditions
**Record:** Every boot on matching hardware. Common for device owners;
not timing-dependent.

### Step 8.3: Failure Mode Severity
**Record:** Missing fan control, turbo management, and battery charge
limiting — **MEDIUM** (no crash/corruption, but degraded hardware
management and potential thermal/battery issues without manual
workarounds).

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Enables full EC platform support on a shipping device;
  consistent with prior oxpec stable backports.
- **Risk:** Very low — 7-line DMI entry, exact string match, reuses
  validated board profile.
- **Ratio:** Favorable; matches established 6.18.y policy for this
  driver.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Trivial DMI quirk addition (stable exception category: device ID /
  hardware quirk)
- Fixes real user-visible problem (driver won’t load)
- Hardware-tested; three Reviewed-by including maintainer
- Prerequisites (`oxp_g1_a`) present since v6.18
- Four analogous oxpec DMI patches already in 6.18.y
- Clean, minimal diff

**AGAINST backport:**
- Not a crash, security, or data-corruption fix
- Only affects one specific handheld model
- Mailing-list stable nomination not verified

**UNRESOLVED:**
- Full lore thread content and any explicit Cc: stable discussion

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — reuses G1 A profile,
   hardware-tested, maintainer-reviewed
2. Fixes real bug affecting users? **PASS** — driver fails to bind; EC
   features unavailable
3. Important issue? **PASS** (moderate) — hardware management broken for
   device owners; aligns with stable’s device-ID exception
4. Small and contained? **PASS** — 7 lines, one file
5. No new features/APIs? **PASS** — no new APIs; enables existing driver
   on new DMI
6. Can apply to local tree? **PASS** — prerequisites present, clean
   insert

### Step 9.3: Exception Category
**Record:** Hardware quirk / DMI ID addition to existing driver (stable
exception #1 and #2).

### Step 9.4: Decision Rationale

For **Linux 6.18.44** (this checkout): the oxpec driver and `oxp_g1_a`
board profile already exist, but Super X is not matched, so owners lack
fan control, turbo toggle, and battery charge management. The fix is a
7-line DMI entry reusing validated board data — the same pattern already
accepted four times in this 6.18.y series. Risk is negligible; benefit
is concrete for Super X users.

---

## Verification

- **[Phase 1]** Parsed commit message, tags, and body from user-provided
  diff
- **[Phase 2]** Diff analysis: +7 lines in `dmi_table[]`, no function
  logic changed
- **[Phase 3]** `git describe HEAD` → v6.18.44; `make kernelversion`
  equivalent → 6.18.44
- **[Phase 3]** `git log --oneline -20 -- drivers/platform/x86/oxpec.c`
  → recent oxpec history
- **[Phase 3]** `git blame -L 267,273` → G1 A entry from
  `b369395c895bf`, `oxp_g1_a` from `232b41d3c2ce8`
- **[Phase 3]** `git merge-base --is-ancestor b369395c895bf HEAD` → G1
  support is ancestor
- **[Phase 3]** `git merge-base --is-ancestor b369395c895bf v6.18` → G1
  support in v6.18 base
- **[Phase 3]** `git log v6.18..v6.18.44 --oneline --
  drivers/platform/x86/oxpec.c` → 4 prior DMI backports
- **[Phase 3]** `git show 0a4e44eb4b0c1` → X1 Air backport by Greg K-H
  with upstream marker
- **[Phase 4]** `b4 dig` → requires commit in tree; not runnable for
  candidate commit
- **[Phase 4]** WebFetch lore/patch.msgid.link → blocked by Anubis;
  thread content UNVERIFIED
- **[Phase 5]** Read `oxp_platform_init()` at lines 1076–1099 →
  `-ENODEV` when DMI unmatched
- **[Phase 5]** Read `oxp_g1_a` usage in turbo/PWM/battery paths →
  existing handling confirmed
- **[Phase 6]** Grep for `ONEXPLAYER SUPER X` → not present in tree
  (only unrelated eisa.ids match)
- **[Phase 6]** Read `drivers/platform/x86/oxpec.c` lines 267–280 → G1 A
  present, Super X absent
- **[Phase 6]** `git show v6.18:drivers/platform/x86/oxpec.c | grep -c
  "ONEXPLAYER G1 A"` → 1 (G1 A in v6.18)
- **[Phase 7]** Kconfig `OXP_EC` at line 1025 → driver exists, depends
  on ACPI_EC/ACPI_BATTERY/HWMON/X86

**YES**

 drivers/platform/x86/oxpec.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/oxpec.c b/drivers/platform/x86/oxpec.c
index a30845ba37969..56df03cd195fd 100644
--- a/drivers/platform/x86/oxpec.c
+++ b/drivers/platform/x86/oxpec.c
@@ -271,6 +271,13 @@ static const struct dmi_system_id dmi_table[] = {
 		},
 		.driver_data = (void *)oxp_g1_a,
 	},
+	{
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "ONE-NETBOOK"),
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "ONEXPLAYER SUPER X"),
+		},
+		.driver_data = (void *)oxp_g1_a,
+	},
 	{
 		.matches = {
 			DMI_MATCH(DMI_BOARD_VENDOR, "ONE-NETBOOK"),
-- 
2.53.0