On 26.05.2017 22:12, gavi...@thegavinli.com wrote:
From: Gavin Li <g...@thegavinli.com>
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 <g...@thegavinli.com>
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
