Hi, > Maybe the last sentence is not needed. When we are using the > secondary interrupters, at least in the offload use case that I've > verified with, the XHCI is completely unaware of what TDs have been > queued, etc... So technically, even if we did call the default > handler (ie xhci_handle_cmd_stop_ep), most of the routines to > invalidate TDs are going to be no-ops. Yes, the cancellation machinery will return immediately if there are no TDs queued by xhci_hcd itself. But xhci_handle_cmd_stop_ep() does a few more things for you - it checks if the command has actually succeeded, clears any halt condition which may be preventing stopping the endpoint, and it sometimes retries the command (only on "bad" chips, AFAIK). This new code does none of the above, so in the general case it can't even guarantee that the endpoint is stopped when it returns zero. This should ideally be documented in some way, or fixed, before somebody is tempted to call it with unrealistically high expectations ;) As far as I see, it only works for you because isochronous never halts and Qualcomm HW is (hopefully) free of those stop-after-restart bugs. There will be problems if the SB tries to use any other endpoint type. Regards, Michal
