xhci: Don't let USB3 ports stuck in polling state prevent suspend
authorMathias Nyman <mathias.nyman@linux.intel.com>
Fri, 22 Mar 2019 15:50:17 +0000 (17:50 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 22 Mar 2019 16:16:05 +0000 (17:16 +0100)
commitd92f2c59cc2cbca6bfb2cc54882b58ba76b15fd4
tree7c62ebf2e77ed07313c7a7a583f2f0a727943733
parent8867ea262196a6945c24a0fb739575af646ec0e9
xhci: Don't let USB3 ports stuck in polling state prevent suspend

Commit 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect
change or polling state is detected") was intended to prevent ports that
were still link training from being forced to U3 suspend state mid
enumeration.
This solved enumeration issues for devices with slow link training.

Turns out some devices are stuck in the link training/polling state,
and thus that patch will prevent suspend completely for these devices.
This is seen with USB3 card readers in some MacBooks.

Instead of preventing suspend, give some time to complete the link
training. On successful training the port will end up as connected
and enabled.
If port instead is stuck in link training the bus suspend will continue
suspending after 360ms (10 * 36ms) timeout (tPollingLFPSTimeout).

Original patch was sent to stable, this one should go there as well

Fixes: 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect change or polling state is detected")
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/usb/host/xhci-hub.c
drivers/usb/host/xhci.h