For the urb to complete. The schedule_timeout() returned without that completion. We only forced the completion path to start, with the unlink; if it wasn't already starting (maybe on another CPU).
So you are doing the conventional wait stuff only to implement the timeout, aren't you?
Not entirely. USB drivers often don't use TASK_INTERRUPTIBLE when they should. You'll notice that this routine is easy to modify so that it allows both timeouts and waits ... delete two letters to make it INTERRUPTIBLE. It's only cleaning up after premature termination (timeout, or interrupt) that _needs_ to be UN-interruptible.
That is, given that this logic works correctly (it did when I tested it), this logic can also be the core of a synchronous usbcore call that provides driver developers a flexibility they should have had all along: users can ^C out of driver waits, processes can be kicked out of 'D' wait.
This seems kind of convoluted to me. May I suggest doing the timeout explicitely like this:
That is, use a timer with a struct completion (and a random un-necessary flag), and cancel the urb in the timer function?
That's simpler, and would work on 2.4 too ... but it doesn't provide flexibility about exiting because of interrupt.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
