Dave: After giving this more thought, it seems to me that we really should issue Clear-TT-Buffer after _every_ transaction fault except -EREMOTEIO, as well as after an unlink. Depending on the value of QTD_STS_STS isn't safe, since the host controller doesn't really know exactly what state the TT is in. For example, a Start-Split could be issued and received, but then the ACK could get lost. That's why the USB spec says Clear-TT-Buffer _must_ occur during endpoint halt processing. Doing this would require a little code reorganization, not too bad. However the really tricky part involves what happens next. We must not reactivate the endpoint queue until the Clear-TT-Buffer has finished! The reason is simple: If a TT buffer is still busy trying to handle an old transaction when the host sends a Start-Split for a new transaction, the TT will ignore the Start-Split. The new transaction will be lost. Conversely, if the buffer wasn't busy when the new transaction began, a Clear-TT-Buffer request arriving later will mess up the new transaction. Since the Clear-TT-Buffer request is sent by a workqueue routine, this will require some tricky synchronization. We'll probably have to pass a callback pointer to usb_hub_tt_clear_buffer along with some extra information. Add an extra flag to the ehci_qh structure to indicate that it's waiting for a Clear-TT-Buffer to complete (or maybe add a new state instead of a new flag), and don't allow qh_link_async to proceed unless the flag is clear. And so on... What do you think? Alan Stern -- 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
