From: Greg Kroah-Hartman Date: Tue, 6 Sep 2022 11:02:58 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v5.10.142~31 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3355f789d504e5e5f19eb75b8c871a9112a4e607;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch --- diff --git a/queue-4.9/series b/queue-4.9/series index b343b3bac68..3d915fd6ef7 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -6,3 +6,4 @@ staging-rtl8712-fix-use-after-free-bugs.patch vt-clear-selection-before-changing-the-font.patch usb-serial-ftdi_sio-add-omron-cs1w-cif31-device-id.patch hwmon-gpio-fan-fix-array-out-of-bounds-access.patch +xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch diff --git a/queue-4.9/xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch b/queue-4.9/xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch new file mode 100644 index 00000000000..419d0db3748 --- /dev/null +++ b/queue-4.9/xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch @@ -0,0 +1,84 @@ +From 33e321586e37b642ad10594b9ef25a613555cd08 Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Thu, 25 Aug 2022 18:08:39 +0300 +Subject: xhci: Add grace period after xHC start to prevent premature runtime suspend. + +From: Mathias Nyman + +commit 33e321586e37b642ad10594b9ef25a613555cd08 upstream. + +After xHC controller is started, either in probe or resume, it can take +a while before any of the connected usb devices are visible to the roothub +due to link training. + +It's possible xhci driver loads, sees no acivity and suspends the host +before the USB device is visible. + +In one testcase with a hotplugged xHC controller the host finally detected +the connected USB device and generated a wake 500ms after host initial +start. + +If hosts didn't suspend the device duringe training it probablty wouldn't +take up to 500ms to detect it, but looking at specs reveal USB3 link +training has a couple long timeout values, such as 120ms +RxDetectQuietTimeout, and 360ms PollingLFPSTimeout. + +So Add a 500ms grace period that keeps polling the roothub for 500ms after +start, preventing runtime suspend until USB devices are detected. + +Cc: stable@vger.kernel.org +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20220825150840.132216-3-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-hub.c | 11 +++++++++++ + drivers/usb/host/xhci.c | 4 +++- + drivers/usb/host/xhci.h | 2 +- + 3 files changed, 15 insertions(+), 2 deletions(-) + +--- a/drivers/usb/host/xhci-hub.c ++++ b/drivers/usb/host/xhci-hub.c +@@ -1297,6 +1297,17 @@ int xhci_hub_status_data(struct usb_hcd + + status = bus_state->resuming_ports; + ++ /* ++ * SS devices are only visible to roothub after link training completes. ++ * Keep polling roothubs for a grace period after xHC start ++ */ ++ if (xhci->run_graceperiod) { ++ if (time_before(jiffies, xhci->run_graceperiod)) ++ status = 1; ++ else ++ xhci->run_graceperiod = 0; ++ } ++ + mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC | PORT_CEC; + + /* For each port, did anything change? If so, set that bit in buf. */ +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -144,9 +144,11 @@ static int xhci_start(struct xhci_hcd *x + xhci_err(xhci, "Host took too long to start, " + "waited %u microseconds.\n", + XHCI_MAX_HALT_USEC); +- if (!ret) ++ if (!ret) { + /* clear state flags. Including dying, halted or removing */ + xhci->xhc_state = 0; ++ xhci->run_graceperiod = jiffies + msecs_to_jiffies(500); ++ } + + return ret; + } +--- a/drivers/usb/host/xhci.h ++++ b/drivers/usb/host/xhci.h +@@ -1607,7 +1607,7 @@ struct xhci_hcd { + + /* Host controller watchdog timer structures */ + unsigned int xhc_state; +- ++ unsigned long run_graceperiod; + u32 command; + struct s3_save s3; + /* Host controller is dying - not responding to commands. "I'm not dead yet!"