[PATCH AUTOSEL 6.19] hwmon: (asus-ec-sensors) add Pro WS TRX50-SAGE WIFI A

[PATCH AUTOSEL 6.19] hwmon: (asus-ec-sensors) add Pro WS TRX50-SAGE WIFI A

[Sasha Levin]

From: Robert McIntyre <rjmcinty@hotmail.com>

[ Upstream commit af7e57d444141ac9e77b57296d59c3e965c4c4fa ]

Adding support for Pro WS TRX50-SAGE WIFI A, which is identical
sensors-wise to Pro WS TRX50-SAGE WIFI

Signed-off-by: Robert McIntyre <rjmcinty@hotmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20251213200531.259435-4-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:

## Analysis

### Commit Message Analysis
This commit adds support for a new motherboard variant — the "Pro WS
TRX50-SAGE WIFI A" — to the asus-ec-sensors hwmon driver. The commit
message explicitly states that this board is "identical sensors-wise" to
the already-supported "Pro WS TRX50-SAGE WIFI".

### Code Change Analysis
The change is minimal and purely additive:

1. **Documentation**: Adds one line to `asus_ec_sensors.rst` listing the
   new board name in the supported boards list.

2. **Driver**: Adds two lines to the DMI matching table in `asus-ec-
   sensors.c`:
  ```c
  DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS TRX50-SAGE WIFI A",
  &board_info_pro_ws_trx50_sage_wifi),
  ```
  This reuses the **exact same** `board_info_pro_ws_trx50_sage_wifi`
  structure as the existing "Pro WS TRX50-SAGE WIFI" entry. No new
  board_info structure, no new sensor definitions, no new code paths —
  just a new DMI string mapping to an existing configuration.

### Classification: New Device ID / Board ID
This falls squarely into the **"New Device IDs"** exception category for
stable backports. It is analogous to adding a new PCI ID or USB ID to an
existing driver. The driver already exists and supports this hardware
configuration; only the board name string is different.

### Risk Assessment
- **Risk: Extremely low**. The change adds a DMI match entry that points
  to an already-tested board configuration. If the DMI doesn't match
  (user has a different board), this code is never reached. If it does
  match, it uses the same well-tested sensor configuration.
- **Scope**: 3 lines of actual code change (1 doc line + 2 driver
  lines).
- **Dependencies**: None. The `board_info_pro_ws_trx50_sage_wifi`
  structure and the `DMI_EXACT_MATCH_ASUS_BOARD_NAME` macro already
  exist in stable trees.
- **Regression potential**: Essentially zero — this cannot affect any
  existing board's behavior.

### User Impact
Without this patch, users with the "Pro WS TRX50-SAGE WIFI A"
motherboard variant have no hardware monitoring sensor support through
this driver, even though the hardware is identical to the already-
supported model. This is a real-world hardware enablement issue.

### Stable Criteria Check
- **Obviously correct**: Yes — trivial DMI table addition reusing
  existing config.
- **Fixes a real issue**: Yes — enables hardware monitoring on a board
  variant that should work but doesn't.
- **Small and contained**: Yes — 3 lines.
- **No new features**: Correct — this uses existing driver
  functionality; it just adds a new board name to match against.
- **No new APIs**: Correct.

**YES**

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

diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index 232885f24430d..b5e1bc7ac0643 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -10,6 +10,7 @@ Supported boards:
  * PRIME X670E-PRO WIFI
  * PRIME Z270-A
  * Pro WS TRX50-SAGE WIFI
+ * Pro WS TRX50-SAGE WIFI A
  * Pro WS X570-ACE
  * Pro WS WRX90E-SAGE SE
  * ProArt X570-CREATOR WIFI
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index 61b18b88ee8ff..a1445799e23d8 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -793,6 +793,8 @@ static const struct dmi_system_id dmi_table[] = {
 					&board_info_pro_art_x870E_creator_wifi),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS TRX50-SAGE WIFI",
 					&board_info_pro_ws_trx50_sage_wifi),
+	DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS TRX50-SAGE WIFI A",
+					&board_info_pro_ws_trx50_sage_wifi),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS WRX90E-SAGE SE",
 					&board_info_pro_ws_wrx90e_sage_se),
 	DMI_EXACT_MATCH_ASUS_BOARD_NAME("Pro WS X570-ACE",
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] hwmon: (nct6683) Add customer ID for ASRock Z590 Taichi

[Sasha Levin]

From: Anj Duvnjak <avian@extremenerds.net>

[ Upstream commit c0fa7879c9850bd4597740a79d4fac5ebfcf69cc ]

Add support for customer ID 0x1621 found on ASRock Z590 Taichi
boards using the Nuvoton NCT6686D embedded controller.

This allows the driver to instantiate without requiring the
force=1 module parameter.

Tested on two separate ASRock Z590 Taichi boards, both with
EC firmware version 1.0 build 01/25/21.

Signed-off-by: Anj Duvnjak <avian@extremenerds.net>
Link: https://lore.kernel.org/r/20251222220942.10762-1-avian@extremenerds.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:

## Analysis

### Commit Message Analysis

This commit adds a new customer ID (0x1621) for ASRock Z590 Taichi
boards to the nct6683 hwmon driver. The purpose is to allow the driver
to instantiate on these boards without requiring the `force=1` module
parameter. The commit has been tested on two separate boards.

### Code Change Analysis

The changes are minimal and straightforward:

1. **Documentation update** (`Documentation/hwmon/nct6683.rst`): Adds
   one line to the tested boards table listing the ASRock Z590 Taichi
   with its firmware version.

2. **Driver change** (`drivers/hwmon/nct6683.c`):
   - Adds a new `#define NCT6683_CUSTOMER_ID_ASROCK5 0x1621` constant.
   - Adds a new `case NCT6683_CUSTOMER_ID_ASROCK5: break;` in the
     `nct6683_probe()` switch statement.

### Classification

This is a **new device ID addition** to an existing driver — one of the
explicitly allowed exception categories for stable backports. The
pattern is identical to previous ASRock customer ID additions (ASROCK,
ASROCK2, ASROCK3, ASROCK4), following a well-established pattern in this
driver.

### Scope and Risk Assessment

- **Lines changed**: ~5 lines of actual code (1 define, 2 case statement
  lines), plus 1 documentation line.
- **Files touched**: 2 (documentation + driver).
- **Risk**: Essentially zero. The new case statement simply allows the
  probe function to proceed for this specific customer ID value instead
  of returning `-ENODEV`. It doesn't change any behavior for existing
  boards. The fallthrough to `break` is the same pattern used for all
  other recognized customer IDs.

### User Impact

Without this patch, users with ASRock Z590 Taichi boards must use
`force=1` to get hardware monitoring support. With this patch, the
driver works out of the box. This is a real usability improvement for
owners of this specific hardware — hwmon support means fan speed
monitoring, temperature readings, etc.

### Stability Indicators

- Tested on two separate boards by the patch author.
- Accepted by the hwmon maintainer (Guenter Roeck).
- Follows the exact same pattern as all prior customer ID additions in
  this driver.

### Dependency Check

No dependencies on other commits. The driver exists in all recent stable
trees, and the change is self-contained.

### Conclusion

This is a textbook example of a device ID addition to an existing driver
— trivial, zero-risk, tested, and enables hardware support for real
users. It meets all stable kernel criteria and falls squarely into the
"new device IDs" exception category.

**YES**

 Documentation/hwmon/nct6683.rst | 1 +
 drivers/hwmon/nct6683.c         | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Documentation/hwmon/nct6683.rst b/Documentation/hwmon/nct6683.rst
index 3e549ba95a15a..45eec9dd349aa 100644
--- a/Documentation/hwmon/nct6683.rst
+++ b/Documentation/hwmon/nct6683.rst
@@ -65,6 +65,7 @@ AMD BC-250			NCT6686D EC firmware version 1.0 build 07/28/21
 ASRock X570			NCT6683D EC firmware version 1.0 build 06/28/19
 ASRock X670E			NCT6686D EC firmware version 1.0 build 05/19/22
 ASRock B650 Steel Legend WiFi	NCT6686D EC firmware version 1.0 build 11/09/23
+ASRock Z590 Taichi		NCT6686D EC firmware version 1.0 build 01/25/21
 MSI B550			NCT6687D EC firmware version 1.0 build 05/07/20
 MSI X670-P			NCT6687D EC firmware version 0.0 build 09/27/22
 MSI X870E			NCT6687D EC firmware version 0.0 build 11/13/24
diff --git a/drivers/hwmon/nct6683.c b/drivers/hwmon/nct6683.c
index 6cda35388b24c..4a83804140386 100644
--- a/drivers/hwmon/nct6683.c
+++ b/drivers/hwmon/nct6683.c
@@ -181,6 +181,7 @@ superio_exit(int ioreg)
 #define NCT6683_CUSTOMER_ID_ASROCK2	0xe1b
 #define NCT6683_CUSTOMER_ID_ASROCK3	0x1631
 #define NCT6683_CUSTOMER_ID_ASROCK4	0x163e
+#define NCT6683_CUSTOMER_ID_ASROCK5	0x1621
 
 #define NCT6683_REG_BUILD_YEAR		0x604
 #define NCT6683_REG_BUILD_MONTH		0x605
@@ -1242,6 +1243,8 @@ static int nct6683_probe(struct platform_device *pdev)
 		break;
 	case NCT6683_CUSTOMER_ID_ASROCK4:
 		break;
+	case NCT6683_CUSTOMER_ID_ASROCK5:
+		break;
 	default:
 		if (!force)
 			return -ENODEV;
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.1] hwmon: (f71882fg) Add F81968 support

[Sasha Levin]

From: "Ji-Ze Hong (Peter Hong)" <peter_hong@fintek.com.tw>

[ Upstream commit e4a3d6f79c9933fece64368168c46d6cf5fc2e52 ]

Add hardware monitoring support for the Fintek F81968 Super I/O chip.
It is fully compatible with F81866.

Several products share compatibility with the F81866. To better distinguish
between them, ensure that the Product ID is displayed when the device is
probed.

Signed-off-by: Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw>
Link: https://lore.kernel.org/r/20251223051040.10227-1-peter_hong@fintek.com.tw
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit adds hardware monitoring support for a new Fintek F81968
Super I/O chip to the existing f71882fg hwmon driver. The commit message
explicitly states "It is fully compatible with F81866." Additionally, it
enhances the probe log message to include the Product ID (devid) for
better distinguishing between compatible products.

### Code Change Analysis

The changes are minimal and straightforward:

1. **New chip ID definition** (1 line): `#define SIO_F81968_ID 0x1806` -
   adds the device ID constant.

2. **New case in switch statement** (1 line): `case SIO_F81968_ID:` is
   added as a fall-through alongside the existing `SIO_F81866_ID` and
   `SIO_F81966_ID` cases, all mapping to `sio_data->type = f81866a`.
   This follows the exact same pattern as the existing F81966 which was
   also added as F81866-compatible.

3. **Enhanced log message** (2 lines changed): The `pr_info` message now
   includes `devid: %04x` to display the product ID during probe. This
   is a minor informational enhancement.

### Classification

This falls squarely into the **"New Device IDs"** exception category for
stable backporting:
- It adds a new chip ID to an **existing, mature driver** (f71882fg)
- The new chip (F81968) is declared **fully compatible** with F81866,
  which is already supported
- The pattern is identical to how F81966 was added (also as
  F81866-compatible)
- No new code paths, no new functionality beyond recognizing the ID

### Scope and Risk Assessment

- **Lines changed**: ~5 lines (1 define, 1 case label, 2-line log
  message change)
- **Files touched**: 1 (drivers/hwmon/f71882fg.c)
- **Risk**: Extremely low. The new ID simply falls through to an
  existing, well-tested code path (f81866a). The only other change is
  adding `devid` to a log message, which is trivially safe.
- **Regression potential**: Near zero. Existing hardware is completely
  unaffected.

### User Impact

Without this patch, users with F81968-based hardware get no hwmon
support (the driver prints "Unsupported Fintek device: 1806" and returns
-ENODEV). With this patch, their hardware monitoring works using the
proven F81866 code path. This is a real-world hardware enablement fix.

### Stability Indicators

- The author is from Fintek (the chip manufacturer), who has direct
  knowledge of chip compatibility
- The maintainer (Guenter Roeck) accepted it, and he is well-known for
  the hwmon subsystem
- The pattern matches exactly how previous compatible chips (F81966)
  were added

### Dependencies

None. The patch is completely self-contained and applies to any kernel
version that has the f71882fg driver with F81866/F81966 support.

### Decision

This is a textbook device ID addition to an existing driver - one of the
explicitly listed exceptions for stable backporting. It's tiny, zero-
risk, enables real hardware, and follows an established pattern in the
driver.

**YES**

 drivers/hwmon/f71882fg.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/f71882fg.c b/drivers/hwmon/f71882fg.c
index df83f9866fbcf..204059d2de6cd 100644
--- a/drivers/hwmon/f71882fg.c
+++ b/drivers/hwmon/f71882fg.c
@@ -51,6 +51,7 @@
 #define SIO_F81866_ID		0x1010	/* Chipset ID */
 #define SIO_F71858AD_ID		0x0903	/* Chipset ID */
 #define SIO_F81966_ID		0x1502	/* Chipset ID */
+#define SIO_F81968_ID		0x1806	/* Chipset ID */
 
 #define REGION_LENGTH		8
 #define ADDR_REG_OFFSET		5
@@ -2570,6 +2571,7 @@ static int __init f71882fg_find(int sioaddr, struct f71882fg_sio_data *sio_data)
 		break;
 	case SIO_F81866_ID:
 	case SIO_F81966_ID:
+	case SIO_F81968_ID:
 		sio_data->type = f81866a;
 		break;
 	default:
@@ -2599,9 +2601,9 @@ static int __init f71882fg_find(int sioaddr, struct f71882fg_sio_data *sio_data)
 	address &= ~(REGION_LENGTH - 1);	/* Ignore 3 LSB */
 
 	err = address;
-	pr_info("Found %s chip at %#x, revision %d\n",
+	pr_info("Found %s chip at %#x, revision %d, devid: %04x\n",
 		f71882fg_names[sio_data->type],	(unsigned int)address,
-		(int)superio_inb(sioaddr, SIO_REG_DEVREV));
+		(int)superio_inb(sioaddr, SIO_REG_DEVREV), devid);
 exit:
 	superio_exit(sioaddr);
 	return err;
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] hwmon: (emc2305) Fix a resource leak in emc2305_of_parse_pwm_child

[Sasha Levin]

From: Felix Gu <gu_0233@qq.com>

[ Upstream commit 2954ce672b7623478c1cfeb69e6a6e4042a3656e ]

When calling of_parse_phandle_with_args(), the caller is responsible
to call of_node_put() to release the reference of device node.
In emc2305_of_parse_pwm_child, it does not release the reference,
causing a resource leak.

Signed-off-by: Felix Gu <gu_0233@qq.com>
Link: https://lore.kernel.org/r/tencent_738BA80BBF28F3440301EEE6F9E470165105@qq.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:

Looking at the full function:

1. **Line 551**: `of_parse_phandle_with_args()` is called, which sets
   `args.np` to a device node with an incremented refcount.
2. **Line 553-554**: If `ret` is non-zero, we return early - but
   `args.np` is not set in the error case (the function failed), so no
   leak there.
3. **Line 581** (before patch): `return 0;` without calling
   `of_node_put(args.np)` - this is the leak.
4. **Line 581** (after patch): `of_node_put(args.np);` is added before
   `return 0;`.

The fix is correct. There's only one successful return path after
`of_parse_phandle_with_args()`, and that's the `return 0;` at the end.
The error return at line 554 doesn't need `of_node_put()` because
`of_parse_phandle_with_args()` failed and didn't set `args.np`.

### Classification

This is a **resource leak fix** — a missing `of_node_put()` call. This
is one of the most common types of stable backport fixes (reference
counting bugs). The device tree node reference count will never be
decremented, preventing the node from being freed.

### Scope and Risk Assessment

- **Size**: Single line addition — minimal.
- **Risk**: Essentially zero. `of_node_put()` is a standard, well-tested
  kernel API. Calling it on the `args.np` returned by
  `of_parse_phandle_with_args()` is the correct and expected pattern.
  This cannot introduce a regression.
- **Files affected**: 1 file, 1 line.

### User Impact

The emc2305 is a fan controller chip used in embedded systems. This leak
occurs every time the device tree parsing runs for each PWM child node.
While a single leaked reference is small, on systems with hot-plugging
or repeated probe/remove cycles, it accumulates. More importantly, this
is a correctness issue — violating the OF API contract.

### Stability Indicators

- The fix follows a well-established kernel pattern (of_node_put after
  of_parse_phandle_with_args).
- It was reviewed and accepted by the hwmon maintainer Guenter Roeck.
- It's a textbook one-line reference counting fix.

### Dependency Check

No dependencies. The `of_node_put()` API and the emc2305 driver have
been in the kernel for a long time.

### Conclusion

This is a textbook stable backport candidate:
- Fixes a real bug (device tree node reference leak)
- Obviously correct (standard kernel pattern)
- Minimal scope (one line)
- Zero regression risk
- No new features or API changes

**YES**

 drivers/hwmon/emc2305.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c
index ceae96c07ac45..67e82021da210 100644
--- a/drivers/hwmon/emc2305.c
+++ b/drivers/hwmon/emc2305.c
@@ -578,6 +578,7 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
 		data->pwm_output_mask |= EMC2305_OPEN_DRAIN << ch;
 	}
 
+	of_node_put(args.np);
 	return 0;
 }
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.6] hwmon: (nct6775) Add ASUS Pro WS WRX90E-SAGE SE

[Sasha Levin]

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

[ Upstream commit 246167b17c14e8a5142368ac6457e81622055e0a ]

Boards Pro WS WRX90E-SAGE SE has got a nct6775 chip, but by default there's
no use of it because of resource conflict with WMI method.

Add the board to the WMI monitoring list.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Tested-by: Marcus <shoes2ga@gmail.com>
Link: https://lore.kernel.org/r/20251231155316.2048-1-pauk.denis@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis
This commit adds a board identifier string ("Pro WS WRX90E-SAGE SE") to
the `asus_msi_boards[]` list in the nct6775 hwmon driver. The commit
message explains that this ASUS motherboard has an nct6775 hardware
monitoring chip, but it cannot be used by default due to a resource
conflict with WMI methods. Adding the board to the WMI monitoring list
resolves this conflict and enables hardware monitoring.

### Code Change Analysis
The change is a **single line addition** — inserting one string into an
alphabetically sorted list of board names:

```c
"Pro WS WRX90E-SAGE SE",
```

This is inserted between "Pro WS W790E-SAGE SE" and "ProArt
B650-CREATOR", maintaining alphabetical order. No logic changes, no new
functions, no structural modifications.

### Classification: Hardware Quirk / Device ID Addition
This falls squarely into the **"hardware quirks/workarounds"** exception
category for stable backports. The `asus_msi_boards[]` list is
effectively a board-level quirk table that tells the driver to use WMI-
based monitoring instead of direct I/O, resolving the resource conflict.
Without this entry, users of this specific motherboard cannot use
hardware monitoring at all.

### Stability Indicators
- **Tested-by:** Marcus confirmed the fix works on the actual hardware
- **Bug report link:**
  https://bugzilla.kernel.org/show_bug.cgi?id=204807 — this is a
  documented real-world issue
- **Reviewed and merged by:** Guenter Roeck, the hwmon subsystem
  maintainer
- **Pattern:** Identical to dozens of other board additions in this same
  file that have been backported to stable

### Risk Assessment
- **Risk: Extremely low.** Adding a string to a board match list cannot
  affect any other board or any other code path. The match is exact —
  only the "Pro WS WRX90E-SAGE SE" board is affected.
- **Scope:** Single line in a single file
- **Dependencies:** None — the WMI monitoring infrastructure already
  exists in stable trees
- **Regression potential:** Essentially zero

### User Impact
Without this fix, users of the ASUS Pro WS WRX90E-SAGE SE motherboard (a
workstation-class board) have no hardware monitoring capability. This is
a real user-reported bug (kernel bugzilla #204807) with a tested fix.

### Stable Criteria Check
1. **Obviously correct and tested:** Yes — single string addition,
   tested by user
2. **Fixes a real bug:** Yes — hardware monitoring doesn't work without
   it
3. **Important issue:** Yes — complete loss of hwmon functionality for
   this board
4. **Small and contained:** Yes — one line
5. **No new features:** Correct — enables existing functionality on
   specific hardware
6. **Applies cleanly:** Very likely — it's a simple list insertion

**YES**

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

diff --git a/drivers/hwmon/nct6775-platform.c b/drivers/hwmon/nct6775-platform.c
index c3a719aef1ace..555029dfe713f 100644
--- a/drivers/hwmon/nct6775-platform.c
+++ b/drivers/hwmon/nct6775-platform.c
@@ -1357,6 +1357,7 @@ static const char * const asus_msi_boards[] = {
 	"Pro WS W680-ACE IPMI",
 	"Pro WS W790-ACE",
 	"Pro WS W790E-SAGE SE",
+	"Pro WS WRX90E-SAGE SE",
 	"ProArt B650-CREATOR",
 	"ProArt B660-CREATOR D4",
 	"ProArt B760-CREATOR D4",
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] hwmon: (nct7363) Fix a resource leak in nct7363_present_pwm_fanin

[Sasha Levin]

From: Felix Gu <gu_0233@qq.com>

[ Upstream commit 4923bbff0bcffe488b3aa76829c829bd15b02585 ]

When calling of_parse_phandle_with_args(), the caller is responsible
to call of_node_put() to release the reference of device node.
In nct7363_present_pwm_fanin, it does not release the reference,
causing a resource leak.

Signed-off-by: Felix Gu <gu_0233@qq.com>
Link: https://lore.kernel.org/r/tencent_9717645269E4C07D3D131F52201E12E5E10A@qq.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 driver was first included in v6.13. This means it's only available
in relatively recent stable trees (6.13.y and later, if those are
maintained as stable). It won't be applicable to older LTS trees like
6.6.y or 6.1.y since the driver doesn't exist there.

### User Impact

For systems using the NCT7363Y hardware monitoring chip (common in
server/embedded platforms), this leak occurs during driver probe. While
a single leak may be small, in systems with deferred probing or module
load/unload cycles, it can accumulate. The fix ensures proper cleanup.

### Conclusion

This is a textbook stable backport candidate:
- **Obviously correct**: Standard `of_node_put()` pattern used thousands
  of times in the kernel
- **Fixes a real bug**: Resource leak on every probe
- **Minimal risk**: 1 line addition, correctly placed
- **Small and contained**: Single file, single function

The only caveat is that the driver is relatively new (v6.13+), so the
backport only applies to recent stable trees. But for those trees where
it applies, this is clearly appropriate.

**YES**

 drivers/hwmon/nct7363.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/nct7363.c b/drivers/hwmon/nct7363.c
index 71cef794835df..47fc1b4a0f3f9 100644
--- a/drivers/hwmon/nct7363.c
+++ b/drivers/hwmon/nct7363.c
@@ -349,6 +349,7 @@ static int nct7363_present_pwm_fanin(struct device *dev,
 	if (ret)
 		return ret;
 
+	of_node_put(args.np);
 	if (args.args[0] >= NCT7363_PWM_COUNT)
 		return -EINVAL;
 	data->pwm_mask |= BIT(args.args[0]);
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] hwmon: (dell-smm) Add support for Dell OptiPlex 7080

[Sasha Levin]

From: Armin Wolf <W_Armin@gmx.de>

[ Upstream commit 46c3e87a79179454f741f797c274dd25f5c6125e ]

The Dell OptiPlex 7080 supports the legacy SMM interface for reading
sensors and performing fan control. Whitelist this machine so that
this driver loads automatically.

Closes: https://github.com/Wer-Wolf/i8kutils/issues/16
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Acked-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20260104000654.6406-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:

## Analysis

### Commit Message Analysis

This commit adds a DMI whitelist entry for the Dell OptiPlex 7080 to the
`dell-smm-hwmon` driver. The commit message explains that this machine
supports the legacy SMM interface for reading sensors and performing fan
control, and the whitelist entry enables the driver to load
automatically on this hardware.

There's a linked issue (`https://github.com/Wer-
Wolf/i8kutils/issues/16`) showing a real user request for this support.

### Code Change Analysis

The change is a simple addition of a single DMI matching entry to the
`i8k_dmi_table[]` array:

```c
{
    .ident = "Dell OptiPlex 7080",
    .matches = {
        DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
        DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7080"),
    },
},
```

This is structurally identical to the existing entries for OptiPlex
7060, 7050, and 7040. The pattern uses `DMI_EXACT_MATCH` for the product
name (matching the convention of other OptiPlex entries), preventing
false matches with similarly named models.

### Classification

This falls squarely into the **device ID / hardware quirk / whitelist**
exception category. It's adding a machine identifier to an existing
driver's whitelist table so the driver auto-loads on that hardware.
Without this entry, the Dell OptiPlex 7080 doesn't get hardware
monitoring and fan control support from this driver (unless force-
loaded).

### Scope and Risk Assessment

- **Lines changed**: +7 lines (a single DMI table entry)
- **Files touched**: 1 (`drivers/hwmon/dell-smm-hwmon.c`)
- **Risk**: Extremely low. The entry only affects Dell OptiPlex 7080
  machines. It cannot affect any other hardware. The matching pattern is
  well-established and identical in structure to dozens of other entries
  in the same table.
- **Complexity**: Trivial

### User Impact

Users with Dell OptiPlex 7080 machines running stable kernels would
benefit from having hardware monitoring and fan control work
automatically. This is a desktop PC used in corporate
environments—exactly the kind of hardware that runs stable/LTS kernels.

### Stability Indicators

- **Acked-by**: Pali Rohár (co-maintainer of this driver)
- **Signed-off-by**: Guenter Roeck (hwmon maintainer)
- The existing driver framework is mature and well-tested
- The same pattern is used for many other Dell models already in the
  table

### Dependency Check

No dependencies. The driver and DMI matching infrastructure exist in all
relevant stable trees. This is a self-contained addition to a data
table.

### Conclusion

This is a textbook example of a hardware whitelist addition that is
appropriate for stable backporting. It enables existing, well-tested
driver functionality on a specific hardware platform. The change is
trivial, zero-risk to other systems, reviewed by the subsystem
maintainers, and benefits real users running stable kernels on Dell
OptiPlex 7080 desktops.

**YES**

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

diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 93143cfc157cf..038edffc1ac74 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -1325,6 +1325,13 @@ static const struct dmi_system_id i8k_dmi_table[] __initconst = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "MP061"),
 		},
 	},
+	{
+		.ident = "Dell OptiPlex 7080",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7080"),
+		},
+	},
 	{
 		.ident = "Dell OptiPlex 7060",
 		.matches = {
-- 
2.51.0