--- /dev/null
+From 0e99e960ce6d5ff586fc0733bc393c087f52c27b Mon Sep 17 00:00:00 2001
+From: Shirish S <shirish.s@amd.com>
+Date: Tue, 3 Aug 2021 14:03:44 +0530
+Subject: drm/amdgpu/display: fix DMUB firmware version info
+
+From: Shirish S <shirish.s@amd.com>
+
+commit 0e99e960ce6d5ff586fc0733bc393c087f52c27b upstream.
+
+DMUB firmware info is printed before it gets initialized.
+Correct this order to ensure true value is conveyed.
+
+Signed-off-by: Shirish S <shirish.s@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -1493,6 +1493,7 @@ static int dm_dmub_sw_init(struct amdgpu
+ }
+
+ hdr = (const struct dmcub_firmware_header_v1_0 *)adev->dm.dmub_fw->data;
++ adev->dm.dmcub_fw_version = le32_to_cpu(hdr->header.ucode_version);
+
+ if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) {
+ adev->firmware.ucode[AMDGPU_UCODE_ID_DMCUB].ucode_id =
+@@ -1506,7 +1507,6 @@ static int dm_dmub_sw_init(struct amdgpu
+ adev->dm.dmcub_fw_version);
+ }
+
+- adev->dm.dmcub_fw_version = le32_to_cpu(hdr->header.ucode_version);
+
+ adev->dm.dmub_srv = kzalloc(sizeof(*adev->dm.dmub_srv), GFP_KERNEL);
+ dmub_srv = adev->dm.dmub_srv;
--- /dev/null
+From 5706cb3c910cc8283f344bc37a889a8d523a2c6d Mon Sep 17 00:00:00 2001
+From: Randy Dunlap <rdunlap@infradead.org>
+Date: Thu, 29 Jul 2021 20:03:47 -0700
+Subject: drm/amdgpu: fix checking pmops when PM_SLEEP is not enabled
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Randy Dunlap <rdunlap@infradead.org>
+
+commit 5706cb3c910cc8283f344bc37a889a8d523a2c6d upstream.
+
+'pm_suspend_target_state' is only available when CONFIG_PM_SLEEP
+is set/enabled. OTOH, when both SUSPEND and HIBERNATION are not set,
+PM_SLEEP is not set, so this variable cannot be used.
+
+../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: In function ‘amdgpu_acpi_is_s0ix_active’:
+../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:1046:11: error: ‘pm_suspend_target_state’ undeclared (first use in this function); did you mean ‘__KSYM_pm_suspend_target_state’?
+ return pm_suspend_target_state == PM_SUSPEND_TO_IDLE;
+ ^~~~~~~~~~~~~~~~~~~~~~~
+ __KSYM_pm_suspend_target_state
+
+Also use shorter IS_ENABLED(CONFIG_foo) notation for checking the
+2 config symbols.
+
+Fixes: 91e273712ab8dd ("drm/amdgpu: Check pmops for desired suspend state")
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: Christian König <christian.koenig@amd.com>
+Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com>
+Cc: amd-gfx@lists.freedesktop.org
+Cc: dri-devel@lists.freedesktop.org
+Cc: linux-next@vger.kernel.org
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+@@ -904,7 +904,7 @@ void amdgpu_acpi_fini(struct amdgpu_devi
+ */
+ bool amdgpu_acpi_is_s0ix_supported(struct amdgpu_device *adev)
+ {
+-#if defined(CONFIG_AMD_PMC) || defined(CONFIG_AMD_PMC_MODULE)
++#if IS_ENABLED(CONFIG_AMD_PMC) && IS_ENABLED(CONFIG_PM_SLEEP)
+ if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) {
+ if (adev->flags & AMD_IS_APU)
+ return pm_suspend_target_state == PM_SUSPEND_TO_IDLE;
--- /dev/null
+From 75d95e2e39b27f733f21e6668af1c9893a97de5e Mon Sep 17 00:00:00 2001
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+Date: Wed, 28 Jul 2021 14:21:07 +0530
+Subject: firmware_loader: fix use-after-free in firmware_fallback_sysfs
+
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+
+commit 75d95e2e39b27f733f21e6668af1c9893a97de5e upstream.
+
+This use-after-free happens when a fw_priv object has been freed but
+hasn't been removed from the pending list (pending_fw_head). The next
+time fw_load_sysfs_fallback tries to insert into the list, it ends up
+accessing the pending_list member of the previously freed fw_priv.
+
+The root cause here is that all code paths that abort the fw load
+don't delete it from the pending list. For example:
+
+ _request_firmware()
+ -> fw_abort_batch_reqs()
+ -> fw_state_aborted()
+
+To fix this, delete the fw_priv from the list in __fw_set_state() if
+the new state is DONE or ABORTED. This way, all aborts will remove
+the fw_priv from the list. Accordingly, remove calls to list_del_init
+that were being made before calling fw_state_(aborted|done).
+
+Also, in fw_load_sysfs_fallback, don't add the fw_priv to the pending
+list if it is already aborted. Instead, just jump out and return early.
+
+Fixes: bcfbd3523f3c ("firmware: fix a double abort case with fw_load_sysfs_fallback")
+Cc: stable <stable@vger.kernel.org>
+Reported-by: syzbot+de271708674e2093097b@syzkaller.appspotmail.com
+Tested-by: syzbot+de271708674e2093097b@syzkaller.appspotmail.com
+Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
+Link: https://lore.kernel.org/r/20210728085107.4141-3-mail@anirudhrb.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/firmware_loader/fallback.c | 12 ++++++++----
+ drivers/base/firmware_loader/firmware.h | 10 +++++++++-
+ drivers/base/firmware_loader/main.c | 2 ++
+ 3 files changed, 19 insertions(+), 5 deletions(-)
+
+--- a/drivers/base/firmware_loader/fallback.c
++++ b/drivers/base/firmware_loader/fallback.c
+@@ -89,12 +89,11 @@ static void __fw_load_abort(struct fw_pr
+ {
+ /*
+ * There is a small window in which user can write to 'loading'
+- * between loading done and disappearance of 'loading'
++ * between loading done/aborted and disappearance of 'loading'
+ */
+- if (fw_sysfs_done(fw_priv))
++ if (fw_state_is_aborted(fw_priv) || fw_sysfs_done(fw_priv))
+ return;
+
+- list_del_init(&fw_priv->pending_list);
+ fw_state_aborted(fw_priv);
+ }
+
+@@ -280,7 +279,6 @@ static ssize_t firmware_loading_store(st
+ * Same logic as fw_load_abort, only the DONE bit
+ * is ignored and we set ABORT only on failure.
+ */
+- list_del_init(&fw_priv->pending_list);
+ if (rc) {
+ fw_state_aborted(fw_priv);
+ written = rc;
+@@ -513,6 +511,11 @@ static int fw_load_sysfs_fallback(struct
+ }
+
+ mutex_lock(&fw_lock);
++ if (fw_state_is_aborted(fw_priv)) {
++ mutex_unlock(&fw_lock);
++ retval = -EINTR;
++ goto out;
++ }
+ list_add(&fw_priv->pending_list, &pending_fw_head);
+ mutex_unlock(&fw_lock);
+
+@@ -538,6 +541,7 @@ static int fw_load_sysfs_fallback(struct
+ } else if (fw_priv->is_paged_buf && !fw_priv->data)
+ retval = -ENOMEM;
+
++out:
+ device_del(f_dev);
+ err_put_dev:
+ put_device(f_dev);
+--- a/drivers/base/firmware_loader/firmware.h
++++ b/drivers/base/firmware_loader/firmware.h
+@@ -117,8 +117,16 @@ static inline void __fw_state_set(struct
+
+ WRITE_ONCE(fw_st->status, status);
+
+- if (status == FW_STATUS_DONE || status == FW_STATUS_ABORTED)
++ if (status == FW_STATUS_DONE || status == FW_STATUS_ABORTED) {
++#ifdef CONFIG_FW_LOADER_USER_HELPER
++ /*
++ * Doing this here ensures that the fw_priv is deleted from
++ * the pending list in all abort/done paths.
++ */
++ list_del_init(&fw_priv->pending_list);
++#endif
+ complete_all(&fw_st->completion);
++ }
+ }
+
+ static inline void fw_state_aborted(struct fw_priv *fw_priv)
+--- a/drivers/base/firmware_loader/main.c
++++ b/drivers/base/firmware_loader/main.c
+@@ -783,8 +783,10 @@ static void fw_abort_batch_reqs(struct f
+ return;
+
+ fw_priv = fw->priv;
++ mutex_lock(&fw_lock);
+ if (!fw_state_is_aborted(fw_priv))
+ fw_state_aborted(fw_priv);
++ mutex_unlock(&fw_lock);
+ }
+
+ /* called from request_firmware() and request_firmware_work_func() */
--- /dev/null
+From 0d6434e10b5377a006f6dd995c8fc5e2d82acddc Mon Sep 17 00:00:00 2001
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+Date: Wed, 28 Jul 2021 14:21:06 +0530
+Subject: firmware_loader: use -ETIMEDOUT instead of -EAGAIN in fw_load_sysfs_fallback
+
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+
+commit 0d6434e10b5377a006f6dd995c8fc5e2d82acddc upstream.
+
+The only motivation for using -EAGAIN in commit 0542ad88fbdd81bb
+("firmware loader: Fix _request_firmware_load() return val for fw load
+abort") was to distinguish the error from -ENOMEM, and so there is no
+real reason in keeping it. -EAGAIN is typically used to tell the
+userspace to try something again and in this case re-using the sysfs
+loading interface cannot be retried when a timeout happens, so the
+return value is also bogus.
+
+-ETIMEDOUT is received when the wait times out and returning that
+is much more telling of what the reason for the failure was. So, just
+propagate that instead of returning -EAGAIN.
+
+Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
+Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210728085107.4141-2-mail@anirudhrb.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/firmware_loader/fallback.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/base/firmware_loader/fallback.c
++++ b/drivers/base/firmware_loader/fallback.c
+@@ -535,8 +535,6 @@ static int fw_load_sysfs_fallback(struct
+ if (fw_state_is_aborted(fw_priv)) {
+ if (retval == -ERESTARTSYS)
+ retval = -EINTR;
+- else
+- retval = -EAGAIN;
+ } else if (fw_priv->is_paged_buf && !fw_priv->data)
+ retval = -ENOMEM;
+
bluetooth-defer-cleanup-of-resources-in-hci_unregist.patch
io-wq-fix-no-lock-protection-of-acct-nr_worker.patch
io-wq-fix-lack-of-acct-nr_workers-acct-max_workers-j.patch
+usb-usbtmc-fix-rcu-stall-warning.patch
+usb-serial-option-add-telit-fd980-composition-0x1056.patch
+usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch
+usb-serial-ftdi_sio-add-device-id-for-auto-m3-op-com-v2.patch
+usb-serial-pl2303-fix-hx-type-detection.patch
+usb-serial-pl2303-fix-gt-type-detection.patch
+firmware_loader-use-etimedout-instead-of-eagain-in-fw_load_sysfs_fallback.patch
+firmware_loader-fix-use-after-free-in-firmware_fallback_sysfs.patch
+drm-amdgpu-fix-checking-pmops-when-pm_sleep-is-not-enabled.patch
+drm-amdgpu-display-fix-dmub-firmware-version-info.patch
--- /dev/null
+From 3c18e9baee0ef97510dcda78c82285f52626764b Mon Sep 17 00:00:00 2001
+From: Willy Tarreau <w@1wt.eu>
+Date: Sat, 24 Jul 2021 17:27:39 +0200
+Subject: USB: serial: ch341: fix character loss at high transfer rates
+
+From: Willy Tarreau <w@1wt.eu>
+
+commit 3c18e9baee0ef97510dcda78c82285f52626764b upstream.
+
+The chip supports high transfer rates, but with the small default buffers
+(64 bytes read), some entire blocks are regularly lost. This typically
+happens at 1.5 Mbps (which is the default speed on Rockchip devices) when
+used as a console to access U-Boot where the output of the "help" command
+misses many lines and where "printenv" mangles the environment.
+
+The FTDI driver doesn't suffer at all from this. One difference is that
+it uses 512 bytes rx buffers and 256 bytes tx buffers. Adopting these
+values completely resolved the issue, even the output of "dmesg" is
+reliable. I preferred to leave the Tx value unchanged as it is not
+involved in this issue, while a change could increase the risk of
+triggering the same issue with other devices having too small buffers.
+
+I verified that it backports well (and works) at least to 5.4. It's of
+low importance enough to be dropped where it doesn't trivially apply
+anymore.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Willy Tarreau <w@1wt.eu>
+Link: https://lore.kernel.org/r/20210724152739.18726-1-w@1wt.eu
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/ch341.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/serial/ch341.c
++++ b/drivers/usb/serial/ch341.c
+@@ -851,6 +851,7 @@ static struct usb_serial_driver ch341_de
+ .owner = THIS_MODULE,
+ .name = "ch341-uart",
+ },
++ .bulk_in_size = 512,
+ .id_table = id_table,
+ .num_ports = 1,
+ .open = ch341_open,
--- /dev/null
+From 8da0e55c7988ef9f08a708c38e5c75ecd8862cf8 Mon Sep 17 00:00:00 2001
+From: David Bauer <mail@david-bauer.net>
+Date: Thu, 5 Aug 2021 01:25:22 +0200
+Subject: USB: serial: ftdi_sio: add device ID for Auto-M3 OP-COM v2
+
+From: David Bauer <mail@david-bauer.net>
+
+commit 8da0e55c7988ef9f08a708c38e5c75ecd8862cf8 upstream.
+
+The Auto-M3 OP-COM v2 is a OBD diagnostic device using a FTD232 for the
+USB connection.
+
+Signed-off-by: David Bauer <mail@david-bauer.net>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/ftdi_sio.c | 1 +
+ drivers/usb/serial/ftdi_sio_ids.h | 3 +++
+ 2 files changed, 4 insertions(+)
+
+--- a/drivers/usb/serial/ftdi_sio.c
++++ b/drivers/usb/serial/ftdi_sio.c
+@@ -219,6 +219,7 @@ static const struct usb_device_id id_tab
+ { USB_DEVICE(FTDI_VID, FTDI_MTXORB_6_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_R2000KU_TRUE_RNG) },
+ { USB_DEVICE(FTDI_VID, FTDI_VARDAAN_PID) },
++ { USB_DEVICE(FTDI_VID, FTDI_AUTO_M3_OP_COM_V2_PID) },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0100_PID) },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0101_PID) },
+ { USB_DEVICE(MTXORB_VID, MTXORB_FTDI_RANGE_0102_PID) },
+--- a/drivers/usb/serial/ftdi_sio_ids.h
++++ b/drivers/usb/serial/ftdi_sio_ids.h
+@@ -159,6 +159,9 @@
+ /* Vardaan Enterprises Serial Interface VEUSB422R3 */
+ #define FTDI_VARDAAN_PID 0xF070
+
++/* Auto-M3 Ltd. - OP-COM USB V2 - OBD interface Adapter */
++#define FTDI_AUTO_M3_OP_COM_V2_PID 0x4f50
++
+ /*
+ * Xsens Technologies BV products (http://www.xsens.com).
+ */
--- /dev/null
+From 5648c073c33d33a0a19d0cb1194a4eb88efe2b71 Mon Sep 17 00:00:00 2001
+From: Daniele Palmas <dnlplm@gmail.com>
+Date: Tue, 3 Aug 2021 21:47:11 +0200
+Subject: USB: serial: option: add Telit FD980 composition 0x1056
+
+From: Daniele Palmas <dnlplm@gmail.com>
+
+commit 5648c073c33d33a0a19d0cb1194a4eb88efe2b71 upstream.
+
+Add the following Telit FD980 composition 0x1056:
+
+Cfg #1: mass storage
+Cfg #2: rndis, tty, adb, tty, tty, tty, tty
+
+Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
+Link: https://lore.kernel.org/r/20210803194711.3036-1-dnlplm@gmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/option.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/usb/serial/option.c
++++ b/drivers/usb/serial/option.c
+@@ -1203,6 +1203,8 @@ static const struct usb_device_id option
+ .driver_info = NCTRL(2) | RSVD(3) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1055, 0xff), /* Telit FN980 (PCIe) */
+ .driver_info = NCTRL(0) | RSVD(1) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1056, 0xff), /* Telit FD980 */
++ .driver_info = NCTRL(2) | RSVD(3) },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910),
+ .driver_info = NCTRL(0) | RSVD(1) | RSVD(3) },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM),
--- /dev/null
+From 3212a99349cee5fb611d3ffcf0e65bc3cd6dcf2f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Wed, 4 Aug 2021 11:31:00 +0200
+Subject: USB: serial: pl2303: fix GT type detection
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 3212a99349cee5fb611d3ffcf0e65bc3cd6dcf2f upstream.
+
+At least some PL2303GT have a bcdDevice of 0x305 instead of 0x100 as the
+datasheet claims. Add it to the list of known release numbers for the
+HXN (G) type.
+
+Fixes: 894758d0571d ("USB: serial: pl2303: tighten type HXN (G) detection")
+Reported-by: Vasily Khoruzhick <anarsoul@gmail.com>
+Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
+Cc: stable@vger.kernel.org # 5.13
+Link: https://lore.kernel.org/r/20210804093100.24811-1-johan@kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/pl2303.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/serial/pl2303.c
++++ b/drivers/usb/serial/pl2303.c
+@@ -432,6 +432,7 @@ static int pl2303_detect_type(struct usb
+ case 0x200:
+ switch (bcdDevice) {
+ case 0x100:
++ case 0x305:
+ /*
+ * Assume it's an HXN-type if the device doesn't
+ * support the old read request value.
--- /dev/null
+From 1e9faef4d26de33bd6b5018695996e7394119e5b Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 30 Jul 2021 14:21:56 +0200
+Subject: USB: serial: pl2303: fix HX type detection
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 1e9faef4d26de33bd6b5018695996e7394119e5b upstream.
+
+The device release number for HX-type devices is configurable in
+EEPROM/OTPROM and cannot be used reliably for type detection.
+
+Assume all (non-H) devices with bcdUSB 1.1 and unknown bcdDevice to be
+of HX type while adding a bcdDevice check for HXD and TB (1.1 and 2.0,
+respectively).
+
+Reported-by: Chris <chris@cyber-anlage.de>
+Fixes: 8a7bf7510d1f ("USB: serial: pl2303: amend and tighten type detection")
+Cc: stable@vger.kernel.org # 5.13
+Link: https://lore.kernel.org/r/20210730122156.718-1-johan@kernel.org
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/pl2303.c | 41 +++++++++++++++++++++++++----------------
+ 1 file changed, 25 insertions(+), 16 deletions(-)
+
+--- a/drivers/usb/serial/pl2303.c
++++ b/drivers/usb/serial/pl2303.c
+@@ -418,24 +418,33 @@ static int pl2303_detect_type(struct usb
+ bcdDevice = le16_to_cpu(desc->bcdDevice);
+ bcdUSB = le16_to_cpu(desc->bcdUSB);
+
+- switch (bcdDevice) {
+- case 0x100:
+- /*
+- * Assume it's an HXN-type if the device doesn't support the old read
+- * request value.
+- */
+- if (bcdUSB == 0x200 && !pl2303_supports_hx_status(serial))
+- return TYPE_HXN;
++ switch (bcdUSB) {
++ case 0x110:
++ switch (bcdDevice) {
++ case 0x300:
++ return TYPE_HX;
++ case 0x400:
++ return TYPE_HXD;
++ default:
++ return TYPE_HX;
++ }
+ break;
+- case 0x300:
+- if (bcdUSB == 0x200)
++ case 0x200:
++ switch (bcdDevice) {
++ case 0x100:
++ /*
++ * Assume it's an HXN-type if the device doesn't
++ * support the old read request value.
++ */
++ if (!pl2303_supports_hx_status(serial))
++ return TYPE_HXN;
++ break;
++ case 0x300:
+ return TYPE_TA;
+-
+- return TYPE_HX;
+- case 0x400:
+- return TYPE_HXD;
+- case 0x500:
+- return TYPE_TB;
++ case 0x500:
++ return TYPE_TB;
++ }
++ break;
+ }
+
+ dev_err(&serial->interface->dev,
--- /dev/null
+From 30fad76ce4e98263edfa8f885c81d5426c1bf169 Mon Sep 17 00:00:00 2001
+From: "Qiang.zhang" <qiang.zhang@windriver.com>
+Date: Fri, 23 Jul 2021 08:43:34 +0800
+Subject: USB: usbtmc: Fix RCU stall warning
+
+From: Qiang.zhang <qiang.zhang@windriver.com>
+
+commit 30fad76ce4e98263edfa8f885c81d5426c1bf169 upstream.
+
+rcu: INFO: rcu_preempt self-detected stall on CPU
+rcu: 1-...!: (2 ticks this GP) idle=d92/1/0x4000000000000000
+ softirq=25390/25392 fqs=3
+ (t=12164 jiffies g=31645 q=43226)
+rcu: rcu_preempt kthread starved for 12162 jiffies! g31645 f0x0
+ RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
+rcu: Unless rcu_preempt kthread gets sufficient CPU time,
+ OOM is now expected behavior.
+rcu: RCU grace-period kthread stack dump:
+task:rcu_preempt state:R running task
+...........
+usbtmc 3-1:0.0: unknown status received: -71
+usbtmc 3-1:0.0: unknown status received: -71
+usbtmc 3-1:0.0: unknown status received: -71
+usbtmc 3-1:0.0: unknown status received: -71
+usbtmc 3-1:0.0: unknown status received: -71
+usbtmc 3-1:0.0: unknown status received: -71
+usbtmc 3-1:0.0: unknown status received: -71
+usbtmc 3-1:0.0: unknown status received: -71
+usbtmc 3-1:0.0: usb_submit_urb failed: -19
+
+The function usbtmc_interrupt() resubmits urbs when the error status
+of an urb is -EPROTO. In systems using the dummy_hcd usb controller
+this can result in endless interrupt loops when the usbtmc device is
+disconnected from the host system.
+
+Since host controller drivers already try to recover from transmission
+errors, there is no need to resubmit the urb or try other solutions
+to repair the error situation.
+
+In case of errors the INT pipe just stops to wait for further packets.
+
+Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation")
+Cc: stable@vger.kernel.org
+Reported-by: syzbot+e2eae5639e7203360018@syzkaller.appspotmail.com
+Signed-off-by: Qiang.zhang <qiang.zhang@windriver.com>
+Acked-by: Guido Kiener <guido.kiener@rohde-schwarz.com>
+Link: https://lore.kernel.org/r/20210723004334.458930-1-qiang.zhang@windriver.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/class/usbtmc.c | 9 +--------
+ 1 file changed, 1 insertion(+), 8 deletions(-)
+
+--- a/drivers/usb/class/usbtmc.c
++++ b/drivers/usb/class/usbtmc.c
+@@ -2324,17 +2324,10 @@ static void usbtmc_interrupt(struct urb
+ dev_err(dev, "overflow with length %d, actual length is %d\n",
+ data->iin_wMaxPacketSize, urb->actual_length);
+ fallthrough;
+- case -ECONNRESET:
+- case -ENOENT:
+- case -ESHUTDOWN:
+- case -EILSEQ:
+- case -ETIME:
+- case -EPIPE:
++ default:
+ /* urb terminated, clean up */
+ dev_dbg(dev, "urb terminated, status: %d\n", status);
+ return;
+- default:
+- dev_err(dev, "unknown status received: %d\n", status);
+ }
+ exit:
+ rv = usb_submit_urb(urb, GFP_ATOMIC);
projects / thirdparty / kernel / stable-queue.git / commitdiff
