Re: [Ksummit-discuss] checkkpatch (in)sanity ?

[Arnd Bergmann]

On Monday 29 August 2016, Kalle Valo wrote:
> MSLEEP: I think this is just noise, we don't care if it's actually 20 ms
> even if ask for 10 ms. That's the minimum time to wait, not the maximum
> (from our/HW point of view).
> 
> drivers/net/wireless/ath/ath10k/ahb.c:422: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
> drivers/net/wireless/ath/ath10k/ahb.c:427: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
> drivers/net/wireless/ath/ath10k/ahb.c:432: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
> drivers/net/wireless/ath/ath10k/ahb.c:437: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
> drivers/net/wireless/ath/ath10k/ahb.c:442: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
> drivers/net/wireless/ath/ath10k/pci.c:2244: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
> drivers/net/wireless/ath/ath10k/pci.c:2251: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
> drivers/net/wireless/ath/ath10k/pci.c:2275: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
> 

I've seen way too many patches addressing this warning in various ways that
do not improve readability or behavior of the driver. Typically a driver
calls "msleep(1)" in a loop as a way to poll for an event that will happen
at some point in the future but that generates no IRQ or other event we
can wait for, the stuff that used to be handled with "yield" a long time
ago.

Now every third caller of usleep_range() uses '1000' as the minimum time
and an arbitrary upper bound.

	Arnd