summaryrefslogtreecommitdiffstats
path: root/net/ipv4/raw.c
diff options
context:
space:
mode:
authorMathias Nyman <mathias.nyman@linux.intel.com>2019-06-18 17:27:47 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-06-18 18:14:38 +0200
commitb8c3b718087bf7c3c8e388eb1f72ac1108a4926e (patch)
treea512906e7d6484f04f3272d869a337e7f4a9a56e /net/ipv4/raw.c
parentc19dffc0a9511a7d7493ec21019aefd97e9a111b (diff)
downloadlinux-b8c3b718087bf7c3c8e388eb1f72ac1108a4926e.tar.bz2
usb: xhci: Don't try to recover an endpoint if port is in error state.
A USB3 device needs to be reset and re-enumarated if the port it connects to goes to a error state, with link state inactive. There is no use in trying to recover failed transactions by resetting endpoints at this stage. Tests show that in rare cases, after multiple endpoint resets of a roothub port the whole host controller might stop completely. Several retries to recover from transaction error can happen as it can take a long time before the hub thread discovers the USB3 port error and inactive link. We can't reliably detect the port error from slot or endpoint context due to a limitation in xhci, see xhci specs section 4.8.3: "There are several cases where the EP State field in the Output Endpoint Context may not reflect the current state of an endpoint" and "Software should maintain an accurate value for EP State, by tracking it with an internal variable that is driven by Events and Doorbell accesses" Same appears to be true for slot state. set a flag to the corresponding slot if a USB3 roothub port link goes inactive to prevent both queueing new URBs and resetting endpoints. Reported-by: Rapolu Chiranjeevi <chiranjeevi.rapolu@intel.com> Tested-by: Rapolu Chiranjeevi <chiranjeevi.rapolu@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net/ipv4/raw.c')
0 files changed, 0 insertions, 0 deletions