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-next>] [day] [month] [year] [list]
Date:   Wed, 30 Nov 2016 14:43:45 +0000
From:   Aniroop Mathur <a.mathur@...sung.com>
To:     Lars-Peter Clausen <lars@...afoo.de>,
        Jonathan Cameron <jic23@...nel.org>,
        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>
Cc:     SAMUEL SEQUEIRA <s.samuel@...sung.com>,
        Rahul Mahale <r.mahale@...sung.com>,
        aniroop.mathur@...il.com 
        <aniroop.mathur@...il.com>,
        Linus Walleij <linus.walleij@...ricsson.com>,
        Vlad Dogaru <vlad.dogaru@...el.com>
Subject: RE: Re: [PATCH] IIO: Change msleep to usleep_range for small msecs

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

Thanks.

BR,
Aniroop Mathur

Powered by blists - more mailing lists