lkml.org 
[lkml]   [2022]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 3/4] hwmon: (sch56xx-common) Replace msleep() with usleep_range()
From
Hi,

On 1/31/22 21:10, Guenter Roeck wrote:
> On 1/31/22 11:31, Armin Wolf wrote:
>> msleep(1) will often sleep more than 20ms, slowing down sensor
>> and watchdog reads/writes. Use usleep_range() as recommended
>> in timers-howto.rst to fix that.
>>
>> Tested on a Fujitsu Esprimo P720.
>>
>> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
>> ---
>>   drivers/hwmon/sch56xx-common.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwmon/sch56xx-common.c b/drivers/hwmon/sch56xx-common.c
>> index 0172aa16dc0c..f66e1ed4b1aa 100644
>> --- a/drivers/hwmon/sch56xx-common.c
>> +++ b/drivers/hwmon/sch56xx-common.c
>> @@ -139,7 +139,7 @@ static int sch56xx_send_cmd(u16 addr, u8 cmd, u16 reg, u8 v)
>>       /* EM Interface Polling "Algorithm" */
>>       for (i = 0; i < max_busy_polls + max_lazy_polls; i++) {
>>           if (i >= max_busy_polls)
>> -            msleep(1);
>> +            usleep_range(1, 2);
>
> This replaces a 1-millisecond sleep with a 1-2 microsecond sleep.
>
> Are you sure this is what you want to do ? Given that task switches typically
> take several microseconds, the new code is pretty much identical to a busy
> loop, and the maximum sleep time is reduced significantly.

Ah good catch, I missed that will reviewing v1, sorry about that.

The issue is actually worse then busy-waiting the max wait time
in this code is expressed in a maximum number of polls, so
if usleep_range(1, 2) would really only sleep 1 usec, we would
wait much too short and may hit a false-positive timeout condition
here.

Regards,

Hans



\
 
 \ /
  Last update: 2022-01-31 22:02    [W:0.031 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site