[PATCH AUTOSEL 7.0-6.19] hwmon: (nct6775) Add ASUS X870/W480 to WMI monitoring list

[PATCH AUTOSEL 7.0-6.19] hwmon: (nct6775) Add ASUS X870/W480 to WMI monitoring list

[Sasha Levin]

From: Denis Pauk <pauk.denis@gmail.com>

[ Upstream commit 21518579cbdeb4e86a6fffbc3d52f52bd74ab87e ]

Boards such as
* G15CE,
* PRIME X870-P WIFI,
* PRIME X870-P,
* Pro WS W480-ACE,
* ProArt X870E-CREATOR WIFI,
* ROG CROSSHAIR X870E APEX,
* ROG CROSSHAIR X870E DARK HERO,
* ROG CROSSHAIR X870E EXTREME,
* ROG CROSSHAIR X870E GLACIAL,
* ROG CROSSHAIR X870E HERO BTF,
* ROG CROSSHAIR X870E HERO,
* ROG STRIX X870-A GAMING WIFI,
* ROG STRIX X870-F GAMING WIFI,
* ROG STRIX X870-I GAMING WIFI,
* ROG STRIX X870E-E GAMING WIFI,
* ROG STRIX X870E-E GAMING WIFI7 R2,
* TUF GAMING X870-PLUS WIFI,
* TUF GAMING X870-PRO WIFI7 W NEO,
* TUF GAMING X870E-PLUS WIFI7,
* W480/SYS,
* X870 AYW GAMING WIFI W,
* X870 MAX GAMING WIFI7 W,
* X870 MAX GAMING WIFI7
have got a nct6775 chip, but by default there's no use of it because of
resource conflict with WMI method.

Add the boards to the WMI monitoring list.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Tested-by: Tomáš Bžatek <bugs@bzatek.net>
Tested-by: Theunis Scheepers <ptscheepers@gmail.com>
Link: https://lore.kernel.org/r/20260322131848.6261-1-pauk.denis@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile my findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `hwmon: (nct6775)`
- Action verb: "Add" — adding board names to whitelist
- Summary: Add 23 ASUS X870 and W480 motherboard names to the WMI
  monitoring board lists

**Step 1.2: Tags**
- `Link: https://bugzilla.kernel.org/show_bug.cgi?id=204807` — long-
  running bug tracking nct6775 WMI access on ASUS boards
- `Signed-off-by: Denis Pauk <pauk.denis@gmail.com>` — author, primary
  maintainer of this WMI board list
- `Tested-by: Tomáš Bžatek <bugs@bzatek.net>` — independent tester
- `Tested-by: Theunis Scheepers <ptscheepers@gmail.com>` — second
  independent tester
- `Link:
  https://lore.kernel.org/r/20260322131848.6261-1-pauk.denis@gmail.com`
  — lore thread
- `Signed-off-by: Guenter Roeck <linux@roeck-us.net>` — hwmon subsystem
  maintainer

Record: Two independent testers, hwmon maintainer sign-off, bug tracker
reference. Strong quality signals.

**Step 1.3: Body Text**
The commit explains that these ASUS boards have nct6775-compatible chips
but "by default there's no use of it because of resource conflict with
WMI method." Without the board name in the whitelist, the driver can't
use WMI to access the hardware monitoring chip, so users get zero sensor
data.

Record: Bug = no hardware monitoring on popular boards due to ACPI/WMI
resource conflict. Symptom = sensors completely unavailable.

**Step 1.4: Hidden Bug Fix Detection**
This is not a hidden bug fix — it's explicitly an enablement for
hardware that is inaccessible without the whitelist entry. This falls
squarely in the "hardware quirk/workaround" exception category.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files changed: 1 (`drivers/hwmon/nct6775-platform.c`)
- Lines added: ~23 string entries across two `const char *` arrays
- Lines removed: 0
- Functions modified: 0 — only data arrays changed
- Scope: Pure data addition, single file, no logic changes

**Step 2.2: Code Flow Change**
- `asus_wmi_boards[]`: 2 entries added ("Pro WS W480-ACE", "W480/SYS")
- `asus_msi_boards[]`: ~21 entries added (G15CE, various X870 boards,
  ProArt X870E, ROG CROSSHAIR X870E variants, ROG STRIX X870 variants,
  TUF GAMING X870 variants, X870 AYW/MAX variants)
- Both arrays are used in `sensors_nct6775_platform_init()` via
  `match_string()` to determine whether WMI access should be used
  instead of direct I/O port access.
- No control flow, no error handling, no locking changes.

**Step 2.3: Bug Mechanism**
Category: Hardware workaround / device ID addition. Board names are
added to static `const` whitelist arrays. When the board DMI name
matches an entry, the driver uses WMI to access the nct6775 chip instead
of direct I/O (which is blocked by ACPI resource claims).

**Step 2.4: Fix Quality**
- Obviously correct: string literals added in alphabetical order to
  const arrays
- Minimal/surgical: only data, zero logic
- Regression risk: zero — adding new strings cannot affect behavior for
  existing boards
- No red flags whatsoever

---

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The `asus_wmi_boards[]` array originates from commit c3963bc0a0cf9
(v5.19-rc1, platform split). The `asus_msi_boards[]` array originates
from commit e2e09989ccc21 (v6.3-rc1). Both have been incrementally
expanded with each new board generation, with ~20 prior similar commits
by Denis Pauk and others.

**Step 3.2: Fixes tag**
No Fixes: tag (expected for this type of commit — it's an enablement,
not a code fix).

**Step 3.3: File History**
20+ prior commits adding board names to these arrays. This is a well-
established, routine pattern. Recent commits include:
- 246167b17c14e: Add ASUS Pro WS WRX90E-SAGE SE
- 03897f9baf3ee: Add ASUS ROG STRIX X870E-H GAMING WIFI7
- ccae49e5cf6eb: Add 665-ACE/600M-CL
- 1f432e4cf1dd3: Add G15CF

**Step 3.4: Author**
Denis Pauk is the primary author of the WMI access support and has
authored the vast majority of board list additions (12+ commits). He is
the de facto maintainer of this feature.

**Step 3.5: Dependencies**
No dependencies. The commit is a pure addition of string constants. No
new functions, no API changes, no prerequisite commits needed.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.2: Patch Discussion**
The lore.kernel.org and bugzilla sites were behind anti-bot protection;
however, web search confirmed:
- Bug 204807 is a long-running tracker (since ~2019) for ASUS boards
  where nct6775 sensors don't work without `acpi_enforce_resources=lax`
- The WMI access method was the proper fix, implemented in v5.16
- Board lists are updated as new ASUS models are released
- Guenter Roeck (hwmon maintainer) reviewed and applied

**Step 4.3: Bug Report**
Bugzilla #204807 is a well-documented, long-standing issue affecting
many ASUS users. The commit message and two Tested-by tags confirm real
users need this.

**Step 4.4-4.5: Related Patches**
This is a standalone patch — no series dependencies. Previous identical-
pattern patches have been applied regularly.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Function Impact**
The modified arrays are referenced only in
`sensors_nct6775_platform_init()` (lines 1521-1531) via
`match_string()`. The call chain is:
1. `module_init(sensors_nct6775_platform_init)` — called once at driver
   load
2. DMI board name is compared against whitelist
3. If match, `nct6775_determine_access()` is called to probe WMI method
4. If WMI works, sensor access uses WMI instead of direct I/O

The change only adds new match targets. Existing matches are completely
unaffected.

**Step 5.5: Similar Patterns**
20+ identical pattern commits exist in the git history. This is routine
maintenance of a device whitelist.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code Existence**
- Both `asus_wmi_boards[]` and `asus_msi_boards[]` exist in the 7.0 tree
  (and 6.6.y, 6.12.y)
- The `asus_msi_boards[]` was introduced in v6.3, so it exists in 6.6.y
  and later
- For 6.1.y, only `asus_wmi_boards[]` entries would apply (2 entries)

**Step 6.2: Backport Complications**
Minimal. The patch adds strings in alphabetical order. The only context
dependency is the surrounding existing strings. The "ROG STRIX X870E-H
GAMING WIFI7" entry (03897f9baf3ee) is already in the 7.0 tree at line
1407, which provides a context anchor. The patch should apply cleanly or
with trivial offset adjustments.

**Step 6.3: Related Fixes Already in Stable**
No — these specific X870/W480 board names are not in any stable tree
yet.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
- Subsystem: `drivers/hwmon` — hardware monitoring
- Criticality: PERIPHERAL (but widely used — temperatures, fan speeds,
  voltages)
- Without this fix, users of these popular boards cannot monitor
  hardware health

**Step 7.2: Activity**
Active subsystem with regular board list updates. The file sees routine
additions every few months.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Users of 23 specific ASUS motherboard models. These are popular consumer
and workstation boards (X870 is current-gen AMD AM5 platform, W480 is
Intel workstation).

**Step 8.2: Trigger**
Every boot on affected hardware. Without this patch, the driver silently
falls back to direct I/O access, which fails due to ACPI resource
conflict, resulting in no sensor data at all.

**Step 8.3: Severity**
- Failure mode: Complete loss of hardware monitoring capability
- Severity: MEDIUM — no crash or data corruption, but hardware
  monitoring is a core system management feature

**Step 8.4: Risk-Benefit**
- BENEFIT: HIGH — enables hardware monitoring on popular current-gen
  motherboards for all stable users
- RISK: NEAR-ZERO — pure string additions to const arrays, cannot affect
  other boards, zero logic changes
- Ratio: Overwhelmingly favorable

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Classic hardware quirk/device ID addition pattern
- Zero logic changes — only const string array additions
- Two independent Tested-by tags
- hwmon maintainer (Guenter Roeck) signed off
- Fixes real issue for popular current-gen hardware
- Long-established pattern with 20+ identical prior commits
- References well-known bugzilla bug #204807
- No regression risk

AGAINST backporting:
- (None identified)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — string additions, two testers
2. Fixes a real bug? **YES** — hardware monitoring inaccessible on
   affected boards
3. Important issue? **MEDIUM** — not a crash, but total loss of hwmon on
   popular boards
4. Small and contained? **YES** — single file, pure data, ~23 lines of
   strings
5. No new features or APIs? **YES** — adds IDs to existing mechanism
6. Can apply to stable? **YES** — clean apply expected

**Step 9.3: Exception Category**
**YES** — This is a hardware quirk/workaround addition (board names to
existing WMI whitelist). This is explicitly listed as an exception that
IS allowed in stable.

---

## Verification

- [Phase 1] Parsed tags: found 2x Tested-by, Link to bugzilla #204807,
  maintainer SOB from Guenter Roeck
- [Phase 2] Diff analysis: ~23 string literals added to
  `asus_wmi_boards[]` (2 entries) and `asus_msi_boards[]` (21 entries),
  zero logic changes
- [Phase 3] git blame: `asus_wmi_boards[]` introduced in c3963bc0a0cf9
  (v5.19-rc1), `asus_msi_boards[]` in e2e09989ccc21 (v6.3-rc1)
- [Phase 3] git log: confirmed 20+ prior identical-pattern board
  addition commits by Denis Pauk
- [Phase 3] Author Denis Pauk: confirmed as primary maintainer of this
  WMI board list feature (12+ commits)
- [Phase 4] WebSearch: confirmed bugzilla #204807 is long-running
  tracker for ASUS nct6775 WMI access issues
- [Phase 4] b4 dig/lore: anti-bot protection prevented direct thread
  access, but maintainer sign-off and metadata verified
- [Phase 5] Code trace: arrays used only in
  `sensors_nct6775_platform_init()` via `match_string()`, single
  callsite
- [Phase 6] Both arrays exist in 7.0 tree, `asus_msi_boards[]` exists in
  6.6.y+
- [Phase 6] "ROG STRIX X870E-H GAMING WIFI7" already present at line
  1407, confirming context compatibility
- [Phase 8] Failure mode: complete loss of hardware monitoring on
  affected boards, severity MEDIUM
- [Phase 8] Risk: near-zero — pure const data addition

**YES**

 drivers/hwmon/nct6775-platform.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/hwmon/nct6775-platform.c b/drivers/hwmon/nct6775-platform.c
index 555029dfe713f..1975399ac440d 100644
--- a/drivers/hwmon/nct6775-platform.c
+++ b/drivers/hwmon/nct6775-platform.c
@@ -1159,6 +1159,7 @@ static const char * const asus_wmi_boards[] = {
 	"Pro A520M-C",
 	"Pro A520M-C II",
 	"Pro B550M-C",
+	"Pro WS W480-ACE",
 	"Pro WS X570-ACE",
 	"ProArt B550-CREATOR",
 	"ProArt X570-CREATOR WIFI",
@@ -1258,6 +1259,7 @@ static const char * const asus_wmi_boards[] = {
 	"TUF Z390-PRO GAMING",
 	"TUF Z390M-PRO GAMING",
 	"TUF Z390M-PRO GAMING (WI-FI)",
+	"W480/SYS",
 	"WS Z390 PRO",
 	"Z490-GUNDAM (WI-FI)",
 };
@@ -1270,6 +1272,7 @@ static const char * const asus_msi_boards[] = {
 	"EX-B760M-V5 D4",
 	"EX-H510M-V3",
 	"EX-H610M-V3 D4",
+	"G15CE",
 	"G15CF",
 	"PRIME A620M-A",
 	"PRIME B560-PLUS",
@@ -1320,6 +1323,8 @@ static const char * const asus_msi_boards[] = {
 	"PRIME X670-P",
 	"PRIME X670-P WIFI",
 	"PRIME X670E-PRO WIFI",
+	"PRIME X870-P",
+	"PRIME X870-P WIFI",
 	"PRIME Z590-A",
 	"PRIME Z590-P",
 	"PRIME Z590-P WIFI",
@@ -1362,11 +1367,18 @@ static const char * const asus_msi_boards[] = {
 	"ProArt B660-CREATOR D4",
 	"ProArt B760-CREATOR D4",
 	"ProArt X670E-CREATOR WIFI",
+	"ProArt X870E-CREATOR WIFI",
 	"ProArt Z690-CREATOR WIFI",
 	"ProArt Z790-CREATOR WIFI",
 	"ROG CROSSHAIR X670E EXTREME",
 	"ROG CROSSHAIR X670E GENE",
 	"ROG CROSSHAIR X670E HERO",
+	"ROG CROSSHAIR X870E APEX",
+	"ROG CROSSHAIR X870E DARK HERO",
+	"ROG CROSSHAIR X870E EXTREME",
+	"ROG CROSSHAIR X870E GLACIAL",
+	"ROG CROSSHAIR X870E HERO",
+	"ROG CROSSHAIR X870E HERO BTF",
 	"ROG MAXIMUS XIII APEX",
 	"ROG MAXIMUS XIII EXTREME",
 	"ROG MAXIMUS XIII EXTREME GLACIAL",
@@ -1404,6 +1416,11 @@ static const char * const asus_msi_boards[] = {
 	"ROG STRIX X670E-E GAMING WIFI",
 	"ROG STRIX X670E-F GAMING WIFI",
 	"ROG STRIX X670E-I GAMING WIFI",
+	"ROG STRIX X870-A GAMING WIFI",
+	"ROG STRIX X870-F GAMING WIFI",
+	"ROG STRIX X870-I GAMING WIFI",
+	"ROG STRIX X870E-E GAMING WIFI",
+	"ROG STRIX X870E-E GAMING WIFI7 R2",
 	"ROG STRIX X870E-H GAMING WIFI7",
 	"ROG STRIX Z590-A GAMING WIFI",
 	"ROG STRIX Z590-A GAMING WIFI II",
@@ -1451,6 +1468,9 @@ static const char * const asus_msi_boards[] = {
 	"TUF GAMING H770-PRO WIFI",
 	"TUF GAMING X670E-PLUS",
 	"TUF GAMING X670E-PLUS WIFI",
+	"TUF GAMING X870-PLUS WIFI",
+	"TUF GAMING X870-PRO WIFI7 W NEO",
+	"TUF GAMING X870E-PLUS WIFI7",
 	"TUF GAMING Z590-PLUS",
 	"TUF GAMING Z590-PLUS WIFI",
 	"TUF GAMING Z690-PLUS",
@@ -1460,6 +1480,9 @@ static const char * const asus_msi_boards[] = {
 	"TUF GAMING Z790-PLUS D4",
 	"TUF GAMING Z790-PLUS WIFI",
 	"TUF GAMING Z790-PLUS WIFI D4",
+	"X870 AYW GAMING WIFI W",
+	"X870 MAX GAMING WIFI7",
+	"X870 MAX GAMING WIFI7 W",
 	"Z590 WIFI GUNDAM EDITION",
 };
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] hwmon: (asus-ec-sensors )add ROG CROSSHAIR X670E EXTREME

[Sasha Levin]

From: "Timothy C. Sweeney-Fanelli" <tim@zerobytellc.com>

[ Upstream commit ab4b7071ae0a831e4c2fd45c626c3b1d66cc1201 ]

Add support for ROG CROSSHAIR X670E EXTREME

Signed-off-by: Timothy C. Sweeney-Fanelli <tim@zerobytellc.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20260215151743.20138-3-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `hwmon: (asus-ec-sensors)`
- Action verb: `add`
- Summary: Add board support for ROG CROSSHAIR X670E EXTREME motherboard

Record: [hwmon/asus-ec-sensors] [add] [New motherboard board definition
for ROG CROSSHAIR X670E EXTREME]

**Step 1.2: Tags**
- `Signed-off-by: Timothy C. Sweeney-Fanelli <tim@zerobytellc.com>` —
  original contributor/tester of the board info
- `Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>` — driver
  maintainer who curates submissions
- `Link: https://lore.kernel.org/r/20260215151743.20138-3-
  eugene.shalygin@gmail.com` — patch 3 of a series
- `Signed-off-by: Guenter Roeck <linux@roeck-us.net>` — hwmon subsystem
  maintainer who merged it

Record: No Fixes tag (expected for a board addition). No Reported-by,
Cc: stable, or syzbot. The patch went through the driver author
(Shalygin) and hwmon maintainer (Roeck). This is patch 3 of a series.

**Step 1.3: Commit Body**
The body simply says "Add support for ROG CROSSHAIR X670E EXTREME." No
bug description, stack traces, or failure modes — this is a hardware
enablement commit.

Record: No bug is described; this is a hardware support addition for a
specific ASUS motherboard model.

**Step 1.4: Hidden Bug Fix Detection**
This is not a hidden bug fix. It's a straightforward board ID / sensor
configuration addition to enable hwmon sensor monitoring on a new
motherboard.

Record: Not a hidden bug fix. Pure hardware enablement.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- `Documentation/hwmon/asus_ec_sensors.rst`: +1 line (adds board name to
  supported list)
- `drivers/hwmon/asus-ec-sensors.c`: +11 lines (9-line board_info struct
  + 2-line DMI table entry)
- Total: ~12 lines added, 0 removed
- Functions modified: None. Only static const data structures added.

Record: 2 files, +12 lines, 0 lines removed. Only adds static const data
(board_info struct and DMI match entry). Scope: single-file surgical
addition.

**Step 2.2: Code Flow**
- Hunk 1 (board_info): Adds `board_info_crosshair_x670e_extreme` struct
  with temperature sensors (CPU, CPU Package, MB, VRM, T_Sensor,
  Water_In, Water_Out), mutex path
  `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0`, and
  `family_amd_600_series`.
- Hunk 2 (DMI table): Adds a `DMI_EXACT_MATCH_ASUS_BOARD_NAME` entry
  linking the board name to the new struct.
- Before: The board was not recognized; driver wouldn't probe on this
  motherboard.
- After: The board is recognized and the defined sensors are exposed via
  hwmon.

**Step 2.3: Bug Mechanism**
Category: Hardware workaround / device ID addition. No bug fix. The new
struct uses existing sensor macros, an existing mutex path (verified at
7 other locations), and an existing family (`family_amd_600_series`).
The sensor table `sensors_family_amd_600[]` (line 275) includes all the
sensors referenced: `ec_sensor_temp_cpu`, `ec_sensor_temp_cpu_package`,
`ec_sensor_temp_mb`, `ec_sensor_temp_vrm`, `ec_sensor_temp_t_sensor`,
`ec_sensor_temp_water_in`, `ec_sensor_temp_water_out`.

Record: This is a hardware enablement (new board ID) addition. All
referenced sensors, mutex path, and family exist in the codebase.

**Step 2.4: Fix Quality**
- Obviously correct: Yes — follows the exact same pattern as dozens of
  other board entries
- Minimal/surgical: Yes — 12 lines of purely static data
- Regression risk: Essentially zero — the new DMI match only triggers on
  the exact board name "ROG CROSSHAIR X670E EXTREME". Cannot affect any
  other board.

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The code this is inserted adjacent to
(`board_info_crosshair_viii_impact` and
`board_info_crosshair_x670e_gene`) has been present since 2022-2023. The
AMD 600 series family support was introduced in commit 790dec13c0128
(April 2023), and is present in all stable trees since ~v6.5+.

**Step 3.2: Fixes Tag**
No Fixes: tag present (expected — this is not a bug fix, it's a new
board addition).

**Step 3.3: File History**
The file has 65+ commits since the driver was introduced (d0ddfd241e571,
Jan 2022). The vast majority are board additions just like this one.
Eugene Shalygin is the driver author/maintainer and has authored nearly
all of them.

**Step 3.4: Author**
Eugene Shalygin is the original author and maintainer of the asus-ec-
sensors driver (copyright 2021, authored 40+ commits). Timothy Sweeney-
Fanelli is the board owner who contributed the sensor data.

**Step 3.5: Dependencies**
No dependencies. All referenced constants (`SENSOR_TEMP_CPU`,
`SENSOR_TEMP_WATER_IN`, `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0`,
`family_amd_600_series`) already exist in the 7.0 stable tree. This is a
standalone addition.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.5:**
The Link: tag indicates this is patch 3 of a series
(20260215151743.20138-3). Lore.kernel.org is behind Anubis protection
and cannot be fetched. However, b4 dig confirmed similar patches from
the same author are findable. The patch was accepted by hwmon maintainer
Guenter Roeck, the standard pathway for all asus-ec-sensors changes.

Record: Could not access lore due to Anubis bot protection. The patch
followed the standard hwmon submission path (contributor -> driver
author -> Guenter Roeck).

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.5:**
No functions are modified. The change adds only static const data
structures. The DMI matching framework (`dmi_table[]`) is used during
module probe. When the DMI system matches the board name, the driver
reads sensors from EC registers at the offsets defined in
`sensors_family_amd_600[]`. This is a purely data-driven mechanism — no
code path changes.

Record: No code flow changes. Only static data additions. The DMI match
→ board_info → sensor table pipeline is well-established and works
identically for all 40+ supported boards.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:**
The driver exists since v5.18 (d0ddfd241e571, Jan 2022). AMD 600 series
support exists since v6.5 (790dec13c0128, Apr 2023). The
`ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0` mutex path and all sensor
macros exist in 7.0.

**Step 6.2:**
The patch should apply cleanly. It's a pure addition between existing
entries in two sorted lists (board_info structs and DMI table). No
conflicts expected.

**Step 6.3:**
No related fix needed — this board has never been supported before.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:**
Subsystem: hwmon (hardware monitoring). Criticality: PERIPHERAL —
affects only users of this specific ASUS motherboard. However, hwmon
sensor monitoring is important for users who rely on temperature/fan
monitoring for system health.

**Step 7.2:**
The driver is actively maintained with 65+ commits, mostly board
additions from the original author.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected users: only owners of the ROG CROSSHAIR X670E
EXTREME motherboard.

**Step 8.2:** Trigger: automatic during driver probe if the DMI board
name matches.

**Step 8.3:** Failure mode without fix: no hwmon sensor data available
for this board. Users cannot monitor CPU/VRM temperatures, water cooling
temps, etc. through the standard hwmon interface.

**Step 8.4:**
- Benefit: LOW-MEDIUM — enables hardware monitoring for a specific
  popular enthusiast motherboard
- Risk: VERY LOW — 12 lines of static const data, cannot affect any
  other board
- Ratio: Favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Falls squarely into the "new device ID / board addition" exception
  category
- Trivially small (12 lines of static const data)
- Zero regression risk (only triggers on exact DMI board name match)
- All infrastructure (AMD 600 series sensors, mutex path) already exists
  in stable
- Authored by the driver maintainer, accepted by the hwmon subsystem
  maintainer
- Follows identical pattern to dozens of prior board additions

**Evidence AGAINST backporting:**
- This is not a bug fix — it's hardware enablement
- Affects only one specific motherboard model
- No Cc: stable tag (but this is expected for board additions needing
  manual review)

**Stable rules checklist:**
1. Obviously correct? YES — identical pattern to 40+ other entries
2. Fixes a real bug? NO — but falls into the device ID exception
3. Important issue? NO — but enables real hardware for real users
4. Small and contained? YES — 12 lines, static data only
5. No new features/APIs? YES — no new interfaces, just enables existing
   driver on new hardware
6. Can apply to stable? YES — clean apply expected

**Verification:**
- [Phase 1] Parsed tags: SOBs from Timothy Sweeney-Fanelli
  (contributor), Eugene Shalygin (driver author), Guenter Roeck (hwmon
  maintainer). Link to lore present.
- [Phase 2] Diff: +12 lines across 2 files. Only static const board_info
  struct and DMI table entry added. No code logic changes.
- [Phase 3] git log: Eugene Shalygin authored 40+ commits to this file,
  is the original driver author (copyright 2021).
- [Phase 3] git log: AMD 600 series support introduced in 790dec13c0128
  (April 2023), present in 7.0 tree.
- [Phase 3] Verified `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0` used
  by 7 other boards (lines 567, 673, 687, 694, 702, 710, 777).
- [Phase 3] Verified all sensor macros used (`SENSOR_TEMP_CPU`,
  `SENSOR_TEMP_CPU_PACKAGE`, `SENSOR_TEMP_MB`, `SENSOR_TEMP_VRM`,
  `SENSOR_TEMP_T_SENSOR`, `SENSOR_TEMP_WATER_IN`,
  `SENSOR_TEMP_WATER_OUT`) exist in `sensors_family_amd_600[]` (lines
  275-293).
- [Phase 4] Lore inaccessible due to Anubis protection; b4 dig could not
  find the commit directly (likely not yet in tree). The submission path
  (contributor -> driver author -> Guenter Roeck) is standard.
- [Phase 5] No functions modified. Only static const data. Zero code
  path impact.
- [Phase 6] Driver and AMD 600 series support exist in 7.0 tree. Clean
  apply expected.
- [Phase 8] Risk: VERY LOW (static data only, DMI-scoped). Benefit:
  enables hwmon on a specific board.

This is a textbook new board ID addition to an existing driver — one of
the explicitly allowed exception categories for stable backporting. It's
trivially small, uses only existing infrastructure, and cannot regress
any other system.

**YES**

 Documentation/hwmon/asus_ec_sensors.rst |  1 +
 drivers/hwmon/asus-ec-sensors.c         | 11 +++++++++++
 2 files changed, 12 insertions(+)

diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index 58986546c7233..8a080a786abd2 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -22,6 +22,7 @@ Supported boards:
  * ROG CROSSHAIR VIII FORMULA
  * ROG CROSSHAIR VIII HERO
  * ROG CROSSHAIR VIII IMPACT
+ * ROG CROSSHAIR X670E EXTREME
  * ROG CROSSHAIR X670E HERO
  * ROG CROSSHAIR X670E GENE
  * ROG MAXIMUS X HERO
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index adedaf0db10e6..934e37738a516 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -456,6 +456,15 @@ static const struct ec_board_info board_info_crosshair_viii_impact = {
 	.family = family_amd_500_series,
 };
 
+static const struct ec_board_info board_info_crosshair_x670e_extreme = {
+	.sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
+		SENSOR_TEMP_MB | SENSOR_TEMP_VRM |
+		SENSOR_TEMP_T_SENSOR | SENSOR_TEMP_WATER_IN |
+		SENSOR_TEMP_WATER_OUT,
+	.mutex_path = ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0,
+	.family = family_amd_600_series,
+};
+
 static const struct ec_board_info board_info_crosshair_x670e_gene = {
 	.sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
 		SENSOR_TEMP_T_SENSOR |
@@ -825,6 +834,8 @@ static const struct dmi_system_id dmi_table[] = {
 					&board_info_crosshair_viii_hero),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR VIII IMPACT",
 					&board_info_crosshair_viii_impact),
+	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR X670E EXTREME",
+					&board_info_crosshair_x670e_extreme),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR X670E GENE",
 					&board_info_crosshair_x670e_gene),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR X670E HERO",
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] hwmon: (gpd-fan) Add GPD Win 5

[Sasha Levin]

From: Antheas Kapenekakis <lkml@antheas.dev>

[ Upstream commit 4853b53264869e51378cad7bf1556d4e8049d445 ]

The GPD Win 5 is a new device by GPD with an AMD AI MAX 385/395 chip.
It uses the same fan control registers as the GPD Win Duo. This
information was provided by GPD.

Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20260220161601.2344291-1-lkml@antheas.dev
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `hwmon: (gpd-fan)`
- Action verb: "Add" — adding a new device entry
- Summary: Adding DMI match for GPD Win 5 handheld device to the gpd-fan
  hwmon driver
- Record: [hwmon/gpd-fan] [Add] [New DMI entry for GPD Win 5 device]

**Step 1.2: Tags**
- `Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>` — the author,
  a GPD/handheld Linux contributor
- `Link:
  https://lore.kernel.org/r/20260220161601.2344291-1-lkml@antheas.dev` —
  original submission
- `Signed-off-by: Guenter Roeck <linux@roeck-us.net>` — the hwmon
  subsystem maintainer accepted the patch
- No Fixes: tag (expected for this type of commit)
- No Reported-by, no Cc: stable (expected for device ID additions)
- Record: Accepted by hwmon maintainer Guenter Roeck. No bug report tags
  — this is hardware enablement.

**Step 1.3: Commit Body**
- The GPD Win 5 is a new handheld device by GPD with AMD AI MAX 385/395.
- It uses the same fan control registers as the GPD Win Duo.
- Information was provided directly by GPD (the manufacturer).
- Record: Hardware enablement for a new device using already-existing
  driver data. No bug being fixed — this is a device ID addition.

**Step 1.4: Hidden Bug Fix Detection**
- This is NOT a hidden bug fix. It is purely a device ID addition to
  enable fan control on new hardware.
- Without this entry, the GPD Win 5 has no kernel-level fan control,
  which could result in overheating or always-on-full-speed fans.
- Record: Not a hidden bug fix; a device ID addition in the "exception"
  category.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files changed: `drivers/hwmon/gpd-fan.c` only
- Lines added: +8 (a single DMI table entry block)
- Lines removed: 0
- Functions modified: None — the change is to the static `dmi_table[]`
  array
- Scope: Single-file, trivial table entry addition
- Record: [drivers/hwmon/gpd-fan.c: +8/-0] [dmi_table[] data array]
  [Trivial table entry]

**Step 2.2: Code Flow Change**
- BEFORE: The `dmi_table[]` does not match GPD Win 5 (DMI product name
  "G1618-05"). The driver returns `-ENODEV` on this hardware.
- AFTER: The `dmi_table[]` has an entry for "G1618-05" pointing to
  `&gpd_duo_drvdata`. The driver will probe and provide fan control on
  GPD Win 5.
- Record: [Before: no match, driver not loaded → After: match found,
  driver loads with duo drvdata]

**Step 2.3: Bug Mechanism**
- Category: Hardware workaround / Device ID addition (category h)
- This is a DMI match table entry addition — the exact same pattern as
  USB device IDs, PCI IDs, etc.
- Uses existing `gpd_duo_drvdata` — no new data structures, code paths,
  or logic.
- Record: [Device ID addition] [DMI_MATCH entry enabling existing driver
  on new hardware]

**Step 2.4: Fix Quality**
- Obviously correct: just adds one DMI table entry with vendor "GPD" and
  product "G1618-05"
- Minimal/surgical: 8 lines, all in the DMI table
- Regression risk: Essentially zero. The entry only matches on the
  specific GPD Win 5 DMI strings. No other hardware affected.
- Record: [Obviously correct, trivially reviewable] [Zero regression
  risk to existing hardware]

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- The `dmi_table[]` structure was introduced in commit `0ab88e2394392`
  (Sep 2025, v6.18) by Cryolitia PukNgae.
- Additional entries have been added in subsequent releases (Micro PC 2
  in v7.0).
- Record: [DMI table introduced in v6.18, exists in 7.0]

**Step 3.2: Fixes Tag**
- No Fixes: tag — expected for device ID additions.

**Step 3.3: File History**
- The driver was created in v6.18 and has had fixes and additions
  through v7.0.
- Between v6.18 and v7.0: 3 commits (Micro PC 2 support, subsystem
  locking fix, merge).
- The file is stable and well-maintained.
- Record: [Standalone commit, no prerequisites beyond the base driver
  existing in 7.0]

**Step 3.4: Author**
- Antheas Kapenekakis is a regular contributor to GPD/handheld Linux
  support, with commits to platform/x86 (oxpec), iommu, and HID
  subsystems.
- Not the subsystem maintainer, but a domain expert for GPD hardware.
- Record: [Domain expert for GPD hardware, active kernel contributor]

**Step 3.5: Dependencies**
- The commit only references `gpd_duo_drvdata` which exists in the 7.0
  tree (introduced in the original driver commit `0ab88e2394392`).
- No dependencies on any other patches.
- Record: [No dependencies. `gpd_duo_drvdata` already exists in 7.0.
  Standalone commit.]

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: Original Patch**
- Link in commit:
  `https://lore.kernel.org/r/20260220161601.2344291-1-lkml@antheas.dev`
- Lore was blocked by Anubis anti-scraping. Could not fetch discussion
  directly.
- The patch was accepted by hwmon maintainer Guenter Roeck (Signed-off-
  by).
- Record: [Lore URL identified but inaccessible. Accepted by maintainer
  per SOB.]

**Step 4.2: Reviewers**
- Guenter Roeck (hwmon maintainer) signed off on the patch — this is the
  appropriate maintainer.
- Record: [hwmon maintainer accepted the patch]

**Step 4.3-4.5: Bug report / Related patches / Stable history**
- Not applicable — this is a device ID addition, not a bug fix. No bug
  report expected.
- Record: [N/A for device ID additions]

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Functions**
- No functions are modified. The change is to a static data table
  (`dmi_table[]`).
- The table is consumed by `dmi_first_match()` in `gpd_fan_init()`,
  which is the module init path.
- The matched `gpd_duo_drvdata` is used by existing code paths
  (`gpd_read_rpm()`, `gpd_write_pwm()`, `gpd_duo_write_pwm()`, etc.)
  that already handle the `duo` board type.
- Record: [Data-only change. All code paths that consume this data
  already exist and work for GPD Duo.]

**Step 5.5: Similar Patterns**
- The entire `dmi_table[]` follows the same pattern. There are 13
  existing entries that are structurally identical.
- Record: [Pattern is identical to all other DMI entries in the table]

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

**Step 6.1: Does the code exist in stable trees?**
- The `gpd-fan` driver was introduced in v6.18. The 7.0 stable tree has
  the complete driver including `gpd_duo_drvdata`.
- Record: [Driver exists in 7.0.y. The `gpd_duo_drvdata` structure
  exists.]

**Step 6.2: Backport Complications**
- The patch should apply cleanly to 7.0.y. The `dmi_table[]` is largely
  unchanged since the driver was introduced, with minor additions (Micro
  PC 2 in 7.0).
- Record: [Expected clean apply to 7.0.y]

**Step 6.3: Related Fixes**
- No related fixes already in stable.
- Record: [No prior attempt to add GPD Win 5 support to stable]

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
- `drivers/hwmon/` — hardware monitoring, specifically fan control for a
  handheld gaming device
- Criticality: PERIPHERAL (specific device driver), but for real users
  of GPD Win 5 handheld devices, fan control is critical for thermal
  management.
- Record: [hwmon, PERIPHERAL but important for device users]

**Step 7.2: Activity**
- The driver is actively maintained with regular additions and fixes.
- Record: [Active subsystem/driver]

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is affected**
- Users of the GPD Win 5 handheld device running stable kernels.
- Without this patch, the device has no kernel fan control, which may
  mean fans stuck at default speeds or no thermal management.
- Record: [Driver-specific: GPD Win 5 users only]

**Step 8.2: Trigger**
- The DMI match is evaluated at module load time. Every GPD Win 5 user
  is affected.
- Record: [Every GPD Win 5 user is affected — automatic match on boot]

**Step 8.3: Severity**
- Without fan control: potential thermal issues, user has no way to
  control fan speed.
- This is hardware enablement rather than a crash fix, but fan control
  is essential for a handheld device.
- Record: [MEDIUM — no crash, but essential hardware functionality
  missing]

**Step 8.4: Risk-Benefit**
- BENEFIT: Enables fan control for all GPD Win 5 users on stable kernels
- RISK: Essentially zero — 8-line data-only change that only matches one
  specific DMI product ID
- Record: [High benefit for GPD Win 5 users, near-zero risk]

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**
- FOR: Device ID addition to existing driver (explicit exception
  category), trivially small (8 lines), data-only change, uses existing
  driver data structure, accepted by hwmon maintainer, zero regression
  risk, enables real hardware for real users.
- AGAINST: Not a bug fix per se — it's hardware enablement. The GPD Win
  5 is a very new device.
- UNRESOLVED: Could not access lore discussion due to Anubis protection.

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivial DMI table entry,
   accepted by maintainer, info from GPD.
2. Fixes a real bug that affects users? **Partial** — it's a device ID
   addition, which is an explicit exception.
3. Important issue? **For affected users, yes** — no fan control without
   this.
4. Small and contained? **YES** — 8 lines in one file, data-only.
5. No new features or APIs? **YES** — no new code, just a table entry.
6. Can apply to stable trees? **YES** — clean apply to 7.0.y expected.

**Step 9.3: Exception Category**
This falls into the **"New Device IDs"** exception category. Adding DMI
match entries to existing drivers is explicitly allowed in stable,
analogous to PCI/USB device IDs.

**Step 9.4: Decision**
This is a textbook device ID addition. The stable kernel rules
explicitly allow these. The change is 8 lines of data-only change, uses
an existing driver data structure (`gpd_duo_drvdata`), was accepted by
the hwmon maintainer, and enables fan control for a real shipping
device.

## Verification

- [Phase 1] Parsed tags: Signed-off-by from author (Antheas Kapenekakis)
  and hwmon maintainer (Guenter Roeck). Link to lore present.
- [Phase 2] Diff analysis: +8 lines, single DMI_MATCH entry in
  dmi_table[] referencing existing `gpd_duo_drvdata`
- [Phase 3] git blame: `dmi_table[]` introduced in commit
  `0ab88e2394392` (v6.18, Sep 2025), exists in 7.0
- [Phase 3] git log: `gpd_duo_drvdata` structure confirmed present at
  line 74-84 of current file
- [Phase 3] Author check: Antheas Kapenekakis is active GPD/handheld
  contributor (multiple commits found)
- [Phase 3] Dependencies: `gpd_duo_drvdata` exists in 7.0 tree, no other
  prerequisites
- [Phase 4] Lore: URL identified
  (`20260220161601.2344291-1-lkml@antheas.dev`), inaccessible due to
  Anubis protection
- [Phase 5] Code analysis: data-only change to static table, consumed by
  `dmi_first_match()` in `gpd_fan_init()`, all code paths for `duo`
  board type already exist
- [Phase 6] Driver exists in 7.0.y (introduced v6.18), patch expected to
  apply cleanly
- [Phase 8] Risk assessment: 8-line data-only change, zero regression
  risk, high benefit for GPD Win 5 users
- UNVERIFIED: Could not read lore discussion to check for reviewer
  concerns or stable nomination

**YES**

 drivers/hwmon/gpd-fan.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/hwmon/gpd-fan.c b/drivers/hwmon/gpd-fan.c
index 1729729b135f8..80de5f20781eb 100644
--- a/drivers/hwmon/gpd-fan.c
+++ b/drivers/hwmon/gpd-fan.c
@@ -209,6 +209,14 @@ static const struct dmi_system_id dmi_table[] = {
 		},
 		.driver_data = &gpd_duo_drvdata,
 	},
+	{
+		// GPD Win 5 with AMD AI MAX 395
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "GPD"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "G1618-05"),
+		},
+		.driver_data = &gpd_duo_drvdata,
+	},
 	{
 		// GPD Pocket 4
 		.matches = {
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] hwmon: (nct6683) Add customer ID for ASRock B650I Lightning WiFi

[Sasha Levin]

From: Petr Klotz <pklotz0@protonmail.com>

[ Upstream commit ff708b549c4dbecb308fa97e360a8fe0b2f89309 ]

The ASRock B650I Lightning WiFi motherboard uses an NCT6686D chip with a
customer ID of 0x1633. Without this ID, the nct6683 driver fails to
recognize the hardware on this board, preventing hardware monitoring
from working.

Add NCT6683_CUSTOMER_ID_ASROCK6 (0x1633) to the list of supported customer
IDs and update the probe function to handle it

Signed-off-by: Petr Klotz <pklotz0@protonmail.com>
Link: https://lore.kernel.org/r/20260412000911.9063-2-pklotz0@protonmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem:** hwmon (nct6683)
- **Action verb:** "Add" (customer ID)
- **Summary:** Add customer ID for ASRock B650I Lightning WiFi
  motherboard

Record: [hwmon/nct6683] [Add] [New customer ID 0x1633 for ASRock B650I
Lightning WiFi]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by:** Petr Klotz <pklotz0@protonmail.com> (author)
- **Link:**
  https://lore.kernel.org/r/20260412000911.9063-2-pklotz0@protonmail.com
- **Signed-off-by:** Guenter Roeck <linux@roeck-us.net> (subsystem
  maintainer / committer)
- No Fixes: tag (expected for manual review candidates)
- No Cc: stable (expected)
- No Reported-by (author is the user who needs this)

Record: Author is Petr Klotz, applied by Guenter Roeck (hwmon
maintainer). No Fixes/stable tags (expected).

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit message states:
- The ASRock B650I Lightning WiFi uses an NCT6686D chip with customer ID
  0x1633
- Without this ID, the nct6683 driver fails to recognize the hardware
  (returns -ENODEV)
- This prevents hardware monitoring from working on this board

Record: Bug = driver fails to instantiate on a real board. Symptom = no
hwmon support. Root cause = customer ID 0x1633 not in the allowlist.

### Step 1.4: DETECT HIDDEN BUG FIXES
This is not a hidden fix - it's a straightforward device ID addition to
enable hardware support on a specific board. This falls into the "NEW
DEVICE IDs" exception category.

Record: Not a hidden fix. Classic hardware ID addition.

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **Files changed:** 1 (`drivers/hwmon/nct6683.c`)
- **Lines added:** 3 (one #define, two lines for `case` statement)
- **Lines removed:** 0
- **Functions modified:** `nct6683_probe()` (adding a case to an
  existing switch)
- **Scope:** Single-file, surgical, trivially small

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Hunk 1** (line ~185): Adds `#define NCT6683_CUSTOMER_ID_ASROCK6
0x1633` to the list of known customer IDs. Pure definition, no behavior
change by itself.

**Hunk 2** (line ~1248): Adds `case NCT6683_CUSTOMER_ID_ASROCK6: break;`
to the probe function's customer ID switch statement. Before: customer
ID 0x1633 falls through to `default`, which returns -ENODEV (unless
force=1). After: 0x1633 is recognized and the probe continues normally.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category:** Hardware enablement / device ID addition

The switch statement in `nct6683_probe()` acts as an allowlist. Without
the ID, the `default` case returns `-ENODEV`, preventing the driver from
loading. Adding the case enables the driver for this specific board.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct?** YES - identical to 10+ previous customer ID
  additions
- **Minimal/surgical?** YES - 3 lines, one define + one case statement
- **Regression risk?** Essentially zero - the new case only matches a
  single specific hardware ID and does nothing different from all other
  ASRock cases
- **Red flags?** None

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The customer ID area was last modified by commit c0fa7879c985 (ASROCK5,
Dec 2025). The switch statement follows the same pattern since the
driver's creation in 2014 (41082d66bfd6).

Record: Driver exists since v3.16 (2014). Customer ID mechanism
unchanged since inception.

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present (expected - this is an ID addition, not a bug fix
per se).

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
There have been 10+ identical customer ID additions to this driver:
- ASROCK (0xe2c) - v5.12
- ASROCK2 (0xe1b) - v5.15
- ASROCK3 (0x1631) - v6.7
- ASROCK4 (0x163e) - v6.14
- ASROCK5 (0x1621) - v7.0-rc1
- MSI through MSI4, AMD, MITAC, INTEL - various versions

This is a well-established pattern with the exact same structure every
time.

Record: Standalone commit. No prerequisites. Follows established
pattern.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Petr Klotz is not the subsystem maintainer. This appears to be a first-
time or infrequent contributor submitting a board-specific ID. However,
Guenter Roeck (the hwmon maintainer) applied it, lending credibility.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
No dependencies. The patch adds a #define and a case to an existing
switch. It applies cleanly to any version that has the customer ID
switch structure (all versions since v3.16).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.2: FIND THE ORIGINAL PATCH DISCUSSION
The Link tag points to `20260412000911.9063-2-pklotz0@protonmail.com`.
Lore.kernel.org was behind Anubis protection during fetch. However, the
commit was applied by Guenter Roeck, the hwmon subsystem maintainer,
confirming it passed review.

The "-2" in the message ID suggests this was patch 2 of a series.

### Step 4.3: BUG REPORT
No separate bug report - the author is the user affected. This is
typical for hardware ID additions.

### Step 4.4-4.5: RELATED PATCHES AND STABLE HISTORY
Similar customer ID additions have been routinely backported to stable
trees. This is standard practice for device enablement.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
Only `nct6683_probe()` is modified (adding a case to an existing
switch).

### Step 5.2: TRACE CALLERS
`nct6683_probe()` is called by the platform driver subsystem during
device enumeration - a standard, well-tested path.

### Step 5.3-5.4: CALL CHAIN
The probe function reads the customer ID from hardware register 0x602,
then checks it against the allowlist. If not found and `force` is not
set, it returns -ENODEV. This is the normal device discovery path.

### Step 5.5: SIMILAR PATTERNS
Identical pattern seen in all 10+ previous customer ID additions. No
unique concerns.

---

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

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
YES. The nct6683 driver with the customer ID switch exists in all active
stable trees:
- **v6.1.y:** Has INTEL, MITAC, MSI, ASROCK, ASROCK2
- **v6.6.y:** Has INTEL, MITAC, MSI, MSI2, ASROCK, ASROCK2
- **v6.12.y:** Has INTEL, MITAC, MSI, MSI2, MSI3, ASROCK through ASROCK3

All versions have the switch structure and the `default: return -ENODEV`
path.

### Step 6.2: BACKPORT COMPLICATIONS
The patch will need trivial context adjustment since each stable tree
has a different number of existing customer IDs. However, the pattern is
identical: add a #define and a case. This is a trivial conflict to
resolve.

### Step 6.3: RELATED FIXES ALREADY IN STABLE
No fix for this specific board (0x1633) exists in stable.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem:** drivers/hwmon (hardware monitoring)
- **Criticality:** PERIPHERAL to IMPORTANT - hwmon is used on all
  server/desktop boards for temperature/fan monitoring. ASRock B650I is
  a consumer AM5 motherboard (AMD Ryzen).

### Step 7.2: SUBSYSTEM ACTIVITY
The nct6683 driver is actively maintained with regular customer ID
additions (the most recent being Dec 2025). Guenter Roeck is the active
maintainer.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users of the ASRock B650I Lightning WiFi motherboard who want hardware
monitoring. This is a consumer AM5 board, so it has a real user
population.

### Step 8.2: TRIGGER CONDITIONS
Every boot on the affected hardware. The driver will always fail to
probe without this ID.

### Step 8.3: FAILURE MODE SEVERITY
Without this patch: hardware monitoring completely non-functional on
this board. Severity: LOW-MEDIUM (not a crash or security issue, but a
real hardware enablement problem). Users can work around with `force=1`
module parameter, but this is non-obvious.

### Step 8.4: RISK-BENEFIT RATIO
- **BENEFIT:** Enables hwmon for a real board. Trivial, well-tested
  pattern.
- **RISK:** Essentially zero. 3 lines, no logic change, only affects one
  specific hardware ID.
- **Ratio:** Very favorable for backporting.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILED

**FOR backporting:**
- Textbook device ID addition to an existing driver (explicit exception
  in stable rules)
- 3 lines total, minimal and obviously correct
- Follows the exact pattern of 10+ previous identical commits
- Enables hardware monitoring on a real consumer motherboard
- Applied by subsystem maintainer (Guenter Roeck)
- Driver exists in all active stable trees
- Zero regression risk

**AGAINST backporting:**
- Not a crash/security/corruption fix
- Cosmetically, it's "adding support" not "fixing a bug"
- Patch needs minor context adjustment for older stable trees (trivial)

### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - identical pattern to 10+
   previous commits, applied by maintainer
2. **Fixes a real bug?** YES - enables hardware monitoring on real
   hardware that is otherwise blocked
3. **Important issue?** MODERATE - hardware completely non-functional
   without it
4. **Small and contained?** YES - 3 lines in one file
5. **No new features or APIs?** CORRECT - just a device ID to an
   existing driver
6. **Can apply to stable?** YES with trivial context adjustments

### Step 9.3: EXCEPTION CATEGORY
**YES - Device ID addition to existing driver.** This is explicitly
listed as an exception that IS allowed in stable despite being an
"addition."

### Step 9.4: DECISION
This is a textbook device ID addition. The stable kernel rules
explicitly allow these because they are trivial, risk-free, and enable
real hardware for real users.

---

## Verification

- [Phase 1] Parsed commit message: author Petr Klotz, applied by Guenter
  Roeck (hwmon maintainer), Link to lore present
- [Phase 2] Diff analysis: 3 lines added - one #define
  (NCT6683_CUSTOMER_ID_ASROCK6 0x1633) and one case statement in
  nct6683_probe()
- [Phase 3] git blame: customer ID mechanism originates from
  41082d66bfd6 (v3.16, 2014), last ASRock ID added in c0fa7879c985 (Dec
  2025)
- [Phase 3] git log history: confirmed 10+ identical customer ID
  additions following the same pattern
- [Phase 4] Lore fetch failed (Anubis protection), but Link tag confirms
  accepted submission; commit applied by subsystem maintainer
- [Phase 4] Web search: confirmed pattern of customer ID additions is
  routine for this driver
- [Phase 5] nct6683_probe() is the only function modified; standard
  platform driver probe path
- [Phase 6] Verified driver exists in v6.1, v6.6, v6.12 stable trees via
  `git show v6.X:drivers/hwmon/nct6683.c`; all have the customer ID
  switch with the default: return -ENODEV path
- [Phase 6] Minor context conflicts expected due to differing number of
  existing IDs per stable tree (trivial to resolve)
- [Phase 8] Risk: essentially zero. Benefit: enables hwmon on real
  ASRock B650I Lightning WiFi board
- UNVERIFIED: Could not read the full lore discussion thread due to
  Anubis protection; however, maintainer acceptance is confirmed by
  Guenter Roeck's SOB

**YES**

 drivers/hwmon/nct6683.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/hwmon/nct6683.c b/drivers/hwmon/nct6683.c
index 4a83804140386..0581770380cc5 100644
--- a/drivers/hwmon/nct6683.c
+++ b/drivers/hwmon/nct6683.c
@@ -182,6 +182,7 @@ superio_exit(int ioreg)
 #define NCT6683_CUSTOMER_ID_ASROCK3	0x1631
 #define NCT6683_CUSTOMER_ID_ASROCK4	0x163e
 #define NCT6683_CUSTOMER_ID_ASROCK5	0x1621
+#define NCT6683_CUSTOMER_ID_ASROCK6	0x1633
 
 #define NCT6683_REG_BUILD_YEAR		0x604
 #define NCT6683_REG_BUILD_MONTH		0x605
@@ -1245,6 +1246,8 @@ static int nct6683_probe(struct platform_device *pdev)
 		break;
 	case NCT6683_CUSTOMER_ID_ASROCK5:
 		break;
+	case NCT6683_CUSTOMER_ID_ASROCK6:
+		break;
 	default:
 		if (!force)
 			return -ENODEV;
-- 
2.53.0