diff options
| author | Guenter Roeck <linux@roeck-us.net> | 2026-11-03 19:45:08 -0800 |
|---|---|---|
| committer | Guenter Roeck <linux@roeck-us.net> | 2026-11-04 06:43:35 -0800 |
| commit | e395bbf3ddf1b3175fd3bddaead63a2909b33694 (patch) | |
| tree | d4f9abb982022e034c4cf44a8f7108315d4f8ee5 /tools/perf/scripts/python | |
| parent | e6b96b76d7074ae64f0d37d880794c71d3ce277e (diff) | |
hwmon: (asus_rog_ryujin) Fix timeout when reading 0% duty cycle
The device uses the same zero-duty report format for both legitimate 0%
duty GET responses and SET confirmation ACKs on cooler and controller
duty channels. To distinguish them, rog_ryujin_raw_event() checks
!completion_done() on cooler_duty_set and controller_duty_set, assuming
this is only true while a SET command is awaiting confirmation.
However, init_completion() initializes the completion count to zero, so
!completion_done() evaluates to true from probe until the first SET
command completes. Likewise, if rog_ryujin_execute_cmd() fails to send a
command, times out, or is interrupted after reinit_completion(), the
completion remains uncompleted. When a valid 0% duty GET response then
arrives, rog_ryujin_raw_event() consumes it as a SET confirmation and
leaves the pending *_duty_received completion uncompleted, causing
rog_ryujin_execute_cmd() to wait 1.5 seconds and fail with -ETIMEDOUT.
Mark all completions as done with complete_all() after initialization in
rog_ryujin_probe(), and complete status_completion on error in
rog_ryujin_execute_cmd(), so !completion_done() is only true while a
command is actively awaiting a response.
Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler")
Cc: Aleksa Savic <savicaleksa83@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
