<div dir="auto">I had the same doubt the other day about the replacement of udelay() with usleep_range(). The corresponding range for the single argument value of udelay() is quite confusing as I couldn't decide the range. <div dir="auto">But as much as I noticed <a href="http://checkpatch.pl" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">checkpatch.pl</a> gives warning for replacing udelay() with usleep_range() by checking the argument value of udelay(). In the documentation, it is written udelay() should be used for a sleep time of at most 10 microseconds but between 10 microseconds and 20 milliseconds, usleep_range() should be used. </div><div dir="auto">I think the range is code specific and will depend on what range is acceptable and doesn't break the code.</div><div dir="auto"> Please correct me if I am wrong.</div><div dir="auto"> </div><div dir="auto">More clarification on this issue will be helpful.</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 29 Mar 2020, 15:17 Julia Lawall, <<a href="mailto:julia.lawall@inria.fr" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">julia.lawall@inria.fr</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Sun, 29 Mar 2020, John Wyatt wrote: > On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote: > > > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote: > > > > > Fix style issue with usleep_range being reported as preferred over > > > udelay. > > > > > > Issue reported by checkpatch. > > > > > > Please review. > > > > > > As written in Documentation/timers/timers-howto.rst udelay is the > > > generally preferred API. hrtimers, as noted in the docs, may be too > > > expensive for this short timer. > > > > > > Are the docs out of date, or, is this a checkpatch issue? > > > > > > Signed-off-by: John B. Wyatt IV <<a href="mailto:jbwyatt4@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">jbwyatt4@gmail.com</a>> > > > --- > > > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > index eeeeec97ad27..019c8cce6bab 100644 > > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > > > dev_dbg(par->info->device, "%s()\n", __func__); > > > > > > gpiod_set_value(par->gpio.reset, 0); > > > - udelay(20); > > > + usleep_range(20, 20); > > > > usleep_range should have a range, eg usleep_range(50, 100);. But it > > is > > hard to know a priori what the range should be. So it is probably > > better > > to leave the code alone. > > Understood. > > With the question I wrote in the commit message: > > "As written in Documentation/timers/timers-howto.rst udelay is the > generally preferred API. hrtimers, as noted in the docs, may be too > expensive for this short timer. > > Are the docs out of date, or, is this a checkpatch issue?" > > Is usleep_range too expensive for this operation? > > Why does checkpatch favor usleep_range while the docs favor udelay? I don't know the answer in detail, but it is quite possible that checkpatch doesn't pay any attention to the delay argument. Checkpatch is a perl script that highlights things that may be of concern. It is not a precise static analsis tool. As a matter of form, all of your Please review comments should have been put below the ---. Currently, if someone had wanted to apply the patch, you would make them do extra work to remove this information. julia > > > > > julia > > > > > gpiod_set_value(par->gpio.reset, 1); > > > mdelay(120); > > > } > > > -- > > > 2.25.1 > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "outreachy-kernel" group. > > > To unsubscribe from this group and stop receiving emails from it, > > > send an email to <a href="mailto:outreachy-kernel%2Bunsubscribe@googlegroups.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">outreachy-kernel+unsubscribe@googlegroups.com</a>. > > > To view this discussion on the web visit > > > <a href="https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com</a> > > > . > > > > > -- You received this message because you are subscribed to the Google Groups "outreachy-kernel" group. To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:outreachy-kernel%2Bunsubscribe@googlegroups.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">outreachy-kernel+unsubscribe@googlegroups.com</a>. To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/outreachy-kernel/alpine.DEB.2.21.2003291144460.2990%40hadrien" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://groups.google.com/d/msgid/outreachy-kernel/alpine.DEB.2.21.2003291144460.2990%40hadrien</a>. </blockquote></div>