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

[Sasha Levin <sashal@kernel.org>]

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