On 26.05.2017 22:12, gavinli@xxxxxxxxxxxxxx wrote:
From: Gavin Li <git@xxxxxxxxxxxxxx> If a stalling TRB is cancelled and NOOP'ed in xhci_handle_cmd_stop_ep(), finish_td() never gets called to reset the halted endpoint and the endpoint remains indefinitely stalled. This patch ensures that xhci_cleanup_halted_endpoint() is called after a TRB completion if the endpoint is halted, irregardless of the status of any pending TRBs. Signed-off-by: Gavin Li <git@xxxxxxxxxxxxxx>
Interesting, I'm trying to understand the details of what's going on here. Does the event ring first have a stopped transfer event, then a stop endpoint command completion event, and finally a transfer event with STALL_ERROR completion code pointing to a no-op trb? If this is the case do yo have any idea if the STALL_ERROR transfer event was issued while the ring was stopping, or only after ring was restarted again? current code relies on the the stopped transfer event to know where on the endpoint ring hardware stopped, sometimes this might not be reliable. I have a change for that, just pushed to my for-usb-next branch in my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git Your patch basically adds a check for STALL_ERROR for no-op trbs, it reveals that the driver currently skips handling all endpoint state related transfer events if that TRB was canceled. This needs to investigated more Thanks -Mathias -- 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
