Hi Gargi,
On Sun, Sep 11, 2016 at 5:58 PM, Gargi Sharma <gs051095@xxxxxxxxx> 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.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
