Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [Ksummit-discuss] checkkpatch (in)sanity ? | Date | Mon, 29 Aug 2016 23:00:35 +0200 |
| |
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
| |