Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132 2022-10-26T12:09:06+00:00 2022-10-26T12:09:06+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2022-10-26T12:09:06+00:00 urn:sha1:88c8e05ed5c0f05a637e654bbe4e49a1ebe7013c This reverts commit 19905240aef0181d1e6944070eb85fce75f75bcd. It was a new feature, and it doesn't even work properly yet, so revert it from this branch as it is not needed for 6.1-final. Cc: Michael Grzeschik <m.grzeschik@pengutronix.de> Cc: stable <stable@kernel.org> Fixes: 19905240aef0 ("usb: gadget: uvc: limit isoc_sg to super speed gadgets") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-10-25T17:06:13+00:00 Michael Grzeschik m.grzeschik@pengutronix.de 2022-10-17T22:11:41+00:00 urn:sha1:19905240aef0181d1e6944070eb85fce75f75bcd The overhead of preparing sg data is high for transfers with limited payload. When transferring isoc over high-speed usb the maximum payload is rather small which is a good argument no to use sg. This patch is changing the uvc_video_encode_isoc_sg encode function only to be used for super speed gadgets. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20221017221141.3134818-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-10-22T10:30:35+00:00 Dan Vacura w36195@motorola.com 2022-10-18T21:50:39+00:00 urn:sha1:0a0a2760b04814428800d48281a447a7522470ad If there is a transmission error the buffer will be returned too early, causing a memory fault as subsequent requests for that buffer are still queued up to be sent. Refactor the error handling to wait for the final request to come in before reporting back the buffer to userspace for all transfer types (bulk/isoc/isoc_sg). This ensures userspace knows if the frame was successfully sent. Fixes: e81e7f9a0eb9 ("usb: gadget: uvc: add scatter gather support") Cc: <stable@vger.kernel.org> Signed-off-by: Dan Vacura <w36195@motorola.com> Link: https://lore.kernel.org/r/20221018215044.765044-4-w36195@motorola.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-06-10T09:50:54+00:00 Michael Grzeschik m.grzeschik@pengutronix.de 2022-05-29T22:38:46+00:00 urn:sha1:87d76b5f1d8eeb49efa16e2018e188864cbb9401 The current limitation of possible number of requests being handled is dependent on the gadget speed. It makes more sense to depend on the typical frame size when calculating the number of requests. This patch is changing this and is using the previous limits as boundaries for reasonable minimum and maximum number of requests. For a 1080p jpeg encoded video stream with a maximum imagesize of e.g. 800kB with a maxburst of 8 and an multiplier of 1 the resulting number of requests is calculated to 49. 800768 1 nreqs = ------ * -------------- ~= 49 2 (1024 * 8 * 1) Tested-by: Dan Vacura <w36195@motorola.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220529223848.105914-2-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-06-10T09:20:30+00:00 Laurent Pinchart laurent.pinchart@ideasonboard.com 2022-06-08T17:49:18+00:00 urn:sha1:c5d337a358b3e41bb4f7abd99a79b68a28eafaa2 The UVC gadget driver historically uses the /* Comment * style */ for multi-line block comments, which is frowned upon. Patches for the driver are required to use the more standard /* * Comment * style */ style. This result in inconsistencies. Fix it by converting all remaining instances of the old style. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20220608174918.14656-1-laurent.pinchart@ideasonboard.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-05-03T14:35:26+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2022-05-03T14:35:26+00:00 urn:sha1:b9c92fb4aabb8d93b657d028f7c530d6c42cb630 We need the USB fixes in here, and this resolves a merge issue in drivers/usb/dwc3/drd.c Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-04-21T16:15:33+00:00 Michael Grzeschik m.grzeschik@pengutronix.de 2022-04-02T23:27:43+00:00 urn:sha1:9b969f93bcef9b3d9e92f1810e22bbd6c344a0e5 On uvc_video_encode_isoc_sg the mapped vb2 buffer is returned to early. Only after the last usb_request worked with the buffer it is allowed to give it back to vb2. This patch fixes that. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220402232744.3622565-3-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-04-21T16:15:33+00:00 Michael Grzeschik m.grzeschik@pengutronix.de 2022-04-02T23:27:42+00:00 urn:sha1:61aa709ca58a0dbeeb817bfa9230c1a92979f2c6 The function uvcg_queue_next_buffer is used different than its name suggests. The return value nextbuf is never used by any caller. This patch reworks the function to its actual purpose, by removing the unused code and renaming it. The function name uvcg_complete_buffer makes it more clear that it is actually marking the current video buffer as complete. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220402232744.3622565-2-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-04-21T16:15:07+00:00 Dan Vacura w36195@motorola.com 2022-04-13T19:24:02+00:00 urn:sha1:be30e3502771ac0b5080ec61223d915354cde1cc The pause flag doesn't appear to serve a purpose as it is possible for the pump worker thread to not be running when new buffers are queued. Before the following change was introduced: "43cd0023872e usb: gadget: uvc_video: add worker to handle the frame pumping", the pause flag status was discarded and never returned. This masked a current issues of the userspace receiving non-zero values (considered unsuccessful) and prevents trace_v4l2_qbuf() from being called. Signed-off-by: Dan Vacura <w36195@motorola.com> Link: https://lore.kernel.org/r/20220413192402.26063-1-w36195@motorola.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2022-04-19T14:22:20+00:00 Dan Vacura w36195@motorola.com 2022-03-31T18:40:23+00:00 urn:sha1:71d471e3faf90c9674cadc7605ac719e82cb7fac During the uvcg_video_pump() process, if an error occurs and uvcg_queue_cancel() is called, the buffer queue will be cleared out, but the current marker (queue->buf_used) of the active buffer (no longer active) is not reset. On the next iteration of uvcg_video_pump() the stale buf_used count will be used and the logic of min((unsigned int)len, buf->bytesused - queue->buf_used) may incorrectly calculate a nbytes size, causing an invalid memory access. [80802.185460][ T315] configfs-gadget gadget: uvc: VS request completed with status -18. [80802.185519][ T315] configfs-gadget gadget: uvc: VS request completed with status -18. ... uvcg_queue_cancel() is called and the queue is cleared out, but the marker queue->buf_used is not reset. ... [80802.262328][ T8682] Unable to handle kernel paging request at virtual address ffffffc03af9f000 ... ... [80802.263138][ T8682] Call trace: [80802.263146][ T8682] __memcpy+0x12c/0x180 [80802.263155][ T8682] uvcg_video_pump+0xcc/0x1e0 [80802.263165][ T8682] process_one_work+0x2cc/0x568 [80802.263173][ T8682] worker_thread+0x28c/0x518 [80802.263181][ T8682] kthread+0x160/0x170 [80802.263188][ T8682] ret_from_fork+0x10/0x18 [80802.263198][ T8682] Code: a8c12829 a88130cb a8c130 Fixes: d692522577c0 ("usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework") Cc: <stable@vger.kernel.org> Signed-off-by: Dan Vacura <w36195@motorola.com> Link: https://lore.kernel.org/r/20220331184024.23918-1-w36195@motorola.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>