--- /dev/null
+From d06b1cf28297e27127d3da54753a3a01a2fa2f28 Mon Sep 17 00:00:00 2001
+From: Robert Hancock <robert.hancock@calian.com>
+Date: Wed, 12 Jan 2022 13:42:14 -0600
+Subject: serial: 8250: of: Fix mapped region size when using reg-offset property
+
+From: Robert Hancock <robert.hancock@calian.com>
+
+commit d06b1cf28297e27127d3da54753a3a01a2fa2f28 upstream.
+
+8250_of supports a reg-offset property which is intended to handle
+cases where the device registers start at an offset inside the region
+of memory allocated to the device. The Xilinx 16550 UART, for which this
+support was initially added, requires this. However, the code did not
+adjust the overall size of the mapped region accordingly, causing the
+driver to request an area of memory past the end of the device's
+allocation. For example, if the UART was allocated an address of
+0xb0130000, size of 0x10000 and reg-offset of 0x1000 in the device
+tree, the region of memory reserved was b0131000-b0140fff, which caused
+the driver for the region starting at b0140000 to fail to probe.
+
+Fix this by subtracting reg-offset from the mapped region size.
+
+Fixes: b912b5e2cfb3 ([POWERPC] Xilinx: of_serial support for Xilinx uart 16550.)
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Robert Hancock <robert.hancock@calian.com>
+Link: https://lore.kernel.org/r/20220112194214.881844-1-robert.hancock@calian.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_of.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/8250/8250_of.c
++++ b/drivers/tty/serial/8250/8250_of.c
+@@ -83,8 +83,17 @@ static int of_platform_serial_setup(stru
+ port->mapsize = resource_size(&resource);
+
+ /* Check for shifted address mapping */
+- if (of_property_read_u32(np, "reg-offset", &prop) == 0)
++ if (of_property_read_u32(np, "reg-offset", &prop) == 0) {
++ if (prop >= port->mapsize) {
++ dev_warn(&ofdev->dev, "reg-offset %u exceeds region size %pa\n",
++ prop, &port->mapsize);
++ ret = -EINVAL;
++ goto err_unprepare;
++ }
++
+ port->mapbase += prop;
++ port->mapsize -= prop;
++ }
+
+ port->iotype = UPIO_MEM;
+ if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
--- /dev/null
+From 037b91ec7729524107982e36ec4b40f9b174f7a2 Mon Sep 17 00:00:00 2001
+From: Valentin Caron <valentin.caron@foss.st.com>
+Date: Tue, 11 Jan 2022 17:44:41 +0100
+Subject: serial: stm32: fix software flow control transfer
+
+From: Valentin Caron <valentin.caron@foss.st.com>
+
+commit 037b91ec7729524107982e36ec4b40f9b174f7a2 upstream.
+
+x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty.
+
+Fix start_tx condition to allow x_char to be sent.
+
+Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
+Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
+Link: https://lore.kernel.org/r/20220111164441.6178-3-valentin.caron@foss.st.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/stm32-usart.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/stm32-usart.c
++++ b/drivers/tty/serial/stm32-usart.c
+@@ -574,7 +574,7 @@ static void stm32_usart_start_tx(struct
+ struct serial_rs485 *rs485conf = &port->rs485;
+ struct circ_buf *xmit = &port->state->xmit;
+
+- if (uart_circ_empty(xmit))
++ if (uart_circ_empty(xmit) && !port->x_char)
+ return;
+
+ if (rs485conf->flags & SER_RS485_ENABLED) {
kvm-x86-update-vcpu-s-runtime-cpuid-on-write-to-msr_ia32_xss.patch
arm64-errata-fix-exec-handling-in-erratum-1418040-workaround.patch
netfilter-nft_payload-do-not-update-layer-4-checksum-when-mangling-fragments.patch
+serial-8250-of-fix-mapped-region-size-when-using-reg-offset-property.patch
+serial-stm32-fix-software-flow-control-transfer.patch
+tty-n_gsm-fix-sw-flow-control-encoding-handling.patch
+tty-add-support-for-brainboxes-uc-cards.patch
+usb-storage-add-unusual-devs-entry-for-vl817-usb-sata-bridge.patch
+usb-xhci-plat-fix-crash-when-suspend-if-remote-wake-enable.patch
+usb-common-ulpi-fix-crash-in-ulpi_match.patch
+usb-gadget-f_sourcesink-fix-isoc-transfer-for-usb_speed_super_plus.patch
+usb-core-fix-hang-in-usb_kill_urb-by-adding-memory-barriers.patch
+usb-typec-tcpm-do-not-disconnect-while-receiving-vbus-off.patch
+ucsi_ccg-check-dev_int-bit-only-when-starting-ccg4.patch
--- /dev/null
+From 152d1afa834c84530828ee031cf07a00e0fc0b8c Mon Sep 17 00:00:00 2001
+From: Cameron Williams <cang1@live.co.uk>
+Date: Mon, 24 Jan 2022 09:42:23 +0000
+Subject: tty: Add support for Brainboxes UC cards.
+
+From: Cameron Williams <cang1@live.co.uk>
+
+commit 152d1afa834c84530828ee031cf07a00e0fc0b8c upstream.
+
+This commit adds support for the some of the Brainboxes PCI range of
+cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279,
+UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368
+and UC-420/431.
+
+Signed-off-by: Cameron Williams <cang1@live.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/AM5PR0202MB2564688493F7DD9B9C610827C45E9@AM5PR0202MB2564.eurprd02.prod.outlook.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_pci.c | 100 ++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 98 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_pci.c
++++ b/drivers/tty/serial/8250/8250_pci.c
+@@ -5171,8 +5171,30 @@ static const struct pci_device_id serial
+ { PCI_VENDOR_ID_INTASHIELD, PCI_DEVICE_ID_INTASHIELD_IS400,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
+ pbn_b2_4_115200 },
++ /* Brainboxes Devices */
+ /*
+- * BrainBoxes UC-260
++ * Brainboxes UC-101
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0BA1,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_2_115200 },
++ /*
++ * Brainboxes UC-235/246
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0AA1,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_1_115200 },
++ /*
++ * Brainboxes UC-257
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0861,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_2_115200 },
++ /*
++ * Brainboxes UC-260/271/701/756
+ */
+ { PCI_VENDOR_ID_INTASHIELD, 0x0D21,
+ PCI_ANY_ID, PCI_ANY_ID,
+@@ -5180,7 +5202,81 @@ static const struct pci_device_id serial
+ pbn_b2_4_115200 },
+ { PCI_VENDOR_ID_INTASHIELD, 0x0E34,
+ PCI_ANY_ID, PCI_ANY_ID,
+- PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
++ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
++ pbn_b2_4_115200 },
++ /*
++ * Brainboxes UC-268
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0841,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_4_115200 },
++ /*
++ * Brainboxes UC-275/279
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0881,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_8_115200 },
++ /*
++ * Brainboxes UC-302
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x08E1,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_2_115200 },
++ /*
++ * Brainboxes UC-310
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x08C1,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_2_115200 },
++ /*
++ * Brainboxes UC-313
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x08A3,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_2_115200 },
++ /*
++ * Brainboxes UC-320/324
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0A61,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_1_115200 },
++ /*
++ * Brainboxes UC-346
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0B02,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_4_115200 },
++ /*
++ * Brainboxes UC-357
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0A81,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_2_115200 },
++ { PCI_VENDOR_ID_INTASHIELD, 0x0A83,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_2_115200 },
++ /*
++ * Brainboxes UC-368
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0C41,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
++ pbn_b2_4_115200 },
++ /*
++ * Brainboxes UC-420/431
++ */
++ { PCI_VENDOR_ID_INTASHIELD, 0x0921,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0, 0,
+ pbn_b2_4_115200 },
+ /*
+ * Perle PCI-RAS cards
--- /dev/null
+From 8838b2af23caf1ff0610caef2795d6668a013b2d Mon Sep 17 00:00:00 2001
+From: "daniel.starke@siemens.com" <daniel.starke@siemens.com>
+Date: Thu, 20 Jan 2022 02:18:57 -0800
+Subject: tty: n_gsm: fix SW flow control encoding/handling
+
+From: daniel.starke@siemens.com <daniel.starke@siemens.com>
+
+commit 8838b2af23caf1ff0610caef2795d6668a013b2d upstream.
+
+n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010.
+See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516
+The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to
+the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF)
+are the control characters defined in ISO/IEC 646. These shall be quoted if
+seen in the data stream to avoid interpretation as flow control characters.
+
+ISO/IEC 646 refers to the set of ISO standards described as the ISO
+7-bit coded character set for information interchange. Its final version
+is also known as ITU T.50.
+See https://www.itu.int/rec/T-REC-T.50-199209-I/en
+
+To abide the standard it is needed to quote DC1 and DC3 correctly if these
+are seen as data bytes and not as control characters. The current
+implementation already tries to enforce this but fails to catch all
+defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most
+significant bit shall be ignored for DC1 and DC3 handling. The current
+implementation handles only the case with the most significant bit set 0.
+Cases in which DC1 and DC3 have the most significant bit set 1 are left
+unhandled.
+
+This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only
+the 7 least significant bits set 1) before comparing them with XON
+(a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need
+quotation via byte stuffing.
+
+Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
+Link: https://lore.kernel.org/r/20220120101857.2509-1-daniel.starke@siemens.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/n_gsm.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/n_gsm.c
++++ b/drivers/tty/n_gsm.c
+@@ -317,6 +317,7 @@ static struct tty_driver *gsm_tty_driver
+ #define GSM1_ESCAPE_BITS 0x20
+ #define XON 0x11
+ #define XOFF 0x13
++#define ISO_IEC_646_MASK 0x7F
+
+ static const struct tty_port_operations gsm_port_ops;
+
+@@ -526,7 +527,8 @@ static int gsm_stuff_frame(const u8 *inp
+ int olen = 0;
+ while (len--) {
+ if (*input == GSM1_SOF || *input == GSM1_ESCAPE
+- || *input == XON || *input == XOFF) {
++ || (*input & ISO_IEC_646_MASK) == XON
++ || (*input & ISO_IEC_646_MASK) == XOFF) {
+ *output++ = GSM1_ESCAPE;
+ *output++ = *input++ ^ GSM1_ESCAPE_BITS;
+ olen++;
--- /dev/null
+From 825911492eb15bf8bb7fb94bc0c0421fe7a6327d Mon Sep 17 00:00:00 2001
+From: Sing-Han Chen <singhanc@nvidia.com>
+Date: Wed, 12 Jan 2022 17:41:43 +0800
+Subject: ucsi_ccg: Check DEV_INT bit only when starting CCG4
+
+From: Sing-Han Chen <singhanc@nvidia.com>
+
+commit 825911492eb15bf8bb7fb94bc0c0421fe7a6327d upstream.
+
+CCGx clears Bit 0:Device Interrupt in the INTR_REG
+if CCGx is reset successfully. However, there might
+be a chance that other bits in INTR_REG are not
+cleared due to internal data queued in PPM. This case
+misleads the driver that CCGx reset failed.
+
+The commit checks bit 0 in INTR_REG and ignores other
+bits. The ucsi driver would reset PPM later.
+
+Fixes: 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx")
+Cc: stable@vger.kernel.org
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Signed-off-by: Sing-Han Chen <singhanc@nvidia.com>
+Signed-off-by: Wayne Chang <waynec@nvidia.com>
+Link: https://lore.kernel.org/r/20220112094143.628610-1-waynec@nvidia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/ucsi/ucsi_ccg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/typec/ucsi/ucsi_ccg.c
++++ b/drivers/usb/typec/ucsi/ucsi_ccg.c
+@@ -325,7 +325,7 @@ static int ucsi_ccg_init(struct ucsi_ccg
+ if (status < 0)
+ return status;
+
+- if (!data)
++ if (!(data & DEV_INT))
+ return 0;
+
+ status = ccg_write(uc, CCGX_RAB_INTR_REG, &data, sizeof(data));
--- /dev/null
+From 2e3dd4a6246945bf84ea6f478365d116e661554c Mon Sep 17 00:00:00 2001
+From: Jon Hunter <jonathanh@nvidia.com>
+Date: Mon, 17 Jan 2022 15:00:39 +0000
+Subject: usb: common: ulpi: Fix crash in ulpi_match()
+
+From: Jon Hunter <jonathanh@nvidia.com>
+
+commit 2e3dd4a6246945bf84ea6f478365d116e661554c upstream.
+
+Commit 7495af930835 ("ARM: multi_v7_defconfig: Enable drivers for
+DragonBoard 410c") enables the CONFIG_PHY_QCOM_USB_HS for the ARM
+multi_v7_defconfig. Enabling this Kconfig is causing the kernel to crash
+on the Tegra20 Ventana platform in the ulpi_match() function.
+
+The Qualcomm USB HS PHY driver that is enabled by CONFIG_PHY_QCOM_USB_HS,
+registers a ulpi_driver but this driver does not provide an 'id_table',
+so when ulpi_match() is called on the Tegra20 Ventana platform, it
+crashes when attempting to deference the id_table pointer which is not
+valid. The Qualcomm USB HS PHY driver uses device-tree for matching the
+ULPI driver with the device and so fix this crash by using device-tree
+for matching if the id_table is not valid.
+
+Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
+Link: https://lore.kernel.org/r/20220117150039.44058-1-jonathanh@nvidia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/common/ulpi.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/common/ulpi.c
++++ b/drivers/usb/common/ulpi.c
+@@ -39,8 +39,11 @@ static int ulpi_match(struct device *dev
+ struct ulpi *ulpi = to_ulpi_dev(dev);
+ const struct ulpi_device_id *id;
+
+- /* Some ULPI devices don't have a vendor id so rely on OF match */
+- if (ulpi->id.vendor == 0)
++ /*
++ * Some ULPI devices don't have a vendor id
++ * or provide an id_table so rely on OF match.
++ */
++ if (ulpi->id.vendor == 0 || !drv->id_table)
+ return of_driver_match_device(dev, driver);
+
+ for (id = drv->id_table; id->vendor; id++)
--- /dev/null
+From 26fbe9772b8c459687930511444ce443011f86bf Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 24 Jan 2022 15:23:45 -0500
+Subject: USB: core: Fix hang in usb_kill_urb by adding memory barriers
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 26fbe9772b8c459687930511444ce443011f86bf upstream.
+
+The syzbot fuzzer has identified a bug in which processes hang waiting
+for usb_kill_urb() to return. It turns out the issue is not unlinking
+the URB; that works just fine. Rather, the problem arises when the
+wakeup notification that the URB has completed is not received.
+
+The reason is memory-access ordering on SMP systems. In outline form,
+usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
+different CPUs perform the following actions:
+
+CPU 0 CPU 1
+---------------------------- ---------------------------------
+usb_kill_urb(): __usb_hcd_giveback_urb():
+ ... ...
+ atomic_inc(&urb->reject); atomic_dec(&urb->use_count);
+ ... ...
+ wait_event(usb_kill_urb_queue,
+ atomic_read(&urb->use_count) == 0);
+ if (atomic_read(&urb->reject))
+ wake_up(&usb_kill_urb_queue);
+
+Confining your attention to urb->reject and urb->use_count, you can
+see that the overall pattern of accesses on CPU 0 is:
+
+ write urb->reject, then read urb->use_count;
+
+whereas the overall pattern of accesses on CPU 1 is:
+
+ write urb->use_count, then read urb->reject.
+
+This pattern is referred to in memory-model circles as SB (for "Store
+Buffering"), and it is well known that without suitable enforcement of
+the desired order of accesses -- in the form of memory barriers -- it
+is entirely possible for one or both CPUs to execute their reads ahead
+of their writes. The end result will be that sometimes CPU 0 sees the
+old un-decremented value of urb->use_count while CPU 1 sees the old
+un-incremented value of urb->reject. Consequently CPU 0 ends up on
+the wait queue and never gets woken up, leading to the observed hang
+in usb_kill_urb().
+
+The same pattern of accesses occurs in usb_poison_urb() and the
+failure pathway of usb_hcd_submit_urb().
+
+The problem is fixed by adding suitable memory barriers. To provide
+proper memory-access ordering in the SB pattern, a full barrier is
+required on both CPUs. The atomic_inc() and atomic_dec() accesses
+themselves don't provide any memory ordering, but since they are
+present, we can use the optimized smp_mb__after_atomic() memory
+barrier in the various routines to obtain the desired effect.
+
+This patch adds the necessary memory barriers.
+
+CC: <stable@vger.kernel.org>
+Reported-and-tested-by: syzbot+76629376e06e2c2ad626@syzkaller.appspotmail.com
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/hcd.c | 14 ++++++++++++++
+ drivers/usb/core/urb.c | 12 ++++++++++++
+ 2 files changed, 26 insertions(+)
+
+--- a/drivers/usb/core/hcd.c
++++ b/drivers/usb/core/hcd.c
+@@ -1562,6 +1562,13 @@ int usb_hcd_submit_urb (struct urb *urb,
+ urb->hcpriv = NULL;
+ INIT_LIST_HEAD(&urb->urb_list);
+ atomic_dec(&urb->use_count);
++ /*
++ * Order the write of urb->use_count above before the read
++ * of urb->reject below. Pairs with the memory barriers in
++ * usb_kill_urb() and usb_poison_urb().
++ */
++ smp_mb__after_atomic();
++
+ atomic_dec(&urb->dev->urbnum);
+ if (atomic_read(&urb->reject))
+ wake_up(&usb_kill_urb_queue);
+@@ -1666,6 +1673,13 @@ static void __usb_hcd_giveback_urb(struc
+
+ usb_anchor_resume_wakeups(anchor);
+ atomic_dec(&urb->use_count);
++ /*
++ * Order the write of urb->use_count above before the read
++ * of urb->reject below. Pairs with the memory barriers in
++ * usb_kill_urb() and usb_poison_urb().
++ */
++ smp_mb__after_atomic();
++
+ if (unlikely(atomic_read(&urb->reject)))
+ wake_up(&usb_kill_urb_queue);
+ usb_put_urb(urb);
+--- a/drivers/usb/core/urb.c
++++ b/drivers/usb/core/urb.c
+@@ -706,6 +706,12 @@ void usb_kill_urb(struct urb *urb)
+ if (!(urb && urb->dev && urb->ep))
+ return;
+ atomic_inc(&urb->reject);
++ /*
++ * Order the write of urb->reject above before the read
++ * of urb->use_count below. Pairs with the barriers in
++ * __usb_hcd_giveback_urb() and usb_hcd_submit_urb().
++ */
++ smp_mb__after_atomic();
+
+ usb_hcd_unlink_urb(urb, -ENOENT);
+ wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
+@@ -747,6 +753,12 @@ void usb_poison_urb(struct urb *urb)
+ if (!urb)
+ return;
+ atomic_inc(&urb->reject);
++ /*
++ * Order the write of urb->reject above before the read
++ * of urb->use_count below. Pairs with the barriers in
++ * __usb_hcd_giveback_urb() and usb_hcd_submit_urb().
++ */
++ smp_mb__after_atomic();
+
+ if (!urb->dev || !urb->ep)
+ return;
--- /dev/null
+From 904edf8aeb459697129be5fde847e2a502f41fd9 Mon Sep 17 00:00:00 2001
+From: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
+Date: Sat, 22 Jan 2022 08:33:22 +0530
+Subject: usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS
+
+From: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
+
+commit 904edf8aeb459697129be5fde847e2a502f41fd9 upstream.
+
+Currently when gadget enumerates in super speed plus, the isoc
+endpoint request buffer size is not calculated correctly. Fix
+this by checking the gadget speed against USB_SPEED_SUPER_PLUS
+and update the request buffer size.
+
+Fixes: 90c4d05780d4 ("usb: fix various gadgets null ptr deref on 10gbps cabling.")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
+Link: https://lore.kernel.org/r/1642820602-20619-1-git-send-email-quic_pkondeti@quicinc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/function/f_sourcesink.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/gadget/function/f_sourcesink.c
++++ b/drivers/usb/gadget/function/f_sourcesink.c
+@@ -583,6 +583,7 @@ static int source_sink_start_ep(struct f
+
+ if (is_iso) {
+ switch (speed) {
++ case USB_SPEED_SUPER_PLUS:
+ case USB_SPEED_SUPER:
+ size = ss->isoc_maxpacket *
+ (ss->isoc_mult + 1) *
--- /dev/null
+From 5b67b315037250a61861119683e7fcb509deea25 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 24 Jan 2022 15:14:40 -0500
+Subject: usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 5b67b315037250a61861119683e7fcb509deea25 upstream.
+
+Two people have reported (and mentioned numerous other reports on the
+web) that VIA's VL817 USB-SATA bridge does not work with the uas
+driver. Typical log messages are:
+
+[ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 inflight: CMD
+[ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18 0c c9 80 00 00 00 80 00 00
+[ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd
+[ 3606.328584] scsi host14: uas_eh_device_reset_handler success
+
+Surprisingly, the devices do seem to work okay for some other people.
+The cause of the differing behaviors is not known.
+
+In the hope of getting the devices to work for the most users, even at
+the possible cost of degraded performance for some, this patch adds an
+unusual_devs entry for the VL817 to block it from binding to the uas
+driver by default. Users will be able to override this entry by means
+of a module parameter, if they want.
+
+CC: <stable@vger.kernel.org>
+Reported-by: DocMAX <mail@vacharakis.de>
+Reported-and-tested-by: Thomas Weißschuh <linux@weissschuh.net>
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/Ye8IsK2sjlEv1rqU@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/unusual_devs.h | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -2301,6 +2301,16 @@ UNUSUAL_DEV( 0x2027, 0xa001, 0x0000, 0x
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
+ US_FL_SCM_MULT_TARG ),
+
++/*
++ * Reported by DocMAX <mail@vacharakis.de>
++ * and Thomas Weißschuh <linux@weissschuh.net>
++ */
++UNUSUAL_DEV( 0x2109, 0x0715, 0x9999, 0x9999,
++ "VIA Labs, Inc.",
++ "VL817 SATA Bridge",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_IGNORE_UAS),
++
+ UNUSUAL_DEV( 0x2116, 0x0320, 0x0001, 0x0001,
+ "ST",
+ "2A",
--- /dev/null
+From 90b8aa9f5b09edae6928c0561f933fec9f7a9987 Mon Sep 17 00:00:00 2001
+From: Badhri Jagan Sridharan <badhri@google.com>
+Date: Fri, 21 Jan 2022 17:55:19 -0800
+Subject: usb: typec: tcpm: Do not disconnect while receiving VBUS off
+
+From: Badhri Jagan Sridharan <badhri@google.com>
+
+commit 90b8aa9f5b09edae6928c0561f933fec9f7a9987 upstream.
+
+With some chargers, vbus might momentarily raise above VSAFE5V and fall
+back to 0V before tcpm gets to read port->tcpc->get_vbus. This will
+will report a VBUS off event causing TCPM to transition to
+SNK_UNATTACHED where it should be waiting in either SNK_ATTACH_WAIT
+or SNK_DEBOUNCED state. This patch makes TCPM avoid vbus off events
+while in SNK_ATTACH_WAIT or SNK_DEBOUNCED state.
+
+Stub from the spec:
+ "4.5.2.2.4.2 Exiting from AttachWait.SNK State
+ A Sink shall transition to Unattached.SNK when the state of both
+ the CC1 and CC2 pins is SNK.Open for at least tPDDebounce.
+ A DRP shall transition to Unattached.SRC when the state of both
+ the CC1 and CC2 pins is SNK.Open for at least tPDDebounce."
+
+[23.194131] CC1: 0 -> 0, CC2: 0 -> 5 [state SNK_UNATTACHED, polarity 0, connected]
+[23.201777] state change SNK_UNATTACHED -> SNK_ATTACH_WAIT [rev3 NONE_AMS]
+[23.209949] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS]
+[23.300579] VBUS off
+[23.300668] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [rev3 NONE_AMS]
+[23.301014] VBUS VSAFE0V
+[23.301111] Start toggling
+
+Fixes: f0690a25a140b8 ("staging: typec: USB Type-C Port Manager (tcpm)")
+Cc: stable@vger.kernel.org
+Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
+Link: https://lore.kernel.org/r/20220122015520.332507-1-badhri@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/tcpm/tcpm.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/typec/tcpm/tcpm.c
++++ b/drivers/usb/typec/tcpm/tcpm.c
+@@ -4164,7 +4164,8 @@ static void _tcpm_pd_vbus_off(struct tcp
+ case SNK_TRYWAIT_DEBOUNCE:
+ break;
+ case SNK_ATTACH_WAIT:
+- tcpm_set_state(port, SNK_UNATTACHED, 0);
++ case SNK_DEBOUNCED:
++ /* Do nothing, as TCPM is still waiting for vbus to reaach VSAFE5V to connect */
+ break;
+
+ case SNK_NEGOTIATE_CAPABILITIES:
--- /dev/null
+From 9df478463d9feb90dae24f183383961cf123a0ec Mon Sep 17 00:00:00 2001
+From: Frank Li <Frank.Li@nxp.com>
+Date: Mon, 10 Jan 2022 11:27:38 -0600
+Subject: usb: xhci-plat: fix crash when suspend if remote wake enable
+
+From: Frank Li <Frank.Li@nxp.com>
+
+commit 9df478463d9feb90dae24f183383961cf123a0ec upstream.
+
+Crashed at i.mx8qm platform when suspend if enable remote wakeup
+
+Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
+Modules linked in:
+CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12
+Hardware name: Freescale i.MX8QM MEK (DT)
+Workqueue: events_unbound async_run_entry_fn
+pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8
+lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8
+sp : ffff80001394bbf0
+x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578
+x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000
+x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001
+x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000
+x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
+x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000
+x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0
+x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453
+x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c
+x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620
+Call trace:
+ xhci_disable_hub_port_wake.isra.62+0x60/0xf8
+ xhci_suspend+0x58/0x510
+ xhci_plat_suspend+0x50/0x78
+ platform_pm_suspend+0x2c/0x78
+ dpm_run_callback.isra.25+0x50/0xe8
+ __device_suspend+0x108/0x3c0
+
+The basic flow:
+ 1. run time suspend call xhci_suspend, xhci parent devices gate the clock.
+ 2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend
+ 3. xhci_suspend call xhci_disable_hub_port_wake, which access register,
+ but clock already gated by run time suspend.
+
+This problem was hidden by power domain driver, which call run time resume before it.
+
+But the below commit remove it and make this issue happen.
+ commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()")
+
+This patch call run time resume before suspend to make sure clock is on
+before access register.
+
+Reviewed-by: Peter Chen <peter.chen@kernel.org>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Frank Li <Frank.Li@nxp.com>
+Testeb-by: Abel Vesa <abel.vesa@nxp.com>
+Link: https://lore.kernel.org/r/20220110172738.31686-1-Frank.Li@nxp.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-plat.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/host/xhci-plat.c
++++ b/drivers/usb/host/xhci-plat.c
+@@ -437,6 +437,9 @@ static int __maybe_unused xhci_plat_susp
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ int ret;
+
++ if (pm_runtime_suspended(dev))
++ pm_runtime_resume(dev);
++
+ ret = xhci_priv_suspend_quirk(hcd);
+ if (ret)
+ return ret;
projects / thirdparty / kernel / stable-queue.git / commitdiff
