udelay vs usleep_range

Hi Gargi,

On Sun, Sep 11, 2016 at 5:58 PM, Gargi Sharma [off-list ref] 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

Which version of checkpatch are you using? Mine didn't catch that.

$ git status
HEAD detached at next-20160909

$ ./scripts/checkpatch.pl -f ./drivers/staging/nvec/nvec.c
total: 0 errors, 0 warnings, 988 lines checked

./drivers/staging/nvec/nvec.c has no obvious style problems and is
ready for submission.

But looking into the code on line 634 where I found the udelay(33), I
have the impression that this is a false positive, something your
checkpatch didn't catch properly. That call is inside a function named
nvec_interrupt(), and the line:

        err = devm_request_irq(&pdev->dev, nvec->irq, nvec_interrupt,
0, "nvec", nvec);

declares it as the interrupt handler. The interrupt handler can't
sleep(interrupt handler runs in the atomic context in terminology of
timers-howto.txt), and using udelay() seems to be the thing to do
here.

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?

That usually depends on hardware specifications, and on the precision
of the method used. Depending on the case the hardware may allow a
range for waiting, and depending on which function you are using for
waiting it is not guaranteed to get the precision you asked for. The
range is a solution to minimize impact on the system while
guaranteeing that the range will be met.