On Tuesday 22 May 2007, Alan Stern wrote: > On Tue, 22 May 2007, Curran, Dominic wrote: > > > > > Lets say the Hosts Mass Storage driver wants to READ 12K: > > > > I believe that the Host Controller driver (e.g. ehci_hcd) might see > > something like this coming from usbcore: > > > > 1) BULK OUT urb (31 bytes) [Contains READ10 command] > > 2) BULK IN urb (4K) [data] > > 3) BULK IN urb (8K) [data] > > 4) BULK IN urb (13 bytes) [status] > > Correct. However 1) must complete before 2) and 3) are submitted, and > 3) must complete before 4) is submitted. This is not a fundamental > limitation; it's just the way usb-storage currently works. > > > I have two questions regarding what happens when the transfer gets > > terminated early: > > > > > > 1) What happens if the device terminates the transfer after the 4KB > > (with a zero-length packet)? > > > > Does the HC driver... > > - set status to 0 in the 4K urb (& actual_length=4096) and > > Yes. > > > - flush all other queued urbs for that EP (in this case the 8K urb) by > > completing them with an error status ? If so what is the status ? > > Not exactly. The 8K URB completes with an error status -EREMOTEIO.
Because the URB_SHORT_NOT_OK was set, and it saw a zero length packet. The usb-storage driver explicitly sets URB_SHORT_NOT_OK because that zero length packet would be an error. Actually, any short packet would be an error -- not just a ZLP. The host asked for 12KB, and any short packet would mean the peripheral sent less than that, which would be an error. > However if there were any other URBs in the endpoint queue at that > time, the HCD would not flush them. The flushing would be done by the > completion handler for the 8K URB; it would call usb_unlink_urb() for > all the remaining URBs. > > > > 2) What happens if the device terminates the transfer during the 4KB > > (after say 3700 bytes received, with a short packet)? > > > > Thus: > > urb->transfer_buffer_length = 4096 > > urb->actual_length = 3700 > > > > I believe that the HC driver should do the following test: > > > > if( (urb->actual_length < urb->transfer_buffer_length) && > > (urb->transfer_flags & URB_SHORT_NOT_OK) ) > > urb->status = -EREMOTEIO; > > > > So if URB_SHORT_NOT_OK is set then -EREMOTEIO will be returned And if > > URB_SHORT_NOT_OK is not set the 0 will be returned. > > > > Is this correct ? > > Yes. The same thing would happen to the 8K URB in your first question. > > > Again I assume that the 8K urb should be completed immediately ? > > If so with what status ? > > No. The 4K URB's completion handler would see the -EREMOTEIO error and TYPO -- 8K, not 4K ... > would unlink the 8K URB, which would then complete with status > -ECONNRESET. Well, you're consistent with the typo; but the -ECONNRESET path would be accurate if instead of an 8KB urb there were in fact two 4KB ones. > > I'm having trouble understand the EHCI code; In the EHCI driver where > > are these situation handled ? qh_completions() ? > > Part of your trouble is because some of these situations are handled > outside the EHCI driver. Take a look at the usb_sg_* routines in > drivers/usb/core/message.c. Also read the kerneldoc comments in > drivers/usb/core/urb.c and read Documentation/usb/error-codes.txt. Right. - Dave ------------------------------------------------------------------------- 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
