* [PATCH AUTOSEL 6.17-6.12] hwmon: (dell-smm) Remove Dell Precision 490 custom config data
2025-10-09 15:54 [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo Sasha Levin
@ 2025-10-09 15:55 ` Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-5.15] hwmon: (sbtsi_temp) AMD CPU extended temperature range support Sasha Levin
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2025-10-09 15:55 UTC (permalink / raw)
To: patches, stable; +Cc: Armin Wolf, Guenter Roeck, Sasha Levin, pali, linux-hwmon
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
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 6.17-5.15] hwmon: (sbtsi_temp) AMD CPU extended temperature range support
2025-10-09 15:54 [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-6.12] hwmon: (dell-smm) Remove Dell Precision 490 custom config data Sasha Levin
@ 2025-10-09 15:55 ` Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based models Sasha Levin
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2025-10-09 15:55 UTC (permalink / raw)
To: patches, stable; +Cc: Chuande Chen, Guenter Roeck, Sasha Levin, linux-hwmon
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
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based models
2025-10-09 15:54 [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-6.12] hwmon: (dell-smm) Remove Dell Precision 490 custom config data Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-5.15] hwmon: (sbtsi_temp) AMD CPU extended temperature range support Sasha Levin
@ 2025-10-09 15:56 ` Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-5.4] hwmon: (dell-smm) Add support for Dell OptiPlex 7040 Sasha Levin
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2025-10-09 15:56 UTC (permalink / raw)
To: patches, stable
Cc: Avadhut Naik, Guenter Roeck, Sasha Levin, clemens, linux-hwmon
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
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 6.17-5.4] hwmon: (dell-smm) Add support for Dell OptiPlex 7040
2025-10-09 15:54 [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo Sasha Levin
` (2 preceding siblings ...)
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based models Sasha Levin
@ 2025-10-09 15:56 ` Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.12] hwmon: (lenovo-ec-sensors) Update P8 supprt Sasha Levin
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2025-10-09 15:56 UTC (permalink / raw)
To: patches, stable; +Cc: Armin Wolf, Guenter Roeck, Sasha Levin, pali, linux-hwmon
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
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 6.17-6.12] hwmon: (lenovo-ec-sensors) Update P8 supprt
2025-10-09 15:54 [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo Sasha Levin
` (3 preceding siblings ...)
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-5.4] hwmon: (dell-smm) Add support for Dell OptiPlex 7040 Sasha Levin
@ 2025-10-09 15:56 ` Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.1] hwmon: sy7636a: add alias Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.1] hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex Sasha Levin
6 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2025-10-09 15:56 UTC (permalink / raw)
To: patches, stable
Cc: David Ober, David Ober, Guenter Roeck, Sasha Levin, linux-hwmon
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
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 6.17-6.1] hwmon: sy7636a: add alias
2025-10-09 15:54 [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo Sasha Levin
` (4 preceding siblings ...)
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.12] hwmon: (lenovo-ec-sensors) Update P8 supprt Sasha Levin
@ 2025-10-09 15:56 ` Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.1] hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex Sasha Levin
6 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2025-10-09 15:56 UTC (permalink / raw)
To: patches, stable; +Cc: Andreas Kemnade, Guenter Roeck, Sasha Levin, linux-hwmon
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
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 6.17-6.1] hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex
2025-10-09 15:54 [PATCH AUTOSEL 6.17-6.6] hwmon: (k10temp) Add device ID for Strix Halo Sasha Levin
` (5 preceding siblings ...)
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.1] hwmon: sy7636a: add alias Sasha Levin
@ 2025-10-09 15:56 ` Sasha Levin
6 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2025-10-09 15:56 UTC (permalink / raw)
To: patches, stable
Cc: Ben Copeland, Eugene Shalygin, Guenter Roeck, Sasha Levin,
linux-hwmon
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
^ permalink raw reply related [flat|nested] 8+ messages in thread