* Sarah Sharp | 2012-01-24 12:46:21 [-0800]: >Either way, I think we'll end up ripping it out later, so I guess I >don't care, as long as the non-streams case is taken care of. okay. >However, what will the uas driver do if the device completes the data >and status phases in the correct order, but the host controller gives >them back in the opposite order? It will try to cancel the request. So your xhci driver should attempt to remove the urb from the list. On request removal on the device side we have to wait until the hardware synchronises i.e. it says command complete on the removal. That means I could receive the request (which I try to cancel) completed with data transfered (according to the event information). Lets hope it is the same thing on your side. Not sure if it is wise to delay the cancelation by 250ms or so. >Since the data and status phases can be sent from different endpoints, >there's no guarantee of ordering of completed transfers. The xHC host >could chose to put the event for the status transfer on the event ring >before the data transfer event. (In practice it probably won't, but it >could happen.) So receiving a status URB completion before the data URB >completion doesn't necessarily mean the device has skipped the data >phase. The confusing part here that your status/sense URB arrives with status=0 (in sense) and sdb->resid maybe set to sdb->length which could confuse the scsi stack (everything went fine but I received no data). >I think your patch will still work in this case. The status URB >completion will attempt to unlink the data URBs, but the xHCI driver >will probably give back the data URB before the stop endpoint command >will be serviced by the host controller. Will the data URB completion >see the URB canceled status in urb->status? What should it do in that >case? Hopefully it won't give back the SCSI command with an error, >since technically the command did complete. As I wrote, if urb->actual_length is 0 you come up with an error. The status is not considered, only the length is updated. So you should not update actual_length unless the hcd moved some data. The only confusing part is (I think) if sense repored that everything went fine and no data arrived. In the diagram in UASP_rev1.0 in "5.4.3 Data-in transfer" the deviceis waiting for in-ack (DATA-in). So I think the device has to wait until the data is sent to the host. So that might be enough buffer to avoid the race you were talking about. On Data-out side the ERDY (Stat) is sent right after ACK (Data-out) but the device needs probably save the new data before it sends the STAT. >Sarah Sharp Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
