udelay vs usleep_range

[der.herr@hofr.at (Nicholas Mc Guire)]

On Sun, Sep 11, 2016 at 09:28:29PM +0530, Gargi Sharma wrote:
> Hi all,
> 
> I ran the checkpatch script over drivers/staging/nvec.c and got the
> following warning
> 
>  udelay(33);
> 
> CHECK: usleep_range is preferred over udelay; see
> Documentation/timers/timers-howto.txt
> 
> I checked out the timers-howto.txt and for usleep_range, one has to specify
> the lower and upper limit for the timer. How does one decide what the upper
> limit will be if one is to change the function from udelay to usleep_range?
>
generally you would try to figure out what the rational for the delay is
and what boundary it might have. Eg. the udelay(100) in 
drivers/staging/nvec/nvec.c carries the comment:
         * We experience less incomplete messages with this delay than without
         * it, but we don't know why. Help is appreciated.
indicating that this time might actually not be that prcise
and even if you can just provide a small range say 100 to 110 microseconds
this would help the timer subsystem a lot. 

If you can not come up with a proposal based on comments (dont worry about
the time being wrong - you will send your patch to the driver maintainer
for review anyway), then you can always simply send mail to the author
and ask. Actually it would be good if the 33 microseconds would be explained
by some comment rather than leaving these "magic" numbers to speculation.

As this is a set of slow devices (kbd, mouse, power) and any current system
must be asumed to exhibit jitter in the range of atleast 10s of microseconds
you most likely can safely change 33 microseconds to a range of (30,40)
which already can allow significant optimization of runtime timer handling.

So the fix might not only contain a API change to usleep_range() but also
change the values to something meaningful in a macro like 
#define I2C_RX_DELAY 	30 /* minimum waiting time for I2C command response */
usleep_range(I2C_RX_DELAY, I2C_RX_DELAY + 10) 

To find out which list to ask if unsure use:
  scripts/get_maintainer.pl drivers/staging/nvec/nvec.c
and check for those marked with "open list" or 
  git blame -L 630,640  drivers/staging/nvec/nvec.c
(in this case the udelay(33) was on line 634) to ask the
author of that line of code where the udelay(33) comes from.

thx!
hofrat