--- /dev/null
+From 581dd69830341d299b0c097fc366097ab497d679 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thi=C3=A9baud=20Weksteen?= <tweek@google.com>
+Date: Mon, 2 May 2022 10:49:52 +1000
+Subject: firmware_loader: use kernel credentials when reading firmware
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thiébaud Weksteen <tweek@google.com>
+
+commit 581dd69830341d299b0c097fc366097ab497d679 upstream.
+
+Device drivers may decide to not load firmware when probed to avoid
+slowing down the boot process should the firmware filesystem not be
+available yet. In this case, the firmware loading request may be done
+when a device file associated with the driver is first accessed. The
+credentials of the userspace process accessing the device file may be
+used to validate access to the firmware files requested by the driver.
+Ensure that the kernel assumes the responsibility of reading the
+firmware.
+
+This was observed on Android for a graphic driver loading their firmware
+when the device file (e.g. /dev/mali0) was first opened by userspace
+(i.e. surfaceflinger). The security context of surfaceflinger was used
+to validate the access to the firmware file (e.g.
+/vendor/firmware/mali.bin).
+
+Previously, Android configurations were not setting up the
+firmware_class.path command line argument and were relying on the
+userspace fallback mechanism. In this case, the security context of the
+userspace daemon (i.e. ueventd) was consistently used to read firmware
+files. More Android devices are now found to set firmware_class.path
+which gives the kernel the opportunity to read the firmware directly
+(via kernel_read_file_from_path_initns). In this scenario, the current
+process credentials were used, even if unrelated to the loading of the
+firmware file.
+
+Signed-off-by: Thiébaud Weksteen <tweek@google.com>
+Cc: <stable@vger.kernel.org> # 5.10
+Reviewed-by: Paul Moore <paul@paul-moore.com>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Link: https://lore.kernel.org/r/20220502004952.3970800-1-tweek@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/firmware_loader/main.c | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+--- a/drivers/base/firmware_loader/main.c
++++ b/drivers/base/firmware_loader/main.c
+@@ -735,6 +735,8 @@ _request_firmware(const struct firmware
+ size_t offset, u32 opt_flags)
+ {
+ struct firmware *fw = NULL;
++ struct cred *kern_cred = NULL;
++ const struct cred *old_cred;
+ bool nondirect = false;
+ int ret;
+
+@@ -751,6 +753,18 @@ _request_firmware(const struct firmware
+ if (ret <= 0) /* error or already assigned */
+ goto out;
+
++ /*
++ * We are about to try to access the firmware file. Because we may have been
++ * called by a driver when serving an unrelated request from userland, we use
++ * the kernel credentials to read the file.
++ */
++ kern_cred = prepare_kernel_cred(NULL);
++ if (!kern_cred) {
++ ret = -ENOMEM;
++ goto out;
++ }
++ old_cred = override_creds(kern_cred);
++
+ ret = fw_get_filesystem_firmware(device, fw->priv, "", NULL);
+
+ /* Only full reads can support decompression, platform, and sysfs. */
+@@ -776,6 +790,9 @@ _request_firmware(const struct firmware
+ } else
+ ret = assign_fw(fw, device);
+
++ revert_creds(old_cred);
++ put_cred(kern_cred);
++
+ out:
+ if (ret < 0) {
+ fw_abort_batch_reqs(fw);
--- /dev/null
+From ee8348496c77e3737d0a6cda307a521f2cff954f Mon Sep 17 00:00:00 2001
+From: Alexander Graf <graf@amazon.com>
+Date: Tue, 10 May 2022 14:37:17 +0200
+Subject: KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context()
+
+From: Alexander Graf <graf@amazon.com>
+
+commit ee8348496c77e3737d0a6cda307a521f2cff954f upstream.
+
+Commit 863771a28e27 ("powerpc/32s: Convert switch_mmu_context() to C")
+moved the switch_mmu_context() to C. While in principle a good idea, it
+meant that the function now uses the stack. The stack is not accessible
+from real mode though.
+
+So to keep calling the function, let's turn on MSR_DR while we call it.
+That way, all pointer references to the stack are handled virtually.
+
+In addition, make sure to save/restore r12 on the stack, as it may get
+clobbered by the C function.
+
+Fixes: 863771a28e27 ("powerpc/32s: Convert switch_mmu_context() to C")
+Cc: stable@vger.kernel.org # v5.14+
+Reported-by: Matt Evans <matt@ozlabs.org>
+Signed-off-by: Alexander Graf <graf@amazon.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20220510123717.24508-1-graf@amazon.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kvm/book3s_32_sr.S | 26 +++++++++++++++++++++-----
+ 1 file changed, 21 insertions(+), 5 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_32_sr.S
++++ b/arch/powerpc/kvm/book3s_32_sr.S
+@@ -122,11 +122,27 @@
+
+ /* 0x0 - 0xb */
+
+- /* 'current->mm' needs to be in r4 */
+- tophys(r4, r2)
+- lwz r4, MM(r4)
+- tophys(r4, r4)
+- /* This only clobbers r0, r3, r4 and r5 */
++ /* switch_mmu_context() needs paging, let's enable it */
++ mfmsr r9
++ ori r11, r9, MSR_DR
++ mtmsr r11
++ sync
++
++ /* switch_mmu_context() clobbers r12, rescue it */
++ SAVE_GPR(12, r1)
++
++ /* Calling switch_mmu_context(<inv>, current->mm, <inv>); */
++ lwz r4, MM(r2)
+ bl switch_mmu_context
+
++ /* restore r12 */
++ REST_GPR(12, r1)
++
++ /* Disable paging again */
++ mfmsr r9
++ li r6, MSR_DR
++ andc r9, r9, r6
++ mtmsr r9
++ sync
++
+ .endm
block-do-not-call-folio_next-on-an-unreferenced-foli.patch
interconnect-restore-sync-state-by-ignoring-ipa-virt.patch
perf-tests-fix-coresight-perf-test-failure.patch
+firmware_loader-use-kernel-credentials-when-reading-firmware.patch
+kvm-ppc-book3s-pr-enable-msr_dr-for-switch_mmu_context.patch
+usb-xhci-mtk-fix-fs-isoc-s-transfer-error.patch
+x86-mm-fix-marking-of-unused-sub-pmd-ranges.patch
+tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch
+tty-n_gsm-fix-buffer-over-read-in-gsm_dlci_data.patch
+tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch
+tty-n_gsm-fix-invalid-gsmtty_write_room-result.patch
+usb-gadget-uvc-allow-for-application-to-cleanly-shutdown.patch
+usb-cdc-wdm-fix-reading-stuck-on-device-close.patch
--- /dev/null
+From fd442e5ba30aaa75ea47b32149e7a3110dc20a46 Mon Sep 17 00:00:00 2001
+From: Daniel Starke <daniel.starke@siemens.com>
+Date: Wed, 4 May 2022 10:17:31 +0200
+Subject: tty: n_gsm: fix buffer over-read in gsm_dlci_data()
+
+From: Daniel Starke <daniel.starke@siemens.com>
+
+commit fd442e5ba30aaa75ea47b32149e7a3110dc20a46 upstream.
+
+'len' is decreased after each octet that has its EA bit set to 0, which
+means that the value is encoded with additional octets. However, the final
+octet does not decreases 'len' which results in 'len' being one byte too
+long. A buffer over-read may occur in tty_insert_flip_string() as it tries
+to read one byte more than the passed content size of 'data'.
+Decrease 'len' also for the final octet which has the EA bit set to 1 to
+write the correct number of bytes from the internal receive buffer to the
+virtual tty.
+
+Fixes: 2e124b4a390c ("TTY: switch tty_flip_buffer_push")
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
+Link: https://lore.kernel.org/r/20220504081733.3494-1-daniel.starke@siemens.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/n_gsm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/tty/n_gsm.c
++++ b/drivers/tty/n_gsm.c
+@@ -1658,6 +1658,7 @@ static void gsm_dlci_data(struct gsm_dlc
+ if (len == 0)
+ return;
+ }
++ len--;
+ slen++;
+ tty = tty_port_tty_get(port);
+ if (tty) {
--- /dev/null
+From 9361ebfbb79fd1bc8594a487c01ad52cdaa391ea Mon Sep 17 00:00:00 2001
+From: Daniel Starke <daniel.starke@siemens.com>
+Date: Wed, 4 May 2022 10:17:33 +0200
+Subject: tty: n_gsm: fix invalid gsmtty_write_room() result
+
+From: Daniel Starke <daniel.starke@siemens.com>
+
+commit 9361ebfbb79fd1bc8594a487c01ad52cdaa391ea upstream.
+
+gsmtty_write() does not prevent the user to use the full fifo size of 4096
+bytes as allocated in gsm_dlci_alloc(). However, gsmtty_write_room() tries
+to limit the return value by 'TX_SIZE' and returns a negative value if the
+fifo has more than 'TX_SIZE' bytes stored. This is obviously wrong as
+'TX_SIZE' is defined as 512.
+Define 'TX_SIZE' to the fifo size and use it accordingly for allocation to
+keep the current behavior. Return the correct remaining size of the fifo in
+gsmtty_write_room() via kfifo_avail().
+
+Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
+Link: https://lore.kernel.org/r/20220504081733.3494-3-daniel.starke@siemens.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/n_gsm.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/drivers/tty/n_gsm.c
++++ b/drivers/tty/n_gsm.c
+@@ -137,6 +137,7 @@ struct gsm_dlci {
+ int retries;
+ /* Uplink tty if active */
+ struct tty_port port; /* The tty bound to this DLCI if there is one */
++#define TX_SIZE 4096 /* Must be power of 2. */
+ struct kfifo fifo; /* Queue fifo for the DLCI */
+ int adaption; /* Adaption layer in use */
+ int prev_adaption;
+@@ -1731,7 +1732,7 @@ static struct gsm_dlci *gsm_dlci_alloc(s
+ return NULL;
+ spin_lock_init(&dlci->lock);
+ mutex_init(&dlci->mutex);
+- if (kfifo_alloc(&dlci->fifo, 4096, GFP_KERNEL) < 0) {
++ if (kfifo_alloc(&dlci->fifo, TX_SIZE, GFP_KERNEL) < 0) {
+ kfree(dlci);
+ return NULL;
+ }
+@@ -2976,8 +2977,6 @@ static struct tty_ldisc_ops tty_ldisc_pa
+ * Virtual tty side
+ */
+
+-#define TX_SIZE 512
+-
+ /**
+ * gsm_modem_upd_via_data - send modem bits via convergence layer
+ * @dlci: channel
+@@ -3217,7 +3216,7 @@ static unsigned int gsmtty_write_room(st
+ struct gsm_dlci *dlci = tty->driver_data;
+ if (dlci->state == DLCI_CLOSED)
+ return 0;
+- return TX_SIZE - kfifo_len(&dlci->fifo);
++ return kfifo_avail(&dlci->fifo);
+ }
+
+ static unsigned int gsmtty_chars_in_buffer(struct tty_struct *tty)
--- /dev/null
+From edd5f60c340086891fab094ad61270d6c80f9ca4 Mon Sep 17 00:00:00 2001
+From: Daniel Starke <daniel.starke@siemens.com>
+Date: Wed, 4 May 2022 10:17:32 +0200
+Subject: tty: n_gsm: fix mux activation issues in gsm_config()
+
+From: Daniel Starke <daniel.starke@siemens.com>
+
+commit edd5f60c340086891fab094ad61270d6c80f9ca4 upstream.
+
+The current implementation activates the mux if it was restarted and opens
+the control channel if the mux was previously closed and we are now acting
+as initiator instead of responder, which is the default setting.
+This has two issues.
+1) No mux is activated if we keep all default values and only switch to
+initiator. The control channel is not allocated but will be opened next
+which results in a NULL pointer dereference.
+2) Switching the configuration after it was once configured while keeping
+the initiator value the same will not reopen the control channel if it was
+closed due to parameter incompatibilities. The mux remains dead.
+
+Fix 1) by always activating the mux if it is dead after configuration.
+Fix 2) by always opening the control channel after mux activation.
+
+Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
+Link: https://lore.kernel.org/r/20220504081733.3494-2-daniel.starke@siemens.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/n_gsm.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/tty/n_gsm.c
++++ b/drivers/tty/n_gsm.c
+@@ -2352,6 +2352,7 @@ static void gsm_copy_config_values(struc
+
+ static int gsm_config(struct gsm_mux *gsm, struct gsm_config *c)
+ {
++ int ret = 0;
+ int need_close = 0;
+ int need_restart = 0;
+
+@@ -2419,10 +2420,13 @@ static int gsm_config(struct gsm_mux *gs
+ * FIXME: We need to separate activation/deactivation from adding
+ * and removing from the mux array
+ */
+- if (need_restart)
+- gsm_activate_mux(gsm);
+- if (gsm->initiator && need_close)
+- gsm_dlci_begin_open(gsm->dlci[0]);
++ if (gsm->dead) {
++ ret = gsm_activate_mux(gsm);
++ if (ret)
++ return ret;
++ if (gsm->initiator)
++ gsm_dlci_begin_open(gsm->dlci[0]);
++ }
+ return 0;
+ }
+
--- /dev/null
+From 447ee1516f19f534a228dda237eddb202f23e163 Mon Sep 17 00:00:00 2001
+From: Yang Yingliang <yangyingliang@huawei.com>
+Date: Thu, 5 May 2022 20:46:21 +0800
+Subject: tty/serial: digicolor: fix possible null-ptr-deref in digicolor_uart_probe()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+commit 447ee1516f19f534a228dda237eddb202f23e163 upstream.
+
+It will cause null-ptr-deref when using 'res', if platform_get_resource()
+returns NULL, so move using 'res' after devm_ioremap_resource() that
+will check it to avoid null-ptr-deref.
+And use devm_platform_get_and_ioremap_resource() to simplify code.
+
+Fixes: 5930cb3511df ("serial: driver for Conexant Digicolor USART")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Reviewed-by: Baruch Siach <baruch@tkos.co.il>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220505124621.1592697-1-yangyingliang@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/digicolor-usart.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/tty/serial/digicolor-usart.c
++++ b/drivers/tty/serial/digicolor-usart.c
+@@ -471,11 +471,10 @@ static int digicolor_uart_probe(struct p
+ if (IS_ERR(uart_clk))
+ return PTR_ERR(uart_clk);
+
+- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+- dp->port.mapbase = res->start;
+- dp->port.membase = devm_ioremap_resource(&pdev->dev, res);
++ dp->port.membase = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+ if (IS_ERR(dp->port.membase))
+ return PTR_ERR(dp->port.membase);
++ dp->port.mapbase = res->start;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
--- /dev/null
+From 01e01f5c89773c600a9f0b32c888de0146066c3a Mon Sep 17 00:00:00 2001
+From: Sergey Ryazanov <ryazanov.s.a@gmail.com>
+Date: Sun, 1 May 2022 20:58:28 +0300
+Subject: usb: cdc-wdm: fix reading stuck on device close
+
+From: Sergey Ryazanov <ryazanov.s.a@gmail.com>
+
+commit 01e01f5c89773c600a9f0b32c888de0146066c3a upstream.
+
+cdc-wdm tracks whether a response reading request is in-progress and
+blocks the next request from being sent until the previous request is
+completed. As soon as last user closes the cdc-wdm device file, the
+driver cancels any ongoing requests, resets the pending response
+counter, but leaves the response reading in-progress flag
+(WDM_RESPONDING) untouched.
+
+So if the user closes the device file during the response receive
+request is being performed, no more data will be obtained from the
+modem. The request will be cancelled, effectively preventing the
+WDM_RESPONDING flag from being reseted. Keeping the flag set will
+prevent a new response receive request from being sent, permanently
+blocking the read path. The read path will staying blocked until the
+module will be reloaded or till the modem will be re-attached.
+
+This stuck has been observed with a Huawei E3372 modem attached to an
+OpenWrt router and using the comgt utility to set up a network
+connection.
+
+Fix this issue by clearing the WDM_RESPONDING flag on the device file
+close.
+
+Without this fix, the device reading stuck can be easily reproduced in a
+few connection establishing attempts. With this fix, a load test for
+modem connection re-establishing worked for several hours without any
+issues.
+
+Fixes: 922a5eadd5a3 ("usb: cdc-wdm: Fix race between autosuspend and reading from the device")
+Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Oliver Neukum <oneukum@suse.com>
+Link: https://lore.kernel.org/r/20220501175828.8185-1-ryazanov.s.a@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/class/cdc-wdm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/class/cdc-wdm.c
++++ b/drivers/usb/class/cdc-wdm.c
+@@ -774,6 +774,7 @@ static int wdm_release(struct inode *ino
+ poison_urbs(desc);
+ spin_lock_irq(&desc->iuspin);
+ desc->resp_count = 0;
++ clear_bit(WDM_RESPONDING, &desc->flags);
+ spin_unlock_irq(&desc->iuspin);
+ desc->manage_power(desc->intf, 0);
+ unpoison_urbs(desc);
--- /dev/null
+From b81ac4395bbeaf36e078dea1a48c02dd97b76235 Mon Sep 17 00:00:00 2001
+From: Dan Vacura <w36195@motorola.com>
+Date: Tue, 3 May 2022 15:10:38 -0500
+Subject: usb: gadget: uvc: allow for application to cleanly shutdown
+
+From: Dan Vacura <w36195@motorola.com>
+
+commit b81ac4395bbeaf36e078dea1a48c02dd97b76235 upstream.
+
+Several types of kernel panics can occur due to timing during the uvc
+gadget removal. This appears to be a problem with gadget resources being
+managed by both the client application's v4l2 open/close and the UDC
+gadget bind/unbind. Since the concept of USB_GADGET_DELAYED_STATUS
+doesn't exist for unbind, add a wait to allow for the application to
+close out.
+
+Some examples of the panics that can occur are:
+
+<1>[ 1147.652313] Unable to handle kernel NULL pointer dereference at
+virtual address 0000000000000028
+<4>[ 1147.652510] Call trace:
+<4>[ 1147.652514] usb_gadget_disconnect+0x74/0x1f0
+<4>[ 1147.652516] usb_gadget_deactivate+0x38/0x168
+<4>[ 1147.652520] usb_function_deactivate+0x54/0x90
+<4>[ 1147.652524] uvc_function_disconnect+0x14/0x38
+<4>[ 1147.652527] uvc_v4l2_release+0x34/0xa0
+<4>[ 1147.652537] __fput+0xdc/0x2c0
+<4>[ 1147.652540] ____fput+0x10/0x1c
+<4>[ 1147.652545] task_work_run+0xe4/0x12c
+<4>[ 1147.652549] do_notify_resume+0x108/0x168
+
+<1>[ 282.950561][ T1472] Unable to handle kernel NULL pointer
+dereference at virtual address 00000000000005b8
+<6>[ 282.953111][ T1472] Call trace:
+<6>[ 282.953121][ T1472] usb_function_deactivate+0x54/0xd4
+<6>[ 282.953134][ T1472] uvc_v4l2_release+0xac/0x1e4
+<6>[ 282.953145][ T1472] v4l2_release+0x134/0x1f0
+<6>[ 282.953167][ T1472] __fput+0xf4/0x428
+<6>[ 282.953178][ T1472] ____fput+0x14/0x24
+<6>[ 282.953193][ T1472] task_work_run+0xac/0x130
+
+<3>[ 213.410077][ T29] configfs-gadget gadget: uvc: Failed to queue
+request (-108).
+<1>[ 213.410116][ T29] Unable to handle kernel NULL pointer
+dereference at virtual address 0000000000000003
+<6>[ 213.413460][ T29] Call trace:
+<6>[ 213.413474][ T29] uvcg_video_pump+0x1f0/0x384
+<6>[ 213.413489][ T29] process_one_work+0x2a4/0x544
+<6>[ 213.413502][ T29] worker_thread+0x350/0x784
+<6>[ 213.413515][ T29] kthread+0x2ac/0x320
+<6>[ 213.413528][ T29] ret_from_fork+0x10/0x30
+
+Signed-off-by: Dan Vacura <w36195@motorola.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220503201039.71720-1-w36195@motorola.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/function/f_uvc.c | 25 +++++++++++++++++++++++++
+ drivers/usb/gadget/function/uvc.h | 2 ++
+ drivers/usb/gadget/function/uvc_v4l2.c | 3 ++-
+ 3 files changed, 29 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/gadget/function/f_uvc.c
++++ b/drivers/usb/gadget/function/f_uvc.c
+@@ -890,13 +890,37 @@ static void uvc_function_unbind(struct u
+ {
+ struct usb_composite_dev *cdev = c->cdev;
+ struct uvc_device *uvc = to_uvc(f);
++ long wait_ret = 1;
+
+ uvcg_info(f, "%s()\n", __func__);
+
++ /* If we know we're connected via v4l2, then there should be a cleanup
++ * of the device from userspace either via UVC_EVENT_DISCONNECT or
++ * though the video device removal uevent. Allow some time for the
++ * application to close out before things get deleted.
++ */
++ if (uvc->func_connected) {
++ uvcg_dbg(f, "waiting for clean disconnect\n");
++ wait_ret = wait_event_interruptible_timeout(uvc->func_connected_queue,
++ uvc->func_connected == false, msecs_to_jiffies(500));
++ uvcg_dbg(f, "done waiting with ret: %ld\n", wait_ret);
++ }
++
+ device_remove_file(&uvc->vdev.dev, &dev_attr_function_name);
+ video_unregister_device(&uvc->vdev);
+ v4l2_device_unregister(&uvc->v4l2_dev);
+
++ if (uvc->func_connected) {
++ /* Wait for the release to occur to ensure there are no longer any
++ * pending operations that may cause panics when resources are cleaned
++ * up.
++ */
++ uvcg_warn(f, "%s no clean disconnect, wait for release\n", __func__);
++ wait_ret = wait_event_interruptible_timeout(uvc->func_connected_queue,
++ uvc->func_connected == false, msecs_to_jiffies(1000));
++ uvcg_dbg(f, "done waiting for release with ret: %ld\n", wait_ret);
++ }
++
+ usb_ep_free_request(cdev->gadget->ep0, uvc->control_req);
+ kfree(uvc->control_buf);
+
+@@ -915,6 +939,7 @@ static struct usb_function *uvc_alloc(st
+
+ mutex_init(&uvc->video.mutex);
+ uvc->state = UVC_STATE_DISCONNECTED;
++ init_waitqueue_head(&uvc->func_connected_queue);
+ opts = fi_to_f_uvc_opts(fi);
+
+ mutex_lock(&opts->lock);
+--- a/drivers/usb/gadget/function/uvc.h
++++ b/drivers/usb/gadget/function/uvc.h
+@@ -14,6 +14,7 @@
+ #include <linux/spinlock.h>
+ #include <linux/usb/composite.h>
+ #include <linux/videodev2.h>
++#include <linux/wait.h>
+
+ #include <media/v4l2-device.h>
+ #include <media/v4l2-dev.h>
+@@ -129,6 +130,7 @@ struct uvc_device {
+ struct usb_function func;
+ struct uvc_video video;
+ bool func_connected;
++ wait_queue_head_t func_connected_queue;
+
+ /* Descriptors */
+ struct {
+--- a/drivers/usb/gadget/function/uvc_v4l2.c
++++ b/drivers/usb/gadget/function/uvc_v4l2.c
+@@ -253,10 +253,11 @@ uvc_v4l2_subscribe_event(struct v4l2_fh
+
+ static void uvc_v4l2_disable(struct uvc_device *uvc)
+ {
+- uvc->func_connected = false;
+ uvc_function_disconnect(uvc);
+ uvcg_video_enable(&uvc->video, 0);
+ uvcg_free_buffers(&uvc->video.queue);
++ uvc->func_connected = false;
++ wake_up_interruptible(&uvc->func_connected_queue);
+ }
+
+ static int
--- /dev/null
+From c237566b78ad8c72bc0431c5d6171db8d12e6f94 Mon Sep 17 00:00:00 2001
+From: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Date: Thu, 12 May 2022 14:49:30 +0800
+Subject: usb: xhci-mtk: fix fs isoc's transfer error
+
+From: Chunfeng Yun <chunfeng.yun@mediatek.com>
+
+commit c237566b78ad8c72bc0431c5d6171db8d12e6f94 upstream.
+
+Due to the scheduler allocates the optimal bandwidth for FS ISOC endpoints,
+this may be not enough actually and causes data transfer error, so come up
+with an estimate that is no less than the worst case bandwidth used for
+any one mframe, but may be an over-estimate.
+
+Fixes: 451d3912586a ("usb: xhci-mtk: update fs bus bandwidth by bw_budget_table")
+Cc: stable@vger.kernel.org
+Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Link: https://lore.kernel.org/r/20220512064931.31670-1-chunfeng.yun@mediatek.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-mtk-sch.c | 16 +++++++---------
+ 1 file changed, 7 insertions(+), 9 deletions(-)
+
+--- a/drivers/usb/host/xhci-mtk-sch.c
++++ b/drivers/usb/host/xhci-mtk-sch.c
+@@ -465,7 +465,7 @@ static int check_fs_bus_bw(struct mu3h_s
+ */
+ for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+ k = XHCI_MTK_BW_INDEX(base + j);
+- tmp = tt->fs_bus_bw[k] + sch_ep->bw_budget_table[j];
++ tmp = tt->fs_bus_bw[k] + sch_ep->bw_cost_per_microframe;
+ if (tmp > FS_PAYLOAD_MAX)
+ return -ESCH_BW_OVERFLOW;
+ }
+@@ -539,19 +539,17 @@ static int check_sch_tt(struct mu3h_sch_
+ static void update_sch_tt(struct mu3h_sch_ep_info *sch_ep, bool used)
+ {
+ struct mu3h_sch_tt *tt = sch_ep->sch_tt;
++ int bw_updated;
+ u32 base;
+- int i, j, k;
++ int i, j;
++
++ bw_updated = sch_ep->bw_cost_per_microframe * (used ? 1 : -1);
+
+ for (i = 0; i < sch_ep->num_esit; i++) {
+ base = sch_ep->offset + i * sch_ep->esit;
+
+- for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+- k = XHCI_MTK_BW_INDEX(base + j);
+- if (used)
+- tt->fs_bus_bw[k] += sch_ep->bw_budget_table[j];
+- else
+- tt->fs_bus_bw[k] -= sch_ep->bw_budget_table[j];
+- }
++ for (j = 0; j < sch_ep->num_budget_microframes; j++)
++ tt->fs_bus_bw[XHCI_MTK_BW_INDEX(base + j)] += bw_updated;
+ }
+
+ if (used)
--- /dev/null
+From 280abe14b6e0a38de9cc86fe6a019523aadd8f70 Mon Sep 17 00:00:00 2001
+From: Adrian-Ken Rueegsegger <ken@codelabs.ch>
+Date: Mon, 9 May 2022 11:06:37 +0200
+Subject: x86/mm: Fix marking of unused sub-pmd ranges
+
+From: Adrian-Ken Rueegsegger <ken@codelabs.ch>
+
+commit 280abe14b6e0a38de9cc86fe6a019523aadd8f70 upstream.
+
+The unused part precedes the new range spanned by the start, end parameters
+of vmemmap_use_new_sub_pmd(). This means it actually goes from
+ALIGN_DOWN(start, PMD_SIZE) up to start.
+
+Use the correct address when applying the mark using memset.
+
+Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges")
+Signed-off-by: Adrian-Ken Rueegsegger <ken@codelabs.ch>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Oscar Salvador <osalvador@suse.de>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20220509090637.24152-2-ken@codelabs.ch
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/init_64.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/mm/init_64.c
++++ b/arch/x86/mm/init_64.c
+@@ -902,6 +902,8 @@ static void __meminit vmemmap_use_sub_pm
+
+ static void __meminit vmemmap_use_new_sub_pmd(unsigned long start, unsigned long end)
+ {
++ const unsigned long page = ALIGN_DOWN(start, PMD_SIZE);
++
+ vmemmap_flush_unused_pmd();
+
+ /*
+@@ -914,8 +916,7 @@ static void __meminit vmemmap_use_new_su
+ * Mark with PAGE_UNUSED the unused parts of the new memmap range
+ */
+ if (!IS_ALIGNED(start, PMD_SIZE))
+- memset((void *)start, PAGE_UNUSED,
+- start - ALIGN_DOWN(start, PMD_SIZE));
++ memset((void *)page, PAGE_UNUSED, start - page);
+
+ /*
+ * We want to avoid memset(PAGE_UNUSED) when populating the vmemmap of
projects / thirdparty / kernel / stable-queue.git / commitdiff
