On Wed, Oct 12, 2016 at 9:03 AM, Guenter Roeck <li...@roeck-us.net> wrote:
> drivers/iio/accel/kxcjk-1013.c: kxcjk1013_runtime_resume()
As far as I can tell these drivers will not suffer unduly from my
change. Worse case they will delay 20us more, which is listed as the
Also note that I assume the reason you flagged these is because they
follow the pattern:
if (sleep_val < 20000)
I will note that usleep_range() is and has always been
uninterruptible, since the implementation says:
void __sched usleep_range(unsigned long min, unsigned long max)
So I'm not at all convinced that we are changing behavior here. The
"interruptible" vs. "uninterruptible" affects whether signals can
interrupt the sleep, not whether a random wake up of a task can. What
we really need to know is if they are affected by a wakeup.
I assume that the person who wrote this code was confused since they wrote:
/* Now sleep between a min of 100-300us and a max of 1ms */
usleep_range(((data->cnt % 3) + 1) * 100, 1000);
That doesn't seem to make sense given the first line of usleep_range().
In any case, again I don't think I am changing behavior.
> A possible solution might be to introduce usleep_range_interruptible()
> and use it there.
This could be a useful function, but I don't think we need it if we
find someone who needs a wakeup to cut short a sleep. We can just
call one of the schedule functions directly and use a timeout.
Thank you for searching through for stuff and for your review, though!