From: Greg Kroah-Hartman Date: Tue, 6 Sep 2022 11:03:11 +0000 (+0200) Subject: 5.19-stable patches X-Git-Tag: v5.10.142~30 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a5324eba43a2d0012ac5ea0b6541cfff3c6b558b;p=thirdparty%2Fkernel%2Fstable-queue.git 5.19-stable patches added patches: media-mceusb-use-new-usb_control_msg_-routines.patch xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch --- diff --git a/queue-5.19/media-mceusb-use-new-usb_control_msg_-routines.patch b/queue-5.19/media-mceusb-use-new-usb_control_msg_-routines.patch new file mode 100644 index 00000000000..e14a52b41c3 --- /dev/null +++ b/queue-5.19/media-mceusb-use-new-usb_control_msg_-routines.patch @@ -0,0 +1,135 @@ +From 608e58a0f4617977178131f5f68a3fce1d3f5316 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Fri, 26 Aug 2022 15:31:40 -0400 +Subject: media: mceusb: Use new usb_control_msg_*() routines + +From: Alan Stern + +commit 608e58a0f4617977178131f5f68a3fce1d3f5316 upstream. + +Automatic kernel fuzzing led to a WARN about invalid pipe direction in +the mceusb driver: + +------------[ cut here ]------------ +usb 6-1: BOGUS control dir, pipe 80000380 doesn't match bRequestType 40 +WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410 +usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 +Modules linked in: +CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS +1.13.0-1ubuntu1.1 04/01/2014 +Workqueue: usb_hub_wq hub_event +RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 +Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8 +44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b +e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41 +RSP: 0018:ffffc900032becf0 EFLAGS: 00010282 +RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000 +RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90 +RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000 +R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000 +R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500 +FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0 +Call Trace: + +usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 +usb_internal_control_msg drivers/usb/core/message.c:102 [inline] +usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 +mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline] +mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807 + +The reason for the warning is clear enough; the driver sends an +unusual read request on endpoint 0 but does not set the USB_DIR_IN bit +in the bRequestType field. + +More importantly, the whole situation can be avoided and the driver +simplified by converting it over to the relatively new +usb_control_msg_recv() and usb_control_msg_send() routines. That's +what this fix does. + +Link: https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA@mail.gmail.com/ +Cc: Mauro Carvalho Chehab +Cc: stable@vger.kernel.org +Reported-and-tested-by: Rondreis +Signed-off-by: Alan Stern +Link: https://lore.kernel.org/r/YwkfnBFCSEVC6XZu@rowland.harvard.edu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/rc/mceusb.c | 35 ++++++++++++++--------------------- + 1 file changed, 14 insertions(+), 21 deletions(-) + +diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c +index 0834d5f866fd..39d2b03e2631 100644 +--- a/drivers/media/rc/mceusb.c ++++ b/drivers/media/rc/mceusb.c +@@ -1416,42 +1416,37 @@ static void mceusb_gen1_init(struct mceusb_dev *ir) + { + int ret; + struct device *dev = ir->dev; +- char *data; +- +- data = kzalloc(USB_CTRL_MSG_SZ, GFP_KERNEL); +- if (!data) { +- dev_err(dev, "%s: memory allocation failed!", __func__); +- return; +- } ++ char data[USB_CTRL_MSG_SZ]; + + /* + * This is a strange one. Windows issues a set address to the device + * on the receive control pipe and expect a certain value pair back + */ +- ret = usb_control_msg(ir->usbdev, usb_rcvctrlpipe(ir->usbdev, 0), +- USB_REQ_SET_ADDRESS, USB_TYPE_VENDOR, 0, 0, +- data, USB_CTRL_MSG_SZ, 3000); ++ ret = usb_control_msg_recv(ir->usbdev, 0, USB_REQ_SET_ADDRESS, ++ USB_DIR_IN | USB_TYPE_VENDOR, ++ 0, 0, data, USB_CTRL_MSG_SZ, 3000, ++ GFP_KERNEL); + dev_dbg(dev, "set address - ret = %d", ret); + dev_dbg(dev, "set address - data[0] = %d, data[1] = %d", + data[0], data[1]); + + /* set feature: bit rate 38400 bps */ +- ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0), +- USB_REQ_SET_FEATURE, USB_TYPE_VENDOR, +- 0xc04e, 0x0000, NULL, 0, 3000); ++ ret = usb_control_msg_send(ir->usbdev, 0, ++ USB_REQ_SET_FEATURE, USB_TYPE_VENDOR, ++ 0xc04e, 0x0000, NULL, 0, 3000, GFP_KERNEL); + + dev_dbg(dev, "set feature - ret = %d", ret); + + /* bRequest 4: set char length to 8 bits */ +- ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0), +- 4, USB_TYPE_VENDOR, +- 0x0808, 0x0000, NULL, 0, 3000); ++ ret = usb_control_msg_send(ir->usbdev, 0, ++ 4, USB_TYPE_VENDOR, ++ 0x0808, 0x0000, NULL, 0, 3000, GFP_KERNEL); + dev_dbg(dev, "set char length - retB = %d", ret); + + /* bRequest 2: set handshaking to use DTR/DSR */ +- ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0), +- 2, USB_TYPE_VENDOR, +- 0x0000, 0x0100, NULL, 0, 3000); ++ ret = usb_control_msg_send(ir->usbdev, 0, ++ 2, USB_TYPE_VENDOR, ++ 0x0000, 0x0100, NULL, 0, 3000, GFP_KERNEL); + dev_dbg(dev, "set handshake - retC = %d", ret); + + /* device resume */ +@@ -1459,8 +1454,6 @@ static void mceusb_gen1_init(struct mceusb_dev *ir) + + /* get hw/sw revision? */ + mce_command_out(ir, GET_REVISION, sizeof(GET_REVISION)); +- +- kfree(data); + } + + static void mceusb_gen2_init(struct mceusb_dev *ir) +-- +2.37.3 + diff --git a/queue-5.19/series b/queue-5.19/series index 8b7a36e68ee..78abf7bf891 100644 --- a/queue-5.19/series +++ b/queue-5.19/series @@ -105,3 +105,5 @@ xen-blkfront-cache-feature_persistent-value-before-advertisement.patch thunderbolt-use-the-actual-buffer-in-tb_async_error.patch thunderbolt-check-router-generation-before-connecting-xhci.patch usb-dwc3-pci-add-support-for-intel-raptor-lake.patch +media-mceusb-use-new-usb_control_msg_-routines.patch +xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch diff --git a/queue-5.19/xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch b/queue-5.19/xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch new file mode 100644 index 00000000000..6315779b5eb --- /dev/null +++ b/queue-5.19/xhci-add-grace-period-after-xhc-start-to-prevent-premature-runtime-suspend.patch @@ -0,0 +1,84 @@ +From 33e321586e37b642ad10594b9ef25a613555cd08 Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Thu, 25 Aug 2022 18:08:39 +0300 +Subject: xhci: Add grace period after xHC start to prevent premature runtime suspend. + +From: Mathias Nyman + +commit 33e321586e37b642ad10594b9ef25a613555cd08 upstream. + +After xHC controller is started, either in probe or resume, it can take +a while before any of the connected usb devices are visible to the roothub +due to link training. + +It's possible xhci driver loads, sees no acivity and suspends the host +before the USB device is visible. + +In one testcase with a hotplugged xHC controller the host finally detected +the connected USB device and generated a wake 500ms after host initial +start. + +If hosts didn't suspend the device duringe training it probablty wouldn't +take up to 500ms to detect it, but looking at specs reveal USB3 link +training has a couple long timeout values, such as 120ms +RxDetectQuietTimeout, and 360ms PollingLFPSTimeout. + +So Add a 500ms grace period that keeps polling the roothub for 500ms after +start, preventing runtime suspend until USB devices are detected. + +Cc: stable@vger.kernel.org +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20220825150840.132216-3-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-hub.c | 11 +++++++++++ + drivers/usb/host/xhci.c | 4 +++- + drivers/usb/host/xhci.h | 2 +- + 3 files changed, 15 insertions(+), 2 deletions(-) + +--- a/drivers/usb/host/xhci-hub.c ++++ b/drivers/usb/host/xhci-hub.c +@@ -1648,6 +1648,17 @@ int xhci_hub_status_data(struct usb_hcd + + status = bus_state->resuming_ports; + ++ /* ++ * SS devices are only visible to roothub after link training completes. ++ * Keep polling roothubs for a grace period after xHC start ++ */ ++ if (xhci->run_graceperiod) { ++ if (time_before(jiffies, xhci->run_graceperiod)) ++ status = 1; ++ else ++ xhci->run_graceperiod = 0; ++ } ++ + mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC | PORT_CEC; + + /* For each port, did anything change? If so, set that bit in buf. */ +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -151,9 +151,11 @@ int xhci_start(struct xhci_hcd *xhci) + xhci_err(xhci, "Host took too long to start, " + "waited %u microseconds.\n", + XHCI_MAX_HALT_USEC); +- if (!ret) ++ if (!ret) { + /* clear state flags. Including dying, halted or removing */ + xhci->xhc_state = 0; ++ xhci->run_graceperiod = jiffies + msecs_to_jiffies(500); ++ } + + return ret; + } +--- a/drivers/usb/host/xhci.h ++++ b/drivers/usb/host/xhci.h +@@ -1826,7 +1826,7 @@ struct xhci_hcd { + + /* Host controller watchdog timer structures */ + unsigned int xhc_state; +- ++ unsigned long run_graceperiod; + u32 command; + struct s3_save s3; + /* Host controller is dying - not responding to commands. "I'm not dead yet!"