The port reset code bails out early if the current connect status is
cleared (device disconnected). If we're issuing a hot reset, it may
also look at the link state before the reset is finished.
Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state, the port connection bit retains the
value from the previous state. Therefore we can't trust it until the
reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software
shall ignore the link state while the port is resetting, as it can be in
an unknown state.
Fix the port reset code to ignore the port link state and current
connect bit until the reset finishes for all USB 3.0 hubs.
This patch should be backported to kernels as old as 2.6.39, which was
the first kernel to support USB 3.0 hubs with commit
dbe79bbe9dcb22cb3651c46f18943477141ca452 "USB 3.0 Hub Changes".
Signed-off-by: Sarah Sharp <sarah.a.sh...@linux.intel.com>
Cc: sta...@vger.kernel.org
---
drivers/usb/core/hub.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b9ce5e8..6276b2a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2534,6 +2534,11 @@ static int hub_port_wait_reset(struct usb_hub *hub, int
port1,
if (ret < 0)
return ret;
+ /* Ignore USB 3.0 CCS and link state until the reset finishes */
+ if (hub_is_superspeed(hub->hdev) &&
+ (portstatus & USB_PORT_STAT_RESET))
+ goto delay;
+
/*
* Some buggy devices require a warm reset to be issued even
* when the port appears not to be connected.
@@ -2601,6 +2606,7 @@ static int hub_port_wait_reset(struct usb_hub *hub, int
port1,
return 0;
}
+delay:
/* switch to the long delay after two short delay failures */
if (delay_time >= 2 * HUB_SHORT_RESET_TIME)
delay = HUB_LONG_RESET_TIME;
--
1.7.9
--
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
