usb-mtu3-fix-extcon-dependency.patch
usb-gadget-f_hid-fix-deadlock-in-f_hidg_write.patch
usb-common-consider-only-available-nodes-for-dr_mode.patch
+usb-host-xhci-rcar-add-xhci_trust_tx_length-quirk.patch
+xhci-fix-port-resume-done-detection-for-ss-ports-with-lpm-enabled.patch
+usb-xhci-dbc-don-t-free-all-memory-with-spinlock-held.patch
+xhci-don-t-let-usb3-ports-stuck-in-polling-state-prevent-suspend.patch
+usb-cdc-acm-fix-race-during-wakeup-blocking-tx-traffic.patch
--- /dev/null
+From 93e1c8a638308980309e009cc40b5a57ef87caf1 Mon Sep 17 00:00:00 2001
+From: Romain Izard <romain.izard.pro@gmail.com>
+Date: Fri, 22 Mar 2019 16:53:02 +0100
+Subject: usb: cdc-acm: fix race during wakeup blocking TX traffic
+
+From: Romain Izard <romain.izard.pro@gmail.com>
+
+commit 93e1c8a638308980309e009cc40b5a57ef87caf1 upstream.
+
+When the kernel is compiled with preemption enabled, the URB completion
+handler can run in parallel with the work responsible for waking up the
+tty layer. If the URB handler sets the EVENT_TTY_WAKEUP bit during the
+call to tty_port_tty_wakeup() to signal that there is room for additional
+input, it will be cleared at the end of this call. As a result, TX traffic
+on the upper layer will be blocked.
+
+This can be seen with a kernel configured with CONFIG_PREEMPT, and a fast
+modem connected with PPP running over a USB CDC-ACM port.
+
+Use test_and_clear_bit() instead, which ensures that each wakeup requested
+by the URB completion code will trigger a call to tty_port_tty_wakeup().
+
+Fixes: 1aba579f3cf5 cdc-acm: handle read pipe errors
+Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Oliver Neukum <oneukum@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/class/cdc-acm.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/usb/class/cdc-acm.c
++++ b/drivers/usb/class/cdc-acm.c
+@@ -558,10 +558,8 @@ static void acm_softint(struct work_stru
+ clear_bit(EVENT_RX_STALL, &acm->flags);
+ }
+
+- if (test_bit(EVENT_TTY_WAKEUP, &acm->flags)) {
++ if (test_and_clear_bit(EVENT_TTY_WAKEUP, &acm->flags))
+ tty_port_tty_wakeup(&acm->port);
+- clear_bit(EVENT_TTY_WAKEUP, &acm->flags);
+- }
+ }
+
+ /*
--- /dev/null
+From 40fc165304f0faaae78b761f8ee30b5d216b1850 Mon Sep 17 00:00:00 2001
+From: Yasushi Asano <yasano@jp.adit-jv.com>
+Date: Mon, 18 Feb 2019 11:26:34 +0100
+Subject: usb: host: xhci-rcar: Add XHCI_TRUST_TX_LENGTH quirk
+
+From: Yasushi Asano <yasano@jp.adit-jv.com>
+
+commit 40fc165304f0faaae78b761f8ee30b5d216b1850 upstream.
+
+When plugging BUFFALO LUA4-U3-AGT USB3.0 to Gigabit Ethernet LAN
+Adapter, warning messages filled up dmesg.
+
+[ 101.098287] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
+[ 101.117463] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
+[ 101.136513] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
+
+Adding the XHCI_TRUST_TX_LENGTH quirk resolves the issue.
+
+Signed-off-by: Yasushi Asano <yasano@jp.adit-jv.com>
+Signed-off-by: Spyridon Papageorgiou <spapageorgiou@de.adit-jv.com>
+Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-rcar.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/host/xhci-rcar.c
++++ b/drivers/usb/host/xhci-rcar.c
+@@ -246,6 +246,7 @@ int xhci_rcar_init_quirk(struct usb_hcd
+ if (!xhci_rcar_wait_for_pll_active(hcd))
+ return -ETIMEDOUT;
+
++ xhci->quirks |= XHCI_TRUST_TX_LENGTH;
+ return xhci_rcar_download_firmware(hcd);
+ }
+
--- /dev/null
+From 8867ea262196a6945c24a0fb739575af646ec0e9 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 22 Mar 2019 17:50:16 +0200
+Subject: usb: xhci: dbc: Don't free all memory with spinlock held
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 8867ea262196a6945c24a0fb739575af646ec0e9 upstream.
+
+The xhci debug capability (DbC) feature did its memory cleanup with
+spinlock held. dma_free_coherent() warns if called with interrupts
+disabled
+
+move the memory cleanup outside the spinlock
+
+Cc: stable <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-dbgcap.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-dbgcap.c
++++ b/drivers/usb/host/xhci-dbgcap.c
+@@ -516,7 +516,6 @@ static int xhci_do_dbc_stop(struct xhci_
+ return -1;
+
+ writel(0, &dbc->regs->control);
+- xhci_dbc_mem_cleanup(xhci);
+ dbc->state = DS_DISABLED;
+
+ return 0;
+@@ -562,8 +561,10 @@ static void xhci_dbc_stop(struct xhci_hc
+ ret = xhci_do_dbc_stop(xhci);
+ spin_unlock_irqrestore(&dbc->lock, flags);
+
+- if (!ret)
++ if (!ret) {
++ xhci_dbc_mem_cleanup(xhci);
+ pm_runtime_put_sync(xhci_to_hcd(xhci)->self.controller);
++ }
+ }
+
+ static void
--- /dev/null
+From d92f2c59cc2cbca6bfb2cc54882b58ba76b15fd4 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 22 Mar 2019 17:50:17 +0200
+Subject: xhci: Don't let USB3 ports stuck in polling state prevent suspend
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit d92f2c59cc2cbca6bfb2cc54882b58ba76b15fd4 upstream.
+
+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 | 19 ++++++++++++-------
+ drivers/usb/host/xhci.h | 8 ++++++++
+ 2 files changed, 20 insertions(+), 7 deletions(-)
+
+--- a/drivers/usb/host/xhci-hub.c
++++ b/drivers/usb/host/xhci-hub.c
+@@ -1501,20 +1501,25 @@ int xhci_bus_suspend(struct usb_hcd *hcd
+ port_index = max_ports;
+ while (port_index--) {
+ u32 t1, t2;
+-
++ int retries = 10;
++retry:
+ t1 = readl(ports[port_index]->addr);
+ t2 = xhci_port_state_to_neutral(t1);
+ portsc_buf[port_index] = 0;
+
+- /* Bail out if a USB3 port has a new device in link training */
+- if ((hcd->speed >= HCD_USB3) &&
++ /*
++ * Give a USB3 port in link training time to finish, but don't
++ * prevent suspend as port might be stuck
++ */
++ if ((hcd->speed >= HCD_USB3) && retries-- &&
+ (t1 & PORT_PLS_MASK) == XDEV_POLLING) {
+- bus_state->bus_suspended = 0;
+ spin_unlock_irqrestore(&xhci->lock, flags);
+- xhci_dbg(xhci, "Bus suspend bailout, port in polling\n");
+- return -EBUSY;
++ msleep(XHCI_PORT_POLLING_LFPS_TIME);
++ spin_lock_irqsave(&xhci->lock, flags);
++ xhci_dbg(xhci, "port %d polling in bus suspend, waiting\n",
++ port_index);
++ goto retry;
+ }
+-
+ /* suspend ports in U0, or bail out for new connect changes */
+ if ((t1 & PORT_PE) && (t1 & PORT_PLS_MASK) == XDEV_U0) {
+ if ((t1 & PORT_CSC) && wake_enabled) {
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -452,6 +452,14 @@ struct xhci_op_regs {
+ */
+ #define XHCI_DEFAULT_BESL 4
+
++/*
++ * USB3 specification define a 360ms tPollingLFPSTiemout for USB3 ports
++ * to complete link training. usually link trainig completes much faster
++ * so check status 10 times with 36ms sleep in places we need to wait for
++ * polling to complete.
++ */
++#define XHCI_PORT_POLLING_LFPS_TIME 36
++
+ /**
+ * struct xhci_intr_reg - Interrupt Register Set
+ * @irq_pending: IMAN - Interrupt Management Register. Used to enable
--- /dev/null
+From 6cbcf596934c8e16d6288c7cc62dfb7ad8eadf15 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 22 Mar 2019 17:50:15 +0200
+Subject: xhci: Fix port resume done detection for SS ports with LPM enabled
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 6cbcf596934c8e16d6288c7cc62dfb7ad8eadf15 upstream.
+
+A suspended SS port in U3 link state will go to U0 when resumed, but
+can almost immediately after that enter U1 or U2 link power save
+states before host controller driver reads the port status.
+
+Host controller driver only checks for U0 state, and might miss
+the finished resume, leaving flags unclear and skip notifying usb
+code of the wake.
+
+Add U1 and U2 to the possible link states when checking for finished
+port resume.
+
+Cc: stable <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-ring.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -1643,10 +1643,13 @@ static void handle_port_status(struct xh
+ }
+ }
+
+- if ((portsc & PORT_PLC) && (portsc & PORT_PLS_MASK) == XDEV_U0 &&
+- DEV_SUPERSPEED_ANY(portsc)) {
++ if ((portsc & PORT_PLC) &&
++ DEV_SUPERSPEED_ANY(portsc) &&
++ ((portsc & PORT_PLS_MASK) == XDEV_U0 ||
++ (portsc & PORT_PLS_MASK) == XDEV_U1 ||
++ (portsc & PORT_PLS_MASK) == XDEV_U2)) {
+ xhci_dbg(xhci, "resume SS port %d finished\n", port_id);
+- /* We've just brought the device into U0 through either the
++ /* We've just brought the device into U0/1/2 through either the
+ * Resume state after a device remote wakeup, or through the
+ * U3Exit state after a host-initiated resume. If it's a device
+ * initiated remote wake, don't pass up the link state change,