[PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo

[PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo

[Sasha Levin]

From: Rong Zhang <i@rong.moe>

[ Upstream commit e5d1e313d7b6272d6dfda983906d99f97ad9062b ]

The device ID of Strix Halo Data Fabric Function 3 has been in the tree
since commit 0e640f0a47d8 ("x86/amd_nb: Add new PCI IDs for AMD family
0x1a"), but is somehow missing from k10temp_id_table.

Add it so that it works out of the box.

Tested on Beelink GTR9 Pro Mini PC.

Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20250823180443.85512-1-i@rong.moe
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES – the added ID lets the existing k10temp driver bind to Strix Halo’s
DF3 device so users get temperature readings on that platform.

- `drivers/hwmon/k10temp.c:560` gains
  `PCI_DEVICE_ID_AMD_1AH_M70H_DF_F3`, fixing the current omission that
  prevents the module from attaching to Strix Halo’s Data Fabric
  function 3 and leaves its sensors unavailable.
- The constant already exists in released kernels
  (`include/linux/pci_ids.h:587`) and is used by the AMD northbridge
  driver (`arch/x86/kernel/amd_nb.c:98`), so the new table entry simply
  connects existing infrastructure; no functional code paths change.
- Scope is minimal (one ID entry, no new logic), making regression risk
  negligible; the patch has been verified on shipping hardware (Beelink
  GTR9 Pro).
- For stable backports, this applies cleanly to branches ≥ v6.10 where
  the PCI ID is defined; older long-term trees would first need commit
  0e640f0a47d8 (or an equivalent definition).

Natural next step: backport to the relevant stable lines that already
carry the Strix Halo PCI ID definition (6.10.y, upcoming 6.11.y, etc.).

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

diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index 2f90a2e9ad496..b98d5ec72c4ff 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -565,6 +565,7 @@ static const struct pci_device_id k10temp_id_table[] = {
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M20H_DF_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M50H_DF_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M60H_DF_F3) },
+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M70H_DF_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M90H_DF_F3) },
 	{ PCI_VDEVICE(HYGON, PCI_DEVICE_ID_AMD_17H_DF_F3) },
 	{}
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.12] hwmon: (dell-smm) Remove Dell Precision 490 custom config data

[Sasha Levin]

From: Armin Wolf <W_Armin@gmx.de>

[ Upstream commit ddb61e737f04e3c6c8299c1e00bf17a42a7f05cf ]

It turns out the second fan on the Dell Precision 490 does not
really support I8K_FAN_TURBO. Setting the fan state to 3 enables
automatic fan control, just like on the other two fans.
The reason why this was misinterpreted as turbo mode was that
the second fan normally spins faster in automatic mode than
in the previous fan states. Yet when in state 3, the fan speed
reacts to heat exposure, exposing the automatic mode setting.

Link: https://github.com/lm-sensors/lm-sensors/pull/383
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20250917181036.10972-2-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:

YES

- What it fixes
  - Corrects a long‑standing misinterpretation on Dell Precision 490:
    fan state 3 is automatic mode, not a manual “turbo” speed. Keeping
    `fan_max = I8K_FAN_TURBO` (3) wrongly exposed a manual level that
    the hardware doesn’t actually support, leading to incorrect sysfs
    behavior and user‑space control on that model.

- Scope and change details
  - Removes the model‑specific override for Precision 490:
    - Deletes the model enum entry `DELL_PRECISION_490` from
      `drivers/hwmon/dell-smm-hwmon.c:1390`.
    - Removes its `i8k_config_data` entry which set `.fan_mult = 1` and
      `.fan_max = I8K_FAN_TURBO` at `drivers/hwmon/dell-smm-
      hwmon.c:1395-1407` (only the Precision 490 block is removed).
    - Drops the DMI entry and associated `driver_data` hook in
      `i8k_config_dmi_table` at `drivers/hwmon/dell-smm-
      hwmon.c:1410-1435`.
  - No functional code paths are changed; only a DMI quirk is removed.

- Why the behavior is now correct and safer
  - With the quirk gone, the driver falls back to default limits:
    - `data->i8k_fan_max = fan_max ? : I8K_FAN_HIGH;` so max manual fan
      state defaults to 2, not 3 (drivers/hwmon/dell-smm-hwmon.c:1256).
      This prevents treating the special state 3 as a regular manual
      speed.
    - The driver already autodetects `fan_mult` (sets it to 1 if nominal
      RPM looks like true RPM): see autodetection at
      `drivers/hwmon/dell-smm-hwmon.c:1231`. So removing the
      Precision‑490 `fan_mult=1` override does not regress RPM
      reporting.
  - Correct sysfs reporting and control of automatic mode:
    - The driver interprets state 3 as “auto” (`I8K_FAN_AUTO == 3`;
      include/uapi/linux/i8k.h:36-41). When `i8k_fan_max` is 2, a
      returned state 3 is “> data->i8k_fan_max” and thus treated as
      auto, not a manual PWM value (drivers/hwmon/dell-smm-
      hwmon.c:956-960).
    - The `pwmX_enable` knob is only exposed when `i8k_fan_max <
      I8K_FAN_AUTO` (drivers/hwmon/dell-smm-hwmon.c:878). With the bad
      `fan_max=3` gone, Precision 490 now correctly gets `pwm_enable` to
      reflect/toggle auto mode per hardware behavior (and
      `hwmon_pwm_enable` reading maps auto to 2 at drivers/hwmon/dell-
      smm-hwmon.c:966-969).

- Historical context and correctness
  - The removed quirk dates back to i8k: “Add support for Dell Precision
    490 ...” which set `fan_max = I8K_FAN_TURBO` (commit 7b88344631536,
    in legacy i8k driver). Newer understanding (and documentation)
    clarified that several machines, including Precision 490, use state
    3 as a “magic” auto state rather than a manual turbo.
  - Documentation now reflects this behavior (Documentation/hwmon/dell-
    smm-hwmon.rst:360-366, 375).

- Stable backport criteria
  - Important user-visible bugfix: prevents exposing/allowing a
    non‑existent manual fan level and aligns sysfs with hardware
    behavior.
  - Small and contained: 14 line deletions in a single driver source
    file; no API/ABI changes; affects only Precision 490 via DMI.
  - Low regression risk: default paths are mature; `fan_mult`
    autodetection covers the removed override; no architectural changes.
  - No dependency on broader refactors: The removal stands alone. It
    synergizes with “automatic fan mode” support (mainline improvement),
    but even on older stable trees it simply avoids mislabeling 3 as a
    valid manual state.

- Conclusion
  - This is a classic quirk fix: minimal, model‑specific, and correcting
    wrong behavior. It should be backported to stable trees that still
    contain the Precision 490 DMI override so those kernels no longer
    misrepresent fan capabilities on that system.

 drivers/hwmon/dell-smm-hwmon.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 1e2c8e2840015..3f61b2d7935e4 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -1331,7 +1331,6 @@ struct i8k_config_data {
 
 enum i8k_configs {
 	DELL_LATITUDE_D520,
-	DELL_PRECISION_490,
 	DELL_STUDIO,
 	DELL_XPS,
 };
@@ -1341,10 +1340,6 @@ static const struct i8k_config_data i8k_config_data[] __initconst = {
 		.fan_mult = 1,
 		.fan_max = I8K_FAN_TURBO,
 	},
-	[DELL_PRECISION_490] = {
-		.fan_mult = 1,
-		.fan_max = I8K_FAN_TURBO,
-	},
 	[DELL_STUDIO] = {
 		.fan_mult = 1,
 		.fan_max = I8K_FAN_HIGH,
@@ -1364,15 +1359,6 @@ static const struct dmi_system_id i8k_config_dmi_table[] __initconst = {
 		},
 		.driver_data = (void *)&i8k_config_data[DELL_LATITUDE_D520],
 	},
-	{
-		.ident = "Dell Precision 490",
-		.matches = {
-			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-			DMI_MATCH(DMI_PRODUCT_NAME,
-				  "Precision WorkStation 490"),
-		},
-		.driver_data = (void *)&i8k_config_data[DELL_PRECISION_490],
-	},
 	{
 		.ident = "Dell Studio",
 		.matches = {
-- 
2.51.0

[PATCH AUTOSEL 6.17-5.15] hwmon: (sbtsi_temp) AMD CPU extended temperature range support

[Sasha Levin]

From: Chuande Chen <chuachen@cisco.com>

[ Upstream commit d9d61f1da35038793156c04bb13f0a1350709121 ]

Many AMD CPUs can support this feature now. We would get a wrong CPU DIE
temperature if don't consider this. In low-temperature environments,
the CPU die temperature can drop below zero. So many platforms would like
to make extended temperature range as their default configuration.
Default temperature range (0C to 255.875C).
Extended temperature range (-49C to +206.875C).
Ref Doc: AMD V3000 PPR (Doc ID #56558).

Signed-off-by: Chuande Chen <chuachen@cisco.com>
Link: https://lore.kernel.org/r/20250814053940.96764-1-chenchuande@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:

YES – the change teaches `sbtsi_temp` to respect the controller’s
“extended range” bit so temperatures below 0 °C are no longer
misreported as large positives on newer AMD parts.

- `drivers/hwmon/sbtsi_temp.c:18-46` adds the missing config-bit
  definitions and the 49 000 m°C offset constant so the driver
  understands the SB-TSI extended range encoding documented in AMD PPR
  #56558.
- `drivers/hwmon/sbtsi_temp.c:52-56` extends `struct sbtsi_data` with
  cached `ext_range_mode`/`read_order` flags, letting runtime reads know
  whether the hardware is in extended range without re-querying the bus
  each sample.
- `drivers/hwmon/sbtsi_temp.c:96-118` now subtracts the 49 °C offset
  whenever `ext_range_mode` is set, ensuring `hwmon_temp_input` reports
  negative values correctly instead of bogus 0…255 °C readings seen on
  V3000 systems.
- `drivers/hwmon/sbtsi_temp.c:140-151` adjusts temperature limit writes
  by adding the same offset before clamping, so user-configured min/max
  thresholds stay aligned with the hardware representation in extended
  range mode.
- `drivers/hwmon/sbtsi_temp.c:178-190` reads `SBTSI_REG_CONFIG` once
  during probe to populate the two flags using `FIELD_GET()`, preserving
  the previous read-order behavior while enabling the new range
  handling.

Impact review: the patch is self-contained to one driver, follows
existing data paths, and fixes a user-visible regression (bad die
temps/limits on systems that ship with extended range enabled). No
architectural churn, no new dependencies, and it relies solely on fields
present since the driver was introduced—so it backports cleanly to
supported stable trees. The only behavioral change beyond the bug fix is
caching the config bits; SB-TSI documentation treats them as static
device configuration, so caching them reduces I²C traffic without adding
realistic risk. Overall this is a low-risk correctness fix and a good
stable backport candidate. Suggested next step: queue for the relevant
stable series that carry `drivers/hwmon/sbtsi_temp.c`.

 drivers/hwmon/sbtsi_temp.c | 46 +++++++++++++++++++++++++-------------
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
index 3c839f56c4603..a6c439e376ff7 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/hwmon/sbtsi_temp.c
@@ -14,6 +14,7 @@
 #include <linux/module.h>
 #include <linux/mutex.h>
 #include <linux/of.h>
+#include <linux/bitfield.h>
 
 /*
  * SB-TSI registers only support SMBus byte data access. "_INT" registers are
@@ -29,8 +30,22 @@
 #define SBTSI_REG_TEMP_HIGH_DEC		0x13 /* RW */
 #define SBTSI_REG_TEMP_LOW_DEC		0x14 /* RW */
 
+/*
+ * Bit for reporting value with temperature measurement range.
+ * bit == 0: Use default temperature range (0C to 255.875C).
+ * bit == 1: Use extended temperature range (-49C to +206.875C).
+ */
+#define SBTSI_CONFIG_EXT_RANGE_SHIFT	2
+/*
+ * ReadOrder bit specifies the reading order of integer and decimal part of
+ * CPU temperature for atomic reads. If bit == 0, reading integer part triggers
+ * latching of the decimal part, so integer part should be read first.
+ * If bit == 1, read order should be reversed.
+ */
 #define SBTSI_CONFIG_READ_ORDER_SHIFT	5
 
+#define SBTSI_TEMP_EXT_RANGE_ADJ	49000
+
 #define SBTSI_TEMP_MIN	0
 #define SBTSI_TEMP_MAX	255875
 
@@ -38,6 +53,8 @@
 struct sbtsi_data {
 	struct i2c_client *client;
 	struct mutex lock;
+	bool ext_range_mode;
+	bool read_order;
 };
 
 /*
@@ -74,23 +91,11 @@ static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
 {
 	struct sbtsi_data *data = dev_get_drvdata(dev);
 	s32 temp_int, temp_dec;
-	int err;
 
 	switch (attr) {
 	case hwmon_temp_input:
-		/*
-		 * ReadOrder bit specifies the reading order of integer and
-		 * decimal part of CPU temp for atomic reads. If bit == 0,
-		 * reading integer part triggers latching of the decimal part,
-		 * so integer part should be read first. If bit == 1, read
-		 * order should be reversed.
-		 */
-		err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
-		if (err < 0)
-			return err;
-
 		mutex_lock(&data->lock);
-		if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
+		if (data->read_order) {
 			temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_DEC);
 			temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_INT);
 		} else {
@@ -122,6 +127,8 @@ static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
 		return temp_dec;
 
 	*val = sbtsi_reg_to_mc(temp_int, temp_dec);
+	if (data->ext_range_mode)
+		*val -= SBTSI_TEMP_EXT_RANGE_ADJ;
 
 	return 0;
 }
@@ -146,6 +153,8 @@ static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type,
 		return -EINVAL;
 	}
 
+	if (data->ext_range_mode)
+		val += SBTSI_TEMP_EXT_RANGE_ADJ;
 	val = clamp_val(val, SBTSI_TEMP_MIN, SBTSI_TEMP_MAX);
 	sbtsi_mc_to_reg(val, &temp_int, &temp_dec);
 
@@ -203,6 +212,7 @@ static int sbtsi_probe(struct i2c_client *client)
 	struct device *dev = &client->dev;
 	struct device *hwmon_dev;
 	struct sbtsi_data *data;
+	int err;
 
 	data = devm_kzalloc(dev, sizeof(struct sbtsi_data), GFP_KERNEL);
 	if (!data)
@@ -211,8 +221,14 @@ static int sbtsi_probe(struct i2c_client *client)
 	data->client = client;
 	mutex_init(&data->lock);
 
-	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data, &sbtsi_chip_info,
-							 NULL);
+	err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
+	if (err < 0)
+		return err;
+	data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), err);
+	data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), err);
+
+	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
+							 &sbtsi_chip_info, NULL);
 
 	return PTR_ERR_OR_ZERO(hwmon_dev);
 }
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based models

[Sasha Levin]

From: Avadhut Naik <avadhut.naik@amd.com>

[ Upstream commit f116af2eb51ed9df24911537fda32a033f1c58da ]

Add thermal info support for newer AMD Family 1Ah-based models.

Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Link: https://lore.kernel.org/r/20250729001644.257645-1-avadhut.naik@amd.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:

YES
- Adds missing device IDs for AMD Family 1Ah model 50h/90h locally in
  `drivers/hwmon/k10temp.c:86` so the stable tree doesn’t need header
  updates, keeping the change self‑contained and under the “just add a
  device ID” rule.
- Extends `k10temp_id_table` to match those IDs
  (`drivers/hwmon/k10temp.c:563` and `drivers/hwmon/k10temp.c:565`),
  letting the existing probe path bind on the new desktop parts; without
  it, users on those CPUs lose all `k10temp` temperature readouts.
- The runtime logic for Family 1Ah CPUs was already upstreamed earlier
  (see the 2023 support commit still present in this tree at
  `drivers/hwmon/k10temp.c:482`), so the new entries simply reuse a
  proven Zen5/1Ah code path with no behavioral changes for older
  systems.
- No collateral effects: no register programming changes, no new flows,
  and the driver keeps using the same SMN readouts, so regression risk
  is negligible while hardware coverage noticeably improves.

 drivers/hwmon/k10temp.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index babf2413d666f..2f90a2e9ad496 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -84,6 +84,13 @@ static DEFINE_MUTEX(nb_smu_ind_mutex);
  */
 #define AMD_I3255_STR				"3255"
 
+/*
+ * PCI Device IDs for AMD's Family 1Ah-based SOCs.
+ * Defining locally as IDs are not shared.
+ */
+#define PCI_DEVICE_ID_AMD_1AH_M50H_DF_F3	0x12cb
+#define PCI_DEVICE_ID_AMD_1AH_M90H_DF_F3	0x127b
+
 struct k10temp_data {
 	struct pci_dev *pdev;
 	void (*read_htcreg)(struct pci_dev *pdev, u32 *regval);
@@ -556,7 +563,9 @@ static const struct pci_device_id k10temp_id_table[] = {
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_19H_M78H_DF_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M00H_DF_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M20H_DF_F3) },
+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M50H_DF_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M60H_DF_F3) },
+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M90H_DF_F3) },
 	{ PCI_VDEVICE(HYGON, PCI_DEVICE_ID_AMD_17H_DF_F3) },
 	{}
 };
-- 
2.51.0

[PATCH AUTOSEL 6.17-5.4] hwmon: (dell-smm) Add support for Dell OptiPlex 7040

[Sasha Levin]

From: Armin Wolf <W_Armin@gmx.de>

[ Upstream commit 53d3bd48ef6ff1567a75ca77728968f5ab493cb4 ]

The Dell OptiPlex 7040 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/15
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20250917181036.10972-5-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:

YES

- Change scope and intent: The patch only adds a single DMI whitelist
  entry for “Dell OptiPlex 7040” to the legacy SMM allowlist used by the
  dell-smm hwmon driver. It adds a new block in `i8k_dmi_table` with
  explicit vendor and exact product matches, no other logic changes. See
  drivers/hwmon/dell-smm-hwmon.c:1334–1339.

- How it affects behavior: The i8k_dmi_table is consulted to decide if
  legacy SMM probing is permitted. If the system is not in this table,
  the driver refuses legacy SMM unless overridden by module params; with
  newer code it falls back to WMI. The gating is in
  `dell_smm_legacy_check()`, which returns -ENODEV when the DMI table
  doesn’t match and neither `ignore_dmi` nor `force` is set
  (drivers/hwmon/dell-smm-hwmon.c:1756–1761). Adding 7040 lets the
  driver load and use the legacy SMM path on that system automatically.

- Autoloading safety and containment: The driver exposes a DMI modalias
  and will auto-load only on machines matching this entry. The new match
  is guarded by both `DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc.")` and
  `DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7040")`, ensuring no
  unintended matches (drivers/hwmon/dell-smm-hwmon.c:1334–1338, 1378).

- Precedent and consistency: Neighboring entries for similar models,
  OptiPlex 7050 and 7060, already exist and were accepted
  (drivers/hwmon/dell-smm-hwmon.c:1320–1332). Extending coverage to the
  7040 is consistent with established support for this platform family
  and the commit message notes the 7040 supports legacy SMM for sensors
  and fan control.

- Risk assessment:
  - No architectural changes, no new interfaces; it’s a pure DMI
    whitelist addition in a single file.
  - SMM-specific risks are mitigated by existing vendor/model blacklists
    for known-problematic systems (e.g., fan support freeze blacklist;
    drivers/hwmon/dell-smm-hwmon.c:1482–1512). 7040 is not on any
    blacklist.
  - Security posture remains unchanged: fan control and serial number
    are already restricted by default to CAP_SYS_ADMIN (`restricted`
    default true; drivers/hwmon/dell-smm-hwmon.c:127–133).

- User impact: Fixes a real-world usability gap where the driver would
  not autoload on OptiPlex 7040 (previously requiring module parameters
  or leaving sensors/fan control unavailable). The commit references a
  user report (Closes: GitHub issue) and was accepted by the hwmon
  maintainer.

- Backport suitability:
  - Change is small, localized, and low risk.
  - It aligns with stable rules for adding device IDs to enable existing
    functionality.
  - Applies cleanly conceptually to older stable trees which also use
    `i8k_dmi_table` and `MODULE_DEVICE_TABLE(dmi, i8k_dmi_table)` (e.g.,
    v6.1, v6.6), even though line positions differ.

Given the minimal, well-scoped nature of the change and clear user
benefit without broader side effects, this is a good candidate for
stable backport.

 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 3f61b2d7935e4..5801128e16c3c 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -1280,6 +1280,13 @@ static const struct dmi_system_id i8k_dmi_table[] __initconst = {
 			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7050"),
 		},
 	},
+	{
+		.ident = "Dell OptiPlex 7040",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7040"),
+		},
+	},
 	{
 		.ident = "Dell Precision",
 		.matches = {
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.12] hwmon: (lenovo-ec-sensors) Update P8 supprt

[Sasha Levin]

From: David Ober <dober6023@gmail.com>

[ Upstream commit 43c056ac85b60232861005765153707f1b0354b6 ]

This fixes differences for the P8 system that was initially set to
the same thermal values as the P7, also adds in the PSU sensor for
all of the supported systems

Signed-off-by: David Ober <dober@lenovo.com>
Signed-off-by: David Ober <dober6023@gmail.com>
Link: https://lore.kernel.org/r/20250807103228.10465-1-dober6023@gmail.com
[groeck: Update subject]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
- Corrects the EC register map and labels so P8 machines stop reusing
  the P7 layout; the new `p8_temp_map` and dedicated label table at
  `drivers/hwmon/lenovo-ec-sensors.c:91` feed the right offsets to
  `lenovo_ec_do_read_temp`, fixing the bogus readings and misnamed
  DIMM/PCI sensors that users currently see.
- Adds the missing PSU temperature channels by wiring the indices into
  every platform map (`px_temp_map` with PSU1/PSU2 at
  `drivers/hwmon/lenovo-ec-sensors.c:69`, and the generic PSU entry at
  `drivers/hwmon/lenovo-ec-sensors.c:109`), and exposes them through the
  hwmon descriptors (`lenovo_ec_hwmon_info_*` blocks beginning at
  `drivers/hwmon/lenovo-ec-sensors.c:301`). This closes the gap where
  the EC already provided data but the driver silently dropped it.
- Updates the P8 probe path to select the new map/labels
  (`drivers/hwmon/lenovo-ec-sensors.c:571`), so only that SKU sees the
  remapped channels while P5/P7 keep the shared generic table plus the
  newly exposed PSU sensor.
- I checked the driver’s short history (only the initial add in
  70118f85e6538) and the surrounding hwmon subsystem; the change stays
  confined to this new platform driver, aligns array sizes, and avoids
  architectural churn, so regression risk is low. The only user-visible
  difference is the appearance/renaming of sensors to match the
  hardware, which is expected for a bug fix.

Given it fixes incorrect sensor data and restores missing thermal
telemetry on shipping systems, while touching only this young driver, it
fits the stable inclusion guidelines.

 drivers/hwmon/lenovo-ec-sensors.c | 34 +++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/lenovo-ec-sensors.c b/drivers/hwmon/lenovo-ec-sensors.c
index 143fb79713f7d..8681bbf6665b1 100644
--- a/drivers/hwmon/lenovo-ec-sensors.c
+++ b/drivers/hwmon/lenovo-ec-sensors.c
@@ -66,7 +66,7 @@ enum systems {
 	LENOVO_P8,
 };
 
-static int px_temp_map[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15};
+static int px_temp_map[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 31, 32};
 
 static const char * const lenovo_px_ec_temp_label[] = {
 	"CPU1",
@@ -84,9 +84,29 @@ static const char * const lenovo_px_ec_temp_label[] = {
 	"PCI_Z3",
 	"PCI_Z4",
 	"AMB",
+	"PSU1",
+	"PSU2",
 };
 
-static int gen_temp_map[] = {0, 2, 3, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15};
+static int p8_temp_map[] = {0, 1, 2, 8, 9, 13, 14, 15, 16, 17, 19, 20, 33};
+
+static const char * const lenovo_p8_ec_temp_label[] = {
+	"CPU1",
+	"CPU_DIMM_BANK1",
+	"CPU_DIMM_BANK2",
+	"M2_Z2R",
+	"M2_Z3R",
+	"DIMM_RIGHT",
+	"DIMM_LEFT",
+	"PCI_Z1",
+	"PCI_Z2",
+	"PCI_Z3",
+	"AMB",
+	"REAR_VR",
+	"PSU",
+};
+
+static int gen_temp_map[] = {0, 2, 3, 6, 7, 8, 9, 10, 11, 12, 13, 14, 31};
 
 static const char * const lenovo_gen_ec_temp_label[] = {
 	"CPU1",
@@ -101,6 +121,7 @@ static const char * const lenovo_gen_ec_temp_label[] = {
 	"PCI_Z3",
 	"PCI_Z4",
 	"AMB",
+	"PSU",
 };
 
 static int px_fan_map[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15};
@@ -293,6 +314,8 @@ static const struct hwmon_channel_info *lenovo_ec_hwmon_info_px[] = {
 			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL,
+			   HWMON_T_INPUT | HWMON_T_LABEL,
+			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL),
 	HWMON_CHANNEL_INFO(fan,
 			   HWMON_F_INPUT | HWMON_F_LABEL | HWMON_F_MAX,
@@ -327,6 +350,7 @@ static const struct hwmon_channel_info *lenovo_ec_hwmon_info_p8[] = {
 			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL,
+			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL),
 	HWMON_CHANNEL_INFO(fan,
 			   HWMON_F_INPUT | HWMON_F_LABEL | HWMON_F_MAX,
@@ -359,6 +383,7 @@ static const struct hwmon_channel_info *lenovo_ec_hwmon_info_p7[] = {
 			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL,
+			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL),
 	HWMON_CHANNEL_INFO(fan,
 			   HWMON_F_INPUT | HWMON_F_LABEL | HWMON_F_MAX,
@@ -388,6 +413,7 @@ static const struct hwmon_channel_info *lenovo_ec_hwmon_info_p5[] = {
 			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL,
+			   HWMON_T_INPUT | HWMON_T_LABEL,
 			   HWMON_T_INPUT | HWMON_T_LABEL),
 	HWMON_CHANNEL_INFO(fan,
 			   HWMON_F_INPUT | HWMON_F_LABEL | HWMON_F_MAX,
@@ -545,9 +571,9 @@ static int lenovo_ec_probe(struct platform_device *pdev)
 		break;
 	case 3:
 		ec_data->fan_labels = p8_ec_fan_label;
-		ec_data->temp_labels = lenovo_gen_ec_temp_label;
+		ec_data->temp_labels = lenovo_p8_ec_temp_label;
 		ec_data->fan_map = p8_fan_map;
-		ec_data->temp_map = gen_temp_map;
+		ec_data->temp_map = p8_temp_map;
 		lenovo_ec_chip_info.info = lenovo_ec_hwmon_info_p8;
 		break;
 	default:
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.1] hwmon: sy7636a: add alias

[Sasha Levin]

From: Andreas Kemnade <andreas@kemnade.info>

[ Upstream commit 80038a758b7fc0cdb6987532cbbf3f75b13e0826 ]

Add module alias to have it autoloaded.

Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://lore.kernel.org/r/20250909080249.30656-1-andreas@kemnade.info
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
**Rationale**
- Adding `MODULE_ALIAS("platform:sy7636a-temperature");` in
  `drivers/hwmon/sy7636a-hwmon.c:105` ensures udev can auto-load the
  module when the MFD core registers the `sy7636a-temperature` platform
  device. Today the driver lacks any `MODULE_ALIAS` or
  `MODULE_DEVICE_TABLE`, so built-as-module systems never bind
  automatically and the hwmon sensor stays unavailable unless manually
  `modprobe`d—an obvious functional bug.
- The platform child is created by `drivers/mfd/simple-mfd-i2c.c:66-73`,
  which exposes the `sy7636a-temperature` modalias; the regulator
  sibling already has a matching alias via its platform ID table
  (`drivers/regulator/sy7636a-regulator.c:122-134`), highlighting that
  the hwmon side simply missed the same piece.
- History (`git log -- drivers/hwmon/sy7636a-hwmon.c`) shows the driver
  has shipped without an alias since it was introduced in commit
  de34a40532507 (Jan 2022), so every stable kernel carrying this driver
  is affected.
- The fix is a one-line metadata change with no runtime impact beyond
  enabling the intended autoload path, so regression risk is negligible
  and it squarely fits stable rules.

**Next Steps**
1. Queue the patch for all supported stable trees that include
   `drivers/hwmon/sy7636a-hwmon.c`.

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

diff --git a/drivers/hwmon/sy7636a-hwmon.c b/drivers/hwmon/sy7636a-hwmon.c
index ed110884786b4..a12fc0ce70e76 100644
--- a/drivers/hwmon/sy7636a-hwmon.c
+++ b/drivers/hwmon/sy7636a-hwmon.c
@@ -104,3 +104,4 @@ module_platform_driver(sy7636a_sensor_driver);
 
 MODULE_DESCRIPTION("SY7636A sensor driver");
 MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:sy7636a-temperature");
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.1] hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex

[Sasha Levin]

From: Ben Copeland <ben.copeland@linaro.org>

[ Upstream commit 584d55be66ef151e6ef9ccb3dcbc0a2155559be1 ]

Some motherboards require more time to acquire the ACPI mutex,
causing "Failed to acquire mutex" messages to appear in the kernel log.
Increase the timeout from 500ms to 800ms to accommodate these cases.

Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20250923192935.11339-3-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

- Minimal, targeted change: The patch only increases the wait timeout
  constant from 500 ms to 800 ms by changing `#define ACPI_LOCK_DELAY_MS
  500` to 800 in `drivers/hwmon/asus-ec-sensors.c:52`. There are no
  logic or structural changes elsewhere.

- Directly addresses observed user-visible failures: The driver warns
  and aborts reads when the ACPI lock can’t be acquired within the
  timeout (“Failed to acquire mutex”). That path is at
  `drivers/hwmon/asus-ec-sensors.c:947`, returning `-EBUSY`. Increasing
  the timeout reduces these spurious failures on boards where firmware
  holds the lock longer.

- Clear impact on lock acquisition sites: The constant feeds both ACPI
  locking paths which guard access to the EC:
  - AML mutex: `acpi_acquire_mutex(..., ACPI_LOCK_DELAY_MS)` at
    `drivers/hwmon/asus-ec-sensors.c:679`
  - ACPI global lock: `acpi_acquire_global_lock(ACPI_LOCK_DELAY_MS,
    ...)` at `drivers/hwmon/asus-ec-sensors.c:691`
  The change thus uniformly relaxes the wait across both lock mechanisms
used by this driver.

- Low regression risk:
  - Scope: confined to `asus-ec-sensors` driver; no ABI/API or cross-
    subsystem changes.
  - Behavior: Only increases the maximum wait under lock contention by
    300 ms. The driver already rate-limits updates to once per second
    (`state->last_updated + HZ`, `drivers/hwmon/asus-ec-sensors.c:978`),
    so the longer wait still fits typical update cadence and avoids
    frequent -EBUSY.
  - Precedent: Other subsystems use even longer or infinite waits for
    ACPI global lock (e.g., `ACPI_WAIT_FOREVER` in other drivers), so an
    800 ms bound is conservative.

- Stable tree suitability:
  - Fixes an actual operational problem for users (spurious lock
    acquisition failures leading to missing/erratic sensor readings and
    kernel log noise).
  - Change is small, contained, and non-architectural.
  - Touches a non-critical subsystem (hwmon), further reducing risk.
  - Signed by the HWMON maintainer, with a mailing list link indicating
    review path.

- Side effects and risk assessment:
  - Slightly longer blocking in the hwmon read path under ACPI lock
    contention. Given hwmon’s non-real-time nature and the once-per-
    second refresh, this is acceptable and far outweighed by the
    reduction in failed reads.
  - No functional behavior change when the lock is uncontended; no
    changes to EC access semantics aside from the timeout.

Given the above, this is an appropriate, low-risk bug-mitigation change
that improves reliability on affected ASUS systems and should be
backported to stable trees that include this driver.

 drivers/hwmon/asus-ec-sensors.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index 4ac554731e98a..a08862644e951 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -49,7 +49,7 @@ static char *mutex_path_override;
  */
 #define ASUS_EC_MAX_BANK	3
 
-#define ACPI_LOCK_DELAY_MS	500
+#define ACPI_LOCK_DELAY_MS	800
 
 /* ACPI mutex for locking access to the EC for the firmware */
 #define ASUS_HW_ACCESS_MUTEX_ASMX	"\\AMW0.ASMX"
-- 
2.51.0