2023-07-29 13:45:28

by Aleksa Savic

[permalink] [raw]
Subject: [PATCH v2] hwmon: (aquacomputer_d5next) Add selective 200ms delay after sending ctrl report

Add a 200ms delay after sending a ctrl report to Quadro,
Octo, D5 Next and Aquaero to give them enough time to
process the request and save the data to memory. Otherwise,
under heavier userspace loads where multiple sysfs entries
are usually set in quick succession, a new ctrl report could
be requested from the device while it's still processing the
previous one and fail with -EPIPE.

Reported by a user on Github [1] and tested by both of us.

[1] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/issues/82

Signed-off-by: Aleksa Savic <[email protected]>
---
Changes in v2:
- Added missing <linux/delay.h> include
---
drivers/hwmon/aquacomputer_d5next.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)

diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
index a997dbcb563f..6ec0ab58a289 100644
--- a/drivers/hwmon/aquacomputer_d5next.c
+++ b/drivers/hwmon/aquacomputer_d5next.c
@@ -13,6 +13,7 @@

#include <linux/crc16.h>
#include <linux/debugfs.h>
+#include <linux/delay.h>
#include <linux/hid.h>
#include <linux/hwmon.h>
#include <linux/jiffies.h>
@@ -652,6 +653,31 @@ static int aqc_send_ctrl_data(struct aqc_data *priv)
ret = hid_hw_raw_request(priv->hdev, priv->secondary_ctrl_report_id,
priv->secondary_ctrl_report, priv->secondary_ctrl_report_size,
HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * Wait 200ms before returning to make sure that the device actually processed both reports
+ * and saved ctrl data to memory. Otherwise, an aqc_get_ctrl_data() call made shortly after
+ * may fail with -EPIPE because the device is still busy and can't provide data. This can
+ * happen when userspace tools, such as fancontrol or liquidctl, write to sysfs entries in
+ * quick succession.
+ *
+ * 200ms was found to be the sweet spot between fixing the issue and not significantly
+ * prolonging the call. Quadro, Octo, D5 Next and Aquaero are currently known to be
+ * affected.
+ */
+ switch (priv->kind) {
+ case quadro:
+ case octo:
+ case d5next:
+ case aquaero:
+ msleep(200);
+ break;
+ default:
+ break;
+ }
+
return ret;
}

--
2.41.0



2023-07-29 14:41:32

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH v2] hwmon: (aquacomputer_d5next) Add selective 200ms delay after sending ctrl report

On 7/29/23 06:42, Aleksa Savic wrote:
> On 2023-07-29 15:31:12 GMT+02:00, Aleksa Savic wrote:
>> Add a 200ms delay after sending a ctrl report to Quadro,
>> Octo, D5 Next and Aquaero to give them enough time to
>> process the request and save the data to memory. Otherwise,
>> under heavier userspace loads where multiple sysfs entries
>> are usually set in quick succession, a new ctrl report could
>> be requested from the device while it's still processing the
>> previous one and fail with -EPIPE.
>>
>> Reported by a user on Github [1] and tested by both of us.
>>
>> [1] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/issues/82
>>
>> Signed-off-by: Aleksa Savic <[email protected]>
>> ---
>> Changes in v2:
>> - Added missing <linux/delay.h> include
>> ---
> Sorry for the noise, I didn't include the Cc: [email protected]
> line from v1 in v2. Do I need to resend?
>

Normally it would be me adding that. Instead, it would make much more
sense to add a Fixes: tag, because otherwise I'll have to spend time
figuring that out. Also, you are not supposed to actually send the patch
to the stable@ mailing list because it hasn't been accepted into the
upstream kernel. It is only necessary to actually send a patch to the
stable@ mailing list if it is a backport.

Either case I'd suggest to consider addressing my feedback before sending
yet another version.

Guenter


2023-07-29 14:41:44

by Aleksa Savic

[permalink] [raw]
Subject: Re: [PATCH v2] hwmon: (aquacomputer_d5next) Add selective 200ms delay after sending ctrl report

On 2023-07-29 15:31:12 GMT+02:00, Aleksa Savic wrote:
> Add a 200ms delay after sending a ctrl report to Quadro,
> Octo, D5 Next and Aquaero to give them enough time to
> process the request and save the data to memory. Otherwise,
> under heavier userspace loads where multiple sysfs entries
> are usually set in quick succession, a new ctrl report could
> be requested from the device while it's still processing the
> previous one and fail with -EPIPE.
>
> Reported by a user on Github [1] and tested by both of us.
>
> [1] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/issues/82
>
> Signed-off-by: Aleksa Savic <[email protected]>
> ---
> Changes in v2:
> - Added missing <linux/delay.h> include
> ---
Sorry for the noise, I didn't include the Cc: [email protected]
line from v1 in v2. Do I need to resend?

Thanks in advance,
Aleksa