From e06fa6d9942b30a8ce7517bb28f3b634d67bb227 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 9 Aug 2021 10:43:02 +0200 Subject: [PATCH] 5.13-stable patches added patches: drm-amdgpu-display-fix-dmub-firmware-version-info.patch drm-amdgpu-fix-checking-pmops-when-pm_sleep-is-not-enabled.patch firmware_loader-fix-use-after-free-in-firmware_fallback_sysfs.patch firmware_loader-use-etimedout-instead-of-eagain-in-fw_load_sysfs_fallback.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-option-add-telit-fd980-composition-0x1056.patch usb-serial-pl2303-fix-gt-type-detection.patch usb-serial-pl2303-fix-hx-type-detection.patch usb-usbtmc-fix-rcu-stall-warning.patch --- ...splay-fix-dmub-firmware-version-info.patch | 39 ++++++ ...g-pmops-when-pm_sleep-is-not-enabled.patch | 51 ++++++++ ...fter-free-in-firmware_fallback_sysfs.patch | 122 ++++++++++++++++++ ...-of-eagain-in-fw_load_sysfs_fallback.patch | 43 ++++++ queue-5.13/series | 10 ++ ...haracter-loss-at-high-transfer-rates.patch | 45 +++++++ ...-add-device-id-for-auto-m3-op-com-v2.patch | 43 ++++++ ...n-add-telit-fd980-composition-0x1056.patch | 34 +++++ ...-serial-pl2303-fix-gt-type-detection.patch | 34 +++++ ...-serial-pl2303-fix-hx-type-detection.patch | 79 ++++++++++++ .../usb-usbtmc-fix-rcu-stall-warning.patch | 73 +++++++++++ 11 files changed, 573 insertions(+) create mode 100644 queue-5.13/drm-amdgpu-display-fix-dmub-firmware-version-info.patch create mode 100644 queue-5.13/drm-amdgpu-fix-checking-pmops-when-pm_sleep-is-not-enabled.patch create mode 100644 queue-5.13/firmware_loader-fix-use-after-free-in-firmware_fallback_sysfs.patch create mode 100644 queue-5.13/firmware_loader-use-etimedout-instead-of-eagain-in-fw_load_sysfs_fallback.patch create mode 100644 queue-5.13/usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch create mode 100644 queue-5.13/usb-serial-ftdi_sio-add-device-id-for-auto-m3-op-com-v2.patch create mode 100644 queue-5.13/usb-serial-option-add-telit-fd980-composition-0x1056.patch create mode 100644 queue-5.13/usb-serial-pl2303-fix-gt-type-detection.patch create mode 100644 queue-5.13/usb-serial-pl2303-fix-hx-type-detection.patch create mode 100644 queue-5.13/usb-usbtmc-fix-rcu-stall-warning.patch diff --git a/queue-5.13/drm-amdgpu-display-fix-dmub-firmware-version-info.patch b/queue-5.13/drm-amdgpu-display-fix-dmub-firmware-version-info.patch new file mode 100644 index 00000000000..8e9d27c17dc --- /dev/null +++ b/queue-5.13/drm-amdgpu-display-fix-dmub-firmware-version-info.patch @@ -0,0 +1,39 @@ +From 0e99e960ce6d5ff586fc0733bc393c087f52c27b Mon Sep 17 00:00:00 2001 +From: Shirish S +Date: Tue, 3 Aug 2021 14:03:44 +0530 +Subject: drm/amdgpu/display: fix DMUB firmware version info + +From: Shirish S + +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 +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.13/drm-amdgpu-fix-checking-pmops-when-pm_sleep-is-not-enabled.patch b/queue-5.13/drm-amdgpu-fix-checking-pmops-when-pm_sleep-is-not-enabled.patch new file mode 100644 index 00000000000..03f68217388 --- /dev/null +++ b/queue-5.13/drm-amdgpu-fix-checking-pmops-when-pm_sleep-is-not-enabled.patch @@ -0,0 +1,51 @@ +From 5706cb3c910cc8283f344bc37a889a8d523a2c6d Mon Sep 17 00:00:00 2001 +From: Randy Dunlap +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 + +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 +Cc: Alex Deucher +Cc: Christian König +Cc: "Pan, Xinhui" +Cc: amd-gfx@lists.freedesktop.org +Cc: dri-devel@lists.freedesktop.org +Cc: linux-next@vger.kernel.org +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.13/firmware_loader-fix-use-after-free-in-firmware_fallback_sysfs.patch b/queue-5.13/firmware_loader-fix-use-after-free-in-firmware_fallback_sysfs.patch new file mode 100644 index 00000000000..f8d8d3a2a68 --- /dev/null +++ b/queue-5.13/firmware_loader-fix-use-after-free-in-firmware_fallback_sysfs.patch @@ -0,0 +1,122 @@ +From 75d95e2e39b27f733f21e6668af1c9893a97de5e Mon Sep 17 00:00:00 2001 +From: Anirudh Rayabharam +Date: Wed, 28 Jul 2021 14:21:07 +0530 +Subject: firmware_loader: fix use-after-free in firmware_fallback_sysfs + +From: Anirudh Rayabharam + +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 +Reported-by: syzbot+de271708674e2093097b@syzkaller.appspotmail.com +Tested-by: syzbot+de271708674e2093097b@syzkaller.appspotmail.com +Reviewed-by: Shuah Khan +Acked-by: Luis Chamberlain +Signed-off-by: Anirudh Rayabharam +Link: https://lore.kernel.org/r/20210728085107.4141-3-mail@anirudhrb.com +Signed-off-by: Greg Kroah-Hartman +--- + 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() */ diff --git a/queue-5.13/firmware_loader-use-etimedout-instead-of-eagain-in-fw_load_sysfs_fallback.patch b/queue-5.13/firmware_loader-use-etimedout-instead-of-eagain-in-fw_load_sysfs_fallback.patch new file mode 100644 index 00000000000..6419e7aca6f --- /dev/null +++ b/queue-5.13/firmware_loader-use-etimedout-instead-of-eagain-in-fw_load_sysfs_fallback.patch @@ -0,0 +1,43 @@ +From 0d6434e10b5377a006f6dd995c8fc5e2d82acddc Mon Sep 17 00:00:00 2001 +From: Anirudh Rayabharam +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 + +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 +Reviewed-by: Shuah Khan +Acked-by: Luis Chamberlain +Signed-off-by: Anirudh Rayabharam +Cc: stable +Link: https://lore.kernel.org/r/20210728085107.4141-2-mail@anirudhrb.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-5.13/series b/queue-5.13/series index 5a3acdaa07f..9e0b8fba4ed 100644 --- a/queue-5.13/series +++ b/queue-5.13/series @@ -70,3 +70,13 @@ blk-iolatency-error-out-if-blk_get_queue-failed-in-i.patch 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 diff --git a/queue-5.13/usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch b/queue-5.13/usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch new file mode 100644 index 00000000000..916a30d4f89 --- /dev/null +++ b/queue-5.13/usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch @@ -0,0 +1,45 @@ +From 3c18e9baee0ef97510dcda78c82285f52626764b Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +Date: Sat, 24 Jul 2021 17:27:39 +0200 +Subject: USB: serial: ch341: fix character loss at high transfer rates + +From: Willy Tarreau + +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 +Link: https://lore.kernel.org/r/20210724152739.18726-1-w@1wt.eu +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.13/usb-serial-ftdi_sio-add-device-id-for-auto-m3-op-com-v2.patch b/queue-5.13/usb-serial-ftdi_sio-add-device-id-for-auto-m3-op-com-v2.patch new file mode 100644 index 00000000000..8828e9ecfc5 --- /dev/null +++ b/queue-5.13/usb-serial-ftdi_sio-add-device-id-for-auto-m3-op-com-v2.patch @@ -0,0 +1,43 @@ +From 8da0e55c7988ef9f08a708c38e5c75ecd8862cf8 Mon Sep 17 00:00:00 2001 +From: David Bauer +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 + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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). + */ diff --git a/queue-5.13/usb-serial-option-add-telit-fd980-composition-0x1056.patch b/queue-5.13/usb-serial-option-add-telit-fd980-composition-0x1056.patch new file mode 100644 index 00000000000..1ad7a910826 --- /dev/null +++ b/queue-5.13/usb-serial-option-add-telit-fd980-composition-0x1056.patch @@ -0,0 +1,34 @@ +From 5648c073c33d33a0a19d0cb1194a4eb88efe2b71 Mon Sep 17 00:00:00 2001 +From: Daniele Palmas +Date: Tue, 3 Aug 2021 21:47:11 +0200 +Subject: USB: serial: option: add Telit FD980 composition 0x1056 + +From: Daniele Palmas + +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 +Link: https://lore.kernel.org/r/20210803194711.3036-1-dnlplm@gmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-5.13/usb-serial-pl2303-fix-gt-type-detection.patch b/queue-5.13/usb-serial-pl2303-fix-gt-type-detection.patch new file mode 100644 index 00000000000..9ae13fb5952 --- /dev/null +++ b/queue-5.13/usb-serial-pl2303-fix-gt-type-detection.patch @@ -0,0 +1,34 @@ +From 3212a99349cee5fb611d3ffcf0e65bc3cd6dcf2f Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 4 Aug 2021 11:31:00 +0200 +Subject: USB: serial: pl2303: fix GT type detection + +From: Johan Hovold + +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 +Tested-by: Vasily Khoruzhick +Cc: stable@vger.kernel.org # 5.13 +Link: https://lore.kernel.org/r/20210804093100.24811-1-johan@kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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. diff --git a/queue-5.13/usb-serial-pl2303-fix-hx-type-detection.patch b/queue-5.13/usb-serial-pl2303-fix-hx-type-detection.patch new file mode 100644 index 00000000000..e49098280f8 --- /dev/null +++ b/queue-5.13/usb-serial-pl2303-fix-hx-type-detection.patch @@ -0,0 +1,79 @@ +From 1e9faef4d26de33bd6b5018695996e7394119e5b Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 30 Jul 2021 14:21:56 +0200 +Subject: USB: serial: pl2303: fix HX type detection + +From: Johan Hovold + +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 +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 +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.13/usb-usbtmc-fix-rcu-stall-warning.patch b/queue-5.13/usb-usbtmc-fix-rcu-stall-warning.patch new file mode 100644 index 00000000000..910223a7b39 --- /dev/null +++ b/queue-5.13/usb-usbtmc-fix-rcu-stall-warning.patch @@ -0,0 +1,73 @@ +From 30fad76ce4e98263edfa8f885c81d5426c1bf169 Mon Sep 17 00:00:00 2001 +From: "Qiang.zhang" +Date: Fri, 23 Jul 2021 08:43:34 +0800 +Subject: USB: usbtmc: Fix RCU stall warning + +From: Qiang.zhang + +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 +Acked-by: Guido Kiener +Link: https://lore.kernel.org/r/20210723004334.458930-1-qiang.zhang@windriver.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); -- 2.47.3