linux-kernel - Re: [PATCH] IIO: Change msleep to usleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 3 Dec 2016 09:00:46 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Aniroop Mathur <aniroop.mathur@...il.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     "knaack.h@....de" <knaack.h@....de>,
        "pmeerw@...erw.net" <pmeerw@...erw.net>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        SAMUEL SEQUEIRA <s.samuel@...sung.com>,
        Rahul Mahale <r.mahale@...sung.com>, a.mathur@...sung.com
Subject: Re: [PATCH] IIO: Change msleep to usleep_range for small msecs

On 02/12/16 19:07, Aniroop Mathur wrote:
> On Wed, Nov 30, 2016 at 8:13 PM, Aniroop Mathur <a.mathur@...sung.com> wrote:
>> On 30 Nov 2016 19:05, "Lars-Peter Clausen" <lars@...afoo.de> wrote:
>>  >
>>  > On 11/27/2016 11:51 AM, Jonathan Cameron wrote:
>>  > > On 26/11/16 03:47, Aniroop Mathur wrote:
>>  > >> msleep(1~20) may not do what the caller intends, and will often sleep longer.
>>  > >> (~20 ms actual sleep for any value given in the 1~20ms range)
>>  > >> This is not the desired behaviour for many cases like device resume time,
>>  > >> device suspend time, device enable time, data reading time, etc.
>>  > >> Thus, change msleep to usleep_range for precise wakeups.
>>  > >>
>>  > >> Signed-off-by: Aniroop Mathur <a.mathur@...sung.com>
>>  > > As these need individual review by the various original authors and driver maintainers to
>>  > > establish the intent of the sleep, it would have been better to have done a series of
>>  > > patches (one per driver) with the relevant maintainers cc'd on the ones that they care about.
>>  > >
>>  > > Most of these are ADI parts looked after by Lars though so perhaps wait for his comments
>>  > > before respining.
>>  >
>>  > I agree with what Jonathan said. For most of these extending the maximum
>>  > sleep time a bit further is ok.
>>  >
>>
>> Well, its right that sleep a bit further is okay but this patch is not trying
>> to solve any major bug. This patch is only trying to make the wake up more
>> precise than before. So like with msleep(1), process could sleep for 20 ms
>> so this patch only making the making the process to sleep for 1 ms as
>> mentioned in the parameter. So I think, changing to usleep_range is only
>> advantageous and does not cause any harm here.
>> We have also applied the same change in enable/disable/suspend/resume
>> functions in accel, gyro, mag, etc drivers and found decent results like the
>> first sesor data is generated much faster than before so response time
>> increased. This is critical as  sensor can run at a rate of 200Hz / 5ms or
>> even more now a days in new devices. We even applied in probe as doing the
>> same in many drivers contribute to a little saving overall in kernel boot up.
>> Also, it is recommended and mentioned in kernel documentation to use
>> usleep_range for 1-10 ms.
>> Sources -
>> https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
>> https://lkml.org/lkml/2007/8/3/250
>>
> 
> 
> Hello Mr. Jonathan / Mr. Lars / All,
> 
> 
> Would you kindly update further about this change?
Hi Aniroop,

Quite a few of us only manage to get to kernel patches once or twice a week
(in my case only on weekends most weeks).

Anyhow, I've applied this patch as is.  I don't necessarily think the change
is that important in the probe paths, but as you said it does little harm.

So what the heck ;)

Applied to the togreg branch of iio.git which I'll push out as testing
once I have a net connection (currently on a train).

Thanks,

Jonathan
> 
> 
>> Thanks.
>>
>> BR,
>> Aniroop Mathur