[PATCH AUTOSEL 6.18-6.12] hwmon: (raspberrypi) Fix delayed-work teardown race

[PATCH AUTOSEL 6.18-6.12] hwmon: (raspberrypi) Fix delayed-work teardown race

[Sasha Levin]

From: Shubham Chakraborty <chakrabortyshubham66@gmail.com>

[ Upstream commit eb0d491e2787aa359f0d930151ff6e5e5df70fb9 ]

The delayed polling work rearms itself from the work function, so use
explicit delayed-work setup and cleanup instead of
devm_delayed_work_autocancel().

Initialize the delayed work with INIT_DELAYED_WORK() and register a
devres cleanup action that calls disable_delayed_work_sync() during
teardown.

This addresses the concern raised during review about the polling work
being able to requeue itself while the driver is being removed.

Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Link: https://lore.kernel.org/r/20260517080445.103962-4-chakrabortyshubham66@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:

Those background searches finished and match the earlier analysis:

- On **6.18.44 (HEAD)**, `git log --grep` does not find this fix — only
  unrelated teardown commits show up.
- On **master**, the fix is **`eb0d491e2787a`** (`hwmon: (raspberrypi)
  Fix delayed-work teardown race`), merged via the `hwmon-for-v7.2` tag.
- It is present on **next** branches (`all-next`, `arch-next`, etc.) but
  **not** on the checked-out **6.18.y** stable tree.

That confirms the patch still needs to be backported to 6.18.44, and the
**YES** recommendation stands.

 drivers/hwmon/raspberrypi-hwmon.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
index a2938881ccd2f..b0f0f50986b9a 100644
--- a/drivers/hwmon/raspberrypi-hwmon.c
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -7,7 +7,6 @@
  * Copyright (C) 2018 Stefan Wahren <stefan.wahren@i2se.com>
  */
 #include <linux/device.h>
-#include <linux/devm-helpers.h>
 #include <linux/err.h>
 #include <linux/hwmon.h>
 #include <linux/module.h>
@@ -72,6 +71,13 @@ static void get_values_poll(struct work_struct *work)
 	schedule_delayed_work(&data->get_values_poll_work, 2 * HZ);
 }
 
+static void rpi_hwmon_cancel_poll_work(void *res)
+{
+	struct rpi_hwmon_data *data = res;
+
+	disable_delayed_work_sync(&data->get_values_poll_work);
+}
+
 static int rpi_read(struct device *dev, enum hwmon_sensor_types type,
 		    u32 attr, int channel, long *val)
 {
@@ -117,8 +123,8 @@ static int rpi_hwmon_probe(struct platform_device *pdev)
 	if (IS_ERR(data->hwmon_dev))
 		return PTR_ERR(data->hwmon_dev);
 
-	ret = devm_delayed_work_autocancel(dev, &data->get_values_poll_work,
-					   get_values_poll);
+	INIT_DELAYED_WORK(&data->get_values_poll_work, get_values_poll);
+	ret = devm_add_action_or_reset(dev, rpi_hwmon_cancel_poll_work, data);
 	if (ret)
 		return ret;
 	platform_set_drvdata(pdev, data);
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.12] hwmon: (raspberrypi) Fix delayed-work teardown race

[sashiko-bot]

> From: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> 
> [ Upstream commit eb0d491e2787aa359f0d930151ff6e5e5df70fb9 ]
> 
> The delayed polling work rearms itself from the work function, so use
> explicit delayed-work setup and cleanup instead of
> devm_delayed_work_autocancel().
> 
> Initialize the delayed work with INIT_DELAYED_WORK() and register a
> devres cleanup action that calls disable_delayed_work_sync() during
> teardown.
> 
> This addresses the concern raised during review about the polling work
> being able to requeue itself while the driver is being removed.
> 
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> Link: https://lore.kernel.org/r/20260517080445.103962-4-chakrabortyshubham66@gmail.com
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-65-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-6.12] hwmon: (dell-smm) Add Dell Latitude 7530 to fan control whitelist

[Sasha Levin]

From: Armin Wolf <W_Armin@gmx.de>

[ Upstream commit 5a1aba28f6c79f4bbb7a5361063225030ecd36f3 ]

A user reported that the Dell Latitude 7530 needs to be whitelisted
for the special SMM calls necessary for globally enabling/disabling
BIOS fan control.

Closes: https://github.com/Wer-Wolf/i8kutils/issues/17
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Acked-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20260610180141.311503-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `hwmon: (dell-smm) Add Dell Latitude 7530 to
fan control whitelist`

**Local tree:** `v6.18.44` (stable/linux-6.18.y)
**Mainline commit:** `5a1aba28f6c79` (merged via `hwmon-for-v7.2`, not
yet in this 6.18.y checkout)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[hwmon: (dell-smm)]` `[Add]` — Add Dell Latitude 7530 to
the existing fan-control DMI whitelist.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Closes:** https://github.com/Wer-Wolf/i8kutils/issues/17
- **Signed-off-by:** Armin Wolf \<W_Armin@gmx.de\>
- **Acked-by:** Pali Rohár \<pali@kernel.org\> (dell-smm co-developer /
  whitelist maintainer)
- **Link:**
  https://lore.kernel.org/r/20260610180141.311503-1-W_Armin@gmx.de
- **Signed-off-by:** Guenter Roeck \<linux@roeck-us.net\> (hwmon
  maintainer)
- No `Fixes:`, `Reported-by:`, `Cc: stable@vger.kernel.org`, `Tested-
  by:`, or syzbot tags.

Notable: maintainer ack from Pali Rohár; user bug report via GitHub
issue.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** Dell Latitude 7530 is missing from
  `i8k_whitelist_fan_control`, so the driver never sets the correct SMM
  codes (`manual_fan`/`auto_fan`) for toggling BIOS automatic fan
  control.
- **Symptom:** Manual fan control via hwmon `pwmX_enable` / i8kutils
  does not work; user saw fan speed capped (~3500 RPM) without the
  whitelist entry vs ~4000 RPM with it.
- **Root cause:** SMM fan-control codes differ per Dell model; only
  whitelisted models get the correct codes at init via
  `dell_smm_init_dmi()`.
- No kernel version range stated in the commit message.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not disguised cleanup — this is an explicit hardware-
enablement / quirk entry. Functionally fixes broken manual fan control
on one laptop model.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **Files:** `drivers/hwmon/dell-smm-hwmon.c` (+8 lines, 0 removed)
- **Functions touched:** data in `i8k_whitelist_fan_control[]` (used by
  `dell_smm_init_dmi()`)
- **Scope:** Single-file, surgical DMI table addition.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**
- **Before:** On Latitude 7530,
  `dmi_first_match(i8k_whitelist_fan_control)` returns NULL →
  `manual_fan`/`auto_fan` stay 0 → `pwmX_enable` sysfs attribute is not
  exposed (`auto_fan` check at line 864 fails) and
  `i8k_enable_fan_auto_mode()` is never used with correct SMM codes.
- **After:** Latitude 7530 matches → `manual_fan=0x30a3`,
  `auto_fan=0x31a3` (same as Latitude 7320) → fan auto/manual SMM
  control is enabled for this machine.
- **Path affected:** `__init` DMI setup at boot (`dell_smm_init_dmi()` →
  `i8k_init()`).

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:** **Category (h): Hardware workaround / DMI quirk.** Missing
DMI whitelist entry prevents correct per-model SMM codes from being
configured. Same mechanism as the existing Latitude 7320 entry
(`b4be51302d687`).

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- Obviously correct: copies the proven Latitude 7320 pattern
  (`I8K_FAN_30A3_31A3`), user-tested on GitHub.
- Minimal, no unrelated changes.
- Regression risk very low: only affects systems matching
  `DMI_PRODUCT_NAME == "Latitude 7530"`. The original 2019 whitelist
  commit notes incorrect SMM codes can be dangerous, but this uses the
  same validated codes as the sibling 7320 model after maintainer/user
  testing.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:** Insertion point is after Latitude 7320 entry
(`b4be51302d687`, Jul 2024). Whitelist infrastructure introduced in
`afe45277ade62` (Nov 2019). `I8K_FAN_30A3_31A3` enum value present since
at least `8debe3c1295ef`. All prerequisites are long-established in
6.18.y.

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

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:** Multiple prior whitelist additions already in 6.18.y:
- `b4be51302d687` — Latitude 7320 (same author, same pattern, same
  `I8K_FAN_30A3_31A3`)
- `f8611a7981cd0` — G15 5510
- `fa0bc8f297b29` — G15 5511
- etc.

Standalone single-patch series (v1 only). No series dependencies.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Armin Wolf is a regular dell-smm contributor in this tree
(7320 whitelist, OptiPlex DMI entries, fan mode support). Not the
subsystem maintainer, but established contributor with maintainer ack on
this patch.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:** No dependencies. Requires only existing
`i8k_whitelist_fan_control`, `i8k_fan_control_data[]`, and
`I8K_FAN_30A3_31A3` — all present in 6.18.44. `git apply --check` on the
mainline patch succeeds cleanly.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:**
- **b4 dig URL:**
  https://patch.msgid.link/20260610180141.311503-1-W_Armin@gmx.de
- **Series:** v1 only (committed version is latest)
- **Reviewer feedback:** Acked-by Pali Rohár; Guenter Roeck applied. No
  NAKs, no stable nomination in thread.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** CC'd: `pali@kernel.org`, `linux@roeck-us.net`, `linux-
hwmon@vger.kernel.org`. Pali Rohár (co-developer of whitelist mechanism)
acked.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** GitHub issue #17 (piotr152):
- User confirmed without `driver_data`: fan capped at 3500 RPM
- With `I8K_FAN_30A3_31A3`: works, ~4000 RPM
- Same treatment needed as Latitude 7320 (issue #8)
- Severity from user perspective: functional fan-control failure, not
  kernel crash

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** Standalone patch. Related prior fix: `b4be51302d687`
(Latitude 7320) — already in 6.18.y.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** No stable-list discussion found for this specific patch. Not
a negative signal per instructions.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** `dell_smm_init_dmi()` (consumer of whitelist),
`i8k_enable_fan_auto_mode()` (uses `manual_fan`/`auto_fan`),
`dell_smm_is_visible()` (exposes `hwmon_pwm_enable` when `auto_fan` is
set).

### Step 5.2: TRACE CALLERS
**Record:** `dell_smm_init_dmi()` called from `i8k_init()` at module
init (`__init`). Affects all subsequent hwmon sysfs read/write on
matched Dell laptops. Not interrupt context; init-time configuration.

### Step 5.3: TRACE CALLEES
**Record:** `dmi_first_match()` → sets globals `manual_fan`/`auto_fan` →
used later by `i8k_enable_fan_auto_mode()` → `dell_smm_call()` (SMM BIOS
call).

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:** Boot-time DMI match → userspace writes `pwm1_enable` via
hwmon sysfs (root typically required) → `i8k_enable_fan_auto_mode()`.
Reachable from userspace on affected hardware; not a security crash
vector.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** Identical pattern used for 12+ models in
`i8k_whitelist_fan_control[]` in this tree, including Latitude 7320 with
the same `I8K_FAN_30A3_31A3` codes.

---

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

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:** **YES.** The whitelist table exists but lacks Latitude 7530.
`grep "Latitude 7530"` returns no matches in 6.18.44. The omission (not
a regression) means 7530 owners on 6.18.y lack fan-control enablement
that sibling models (7320) already have.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** **Clean apply expected.** Verified with `git apply --check`.
Insertion point (after 7320, before E6440) matches current file layout
exactly.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** Latitude 7320 whitelist (`b4be51302d687`) is present.
Latitude 7530 fix is not. No duplicate fix.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** **hwmon / dell-smm driver.** **IMPORTANT** for Dell laptop
users relying on fan control; **PERIPHERAL** from a whole-kernel
perspective (DMI-gated, one laptop model).

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** hwmon is actively maintained in 6.18.y; dell-smm receives
regular DMI whitelist updates (7320, G15 5510/5511, XPS entries, etc.).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** **Driver-specific / platform-specific** — Dell Latitude 7530
owners using `dell-smm` hwmon fan control (i8kutils, manual thermal
management).

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:** Every boot on Latitude 7530 with `dell-smm` loaded. Common
for affected hardware owners. Requires root for sysfs writes; not an
unprivileged attack vector.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:** **Functional failure** — manual BIOS fan-control toggle via
SMM does not work; fan speed may be capped below what manual control
allows. **Severity: LOW–MEDIUM** (thermal management inconvenience, not
kernel oops/corruption). Could matter under heavy workloads if BIOS auto
mode is inadequate.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Enables fan control on a real, shipping laptop for 6.18.y
  users; direct precedent already accepted in this tree (7320).
- **Risk:** Very low — 8 lines, DMI-gated, maintainer-acked, user-tested
  codes.
- **Ratio:** Favorable for backport under the hardware-quirk exception.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backport:**
- Hardware quirk / DMI whitelist exception (explicitly allowed for
  stable)
- Real user-reported issue with on-hardware testing
- Acked-by subsystem co-developer (Pali Rohár)
- Identical precedent already in 6.18.y (Latitude 7320, same SMM codes)
- 8-line patch, applies cleanly, no dependencies
- Driver and infrastructure fully present in 6.18.44

**AGAINST backport:**
- Not a crash, security, deadlock, or data-corruption fix
- Strict reading of "important issue" criterion is borderline
- Fan-control SMM calls carry inherent risk if codes are wrong
  (mitigated by 7320 precedent and user testing)

**UNRESOLVED:** None material to the decision.

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — mirrors 7320 entry; user-
   tested on GitHub; maintainer acked.
2. Fixes a real bug affecting users? **PASS** — manual fan control non-
   functional on Latitude 7530.
3. Important issue? **PASS (via quirk exception)** — not crash-level,
   but real hardware functionality for laptop thermal management; fits
   hardware-quirk stable exception.
4. Small and contained? **PASS** — 8 lines, one file.
5. No new features or APIs? **PASS** — DMI table entry only; no new
   sysfs/API surface.
6. Can apply to local tree? **PASS** — verified clean apply to 6.18.44.

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
**Record:** **Hardware quirk / DMI whitelist workaround** — same
category as Latitude 7320, XPS 9315, G15 5510 entries already in 6.18.y.

### Step 9.4: DECISION RATIONALE

This commit should be backported to **6.18.y**. The dell-smm fan-control
whitelist is an established, conservative mechanism for per-model SMM
code selection. Adding Latitude 7530 with the same `I8K_FAN_30A3_31A3`
codes as the already-backported Latitude 7320 is low risk and fixes a
confirmed user-facing hardware issue. It is not a kernel-stability crash
fix, but it squarely matches the stable-tree exception for hardware-
specific quirks that enable existing driver functionality on real
devices.

---

## Verification

- **[Phase 1]** `git show 5a1aba28f6c79`: parsed subject, tags, body
- **[Phase 1]** GitHub issue #17 fetched: user testing confirms
  `I8K_FAN_30A3_31A3` works; without entry fan capped at 3500 RPM
- **[Phase 2]** Read `dell-smm-hwmon.c` lines 432-441, 863-878,
  1059-1084, 1530-1777: confirmed whitelist → `auto_fan`/`manual_fan` →
  sysfs and SMM path
- **[Phase 2]** `git show 5a1aba28f6c79 --stat`: 1 file, +8 lines
- **[Phase 3]** `git describe HEAD` / `make kernelversion`: tree is
  v6.18.44
- **[Phase 3]** `git blame -L 1560,1567`: Latitude 7320 entry from
  `b4be51302d687`
- **[Phase 3]** `git log -S i8k_whitelist_fan_control`: whitelist
  introduced `afe45277ade62` (2019)
- **[Phase 3]** `git log --grep="fan control whitelist" HEAD`: multiple
  whitelist commits already in 6.18.y including 7320
- **[Phase 3]** `git apply --check` on mainline patch: applies cleanly
  to 6.18.44
- **[Phase 4]** `b4 dig -c 5a1aba28f6c79`: lore thread found
- **[Phase 4]** `b4 dig -c 5a1aba28f6c79 -w`: Pali Rohár and Guenter
  Roeck CC'd
- **[Phase 4]** `b4 dig -c 5a1aba28f6c79 -a`: v1 only, no later
  revisions
- **[Phase 4]** `b4 dig -m /tmp/latitude7530.mbox`: thread downloaded;
  Acked-by Pali Rohár; no stable Cc
- **[Phase 5]** `grep dell_smm_init_dmi`: called from `i8k_init()` at
  line 1808
- **[Phase 6]** `grep "Latitude 7530"`: not present in 6.18.44 (fix
  needed)
- **[Phase 6]** `grep "Latitude 7320"`: present at line 1561 (insertion
  point confirmed)
- **[Phase 6]** `I8K_FAN_30A3_31A3` enum and data present at lines
  1536-1544
- **[Phase 7]** `git log --oneline -20 -- drivers/hwmon/`: active hwmon
  maintenance in tree
- **[Phase 8]** Failure mode assessed as functional/thermal, not crash —
  severity LOW-MEDIUM

**YES**

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

diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 768690a597f4d..9f102589f240c 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -1565,6 +1565,14 @@ static const struct dmi_system_id i8k_whitelist_fan_control[] __initconst = {
 		},
 		.driver_data = (void *)&i8k_fan_control_data[I8K_FAN_30A3_31A3],
 	},
+	{
+		.ident = "Dell Latitude 7530",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 7530"),
+		},
+		.driver_data = (void *)&i8k_fan_control_data[I8K_FAN_30A3_31A3],
+	},
 	{
 		.ident = "Dell Latitude E6440",
 		.matches = {
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.12] hwmon: (dell-smm) Add Dell Latitude 7530 to fan control whitelist

[sashiko-bot]

> From: Armin Wolf <W_Armin@gmx.de>
> 
> [ Upstream commit 5a1aba28f6c79f4bbb7a5361063225030ecd36f3 ]
> 
> A user reported that the Dell Latitude 7530 needs to be whitelisted
> for the special SMM calls necessary for globally enabling/disabling
> BIOS fan control.
> 
> Closes: https://github.com/Wer-Wolf/i8kutils/issues/17
> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
> Acked-by: Pali Rohár <pali@kernel.org>
> Link: https://lore.kernel.org/r/20260610180141.311503-1-W_Armin@gmx.de
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-66-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-6.6] hwmon: (corsair-psu) Fix linear11 calculation

[Sasha Levin]

From: Guenter Roeck <linux@roeck-us.net>

[ Upstream commit c6c4234928d2eb4f61fecb61067e612d9bdbd2ff ]

In corsairpsu_linear11_to_int(), the mantissa is extracted using bitwise
operations and cast to s16 before being shifted left:

static int corsairpsu_linear11_to_int(const u16 val, const int scale)
{
    ...
    const int mant = (((s16)(val & 0x7ff)) << 5) >> 5;
    ...
}

Due to C integer promotion rules, the masked value (which is always
positive) is promoted to a 32-bit integer before the left shift. As a
result, the sign bit is never extended to bit 31 of the promoted integer.

When the device hardware reports a negative temperature in Linear11 format
(such as an ambient temperature probe reporting sub-zero), the negative
mantissa is parsed incorrectly as a massive positive value. For example,
-1 becomes 2047, which scales to 2047 degrees Celsius.

Fix the problem by type casting the result of the left shift operation
to s16.

Another problem is left-shifting of negative values. In C, the result of
left-shifting negative values is undefined. Use a multiplication instead
to avoid the problem.

Also use a local s64 variable to store temporary results, change
the return value type from int to long, and clamp the final value
to LONG_MIN and LONG_MAX to avoid under- and overflow issues while
retaining as much information as possible.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Cc: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Link: https://lore.kernel.org/r/20260804034811.2385506-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `hwmon: (corsair-psu) Fix linear11
calculation`

**Local tree:** `v6.18.44` (linux-6.18.y, `VERSION = 6`, `PATCHLEVEL =
18`, `SUBLEVEL = 44`)
**Upstream fix commit:** `c6c4234928d2e` (on `master`, not yet in this
tree)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Parse the Subject Line
**Record:** `[hwmon: (corsair-psu)] [fix] [correct LINEAR11 mantissa
sign-extension and exponent handling in sensor value conversion]`

### Step 1.2: Parse All Commit Message Tags
**Record:**
| Tag | Value |
|-----|-------|
| Reported-by | Sashiko \<sashiko-bot@kernel.org\> (AI code review bot,
not a user crash report) |
| Cc | Wilken Gottwalt \<wilken.gottwalt@posteo.net\> (driver author) |
| Signed-off-by | Guenter Roeck \<linux@roeck-us.net\> (hwmon subsystem
maintainer) |
| Tested-by | Wilken Gottwalt \<wilken.gottwalt@posteo.net\> |
| Link | https://lore.kernel.org/r/20260804034811.2385506-1-linux@roeck-
us.net |
| Fixes: | **Absent** (expected for manual review) |
| Cc: stable | **Absent** (expected) |

**Notable patterns:** Maintainer-authored fix with hardware-expert
Tested-by. Reported-by is an automated AI reviewer, not syzbot or a user
bug report.

### Step 1.3: Analyze Commit Body
**Record:**
- **Bug description:** `corsairpsu_linear11_to_int()` incorrectly
  extracts the signed 11-bit LINEAR11 mantissa. Casting `(val & 0x7ff)`
  to `s16` before left-shift fails because the masked value is always
  non-negative and gets promoted to a 32-bit int without sign extension.
- **Symptom:** Negative temperatures (e.g., sub-zero ambient probe)
  parse as huge positive values. Example: -1°C → 2047°C.
- **Secondary issues:** Left-shifting negative values is undefined
  behavior in C; exponent scaling can overflow `int`.
- **Root cause:** Integer promotion rules + incorrect cast order in
  mantissa extraction (introduced in 2021 refactor).
- **Version info:** None explicit; bug has existed since Feb 2021.

### Step 1.4: Detect Hidden Bug Fixes
**Record:** Not disguised — explicitly labeled and described as a fix.
The overflow/clamp and UB avoidance are genuine correctness improvements
bundled with the sign-extension fix.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory the Changes
**Record:**
- **File:** `drivers/hwmon/corsair-psu.c` — +14 / -9 lines (23 lines
  total with context)
- **Functions modified:** `corsairpsu_linear11_to_int()` → renamed
  `corsairpsu_linear11_to_long()`; call sites in
  `corsairpsu_get_value()`
- **Scope:** Single-file surgical fix

### Step 2.2: Code Flow Change (per hunk)

**Hunk 1 — `corsairpsu_linear11_to_long()`:**
- **Before:** Mantissa `(((s16)(val & 0x7ff)) << 5) >> 5` — sign never
  propagated for negative mantissas; exponent applied via bit-shift on
  `int`; returns `int`.
- **After:** Mantissa `((s16)((val & 0x7ff) << 5)) >> 5` — sign
  extension works; exponent via multiplication/division on `s64`; result
  clamped to `LONG_MIN`/`LONG_MAX`; returns `long`.

**Hunk 2 — `corsairpsu_get_value()` call sites:**
- **Before:** Calls `corsairpsu_linear11_to_int()` for temps, fan, PWM,
  watts.
- **After:** Calls `corsairpsu_linear11_to_long()` — same call paths,
  corrected return type.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Logic/correctness fix (type promotion bug) +
  initialization/overflow hardening
- **Mechanism:** For LINEAR11 value `0xFFFF` (mantissa -1): `val &
  0x7ff` = `0x7FF` (2047). Old code: `(s16)2047 << 5 >> 5` = 2047. Fixed
  code: `(s16)(2047 << 5) >> 5` = `(s16)0xFFE0 >> 5` = -1. Affects all
  LINEAR11 conversions; primary real-world impact is temperature sysfs
  readings at sub-zero ambient.

### Step 2.4: Fix Quality Assessment
**Record:**
- Fix is obviously correct by inspection; matches standard LINEAR11
  sign-extension pattern.
- Minimal, self-contained; no API changes visible to userspace (still
  `long` hwmon values).
- **Regression risk:** Very low. Positive values unchanged; only
  negative mantissa paths and overflow edge cases differ.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame the Changed Lines
**Record:**
- Buggy mantissa line introduced by **918f22104d64d** (Wilken Gottwalt,
  2021-02-27): `hwmon: (corsair-psu) Update calculation of LINEAR11
  values`
- Function shell from **d115b51e0e5671** (2020-10-27): original driver
  introduction
- Bug present since kernel ~5.12 era; definitely present in this 6.18.y
  tree

### Step 3.2: Follow Fixes: Tag
**Record:** No `Fixes:` tag present. Bug introduced by 918f22104d64d,
which is an ancestor of HEAD — confirmed with `git merge-base --is-
ancestor`.

### Step 3.3: File History for Related Changes
**Record:** Recent corsair-psu changes in this tree include UAF fix
(`ec477af3a7e8d`), probe error handling, device ID additions. On master
after v6.18.44: additional corsair-psu fixes (debugfs serialization,
string termination, this linear11 fix). **Standalone** — no series
dependency.

### Step 3.4: Author's Other Commits
**Record:** Guenter Roeck is hwmon subsystem maintainer. Wilken Gottwalt
is the primary corsair-psu driver author (multiple commits in this
file). High subsystem expertise.

### Step 3.5: Prerequisites
**Record:** No dependencies. Patch applies cleanly to current tree (`git
apply --check` → `APPLIES_CLEANLY`). Fix commit `c6c4234928d2e` is NOT
an ancestor of HEAD (`fix_NOT_in_tree`).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original Patch Discussion
**Record:**
- **URL:**
  https://patch.msgid.link/20260804034811.2385506-1-linux@roeck-us.net
- **Series:** v1 (RESEND, 2026-08-03) → v2 (2026-08-03, applied
  version). v2 change: "Skip handling right-shift of negative values"
- **Reviewer feedback:** Sashiko AI bot: "found no issues." Wilken
  Gottwalt: "Don't see any anomalies," gave Tested-by; noted he cannot
  simulate negative temps but PSU operating range is 0–50°C.
- **Stable nominations:** None found in thread.
- **NAKs:** None.

### Step 4.2: Who Reviewed
**Record:** CC'd to `linux-hwmon@vger.kernel.org`, Sashiko bot, Wilken
Gottwalt (driver author). Maintainer self-submitted.

### Step 4.3: Bug Report
**Record:** No user bug report, syzbot, or KASAN report. Found via code
review (Sashiko AI). Concrete failure example provided in commit message
(-1 → 2047°C).

### Step 4.4: Related Patches
**Record:** Standalone 1-patch series. No other patches required.

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

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** `corsairpsu_linear11_to_long()` (was `_to_int`), called from
`corsairpsu_get_value()`.

### Step 5.2: Trace Callers
**Record:** `corsairpsu_get_value()` called from:
- `corsairpsu_get_criticals()` — critical threshold reads at probe
- `corsairpsu_hwmon_temp_read()` — **TEMP0/TEMP1** (primary bug impact)
- `corsairpsu_hwmon_fan_read()`, `corsairpsu_hwmon_power_read()`,
  `corsairpsu_hwmon_in_read()`, `corsairpsu_hwmon_curr_read()`
- debugfs read paths

All ultimately reachable from userspace via sysfs hwmon reads
(`corsairpsu_hwmon_ops_read`).

### Step 5.3: Key Callees
**Record:** `corsairpsu_request()` (USB HID I/O), `clamp()` macro. No
locking changes.

### Step 5.4: Call Chain / Reachability
**Record:** Userspace reads `/sys/class/hwmon/hwmonN/tempN_input` →
`corsairpsu_hwmon_ops_read()` → `corsairpsu_hwmon_temp_read()` →
`corsairpsu_get_value()` → `corsairpsu_linear11_to_long()`. **Reachable
from userspace** on systems with `CONFIG_SENSORS_CORSAIR_PSU` enabled
and a supported Corsair PSU connected.

### Step 5.5: Similar Patterns
**Record:** Other hwmon drivers in this tree have had LINEAR11 fixes
backported (e.g., `pmbus/fsp-3y` non-compliant linear11 vout encoding).
Same class of sensor-parsing correctness bug.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

### Step 6.1: Does Buggy Code Exist?
**Record:** **YES.** Current tree at lines 143–149 has the exact buggy
code:

```143:149:drivers/hwmon/corsair-psu.c
static int corsairpsu_linear11_to_int(const u16 val, const int scale)
{
        const int exp = ((s16)val) >> 11;
        const int mant = (((s16)(val & 0x7ff)) << 5) >> 5;
        const int result = mant * scale;

        return (exp >= 0) ? (result << exp) : (result >> -exp);
```

Driver present since driver intro commit `d115b51e0e5671`; buggy
mantissa since `918f22104d64d`.

### Step 6.2: Backport Complications
**Record:** **Clean apply** — verified with `git apply --check`. No
conflicting changes in the affected region.

### Step 6.3: Related Fixes Already Present?
**Record:** Other corsair-psu fixes are present (UAF fix
`ec477af3a7e8d`, probe fixes), but this linear11 fix is **not** yet in
v6.18.44.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem Criticality
**Record:** `drivers/hwmon/` — **PERIPHERAL** (optional tristate module
`CONFIG_SENSORS_CORSAIR_PSU`, Corsair PSU HID hardware only).

### Step 7.2: Subsystem Activity
**Record:** Actively maintained. Recent 6.18.y stable queue includes
multiple hwmon sensor-correctness and crash fixes (adt7470, ina2xx,
ltc4282, sht3x).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
**Record:** **Driver-specific** — users with supported Corsair PSUs
(RM/HX series with HID interface) who have `CONFIG_SENSORS_CORSAIR_PSU`
built-in or loaded as module.

### Step 8.2: Trigger Conditions
**Record:** PSU firmware reports a negative LINEAR11 mantissa, most
plausibly on temperature sensors in sub-zero ambient conditions.
Unprivileged users can trigger sysfs reads but cannot inject the
hardware value. **Uncommon** but realistic in cold environments; driver
author notes PSU spec is 0–50°C continuous.

### Step 8.3: Failure Mode Severity
**Record:**
- **Failure mode:** Incorrect sysfs sensor readings (e.g., 2047°C
  instead of -1°C); could cause false monitoring alerts or fan-control
  script misfires if tied to PSU temps.
- **NOT:** kernel crash, oops, hang, deadlock, data corruption, or
  security issue.
- **Severity: MEDIUM** — real user-visible incorrect data, but no kernel
  instability.

### Step 8.4: Risk-Benefit Ratio
**Record:**
- **Benefit:** Correct temperature/voltage/power readings for affected
  hardware; eliminates absurd 2047°C values.
- **Risk:** Very low — 23-line change, maintainer-authored, tested,
  clean apply.
- **Ratio:** Moderate benefit, very low risk. Appropriate for 6.18.y
  where the driver and bug both exist.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- Real, reproducible parsing bug with concrete example (-1 → 2047°C)
- Bug present in this tree since 2021
- Fix from hwmon maintainer (Guenter Roeck), Tested-by from driver
  author
- Small (23 lines), single file, applies cleanly
- Precedent: similar hwmon sensor-reading correctness fixes already in
  6.18.y stable queue
- Fixes undefined behavior (left-shift of negative values)

**AGAINST backport:**
- Niche optional driver; small user population
- No crash/corruption/security impact
- Trigger requires sub-zero ambient (edge case per driver author)
- Reported-by is AI review bot, not a user bug report
- Does not meet the strongest stable signals (oops, UAF, syzbot)

**Unresolved:** No independent user reports of the 2047°C symptom found.

### Step 9.2: Stable Rules Checklist
| Criterion | Result |
|-----------|--------|
| 1. Obviously correct and tested? | **PASS** — clear C promotion fix;
Tested-by from driver author |
| 2. Fixes a real bug affecting users? | **PASS** — wrong sysfs sensor
values for Corsair PSU users |
| 3. Important issue? | **PASS (borderline)** — "oh, that's not good"
per stable-kernel-rules.rst; not crash-level but clearly wrong
monitoring data |
| 4. Small and contained? | **PASS** — 23 lines, 1 file |
| 5. No new features/APIs? | **PASS** — bug fix only |
| 6. Can apply to local tree? | **PASS** — verified clean apply |

### Step 9.3: Exception Categories
**Record:** None (not device ID, quirk, DT, build fix, or docs fix).
Qualifies as a hardware-monitoring correctness bug fix.

### Step 9.4: Decision Rationale

For **linux-6.18.y at v6.18.44**: the corsair-psu driver and the buggy
LINEAR11 code are both present. The fix is maintainer-quality, tested,
minimal, and applies cleanly. While the impact is limited to a niche
driver and cold-ambient edge cases (wrong sysfs readings, not kernel
crashes), stable-kernel-rules explicitly include fixes for real bugs
that bother users and "oh, that's not good" issues. This tree already
backports similar hwmon sensor-correctness fixes. The risk of regression
is negligible.

---

## Verification

- **[Phase 1]** Parsed commit message tags from `git show c6c4234928d2e`
- **[Phase 2]** Diff analysis: 23 lines changed in
  `drivers/hwmon/corsair-psu.c`; verified buggy mantissa at lines
  143–149
- **[Phase 3]** `git blame`: buggy line from 918f22104d64d (2021-02-27);
  driver from d115b51e0e5671 (2020-10-27)
- **[Phase 3]** `git merge-base --is-ancestor`: driver and buggy code
  both in tree; fix commit NOT in tree
- **[Phase 3]** `git log --oneline -20 -- drivers/hwmon/corsair-psu.c`:
  history reviewed
- **[Phase 4]** `b4 dig -c c6c4234928d2e`: found v1→v2 series at lore
  URL above
- **[Phase 4]** `b4 dig -c c6c4234928d2e -w`: CC'd linux-hwmon, Sashiko,
  Wilken Gottwalt
- **[Phase 4]** `b4 dig -m /tmp/corsair_linear11.mbox`: read thread;
  Tested-by from Wilken; no stable nomination; no NAKs
- **[Phase 5]** `grep corsairpsu_get_value`: traced callers to hwmon
  sysfs read path
- **[Phase 6]** `git describe HEAD`: v6.18.44
- **[Phase 6]** `git apply --check`: patch applies cleanly
- **[Phase 6]** Read current `corsairpsu_linear11_to_int()` — buggy code
  confirmed present
- **[Phase 7]** `CONFIG_SENSORS_CORSAIR_PSU` in `drivers/hwmon/Kconfig`
  — tristate optional module
- **[Phase 8]** Assessed severity as MEDIUM (wrong sysfs data, no kernel
  crash)

---

**YES**The background lookups are done and match what the analysis
already used:

- **b4 dig** found the patch thread: [PATCH v2] hwmon: (corsair-psu) Fix
  linear11 calculation (v1 → v2, Tested-by from Wilken Gottwalt).
- **`git log --grep="Fix linear11"`** hung and was stopped; the fix was
  already located on `master` as `c6c4234928d2e`.
- **`git log --grep="linear11"`** returned unrelated hwmon LINEAR11
  commits in other drivers (pmbus/fsp-3y, etc.), not this corsair-psu
  fix.

Nothing else is needed from those tasks. The backport recommendation for
**linux-6.18.y (v6.18.44)** remains **YES** — small maintainer fix for
wrong sub-zero temperature readings, applies cleanly, and the buggy code
is present in this tree.

 drivers/hwmon/corsair-psu.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/hwmon/corsair-psu.c b/drivers/hwmon/corsair-psu.c
index 4681af6843596..d56a6cd76ff26 100644
--- a/drivers/hwmon/corsair-psu.c
+++ b/drivers/hwmon/corsair-psu.c
@@ -140,13 +140,18 @@ struct corsairpsu_data {
 };
 
 /* some values are SMBus LINEAR11 data which need a conversion */
-static int corsairpsu_linear11_to_int(const u16 val, const int scale)
+static long corsairpsu_linear11_to_long(const u16 val, const int scale)
 {
 	const int exp = ((s16)val) >> 11;
-	const int mant = (((s16)(val & 0x7ff)) << 5) >> 5;
-	const int result = mant * scale;
+	const int mant = ((s16)((val & 0x7ff) << 5)) >> 5;
+	s64 result = mant * scale;
 
-	return (exp >= 0) ? (result << exp) : (result >> -exp);
+	if (exp >= 0)
+		result *= (int)(1UL << exp);
+	else
+		result >>= -exp;
+
+	return clamp(result, LONG_MIN, LONG_MAX);
 }
 
 /* the micro-controller uses percentage values to control pwm */
@@ -271,13 +276,13 @@ static int corsairpsu_get_value(struct corsairpsu_data *priv, u8 cmd, u8 rail, l
 	case PSU_CMD_RAIL_AMPS:
 	case PSU_CMD_TEMP0:
 	case PSU_CMD_TEMP1:
-		*val = corsairpsu_linear11_to_int(tmp & 0xFFFF, 1000);
+		*val = corsairpsu_linear11_to_long(tmp & 0xFFFF, 1000);
 		break;
 	case PSU_CMD_FAN:
-		*val = corsairpsu_linear11_to_int(tmp & 0xFFFF, 1);
+		*val = corsairpsu_linear11_to_long(tmp & 0xFFFF, 1);
 		break;
 	case PSU_CMD_FAN_PWM_ENABLE:
-		*val = corsairpsu_linear11_to_int(tmp & 0xFFFF, 1);
+		*val = corsairpsu_linear11_to_long(tmp & 0xFFFF, 1);
 		/*
 		 * 0 = automatic mode, means the micro-controller controls the fan using a plan
 		 *     which can be modified, but changing this plan is not supported by this
@@ -291,12 +296,12 @@ static int corsairpsu_get_value(struct corsairpsu_data *priv, u8 cmd, u8 rail, l
 			*val = 2;
 		break;
 	case PSU_CMD_FAN_PWM:
-		*val = corsairpsu_linear11_to_int(tmp & 0xFFFF, 1);
+		*val = corsairpsu_linear11_to_long(tmp & 0xFFFF, 1);
 		*val = corsairpsu_dutycycle_to_pwm(*val);
 		break;
 	case PSU_CMD_RAIL_WATTS:
 	case PSU_CMD_TOTAL_WATTS:
-		*val = corsairpsu_linear11_to_int(tmp & 0xFFFF, 1000000);
+		*val = corsairpsu_linear11_to_long(tmp & 0xFFFF, 1000000);
 		break;
 	case PSU_CMD_TOTAL_UPTIME:
 	case PSU_CMD_UPTIME:
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.6] hwmon: (corsair-psu) Fix linear11 calculation

[sashiko-bot]

> From: Guenter Roeck <linux@roeck-us.net>
> 
> [ Upstream commit c6c4234928d2eb4f61fecb61067e612d9bdbd2ff ]
> 
> In corsairpsu_linear11_to_int(), the mantissa is extracted using bitwise
> operations and cast to s16 before being shifted left:
> 
> static int corsairpsu_linear11_to_int(const u16 val, const int scale)
> {
>     ...
>     const int mant = (((s16)(val & 0x7ff)) << 5) >> 5;
>     ...
> }
> 
> Due to C integer promotion rules, the masked value (which is always
> [ ... ]
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Tested-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
> Link: https://lore.kernel.org/r/20260804034811.2385506-1-linux@roeck-us.net
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-287-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-5.10] hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i

[Sasha Levin]

From: Potin Lai <potin.lai.pt@gmail.com>

[ Upstream commit 83dda7ed185501ba1f8165aeca83ff4a8ef7c263 ]

Swap the high setting and low setting coefficients in the lm25066_coeff
table for LM5064, LM5066, and LM5066i. The coefficients were previously
mapped incorrectly, resulting in inverted current and power scaling.

Additionally, dynamically assign the exponent (R) registers inside the
probe's LM25066_DEV_SETUP_CL check. This ensures that the proper
exponent is applied (e.g., for LM25056, high setting power exponent
is -4, but low setting power exponent is -3).

Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@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:

The background git history search finished successfully. It confirms the
driver has been in-tree since `03e9bd8dbcee6` (2011,
LM25066/LM5064/LM5066) and LM5066i support was added in `5783ec2e5c102`
(2017), with no prior coefficient-fix commits in the history.

That lines up with the earlier analysis: the swapped coefficients date
back to the 2013 refactor, and the verdict for this 6.18.y tree remains
**YES** — a small, maintainer-reviewed fix for wrong current/power
readings on production BMC hardware using these chips.

 drivers/hwmon/pmbus/lm25066.c | 54 ++++++++++++++++++-----------------
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/hwmon/pmbus/lm25066.c b/drivers/hwmon/pmbus/lm25066.c
index dd7275a67a0ab..6e23ada64e2ff 100644
--- a/drivers/hwmon/pmbus/lm25066.c
+++ b/drivers/hwmon/pmbus/lm25066.c
@@ -132,23 +132,23 @@ static const struct __coeff lm25066_coeff[][PSC_NUM_CLASSES + 2] = {
 			.R = -2,
 		},
 		[PSC_CURRENT_IN] = {
-			.m = 10742,
-			.b = 1552,
+			.m = 5456,
+			.b = 2118,
 			.R = -2,
 		},
 		[PSC_CURRENT_IN_L] = {
-			.m = 5456,
-			.b = 2118,
+			.m = 10742,
+			.b = 1552,
 			.R = -2,
 		},
 		[PSC_POWER] = {
-			.m = 1204,
-			.b = 8524,
+			.m = 612,
+			.b = 11202,
 			.R = -3,
 		},
 		[PSC_POWER_L] = {
-			.m = 612,
-			.b = 11202,
+			.m = 1204,
+			.b = 8524,
 			.R = -3,
 		},
 		[PSC_TEMPERATURE] = {
@@ -167,23 +167,23 @@ static const struct __coeff lm25066_coeff[][PSC_NUM_CLASSES + 2] = {
 			.R = -2,
 		},
 		[PSC_CURRENT_IN] = {
-			.m = 10753,
-			.b = -1200,
+			.m = 5405,
+			.b = -600,
 			.R = -2,
 		},
 		[PSC_CURRENT_IN_L] = {
-			.m = 5405,
-			.b = -600,
+			.m = 10753,
+			.b = -1200,
 			.R = -2,
 		},
 		[PSC_POWER] = {
-			.m = 1204,
-			.b = -6000,
+			.m = 605,
+			.b = -8000,
 			.R = -3,
 		},
 		[PSC_POWER_L] = {
-			.m = 605,
-			.b = -8000,
+			.m = 1204,
+			.b = -6000,
 			.R = -3,
 		},
 		[PSC_TEMPERATURE] = {
@@ -202,23 +202,23 @@ static const struct __coeff lm25066_coeff[][PSC_NUM_CLASSES + 2] = {
 			.R = -2,
 		},
 		[PSC_CURRENT_IN] = {
-			.m = 15076,
-			.b = -504,
+			.m = 7645,
+			.b = 100,
 			.R = -2,
 		},
 		[PSC_CURRENT_IN_L] = {
-			.m = 7645,
-			.b = 100,
+			.m = 15076,
+			.b = -504,
 			.R = -2,
 		},
 		[PSC_POWER] = {
-			.m = 1701,
-			.b = -4000,
+			.m = 861,
+			.b = -965,
 			.R = -3,
 		},
 		[PSC_POWER_L] = {
-			.m = 861,
-			.b = -965,
+			.m = 1701,
+			.b = -4000,
 			.R = -3,
 		},
 		[PSC_TEMPERATURE] = {
@@ -519,18 +519,20 @@ static int lm25066_probe(struct i2c_client *client)
 	info->m[PSC_VOLTAGE_OUT] = coeff[PSC_VOLTAGE_OUT].m;
 	info->b[PSC_VOLTAGE_OUT] = coeff[PSC_VOLTAGE_OUT].b;
 	info->R[PSC_VOLTAGE_OUT] = coeff[PSC_VOLTAGE_OUT].R;
-	info->R[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].R;
-	info->R[PSC_POWER] = coeff[PSC_POWER].R;
 	if (config & LM25066_DEV_SETUP_CL) {
 		info->m[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN_L].m;
 		info->b[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN_L].b;
+		info->R[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN_L].R;
 		info->m[PSC_POWER] = coeff[PSC_POWER_L].m;
 		info->b[PSC_POWER] = coeff[PSC_POWER_L].b;
+		info->R[PSC_POWER] = coeff[PSC_POWER_L].R;
 	} else {
 		info->m[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].m;
 		info->b[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].b;
+		info->R[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].R;
 		info->m[PSC_POWER] = coeff[PSC_POWER].m;
 		info->b[PSC_POWER] = coeff[PSC_POWER].b;
+		info->R[PSC_POWER] = coeff[PSC_POWER].R;
 	}
 
 	/*
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i

[sashiko-bot]

> From: Potin Lai <potin.lai.pt@gmail.com>
> 
> [ Upstream commit 83dda7ed185501ba1f8165aeca83ff4a8ef7c263 ]
> 
> Swap the high setting and low setting coefficients in the lm25066_coeff
> table for LM5064, LM5066, and LM5066i. The coefficients were previously
> mapped incorrectly, resulting in inverted current and power scaling.
> 
> Additionally, dynamically assign the exponent (R) registers inside the
> probe's LM25066_DEV_SETUP_CL check. This ensures that the proper
> exponent is applied (e.g., for LM25056, high setting power exponent
> is -4, but low setting power exponent is -3).
> 
> Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@gmail.com
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-321-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18] hwmon: (asus-ec-sensors) add ROG MAXIMUS Z790 EXTREME

[Sasha Levin]

From: Brian Downey <bdowne01@gmail.com>

[ Upstream commit 5f6617089dc06f9941e8ca57ba64345c9f1ed9ed ]

Add support for ROG MAXIMUS Z790 EXTREME

Signed-off-by: Brian Downey <bdowne01@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20260608060855.40469-1-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:

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[hwmon: (asus-ec-sensors)] [add] [ROG MAXIMUS Z790 EXTREME
board support to existing EC sensors driver]`

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none
- **Acked-by:** — none
- **Link:** `https://lore.kernel.org/r/20260608060855.40469-1-
  eugene.shalygin@gmail.com`
- **Cc: stable@vger.kernel.org** — not present (expected)
- **Signed-off-by:** Brian Downey, Eugene Shalygin, Guenter Roeck (hwmon
  maintainer)

Notable: no syzbot/sanitizer reports; maintainer (Guenter Roeck)
committed it.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug description:** None stated. Commit only says "Add support for
  ROG MAXIMUS Z790 EXTREME."
- **Symptom/failure mode:** Without this patch, `asus-ec-sensors` does
  not match this board's DMI name and does not expose EC-based hwmon
  sensors (T_Sensor, VRM, water-in/out, water-flow).
- **Version info:** None in message.
- **Root cause:** Board not listed in `dmi_table[]`;
  `sensors_family_intel_700[]` lacked water-sensor EC register mappings
  needed by this board.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not a hidden bug fix. This is explicit hardware enablement —
a DMI board table entry plus sensor-family data for a new motherboard.
No crash, leak, race, or corruption is described or implied.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- `Documentation/hwmon/asus_ec_sensors.rst`: +1 line (board list)
- `drivers/hwmon/asus-ec-sensors.c`: +15 lines
- **Functions modified:** None (only static data:
  `sensors_family_intel_700[]`, new `board_info_maximus_z790_extreme`,
  `dmi_table[]`)
- **Scope:** Single-file driver change + doc; surgical hardware-ID
  addition

### Step 2.2: CODE FLOW CHANGE
**Record:**
- **Hunk 1 (`sensors_family_intel_700[]`):** Before: intel 700 family
  had T_Sensor, T_Sensor 2, VRM, CPU_Opt only. After: adds Water_Flow,
  Water_In, Water_Out EC register mappings (same addresses as intel 600
  family).
- **Hunk 2 (`board_info_maximus_z790_extreme`):** New board config
  mirroring `board_info_maximus_z690_formula` but using
  `family_intel_700_series`.
- **Hunk 3 (`dmi_table[]`):** Adds DMI exact match for `"ROG MAXIMUS
  Z790 EXTREME"` → new board info.
- **Affected path:** `get_board_info()` → `dmi_first_match()` →
  `asus_ec_probe()` only when DMI matches this board.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:**
- **Bug category:** None (hardware enablement / missing board ID)
- **Mechanism:** Driver probes via platform device; `get_board_info()`
  returns NULL for unknown boards → probe returns `-ENODEV`. This patch
  adds the missing board identifier and its sensor map.

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- Fix is obviously correct: copies the established Z690 FORMULA pattern
  (same sensor set, same mutex path) onto intel 700 family.
- Minimal and surgical; no logic changes.
- **Regression risk:** Very low. Water sensor entries in
  `sensors_family_intel_700[]` are only used when a board's `.sensors`
  bitmask requests them. Existing intel-700 boards (`ROG STRIX Z790-E
  GAMING WIFI II`, `ROG STRIX Z790-I GAMING WIFI`) do not enable water
  sensors and are unaffected.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:**
- `sensors_family_intel_700[]` introduced in `0183cb21b8a87`
  (2025-07-28, "Add ROG STRIX Z790E GAMING WIFI II"); water sensors were
  absent from the start.
- Commit `5f6617089dc06` (2026-06-08) adds Z790 EXTREME support.
- Intel 700 family and DMI infrastructure are present in this tree since
  v6.18 development.

### Step 3.2: FOLLOW THE FIXES: TAG
**Record:** No `Fixes:` tag present; step not applicable.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:**
- Similar board-add commits already in v6.18.44: `15c8317366908` (Z790-I
  GAMING WIFI), `0183cb21b8a87` (Z790E GAMING WIFI II), `34c61c198d06b`
  (Z690-E GAMING WIFI).
- Same author ecosystem (Eugene Shalygin as committer/reviewer on many
  board-add patches).
- Standalone single-patch series (v1 → v2 per `b4 dig -a`); no multi-
  patch dependency.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Eugene Shalygin is a regular `asus-ec-sensors` contributor
(many board-add patches). Brian Downey contributed the board data.
Guenter Roeck (hwmon maintainer) committed it.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:**
- Prerequisites present in v6.18.44: `asus-ec-sensors` driver,
  `family_intel_700_series`, `ASUS_HW_ACCESS_MUTEX_RMTW_ASMX`, DMI
  matching macros, water sensor enum/bit definitions.
- Commit is self-contained; no series dependencies.
- Cherry-pick to v6.18.44 applies cleanly (verified).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:**
- `b4 dig -c 5f6617089dc06`: matched v2 at `https://patch.msgid.link/202
  60608060855.40469-1-eugene.shalygin@gmail.com`
- `b4 dig -a`: v1 (2026-06-07) and v2 (2026-06-08); committed version is
  latest (v2).
- Lore thread content could not be fetched (Anubis bot protection on
  patch.msgid.link). Stable nomination in thread: **unverified**.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** `b4 dig -w` recipients include Guenter Roeck (hwmon
maintainer), linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
Jonathan Corbet, Shuah Khan.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** No bug report tags or syzbot links. This is a user/hardware
enablement request, not a crash report.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** Standalone 1-patch series (v1/v2). No companion fixes
required.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** Not searched (no stable Cc: tag, no bug report to anchor
search). Stable-specific discussion: **unverified**.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** No functions modified. Static data consumed by
`get_board_info()` and `asus_ec_probe()`.

### Step 5.2: TRACE CALLERS
**Record:**
- `get_board_info()` → called from `asus_ec_probe()` (line ~1256)
- `asus_ec_probe()` → registered as `.probe` in platform driver; reached
  from `asus_ec_init()` via `platform_create_bundle()`
- `module_init(asus_ec_init)` at driver load
- Context: module init / platform probe during boot; not a hot path

### Step 5.3: TRACE CALLEES
**Record:** `dmi_first_match(dmi_table)`, sensor setup via
`setup_sensor_data()`, `fill_ec_registers()`, hwmon device registration.
Uses existing EC read infrastructure and ACPI mutex locking.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:** Boot-time driver load → DMI match → hwmon sysfs sensors
exposed. Not directly syscall-triggered, but affects all users of this
motherboard who want temperature/fan monitoring via `asus-ec-sensors`.
Without match, driver silently does not bind (`-ENODEV`).

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** Identical pattern used for dozens of boards in this driver
(e.g., `board_info_maximus_z690_formula` with same sensor set on intel
600 family). Water sensor EC addresses match those in
`sensors_family_intel_600[]`.

---

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

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:**
- **Local tree:** `v6.18.44` (linux-6.18.y stable), `VERSION=6
  PATCHLEVEL=18 SUBLEVEL=44`
- **Missing board support exists:** `ROG MAXIMUS Z790 EXTREME` is absent
  from `dmi_table[]` and documentation in HEAD.
- Commit `5f6617089dc06` is **not** an ancestor of HEAD (`commit NOT in
  tree`).
- Driver `asus-ec-sensors` and `family_intel_700_series` **do** exist.
- `ROG MAXIMUS Z790 EXTREME` appears in `nct6775-platform.c` WMI list
  (partial/alternate monitoring path), but not in `asus-ec-sensors`.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** Cherry-pick of `5f6617089dc06` onto v6.18.44 succeeds with
auto-merge, no conflicts. Expected apply: **clean**.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** No equivalent Z790 EXTREME entry in `asus-ec-sensors`.
Related intel-700 Z790 boards (Z790-I, Z790E WIFI II) are already
supported. This specific board is the gap.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** `drivers/hwmon/` — hardware monitoring. **Criticality:
PERIPHERAL** (affects specific ASUS motherboard owners, not core kernel
paths).

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** `asus-ec-sensors` is actively maintained with frequent
board-add commits. v6.18.44 already includes multiple board-add patches
from the same series.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** **Platform-specific** — owners of ASUS ROG MAXIMUS Z790
EXTREME motherboards running `CONFIG_SENSORS_ASUS_EC`. No impact on
other hardware.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:** Triggered at boot when DMI reports `"ROG MAXIMUS Z790
EXTREME"` and `asus-ec-sensors` module loads. Common for affected
hardware owners. Not a security issue; not userspace-triggerable beyond
normal module loading.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:** Without patch: EC-based hwmon sensors unavailable (no
T_Sensor header, VRM temp, water loop temps/flow via this driver).
System boots normally; monitoring gap only. **Severity: LOW** (missing
functionality, not crash/corruption/hang).

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Enables hwmon for a real, shipping high-end motherboard
  on 6.18.y; matches established in-tree pattern.
- **Risk:** Very low — 16 lines of static data, no logic changes, no
  effect on existing boards.
- **Ratio:** Moderate benefit for a small user population vs. very low
  regression risk.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Explicitly permitted by `Documentation/process/stable-kernel-
  rules.rst`: *"must either fix a real bug … or just add a device ID"*
- DMI board table entry is the functional equivalent of a device ID for
  this driver
- Driver already exists in v6.18.44; only board ID + sensor map added
- Small (16 lines), applies cleanly, obviously correct
- Same pattern as board-add commits already present in this tree
  (Z790-I, Z690 FORMULA, etc.)
- Hwmon maintainer committed it
- No regression risk for existing configurations

**AGAINST backporting:**
- Not a bug fix (no crash, corruption, security, deadlock)
- Missing sensors is low-severity — system works without them
- Partial monitoring may exist via `nct6775` WMI path for this board
  name
- Adds sensor family entries beyond a pure one-line ID (though only used
  by the new board)
- No `Cc: stable` or user bug reports demonstrating urgency

**Unresolved:**
- Whether lore reviewers nominated for stable (thread inaccessible)
- Whether users rely exclusively on `asus-ec-sensors` vs. `nct6775` on
  this board

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — mirrors Z690 FORMULA;
   maintainer committed; v1→v2 review cycle
2. Fixes a real bug affecting users? **PASS** (via device-ID exception)
   — not a crash bug, but missing board ID prevents hardware monitoring
   on a supported driver
3. Important issue (crash, security, corruption, deadlock)? **FAIL** for
   bug-fix criterion; **PASS** only under device-ID exception (low-
   severity enablement)
4. Small and contained? **PASS** — 16 lines, 2 files, static data only
5. No new features or APIs? **PASS** — no new APIs; board ID addition
   per stable rules exception
6. Can apply to local tree? **PASS** — cherry-pick verified clean on
   v6.18.44

### Step 9.3: EXCEPTION CATEGORIES
**Record:** Falls under **device ID addition** (DMI board identifier for
existing driver). Analogous to PCI/USB ID additions documented in stable
rules and review guidelines.

### Step 9.4: DECISION RATIONALE

For **linux-6.18.y (v6.18.44)**: the `asus-ec-sensors` driver, intel-700
sensor family, and DMI infrastructure are all present. The commit adds
only a missing board identifier and its sensor configuration — the exact
pattern already used for other Z790/Z690 boards in this stable series.
Per the tree's own stable rules, device-ID additions to existing drivers
are explicitly eligible for stable backport even when they are not crash
fixes.

The patch is minimal, applies cleanly, and cannot affect boards that do
not match the new DMI entry. The benefit is enabling EC sensor
monitoring for ROG MAXIMUS Z790 EXTREME owners on 6.18.y; the risk is
negligible.

---

## Verification

- [Phase 1] Parsed subject, tags, body: hardware enablement, no
  bug/crash language
- [Phase 1] No syzbot/sanitizer/Fixes tags found
- [Phase 2] Diff: 16 lines, static data only in `asus-ec-sensors.c` + 1
  doc line
- [Phase 2] Verified water sensor bits not set on existing intel-700
  boards in HEAD
- [Phase 3] `git describe HEAD`: `v6.18.44`
- [Phase 3] `git merge-base --is-ancestor 5f6617089dc06 HEAD`: commit
  NOT in tree
- [Phase 3] `git blame` on `sensors_family_intel_700[]`: introduced
  0183cb21b8a87
- [Phase 3] Similar board-add `15c8317366908` IS in v6.18.44
- [Phase 4] `b4 dig -c 5f6617089dc06`: v2 lore URL found
- [Phase 4] `b4 dig -a`: v1 and v2 revisions found
- [Phase 4] `b4 dig -w`: Guenter Roeck and linux-hwmon CC'd
- [Phase 4] UNVERIFIED: lore thread content (Anubis blocked fetch)
- [Phase 5] Traced `get_board_info()` → `asus_ec_probe()` call chain in
  source
- [Phase 5] `module_init(asus_ec_init)` confirmed at line 1402
- [Phase 6] `ROG MAXIMUS Z790 EXTREME` absent from `asus-ec-sensors.c`
  in HEAD
- [Phase 6] `ROG MAXIMUS Z790 EXTREME` present in `nct6775-platform.c`
  WMI list
- [Phase 6] Cherry-pick `5f6617089dc06` onto HEAD: clean auto-merge
- [Phase 7] `CONFIG_SENSORS_ASUS_EC` exists in `drivers/hwmon/Kconfig`
- [Phase 8] Failure mode assessed as missing hwmon, severity LOW
- [Phase 9] `Documentation/process/stable-kernel-rules.rst` line 15:
  device ID exception confirmed

**YES**

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

diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index a8456f29db950..8b9c24664e158 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -25,6 +25,7 @@ Supported boards:
  * ROG MAXIMUS XI HERO
  * ROG MAXIMUS XI HERO (WI-FI)
  * ROG MAXIMUS Z690 FORMULA
+ * ROG MAXIMUS Z790 EXTREME
  * ROG STRIX B550-E GAMING
  * ROG STRIX B550-I GAMING
  * ROG STRIX B650E-I GAMING WIFI
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index 57b771d96d4f0..33402bc3f6cd7 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -382,6 +382,12 @@ static const struct ec_sensor_info sensors_family_intel_700[] = {
 	[ec_sensor_temp_vrm] = EC_SENSOR("VRM", hwmon_temp, 1, 0x00, 0x33),
 	[ec_sensor_fan_cpu_opt] =
 		EC_SENSOR("CPU_Opt", hwmon_fan, 2, 0x00, 0xb0),
+	[ec_sensor_fan_water_flow] =
+		EC_SENSOR("Water_Flow", hwmon_fan, 2, 0x00, 0xbc),
+	[ec_sensor_temp_water_in] =
+		EC_SENSOR("Water_In", hwmon_temp, 1, 0x01, 0x00),
+	[ec_sensor_temp_water_out] =
+		EC_SENSOR("Water_Out", hwmon_temp, 1, 0x01, 0x01),
 };
 
 /* Shortcuts for common combinations */
@@ -475,6 +481,13 @@ static const struct ec_board_info board_info_maximus_z690_formula = {
 	.family = family_intel_600_series,
 };
 
+static const struct ec_board_info board_info_maximus_z790_extreme = {
+	.sensors = SENSOR_TEMP_T_SENSOR | SENSOR_TEMP_VRM |
+		SENSOR_SET_TEMP_WATER | SENSOR_FAN_WATER_FLOW,
+	.mutex_path = ASUS_HW_ACCESS_MUTEX_RMTW_ASMX,
+	.family = family_intel_700_series,
+};
+
 static const struct ec_board_info board_info_prime_x470_pro = {
 	.sensors = SENSOR_SET_TEMP_CHIPSET_CPU_MB |
 		SENSOR_TEMP_T_SENSOR | SENSOR_TEMP_VRM |
@@ -776,6 +789,8 @@ static const struct dmi_system_id dmi_table[] = {
 					&board_info_maximus_xi_hero),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG MAXIMUS Z690 FORMULA",
 					&board_info_maximus_z690_formula),
+	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG MAXIMUS Z790 EXTREME",
+					&board_info_maximus_z790_extreme),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B550-E GAMING",
 					&board_info_strix_b550_e_gaming),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B550-I GAMING",
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18] hwmon: (asus-ec-sensors) add ROG MAXIMUS Z790 EXTREME

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Spurious EC register reads due to incorrect bank check condition in asus_ec_block_read().
- [High] The return value of asus_ec_hwmon_add_chan_info() is ignored, leading to a NULL pointer dereference in the hwmon core if allocation fails.
--

commit 751ec7ce900f71bbf414765f09e4deeff7e667fe
Author: Brian Downey <bdowne01@gmail.com>

hwmon: (asus-ec-sensors) add ROG MAXIMUS Z790 EXTREME

Add support for ROG MAXIMUS Z790 EXTREME.

Link: https://lore.kernel.org/r/20260608060855.40469-1-eugene.shalygin@gmail.com

> diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
> index 34a8f6b834c97..bd89ffbe25897 100644
> --- a/drivers/hwmon/asus-ec-sensors.c
> +++ b/drivers/hwmon/asus-ec-sensors.c

[ ... ]

> @@ -470,6 +476,13 @@ static const struct ec_board_info board_info_maximus_z690_formula = {
>  	.family = family_intel_600_series,
>  };
>  
> +static const struct ec_board_info board_info_maximus_z790_extreme = {
> +	.sensors = SENSOR_TEMP_T_SENSOR | SENSOR_TEMP_VRM |
> +		SENSOR_SET_TEMP_WATER | SENSOR_FAN_WATER_FLOW,
> +	.mutex_path = ASUS_HW_ACCESS_MUTEX_RMTW_ASMX,
> +	.family = family_intel_700_series,
> +};
> +

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the new board
support, I noticed a pre-existing issue in asus_ec_block_read() that could
affect hardware interaction on boards with sensors spanning multiple banks.

Could this condition cause spurious reads on unintended EC registers?

drivers/hwmon/asus-ec-sensors.c:asus_ec_block_read() {
		for (ireg = 0; ireg < ec->nr_registers; ireg++) {
			reg_bank = register_bank(ec->registers[ireg]);
			if (reg_bank < bank) {
				continue;
			}
			ec_read(register_index(ec->registers[ireg]),
				ec->read_buffer + ireg);
		}
}

The loop uses if (reg_bank < bank) to skip registers from previously
processed banks, but it appears to not skip registers from future banks where
reg_bank > bank.

Since the read uses the current hardware bank, could this result in unintended
reads that might trigger unexpected hardware side-effects?


[Severity: High]
This is a pre-existing issue, but I also noticed a potential missing error
handling path in the driver's probe function.

Does this loop in asus_ec_probe() silently discard the error return value from
asus_ec_hwmon_add_chan_info()?

drivers/hwmon/asus-ec-sensors.c:asus_ec_probe() {
	for (type = 0; type < hwmon_max; ++type) {
		if (!nr_count[type])
			continue;

		asus_ec_hwmon_add_chan_info(asus_ec_hwmon_chan, dev,
					     nr_count[type], type,
					     hwmon_attributes[type]);
		*ptr_asus_ec_ci++ = asus_ec_hwmon_chan++;
	}
}

Because asus_ec_hwmon_add_chan_info() can return -ENOMEM if its memory
allocation fails, ignoring its return value could leave the config pointer in
asus_ec_hwmon_chan as NULL.

When this partially initialized structure is subsequently passed to
devm_hwmon_device_register_with_info(), the hwmon core will iterate over the
channel configuration in hwmon_num_channel_attrs().

Could this cause a NULL pointer dereference when the core iterates using
for (i = n = 0; info->config[i]; i++)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-412-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18] hwmon: (asus-ec-sensors) add ROG STRIX B850-E GAMING WIFI

[Sasha Levin]

From: Eugene Shalygin <eugene.shalygin@gmail.com>

[ Upstream commit 5e9f31543515d685cafed33274433b6360c0e1e4 ]

The board has a similar sensor configuration to the
ROG STRIX B850-I GAMING WIFI, but includes an additional
T-Sensor header. The patch was provided via GitHub [1].

[1] https://github.com/zeule/asus-ec-sensors/pull/105

Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20260607123626.100630-1-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:

## Phase 1: Commit Message Forensics

### Step 1.1: Parse the Subject Line
**Record:** `[hwmon: (asus-ec-sensors)] [add] [ROG STRIX B850-E GAMING
WIFI board support]`

### Step 1.2: Parse All Commit Message Tags
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — not present
- **Tested-by:** — not present
- **Reviewed-by:** — not present
- **Acked-by:** — not present
- **Link:** `https://lore.kernel.org/r/20260607123626.100630-1-
  eugene.shalygin@gmail.com`
- **Cc: stable@vger.kernel.org:** — not present (expected)
- **Signed-off-by:** Eugene Shalygin `<eugene.shalygin@gmail.com>`
  (author)
- **Signed-off-by:** Guenter Roeck `<linux@roeck-us.net>` (hwmon
  maintainer)
- **Notable:** GitHub reference `[1] https://github.com/zeule/asus-ec-
  sensors/pull/105` in body; no syzbot/fuzzer tags

### Step 1.3: Analyze Commit Body
**Record:**
- **Bug description:** Not a crash/corruption fix. Adds DMI board
  identification and sensor configuration for the ASUS ROG STRIX B850-E
  GAMING WIFI motherboard.
- **Symptom without patch:** `asus-ec-sensors` does not bind on this
  board; no EC-based temperature/fan hwmon sensors are exposed.
- **Root cause:** Board is absent from the driver's `dmi_table[]` and
  has no `ec_board_info` entry.
- **Configuration detail:** Similar to B850-I, but adds
  `SENSOR_TEMP_T_SENSOR` (T-Sensor header) and uses
  `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0` instead of the ACPI
  global lock used by B850-I.
- **Version info:** None in commit message.

### Step 1.4: Detect Hidden Bug Fixes
**Record:** Not a hidden bug fix. This is explicit hardware enablement —
a DMI board-table addition analogous to adding a PCI/USB device ID. No
error-path, locking, refcount, or memory-safety changes.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory the Changes
**Record:**
- `Documentation/hwmon/asus_ec_sensors.rst`: +1 line (board list)
- `drivers/hwmon/asus-ec-sensors.c`: +10 lines (struct + DMI entry)
- **Total:** ~11 lines added, 0 removed
- **Functions modified:** None; only static data
  (`board_info_strix_b850_e_gaming_wifi`, `dmi_table[]`)
- **Scope:** Single-subsystem, single-driver, surgical data-table
  addition

### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (docs):** Adds board name to supported-boards list.
- **Hunk 2 (board_info):** Before → no config for B850-E. After → new
  `ec_board_info` with CPU/CPU package/MB/VRM temps, T-Sensor, CPU_OPT
  fan, SB PCI0 SIO1 mutex, `family_amd_800_series`.
- **Hunk 3 (dmi_table):** Before → DMI match fails for `"ROG STRIX
  B850-E GAMING WIFI"`, `get_board_info()` returns NULL,
  `asus_ec_probe()` returns `-ENODEV`. After → board matches and probe
  proceeds with correct sensor/mutex config.
- **Path affected:** Driver probe on matching DMI hardware only.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Hardware enablement / board ID addition (DMI quirk
  equivalent)
- **Mechanism:** Missing DMI entry prevents driver binding; not a
  runtime crash bug. Wrong mutex/sensor map (if guessed from B850-I)
  could cause incorrect EC access — the patch supplies board-owner-
  validated configuration.

### Step 2.4: Fix Quality Assessment
**Record:**
- **Quality:** High. Follows the exact pattern of
  `board_info_strix_b850_i_gaming_wifi` (commit `25b2c02e5b1f8`) and
  other ATX boards using `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0`
  (e.g. `board_info_strix_x670e_e_gaming_wifi`).
- **Regression risk:** Very low — only adds a new DMI match; existing
  boards unaffected.
- **Red flags:** None.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame Changed Lines
**Record:** Commit not yet in this tree. Sister board B850-I was added
by `25b2c02e5b1f8` (2025-07-28, merged via `989253cc46ff3` hwmon-
for-v6.18-rc1). `family_amd_800_series` introduced in `2c8ac03aad7a8`
(ROG STRIX X870E-E GAMING WIFI). All prerequisite infrastructure
predates 6.18.44.

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

### Step 3.3: File History for Related Changes
**Record:** Recent `asus-ec-sensors.c` changes on `stable/linux-6.18.y`
after v6.18.0 are bug fixes only (`ENOMEM` handling, EC read intervals,
bank looping, T_Sensor fix for PRIME X670E-PRO WIFI). No new board
additions were backported post-v6.18.0. B850-I and other boards arrived
via the v6.18-rc1 merge. This commit would be the first post-release
board addition for this driver in 6.18.y, but that is precedent context,
not a disqualifier.

### Step 3.4: Author's Other Commits
**Record:** Eugene Shalygin is an active `asus-ec-sensors` contributor
(e.g. B850-I co-author, multiple board/fix commits). Guenter Roeck is
the hwmon maintainer and committed the patch.

### Step 3.5: Dependent/Prerequisite Commits
**Record:** No series dependency. Requires only existing infrastructure
in this tree:
- `asus-ec-sensors` driver ✓
- `family_amd_800_series` ✓
- `SENSOR_TEMP_T_SENSOR`, `SENSOR_FAN_CPU_OPT` ✓
- `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0` ✓
- B850-I support (`25b2c02e5b1f8`) ✓
Standalone backport.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:** Lore URL blocked by Anubis bot protection (could not read
thread). GitHub PR #105 (merged 2026-04-18, author `leimh`) confirms
hardware-owner testing; board config includes T-Sensor header and
dedicated hardware mutex. Label `mainlined` added. `b4 dig` without
commit hash failed; `b4 dig -c 25b2c02e5b1f8` worked for the related
B850-I patch only.

### Step 4.2: Reviewers
**Record:** Guenter Roeck (maintainer) Signed-off-by on commit. GitHub
review by `zeule` (asus-ec-sensors maintainer) before merge.

### Step 4.3: Bug Report
**Record:** No formal bug report. Hardware validation via GitHub PR #105
from a B850-E owner. Symptom: missing sensor support, not a kernel oops.

### Step 4.4: Related Patches/Series
**Record:** Standalone 1/1 patch. Related: B850-I addition
(`25b2c02e5b1f8`) already in tree; B850-E extends the same product line
with different sensor/mutex layout.

### Step 4.5: Stable Mailing List History
**Record:** Not searched (lore access blocked). No stable nomination
found in available sources.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** No functions modified. Data consumed by `get_board_info()` →
`asus_ec_probe()`.

### Step 5.2: Callers
**Record:** `get_board_info()` called from `asus_ec_probe()` (line
1256). `asus_ec_probe()` is the platform driver probe callback — runs at
boot/module load on ASUS boards with `CONFIG_SENSORS_ASUS_EC=y/m`.

### Step 5.3: Callees
**Record:** `dmi_first_match(dmi_table)` performs string match against
DMI board name; returns `ec_board_info` pointer used for sensor bitmask,
mutex path, and family selection.

### Step 5.4: Call Chain / Reachability
**Record:** Boot-time platform driver probe → DMI match → hwmon device
registration. Reachable on every boot for B850-E owners with the driver
enabled. Not a syscall-triggered path; not unprivileged-user
triggerable.

### Step 5.5: Similar Patterns
**Record:** Identical pattern to B850-I (`25b2c02e5b1f8`), X670E-E,
X870-I, and dozens of other `DMI_EXACT_MATCH_ASUS_BOARD_NAME` entries in
the same file (44 total matches).

---

## Phase 6: Cross-Referencing Against Local Tree

### Step 6.1: Does Buggy/Missing Code Exist?
**Record:** Local tree is **linux-6.18.y at v6.18.44** (`git describe
HEAD` → `v6.18.44`). `B850-E` is **not** present; `B850-I` **is**
present. Without this patch, B850-E users get `-ENODEV` from
`asus_ec_probe()`. All patch dependencies exist.

### Step 6.2: Backport Complications
**Record:** Expected **clean apply**. Insertion anchors verified in
current tree:
- After `board_info_strix_b650e_i_gaming` (lines 575–580)
- Before `board_info_strix_b850_i_gaming_wifi` (lines 582–587)
- DMI table between B650E-I and B850-I entries (lines 775–778)
- Docs between B650E-I and B850-I (lines 30–31)

### Step 6.3: Related Fixes Already Present?
**Record:** No B850-E entry or equivalent fix present. B850-I support
already in tree as the closest reference implementation.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** `drivers/hwmon/` — **PERIPHERAL** (board-specific sensor
driver). Affects only users of `CONFIG_SENSORS_ASUS_EC` on this specific
motherboard.

### Step 7.2: Subsystem Activity
**Record:** Actively maintained; 4 bug-fix backports to this driver
since v6.18.0, plus many board additions in the v6.18-rc1 merge.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** **Driver-specific / platform-specific** — owners of ROG
STRIX B850-E GAMING WIFI running `CONFIG_SENSORS_ASUS_EC`.

### Step 8.2: Trigger Conditions
**Record:** Every boot with matching DMI and driver enabled. Common for
target hardware. Not security-relevant; not userspace-triggerable.

### Step 8.3: Failure Mode Severity
**Record:** Without patch: no hwmon sensors (temperature/fan monitoring
unavailable via this driver); probe returns `-ENODEV`. **Severity: LOW**
— functional gap, not crash/corruption/deadlock. Fan control may fall
back to BIOS/EC defaults.

### Step 8.4: Risk-Benefit Ratio
**Record:**
- **Benefit:** Enables correct thermal/fan monitoring on a current AM5
  board for stable-kernel users; validated by hardware owner.
- **Risk:** Very low (~11 lines, data-only, no logic changes).
- **Ratio:** Favorable. Matches the stable-tree exception for
  device/board ID additions explicitly allowed in
  `Documentation/process/stable-kernel-rules.rst`.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Explicitly allowed by stable rules: "just add a device ID" (`stable-
  kernel-rules.rst` line 15)
- DMI board entry is the hwmon equivalent of a device ID/quirk
- Tiny, surgical, obviously correct
- All prerequisites present in 6.18.44 (driver, `family_amd_800_series`,
  B850-I precedent, mutex path, sensor flags)
- Hardware-validated via GitHub PR #105
- Maintainer (Guenter Roeck) signed off
- Sister board B850-I already supported in this tree

**AGAINST backport:**
- Does not fix a crash, security issue, or data corruption
- No post-v6.18.0 board-addition backports for this driver (only bug
  fixes) — conservative precedent
- Affects a narrow hardware population

**Unresolved:**
- Full lore review thread inaccessible (Anubis block)
- Exact mainline commit SHA not in local tree (not needed for
  applicability assessment)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — pattern proven by sibling
   boards; GitHub PR from hardware owner; maintainer SOB.
2. Fixes a real bug affecting users? **PASS (exception)** — not a
   runtime bug, but stable rules explicitly allow device/board ID
   additions for hardware enablement.
3. Important issue? **PASS (exception)** — hardware quirk/ID category;
   enables monitoring on real production hardware.
4. Small and contained? **PASS** — ~11 lines, 2 files, data only.
5. No new features/APIs? **PASS** — no new APIs; board table entry only.
6. Can apply to local tree? **PASS** — prerequisites present; clean
   insertion points verified.

### Step 9.3: Exception Category
**Record:** Device/board ID addition to an existing driver (DMI quirk
equivalent). Driver `asus-ec-sensors` and `family_amd_800_series`
already exist; only the board entry is new.

### Step 9.4: Decision Rationale

For **linux-6.18.y (v6.18.44)**, this commit should be backported. It is
a minimal DMI board-table addition to an existing, already-shipped
driver — the same category explicitly permitted by stable-kernel rules
alongside PCI/USB ID additions. The B850-E is not covered by the
existing B850-I entry (different mutex path and additional T-Sensor).
Without it, owners of this board on 6.18.y get no `asus-ec-sensors`
support despite the driver and AMD 800-series infrastructure already
being present. Risk is negligible.

---

## Verification

- [Phase 1] Parsed subject, tags, body; no Fixes:/syzbot tags; Link to
  lore present
- [Phase 1] GitHub PR #105 fetched: merged, hardware-owner tested,
  T-Sensor + mutex noted
- [Phase 2] Diff inventory: 2 files, ~11 lines, static data only
- [Phase 2] Read `asus_ec_probe()` lines 1256–1258: `-ENODEV` when
  `get_board_info()` returns NULL
- [Phase 3] `git describe HEAD` → `v6.18.44`; `make kernelversion` →
  `6.18.44`
- [Phase 3] `git log --grep="B850-E"` → no commit in tree; B850-I at
  `25b2c02e5b1f8` confirmed in tree
- [Phase 3] `git blame` lines 582–587 → B850-I added by `25b2c02e5b1f8`
- [Phase 3] `git log v6.18.44 --not v6.18 -- drivers/hwmon/asus-ec-
  sensors.c` → 4 bug-fix backports only, no board additions
- [Phase 4] Lore fetch blocked by Anubis; GitHub PR #105 verified
  instead
- [Phase 4] `b4 dig -c 25b2c02e5b1f8` → B850-I lore URL (related patch
  only)
- [Phase 5] `get_board_info()` at line 1233; `asus_ec_probe()` at line
  1241; DMI table at line 728
- [Phase 5] `family_amd_800_series` case at line 1279 confirmed
- [Phase 6] `grep B850-E` in tree → not found; `grep B850-I` → present
- [Phase 6] Insertion anchor lines 575–587, 775–778, docs 30–31 verified
  by reading files
- [Phase 6] `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0` used by
  existing boards (e.g. X670E-E line 625)
- [Phase 7] `CONFIG_SENSORS_ASUS_EC` in `drivers/hwmon/Kconfig` line
  2704; built via `drivers/hwmon/Makefile`
- [Phase 8] `Documentation/process/stable-kernel-rules.rst` line 15: "or
  just add a device ID"
- [Phase 8] Failure without patch: `-ENODEV`, no sensors — severity LOW,
  not crash
- UNVERIFIED: Full lore.kernel.org review thread (blocked)
- UNVERIFIED: Exact mainline commit SHA (not in local tree; irrelevant
  to 6.18.y applicability)

**YES**The analysis is complete for **linux-6.18.y (v6.18.44)**.

**Commit:** `hwmon: (asus-ec-sensors) add ROG STRIX B850-E GAMING WIFI`
**What it does:** Adds a DMI board entry and sensor config (~11 lines)
so the existing `asus-ec-sensors` driver works on the ROG STRIX B850-E
(CPU/MB/VRM temps, T-Sensor, CPU_OPT fan). Sister board B850-I is
already supported in this tree; B850-E is not.

**Verdict: YES** — This is a small board-ID addition to an existing
driver, explicitly allowed under stable rules (“just add a device ID”).
All prerequisites (`family_amd_800_series`, mutex paths, sensor flags)
are present in 6.18.44. Risk is very low; benefit is real hardware
enablement validated via GitHub PR #105.

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

diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index a5a58c00c3223..a8456f29db950 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -28,6 +28,7 @@ Supported boards:
  * ROG STRIX B550-E GAMING
  * ROG STRIX B550-I GAMING
  * ROG STRIX B650E-I GAMING WIFI
+ * ROG STRIX B850-E GAMING WIFI
  * ROG STRIX B850-I GAMING WIFI
  * ROG STRIX X570-E GAMING
  * ROG STRIX X570-E GAMING WIFI II
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index 13fd212ad4040..57b771d96d4f0 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -579,6 +579,14 @@ static const struct ec_board_info board_info_strix_b650e_i_gaming = {
 	.family = family_amd_600_series,
 };
 
+static const struct ec_board_info board_info_strix_b850_e_gaming_wifi = {
+	.sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
+		SENSOR_TEMP_MB | SENSOR_TEMP_VRM |
+		SENSOR_TEMP_T_SENSOR | SENSOR_FAN_CPU_OPT,
+	.mutex_path = ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0,
+	.family = family_amd_800_series,
+};
+
 static const struct ec_board_info board_info_strix_b850_i_gaming_wifi = {
 	.sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
 		SENSOR_TEMP_MB | SENSOR_TEMP_VRM,
@@ -774,6 +782,8 @@ static const struct dmi_system_id dmi_table[] = {
 					&board_info_strix_b550_i_gaming),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B650E-I GAMING WIFI",
 					&board_info_strix_b650e_i_gaming),
+	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B850-E GAMING WIFI",
+					&board_info_strix_b850_e_gaming_wifi),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B850-I GAMING WIFI",
 					&board_info_strix_b850_i_gaming_wifi),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX X570-E GAMING",
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18] hwmon: (asus-ec-sensors) add ROG STRIX B850-E GAMING WIFI

[sashiko-bot]

> From: Eugene Shalygin <eugene.shalygin@gmail.com>
> 
> [ Upstream commit 5e9f31543515d685cafed33274433b6360c0e1e4 ]
> 
> The board has a similar sensor configuration to the
> ROG STRIX B850-I GAMING WIFI, but includes an additional
> T-Sensor header. The patch was provided via GitHub [1].
> 
> [1] https://github.com/zeule/asus-ec-sensors/pull/105
> 
> Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
> Link: https://lore.kernel.org/r/20260607123626.100630-1-eugene.shalygin@gmail.com
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-440-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-5.10] hwmon: (adt7462) Add of_match_table to support devicetree

[Sasha Levin]

From: Kory Maincent <kory.maincent@bootlin.com>

[ Upstream commit cd1b42617aafe01810ab7d3b9948d2f5fa9fb8af ]

Add of_match_table to add support of devicetree probing.

Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[rgantois: Removed of_match_ptr().]
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
Link: https://lore.kernel.org/r/20260608-adt7462-bindings-v2-1-272982c40325@bootlin.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:

# Stable Backport Analysis: `hwmon: (adt7462) Add of_match_table to
support devicetree`

**Local tree:** `v6.18.44` (Makefile: VERSION=6, PATCHLEVEL=18,
SUBLEVEL=44)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
**Record:** `[hwmon/adt7462]` `[Add]` — Add `of_match_table` to enable
Device Tree probing for the existing ADT7462 hwmon driver.

### Step 1.2: Tags
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none (Guenter Roeck committed it as hwmon
  maintainer)
- **Acked-by:** — none
- **Link:** https://lore.kernel.org/r/20260608-adt7462-bindings-v2-1-
  272982c40325@bootlin.com
- **Cc: stable:** — none
- **Signed-off-by:** Kory Maincent, Romain Gantois (noted removal of
  `of_match_ptr()`), Guenter Roeck

No syzbot, no user bug reports, no explicit stable nomination in commit
message.

### Step 1.3: Body Analysis
**Record:**
- **Bug described:** The ADT7462 I2C hwmon driver lacks an
  `of_match_table`, so it cannot be probed via Device Tree even when a
  DT node declares `compatible = "onnn,adt7462"`.
- **Symptom:** Fan controller / temperature monitor chip is not bound on
  DT-based platforms; hwmon sensors never appear.
- **Root cause:** Driver was written for legacy I2C detect probing only;
  DT binding was added separately without the corresponding driver OF
  table.

### Step 1.4: Hidden Bug Fix?
**Record:** Not a crash/leak/race fix. This is **hardware enablement** —
completing DT integration that was partially merged. The driver probe
path itself is unchanged; only the matching mechanism is added.
Classified as a functional gap, not a hidden memory-safety fix.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/hwmon/adt7462.c` — +8 lines, 0 removed
- **Functions modified:** None functionally; changes are at
  module/driver registration level
- **Scope:** Single-file, surgical addition

### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (include):** Adds `#include <linux/mod_devicetable.h>` for
  `MODULE_DEVICE_TABLE(of, ...)`.
- **Hunk 2 (of_match table):** Adds `adt7462_of_match[]` with `{
  .compatible = "onnn,adt7462" }` and `MODULE_DEVICE_TABLE(of, ...)`.
- **Hunk 3 (driver struct):** Sets `.of_match_table = adt7462_of_match`
  in `adt7462_driver`.
- **Before:** I2C core could only match via `id_table` or legacy
  `.detect` on non-DT buses.
- **After:** I2C core can match DT nodes with `compatible =
  "onnn,adt7462"` to this driver.

### Step 2.3: Bug Mechanism
**Record:** **Category (h): Hardware/DT enablement.** On DT platforms,
I2C devices are instantiated from the device tree at boot. Without
`of_match_table`, the I2C subsystem has no way to associate the DT node
with `adt7462_driver`. The `.detect` callback is not used for OF-
instantiated devices.

### Step 2.4: Fix Quality
**Record:** Obviously correct — standard pattern used by dozens of hwmon
drivers in this tree (e.g., `tmp108.c`, `ltc4282.c`, `sht4x.c`). Minimal
diff. No regression risk for non-DT users (OF table is only consulted
for DT nodes). Romain Gantois removed unnecessary `of_match_ptr()`
wrapper per maintainer feedback.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** `adt7462_driver` structure dates to 2014 (commit
`a2cc242823399`). Driver has never had `of_match_table`. `.probe`
updated in 2023 (`1975d167869ef`). The "bug" is longstanding absence of
DT support, exposed when DT binding and board DTS were added in
6.13/6.14.

### Step 3.2: Fixes: Tag
**Record:** Not applicable — no `Fixes:` tag present.

### Step 3.3: Related File History
**Record:**
- `3d973b98d2744` (v6.13): `dt-bindings: trivial-devices: add
  onnn,adt7462` — binding added
- `de153911ffcb6` (v6.14): `ARM: dts: aspeed: Add device tree for
  Ampere's Mt. Jefferson BMC` — board DTS with `compatible =
  "onnn,adt7462"` at i2c8:0x5c
- `cd1b42617aafe` (v7.2, NOT in this tree): driver OF table added
- Both binding and Jefferson DTS are ancestors of HEAD (v6.18.44);
  driver fix is NOT

### Step 3.4: Author Context
**Record:** Kory Maincent and Romain Gantois (Bootlin). Guenter Roeck
(hwmon maintainer) committed. No prior hwmon commits from these authors
in this tree. Maintainer-reviewed and accepted.

### Step 3.5: Dependencies
**Record:** Standalone — no prerequisite commits. Requires only that
`onnn,adt7462` binding exist (present since v6.13) and that `adt7462.c`
driver exist (present since v4.x). Patch applies cleanly (`git apply
--check` succeeded).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original Discussion
**Record:** `b4 dig -c cd1b42617aafe` found thread at https://patch.msgi
d.link/20260608-adt7462-bindings-v2-1-272982c40325@bootlin.com. Part of
a 2-patch series (v1 added binding, v2 added driver OF table). Lore page
blocked by bot protection — could not read review thread content.

### Step 4.2: Reviewers
**Record:** `b4 dig -w` shows CC to Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Petazzoni, linux-hwmon@,
devicetree@, linux-kernel@. Appropriate maintainers included.

### Step 4.3: Bug Reports
**Record:** No bug reports, syzbot links, or bugzilla references.

### Step 4.4: Series Context
**Record:** v1 (2026-06-03) added DT binding; v2 (2026-06-08) added
driver OF table. Binding portion was already merged separately in v6.13
(`3d973b98d2744`); only the driver portion remains missing from this
tree.

### Step 4.5: Stable List History
**Record:** Not searched (lore blocked). No stable nomination found in
commit message.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** No functions modified. Changes affect `adt7462_of_match[]`
(new), `adt7462_driver` (registration), and module tables.

### Step 5.2: Callers
**Record:** `adt7462_probe()` is called by I2C core during device
binding. Currently unreachable from DT on Ampere Jefferson; after fix,
reachable when DT node `fan-controller@5c` with `compatible =
"onnn,adt7462"` is present.

### Step 5.3: Callees
**Record:** `adt7462_probe()` uses `devm_kzalloc`,
`devm_hwmon_device_register_with_groups` — unchanged.

### Step 5.4: Reachability
**Record:** On Ampere Mt. Jefferson BMC (`aspeed-bmc-ampere-
mtjefferson.dts`), the ADT7462 fan controller at I2C bus 8, address 0x5c
is declared in DT. Without this fix, no driver binds. With fix, probe
runs at boot on that platform. Not reachable from userspace syscalls;
platform-specific embedded path.

### Step 5.5: Similar Patterns
**Record:** Standard hwmon DT enablement pattern. Similar commit:
`393de14673d60 hwmon: (sht21) Add devicetree support` (+13 lines, same
pattern).

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

### Step 6.1: Buggy Code Exists?
**Record:** **YES.** `drivers/hwmon/adt7462.c` in v6.18.44 lacks
`of_match_table` (verified: no matches for `adt7462_of_match`). DT
binding (`onnn,adt7462` in `trivial-devices.yaml`, since v6.13) and
board DTS (`aspeed-bmc-ampere-mtjefferson.dts`, since v6.14) are both
present. The integration is incomplete in this tree.

### Step 6.2: Backport Complications
**Record:** **Clean apply.** `git apply --check` on commit diff
succeeded with no conflicts.

### Step 6.3: Related Fixes Already Present?
**Record:** None. `git log --grep="adt7462.*of_match"` found no matching
commit in HEAD. Binding commit `3d973b98d2744` is present; driver OF
table commit `cd1b42617aafe` is NOT.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
**Record:** `drivers/hwmon/` — **PERIPHERAL** (specific I2C sensor/fan
controller driver). Critical for BMC thermal management on affected
platform but not a core kernel path.

### Step 7.2: Activity
**Record:** hwmon subsystem actively maintained. adt7462 driver last
touched for struct initialization cleanup (`d8a66f3621c28`). Low churn
on this specific file.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
**Record:** **Platform-specific** — users of Ampere Mt. Jefferson BMC
(ASPEED AST2600) with `CONFIG_SENSORS_ADT7462=y/m`. Currently the only
in-tree DTS using `onnn,adt7462`. Enterprise server BMC deployments.

### Step 8.2: Trigger Conditions
**Record:** Boot on DT platform with `compatible = "onnn,adt7462"` node.
Deterministic — happens every boot on Jefferson BMC. Not triggerable by
unprivileged users; embedded platform init path.

### Step 8.3: Failure Mode Severity
**Record:** ADT7462 fan controller and temperature sensors never
initialize. No kernel crash, oops, or data corruption. **Severity:
MEDIUM** for affected platform (loss of fan monitoring/thermal
management on server BMC); **LOW** globally (single known board).

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Enables fan/thermal monitoring on Ampere Jefferson BMC;
  completes DT integration already shipped in this tree. Real hardware
  fix for a real platform.
- **Risk:** Very low — 8 lines, standard pattern, no logic changes, no
  impact on non-DT systems.
- **Ratio:** Moderate benefit for embedded/BMC users, very low risk.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- DT binding and Ampere Jefferson board DTS already shipped in v6.18.44
  without driver OF support — incomplete integration
- Fan controller is completely non-functional on Jefferson BMC without
  this fix
- Tiny (8 lines), obviously correct, applies cleanly
- Falls under stable **DT exception**: "Enabling already-supported
  hardware on new boards"
- Driver already exists; only adds matching glue for already-declared
  hardware
- Zero regression risk for existing non-DT users

**AGAINST backport:**
- Not a crash, security, corruption, or deadlock fix
- Technically adds DT probing capability (feature addition)
- Only one in-tree board currently affected
- No user bug reports or syzbot findings
- Binding was merged 3 major versions before driver fix — gap has
  existed since v6.14

**Unresolved:**
- Could not read lore review thread (bot protection) — stable nomination
  in review unverified

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — standard OF table pattern;
   maintainer-committed; no functional logic changes
2. Fixes real bug affecting users? **PASS** — DT-declared hardware is
   non-functional on Jefferson BMC in this tree
3. Important issue? **PASS (borderline)** — not crash/security, but loss
   of fan/thermal monitoring on server BMC is operationally significant
   for that platform
4. Small and contained? **PASS** — 8 lines, one file
5. No new features or APIs? **PASS with exception** — adds DT probing
   path, but qualifies under DT exception for enabling hardware on
   boards already in tree
6. Can apply to local tree? **PASS** — clean apply verified

### Step 9.3: Exception Category
**Record:** **Device Tree update** — enabling already-supported hardware
(ADT7462 via existing driver) on a board (Ampere Mt. Jefferson) whose
DTS and binding are already present in v6.18.44.

### Step 9.4: Decision Rationale

This tree (v6.18.44) already contains the `onnn,adt7462` DT binding
(since v6.13) and the Ampere Mt. Jefferson BMC device tree (since v6.14)
declaring a `fan-controller@5c` node. Without the driver's
`of_match_table`, that hardware cannot be driven — the I2C core has no
mechanism to bind the existing driver to the DT node. The commit
completes an integration that was partially merged into this stable
series.

While this is not a crash or security fix, it is a real functional
defect for the Jefferson BMC platform and fits the stable exception for
DT updates that enable hardware on boards already supported in-tree. The
patch is minimal, standard, and applies cleanly with no regression risk.

---

## Verification

- [Phase 1] Parsed commit `cd1b42617aafe`: subject, SOBs, Link tag; no
  Fixes/Reported-by/syzbot
- [Phase 2] Diff analysis: +8 lines in `adt7462.c`; adds include,
  `of_match_table`, `MODULE_DEVICE_TABLE(of)`
- [Phase 3] `git describe HEAD`: v6.18.44
- [Phase 3] `git blame` on driver struct: dates to 2014, never had OF
  table
- [Phase 3] `3d973b98d2744`: DT binding in tree since v6.13; confirmed
  ancestor of HEAD
- [Phase 3] `de153911ffcb6`: Jefferson DTS in tree since v6.14;
  confirmed ancestor of HEAD
- [Phase 3] `cd1b42617aafe`: NOT ancestor of HEAD; only on v7.2+
  branches
- [Phase 3] `git apply --check`: patch applies cleanly
- [Phase 4] `b4 dig -c cd1b42617aafe`: found lore thread; v1/v2 series
  identified
- [Phase 4] `b4 dig -w`: Guenter Roeck, Rob Herring, Krzysztof Kozlowski
  CC'd
- [Phase 4] Lore fetch: blocked by Anubis bot protection — review
  content UNVERIFIED
- [Phase 5] Grep `onnn,adt7462`: only in `aspeed-bmc-ampere-
  mtjefferson.dts` and binding YAML
- [Phase 5] Read DTS lines 466-472: `fan-controller@5c` with `compatible
  = "onnn,adt7462"`, `reg = <0x5c>`
- [Phase 5] Grep `adt7462_of_match` in tree: no matches (fix absent)
- [Phase 6] Read current `adt7462.c` lines 1811-1826: no
  `of_match_table` present
- [Phase 6] Compared with other hwmon drivers: standard `of_match_table`
  pattern confirmed
- [Phase 8] Failure mode: no driver binding on DT platform; fan/thermal
  sensors absent; severity MEDIUM for platform

**YES**

 drivers/hwmon/adt7462.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/hwmon/adt7462.c b/drivers/hwmon/adt7462.c
index 174dfee47f7a7..f935c3477b364 100644
--- a/drivers/hwmon/adt7462.c
+++ b/drivers/hwmon/adt7462.c
@@ -12,6 +12,7 @@
 #include <linux/hwmon.h>
 #include <linux/hwmon-sysfs.h>
 #include <linux/err.h>
+#include <linux/mod_devicetable.h>
 #include <linux/mutex.h>
 #include <linux/log2.h>
 #include <linux/slab.h>
@@ -1814,10 +1815,17 @@ static const struct i2c_device_id adt7462_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, adt7462_id);
 
+static const struct of_device_id adt7462_of_match[] = {
+	{ .compatible = "onnn,adt7462" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, adt7462_of_match);
+
 static struct i2c_driver adt7462_driver = {
 	.class		= I2C_CLASS_HWMON,
 	.driver = {
 		.name	= "adt7462",
+		.of_match_table = adt7462_of_match,
 	},
 	.probe		= adt7462_probe,
 	.id_table	= adt7462_id,
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] hwmon: (adt7462) Add of_match_table to support devicetree

[sashiko-bot]

> From: Kory Maincent <kory.maincent@bootlin.com>
> 
> [ Upstream commit cd1b42617aafe01810ab7d3b9948d2f5fa9fb8af ]
> 
> Add of_match_table to add support of devicetree probing.
> 
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> [rgantois: Removed of_match_ptr().]
> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
> Link: https://lore.kernel.org/r/20260608-adt7462-bindings-v2-1-272982c40325@bootlin.com
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-451-sashal@kernel.org?part=1