summaryrefslogtreecommitdiff
path: root/Documentation/x86
diff options
context:
space:
mode:
authorMathias Nyman <mathias.nyman@linux.intel.com>2016-06-01 18:09:08 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2016-06-01 14:55:01 -0700
commit3425aa03f484d45dc21e0e791c2f6c74ea656421 (patch)
treeb22cfe0e98d6a6a85e24bfe7b6e5ce93b56fff9a /Documentation/x86
parent27a41a83ec54d0edfcaf079310244e7f013a7701 (diff)
xhci: Fix handling timeouted commands on hosts in weird states.
If commands timeout we mark them for abortion, then stop the command ring, and turn the commands to no-ops and finally restart the command ring. If the host is working properly the no-op commands will finish and pending completions are called. If we notice the host is failing, driver clears the command ring and completes, deletes and frees all pending commands. There are two separate cases reported where host is believed to work properly but is not. In the first case we successfully stop the ring but no abort or stop command ring event is ever sent and host locks up. The second case is if a host is removed, command times out and driver believes the ring is stopped, and assumes it will be restarted, but actually ends up timing out on the same command forever. If one of the pending commands has the xhci->mutex held it will block xhci_stop() in the remove codepath which otherwise would cleanup pending commands. Add a check that clears all pending commands in case host is removed, or we are stuck timing out on the same command. Also restart the command timeout timer when stopping the command ring to ensure we recive an ring stop/abort event. Cc: stable <stable@vger.kernel.org> Tested-by: Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/x86')
0 files changed, 0 insertions, 0 deletions