summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorGuenter Roeck <linux@roeck-us.net>2026-11-03 19:45:08 -0800
committerGuenter Roeck <linux@roeck-us.net>2026-11-04 06:43:35 -0800
commite395bbf3ddf1b3175fd3bddaead63a2909b33694 (patch)
treed4f9abb982022e034c4cf44a8f7108315d4f8ee5 /tools/perf/scripts/python
parente6b96b76d7074ae64f0d37d880794c71d3ce277e (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