More importantly, I don't like this notion of doing things differently depending on whether or not in_interrupt() is true. It doesn't take into
account other things the programmer should be aware of, like whether interrupts are enabled or any spinlocks are held. IMO we should have a
single non-inline function that always calls schedule_timeout(). If someone wants to use mdelay() instead, let them call mdelay() directly.
Yes, I'd have said the same thing. In fact, I suppose I did that exact thing in recent ohci/ehci patches ... ;)
When the msec_to_jiffies() stuff settles down, we should switch over to use that with schedule_timeout() whenever mdelay() is inappropriate.
Also, why the retries on schedule_timeout() ... what's the path by which timers would fire early?
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
