On Fri, 4 May 2007, Oliver Neukum wrote: > > A better approach would be to have a routine which would block until all > > URBs on an anchor have completed. With a timeout, so that they can be > > killed if they take too long. > > I can't follow your logic here. The partial completion case has to be > handled anyway, so what is gained waiting?
The URB's completion handler will see the unlink and treat it as a normal I/O error (maybe even realize that the URB timed out). The user's I/O will fail just as it would in case of a normal timeout. Remember, this is abnormal activity -- in the common case we expect there will be no timeout and no errors. When the driver realizes that the anchored URBs timed out instead of completing normally (usb_wait_for_anchor() returns -ETIMEDOUT), it will engage in some sort of error recovery. Once that is finished it should be ready for the suspend -- no more pending URBs and the device is in a known good state. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
