From: Greg Kroah-Hartman Date: Mon, 9 Aug 2021 08:41:08 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v4.4.280~64 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2219a4545e068cb7f39d59ddcfd3aecc417c3dcf;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: 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-usbtmc-fix-rcu-stall-warning.patch --- diff --git a/queue-4.14/series b/queue-4.14/series index 4c9f06ace1a..0ba9218affb 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -12,3 +12,7 @@ net-pegasus-fix-uninit-value-in-get_interrupt_interv.patch net-fec-fix-use-after-free-in-fec_drv_remove.patch net-vxge-fix-use-after-free-in-vxge_device_unregiste.patch bluetooth-defer-cleanup-of-resources-in-hci_unregist.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 diff --git a/queue-4.14/usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch b/queue-4.14/usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch new file mode 100644 index 00000000000..a6384ffbe74 --- /dev/null +++ b/queue-4.14/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 +@@ -628,6 +628,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-4.14/usb-serial-ftdi_sio-add-device-id-for-auto-m3-op-com-v2.patch b/queue-4.14/usb-serial-ftdi_sio-add-device-id-for-auto-m3-op-com-v2.patch new file mode 100644 index 00000000000..330d4937eea --- /dev/null +++ b/queue-4.14/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 +@@ -214,6 +214,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-4.14/usb-serial-option-add-telit-fd980-composition-0x1056.patch b/queue-4.14/usb-serial-option-add-telit-fd980-composition-0x1056.patch new file mode 100644 index 00000000000..bb591cd4dd1 --- /dev/null +++ b/queue-4.14/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 +@@ -1206,6 +1206,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-4.14/usb-usbtmc-fix-rcu-stall-warning.patch b/queue-4.14/usb-usbtmc-fix-rcu-stall-warning.patch new file mode 100644 index 00000000000..f58744bf426 --- /dev/null +++ b/queue-4.14/usb-usbtmc-fix-rcu-stall-warning.patch @@ -0,0 +1,72 @@ +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 | 8 +------- + 1 file changed, 1 insertion(+), 7 deletions(-) + +--- a/drivers/usb/class/usbtmc.c ++++ b/drivers/usb/class/usbtmc.c +@@ -1343,16 +1343,10 @@ static void usbtmc_interrupt(struct urb + case -EOVERFLOW: + dev_err(dev, "overflow with length %d, actual length is %d\n", + data->iin_wMaxPacketSize, urb->actual_length); +- case -ECONNRESET: +- case -ENOENT: +- case -ESHUTDOWN: +- case -EILSEQ: +- case -ETIME: ++ 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);