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"