--- /dev/null
+From 80dd33cf72d1ab4f0af303f1fa242c6d6c8d328f Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Fri, 14 May 2021 14:10:15 +0200
+Subject: drivers: base: Fix device link removal
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 80dd33cf72d1ab4f0af303f1fa242c6d6c8d328f upstream.
+
+When device_link_free() drops references to the supplier and
+consumer devices of the device link going away and the reference
+being dropped turns out to be the last one for any of those
+device objects, its ->release callback will be invoked and it
+may sleep which goes against the SRCU callback execution
+requirements.
+
+To address this issue, make the device link removal code carry out
+the device_link_free() actions preceded by SRCU synchronization from
+a separate work item (the "long" workqueue is used for that, because
+it does not matter when the device link memory is released and it may
+take time to get to that point) instead of using SRCU callbacks.
+
+While at it, make the code work analogously when SRCU is not enabled
+to reduce the differences between the SRCU and non-SRCU cases.
+
+Fixes: 843e600b8a2b ("driver core: Fix sleeping in invalid context during device link deletion")
+Cc: stable <stable@vger.kernel.org>
+Reported-by: chenxiang (M) <chenxiang66@hisilicon.com>
+Tested-by: chenxiang (M) <chenxiang66@hisilicon.com>
+Reviewed-by: Saravana Kannan <saravanak@google.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Link: https://lore.kernel.org/r/5722787.lOV4Wx5bFT@kreacher
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/core.c | 37 +++++++++++++++++++++++--------------
+ include/linux/device.h | 6 ++----
+ 2 files changed, 25 insertions(+), 18 deletions(-)
+
+--- a/drivers/base/core.c
++++ b/drivers/base/core.c
+@@ -192,6 +192,11 @@ int device_links_read_lock_held(void)
+ {
+ return srcu_read_lock_held(&device_links_srcu);
+ }
++
++static void device_link_synchronize_removal(void)
++{
++ synchronize_srcu(&device_links_srcu);
++}
+ #else /* !CONFIG_SRCU */
+ static DECLARE_RWSEM(device_links_lock);
+
+@@ -222,6 +227,10 @@ int device_links_read_lock_held(void)
+ return lockdep_is_held(&device_links_lock);
+ }
+ #endif
++
++static inline void device_link_synchronize_removal(void)
++{
++}
+ #endif /* !CONFIG_SRCU */
+
+ static bool device_is_ancestor(struct device *dev, struct device *target)
+@@ -443,8 +452,13 @@ static struct attribute *devlink_attrs[]
+ };
+ ATTRIBUTE_GROUPS(devlink);
+
+-static void device_link_free(struct device_link *link)
++static void device_link_release_fn(struct work_struct *work)
+ {
++ struct device_link *link = container_of(work, struct device_link, rm_work);
++
++ /* Ensure that all references to the link object have been dropped. */
++ device_link_synchronize_removal();
++
+ while (refcount_dec_not_one(&link->rpm_active))
+ pm_runtime_put(link->supplier);
+
+@@ -453,24 +467,19 @@ static void device_link_free(struct devi
+ kfree(link);
+ }
+
+-#ifdef CONFIG_SRCU
+-static void __device_link_free_srcu(struct rcu_head *rhead)
+-{
+- device_link_free(container_of(rhead, struct device_link, rcu_head));
+-}
+-
+ static void devlink_dev_release(struct device *dev)
+ {
+ struct device_link *link = to_devlink(dev);
+
+- call_srcu(&device_links_srcu, &link->rcu_head, __device_link_free_srcu);
+-}
+-#else
+-static void devlink_dev_release(struct device *dev)
+-{
+- device_link_free(to_devlink(dev));
++ INIT_WORK(&link->rm_work, device_link_release_fn);
++ /*
++ * It may take a while to complete this work because of the SRCU
++ * synchronization in device_link_release_fn() and if the consumer or
++ * supplier devices get deleted when it runs, so put it into the "long"
++ * workqueue.
++ */
++ queue_work(system_long_wq, &link->rm_work);
+ }
+-#endif
+
+ static struct class devlink_class = {
+ .name = "devlink",
+--- a/include/linux/device.h
++++ b/include/linux/device.h
+@@ -566,7 +566,7 @@ struct device {
+ * @flags: Link flags.
+ * @rpm_active: Whether or not the consumer device is runtime-PM-active.
+ * @kref: Count repeated addition of the same link.
+- * @rcu_head: An RCU head to use for deferred execution of SRCU callbacks.
++ * @rm_work: Work structure used for removing the link.
+ * @supplier_preactivated: Supplier has been made active before consumer probe.
+ */
+ struct device_link {
+@@ -579,9 +579,7 @@ struct device_link {
+ u32 flags;
+ refcount_t rpm_active;
+ struct kref kref;
+-#ifdef CONFIG_SRCU
+- struct rcu_head rcu_head;
+-#endif
++ struct work_struct rm_work;
+ bool supplier_preactivated; /* Owned by consumer probe. */
+ };
+
--- /dev/null
+From 016002848c82eeb5d460489ce392d91fe18c475c Mon Sep 17 00:00:00 2001
+From: Zheyu Ma <zheyuma97@gmail.com>
+Date: Fri, 21 May 2021 06:08:43 +0000
+Subject: serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait'
+
+From: Zheyu Ma <zheyuma97@gmail.com>
+
+commit 016002848c82eeb5d460489ce392d91fe18c475c upstream.
+
+In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls
+'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the
+firmware don't exists, function just return without initializing ports
+of 'rp2_card'. But now the interrupt handler function has been
+registered, and when an interrupt comes, 'rp2_uart_interrupt' may access
+those ports then causing NULL pointer dereference or other bugs.
+
+Because the driver does some initialization work in 'rp2_fw_cb', in
+order to make the driver ready to handle interrupts, 'request_firmware'
+should be used instead of asynchronous 'request_firmware_nowait'.
+
+This report reveals it:
+
+INFO: trying to register non-static key.
+the code is fine but needs lockdep annotation.
+turning off the locking correctness validator.
+CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45
+Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-
+gc9ba5276e321-prebuilt.qemu.org 04/01/2014
+Call Trace:
+ <IRQ>
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xec/0x156 lib/dump_stack.c:118
+ assign_lock_key kernel/locking/lockdep.c:727 [inline]
+ register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753
+ __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303
+ lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907
+ __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
+ _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144
+ spin_lock include/linux/spinlock.h:329 [inline]
+ rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline]
+ rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493
+ rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504
+ __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149
+ handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189
+ handle_irq_event+0xac/0x140 kernel/irq/handle.c:206
+ handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725
+ generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
+ handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87
+ do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247
+ common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
+ </IRQ>
+RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61
+Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8
+8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90
+90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
+RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
+RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285
+RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200
+RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840
+R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002
+R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000
+ arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
+ default_idle+0x6f/0x360 arch/x86/kernel/process.c:557
+ arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
+ default_idle_call+0x3b/0x60 kernel/sched/idle.c:93
+ cpuidle_idle_call kernel/sched/idle.c:153 [inline]
+ do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263
+ cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
+ start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271
+ secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
+BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
+PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0
+Oops: 0000 [#1] PREEMPT SMP KASAN PTI
+CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45
+Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-
+gc9ba5276e321-prebuilt.qemu.org 04/01/2014
+RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]
+RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]
+RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c:
+493
+Code: df e8 43 5d c2 05 48 8d 83 e8 01 00 00 48 89 85 60 ff ff ff 48 c1 e8
+03 42 80 3c 30 00 0f 85 aa 07 00 00 48 8b 83 e8 01 00 00 <8b> 40 10 89 c1
+89 85 68 ff ff ff 48 8b 83 e8 01 00 00 89 48 10 83
+RSP: 0018:ffff88806c287cd0 EFLAGS: 00010046
+RAX: 0000000000000000 RBX: ffff88806ade6820 RCX: ffffffff814300b1
+RDX: 1ffff1100d5bcd06 RSI: 0000000000000004 RDI: ffff88806ade6820
+RBP: ffff88806c287db8 R08: ffffed100d5bcd05 R09: ffffed100d5bcd05
+R10: 0000000000000001 R11: ffffed100d5bcd04 R12: ffffc90001e00000
+R13: ffff888069654e10 R14: dffffc0000000000 R15: ffff888069654df0
+FS: 0000000000000000(0000) GS:ffff88806c280000(0000) knlGS:
+0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000010 CR3: 000000006892c000 CR4: 00000000000006e0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <IRQ>
+ rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504
+ __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149
+ handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189
+ handle_irq_event+0xac/0x140 kernel/irq/handle.c:206
+ handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725
+ generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
+ handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87
+ do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247
+ common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
+ </IRQ>
+RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61
+Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7
+f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90
+90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
+RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
+RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285
+RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200
+RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840
+R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002
+R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000
+ arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
+ default_idle+0x6f/0x360 arch/x86/kernel/process.c:557
+ arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
+ default_idle_call+0x3b/0x60 kernel/sched/idle.c:93
+ cpuidle_idle_call kernel/sched/idle.c:153 [inline]
+ do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263
+ cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
+ start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271
+ secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
+Modules linked in:
+Dumping ftrace buffer:
+ (ftrace buffer empty)
+CR2: 0000000000000010
+---[ end trace 11804dbb55cb1a64 ]---
+RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]
+RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]
+RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c:
+493
+Code: df e8 43 5d c2 05 48 8d 83 e8 01 00 00 48 89 85 60 ff ff ff 48 c1
+e8 03 42 80 3c 30 00 0f 85 aa 07 00 00 48 8b 83 e8 01 00 00 <8b> 40 10 89
+c1 89 85 68 ff ff ff 48 8b 83 e8 01 00 00 89 48 10 83
+RSP: 0018:ffff88806c287cd0 EFLAGS: 00010046
+RAX: 0000000000000000 RBX: ffff88806ade6820 RCX: ffffffff814300b1
+RDX: 1ffff1100d5bcd06 RSI: 0000000000000004 RDI: ffff88806ade6820
+RBP: ffff88806c287db8 R08: ffffed100d5bcd05 R09: ffffed100d5bcd05
+R10: 0000000000000001 R11: ffffed100d5bcd04 R12: ffffc90001e00000
+R13: ffff888069654e10 R14: dffffc0000000000 R15: ffff888069654df0
+FS: 0000000000000000(0000) GS:ffff88806c280000(0000) knlGS:
+0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000010 CR3: 000000006892c000 CR4: 00000000000006e0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+
+Reported-by: Zheyu Ma <zheyuma97@gmail.com>
+Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
+Link: https://lore.kernel.org/r/1621577323-1541-1-git-send-email-zheyuma97@gmail.com
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/rp2.c | 52 +++++++++++++++--------------------------------
+ 1 file changed, 17 insertions(+), 35 deletions(-)
+
+--- a/drivers/tty/serial/rp2.c
++++ b/drivers/tty/serial/rp2.c
+@@ -195,7 +195,6 @@ struct rp2_card {
+ void __iomem *bar0;
+ void __iomem *bar1;
+ spinlock_t card_lock;
+- struct completion fw_loaded;
+ };
+
+ #define RP_ID(prod) PCI_VDEVICE(RP, (prod))
+@@ -664,17 +663,10 @@ static void rp2_remove_ports(struct rp2_
+ card->initialized_ports = 0;
+ }
+
+-static void rp2_fw_cb(const struct firmware *fw, void *context)
++static int rp2_load_firmware(struct rp2_card *card, const struct firmware *fw)
+ {
+- struct rp2_card *card = context;
+ resource_size_t phys_base;
+- int i, rc = -ENOENT;
+-
+- if (!fw) {
+- dev_err(&card->pdev->dev, "cannot find '%s' firmware image\n",
+- RP2_FW_NAME);
+- goto no_fw;
+- }
++ int i, rc = 0;
+
+ phys_base = pci_resource_start(card->pdev, 1);
+
+@@ -720,23 +712,13 @@ static void rp2_fw_cb(const struct firmw
+ card->initialized_ports++;
+ }
+
+- release_firmware(fw);
+-no_fw:
+- /*
+- * rp2_fw_cb() is called from a workqueue long after rp2_probe()
+- * has already returned success. So if something failed here,
+- * we'll just leave the now-dormant device in place until somebody
+- * unbinds it.
+- */
+- if (rc)
+- dev_warn(&card->pdev->dev, "driver initialization failed\n");
+-
+- complete(&card->fw_loaded);
++ return rc;
+ }
+
+ static int rp2_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+ {
++ const struct firmware *fw;
+ struct rp2_card *card;
+ struct rp2_uart_port *ports;
+ void __iomem * const *bars;
+@@ -747,7 +729,6 @@ static int rp2_probe(struct pci_dev *pde
+ return -ENOMEM;
+ pci_set_drvdata(pdev, card);
+ spin_lock_init(&card->card_lock);
+- init_completion(&card->fw_loaded);
+
+ rc = pcim_enable_device(pdev);
+ if (rc)
+@@ -780,21 +761,23 @@ static int rp2_probe(struct pci_dev *pde
+ return -ENOMEM;
+ card->ports = ports;
+
+- rc = devm_request_irq(&pdev->dev, pdev->irq, rp2_uart_interrupt,
+- IRQF_SHARED, DRV_NAME, card);
+- if (rc)
++ rc = request_firmware(&fw, RP2_FW_NAME, &pdev->dev);
++ if (rc < 0) {
++ dev_err(&pdev->dev, "cannot find '%s' firmware image\n",
++ RP2_FW_NAME);
+ return rc;
++ }
+
+- /*
+- * Only catastrophic errors (e.g. ENOMEM) are reported here.
+- * If the FW image is missing, we'll find out in rp2_fw_cb()
+- * and print an error message.
+- */
+- rc = request_firmware_nowait(THIS_MODULE, 1, RP2_FW_NAME, &pdev->dev,
+- GFP_KERNEL, card, rp2_fw_cb);
++ rc = rp2_load_firmware(card, fw);
++
++ release_firmware(fw);
++ if (rc < 0)
++ return rc;
++
++ rc = devm_request_irq(&pdev->dev, pdev->irq, rp2_uart_interrupt,
++ IRQF_SHARED, DRV_NAME, card);
+ if (rc)
+ return rc;
+- dev_dbg(&pdev->dev, "waiting for firmware blob...\n");
+
+ return 0;
+ }
+@@ -803,7 +786,6 @@ static void rp2_remove(struct pci_dev *p
+ {
+ struct rp2_card *card = pci_get_drvdata(pdev);
+
+- wait_for_completion(&card->fw_loaded);
+ rp2_remove_ports(card);
+ }
+
--- /dev/null
+From 2ea2e019c190ee3973ef7bcaf829d8762e56e635 Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Mon, 10 May 2021 14:07:55 +0200
+Subject: serial: sh-sci: Fix off-by-one error in FIFO threshold register setting
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit 2ea2e019c190ee3973ef7bcaf829d8762e56e635 upstream.
+
+The Receive FIFO Data Count Trigger field (RTRG[6:0]) in the Receive
+FIFO Data Count Trigger Register (HSRTRGR) of HSCIF can only hold values
+ranging from 0-127. As the FIFO size is equal to 128 on HSCIF, the user
+can write an out-of-range value, touching reserved bits.
+
+Fix this by limiting the trigger value to the FIFO size minus one.
+Reverse the order of the checks, to avoid rx_trig becoming zero if the
+FIFO size is one.
+
+Note that this change has no impact on other SCIF variants, as their
+maximum supported trigger value is lower than the FIFO size anyway, and
+the code below takes care of enforcing these limits.
+
+Fixes: a380ed461f66d1b8 ("serial: sh-sci: implement FIFO threshold register setting")
+Reported-by: Linh Phung <linh.phung.jy@renesas.com>
+Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/5eff320aef92ffb33d00e57979fd3603bbb4a70f.1620648218.git.geert+renesas@glider.be
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/sh-sci.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/sh-sci.c
++++ b/drivers/tty/serial/sh-sci.c
+@@ -1023,10 +1023,10 @@ static int scif_set_rtrg(struct uart_por
+ {
+ unsigned int bits;
+
++ if (rx_trig >= port->fifosize)
++ rx_trig = port->fifosize - 1;
+ if (rx_trig < 1)
+ rx_trig = 1;
+- if (rx_trig >= port->fifosize)
+- rx_trig = port->fifosize;
+
+ /* HSCIF can be set to an arbitrary level. */
+ if (sci_getreg(port, HSRTRGR)->size) {
--- /dev/null
+From 3ddb4ce1e6e3bd112778ab93bbd9092f23a878ec Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+Date: Mon, 26 Apr 2021 11:55:14 +0100
+Subject: serial: tegra: Fix a mask operation that is always true
+
+From: Colin Ian King <colin.king@canonical.com>
+
+commit 3ddb4ce1e6e3bd112778ab93bbd9092f23a878ec upstream.
+
+Currently the expression lsr | UART_LSR_TEMT is always true and
+this seems suspect. I believe the intent was to mask lsr with UART_LSR_TEMT
+to check that bit, so the expression should be using the & operator
+instead. Fix this.
+
+Fixes: b9c2470fb150 ("serial: tegra: flush the RX fifo on frame error")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210426105514.23268-1-colin.king@canonical.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/serial-tegra.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/serial-tegra.c
++++ b/drivers/tty/serial/serial-tegra.c
+@@ -338,7 +338,7 @@ static void tegra_uart_fifo_reset(struct
+
+ do {
+ lsr = tegra_uart_read(tup, UART_LSR);
+- if ((lsr | UART_LSR_TEMT) && !(lsr & UART_LSR_DR))
++ if ((lsr & UART_LSR_TEMT) && !(lsr & UART_LSR_DR))
+ break;
+ udelay(1);
+ } while (--tmout);
serial-8250_pci-handle-fl_noirq-board-flag.patch
usb-trancevibrator-fix-control-request-direction.patch
revert-irqbypass-do-not-start-cons-prod-when-failed-connect.patch
+usb-usbfs-don-t-warn-about-excessively-large-memory-allocations.patch
+xhci-fix-giving-back-urb-with-incorrect-status-regression-in-5.12.patch
+xhci-fix-5.12-regression-of-missing-xhc-cache-clearing-command-after-a-stall.patch
+drivers-base-fix-device-link-removal.patch
+serial-tegra-fix-a-mask-operation-that-is-always-true.patch
+serial-sh-sci-fix-off-by-one-error-in-fifo-threshold-register-setting.patch
+serial-rp2-use-request_firmware-instead-of-request_firmware_nowait.patch
+usb-serial-ti_usb_3410_5052-add-startech.com-device-id.patch
+usb-serial-option-add-telit-le910-s1-compositions-0x7010-0x7011.patch
+usb-serial-ftdi_sio-add-ids-for-ids-gmbh-products.patch
+usb-serial-pl2303-add-device-id-for-adlink-nd-6530-gc.patch
+thermal-drivers-intel-initialize-rw-trip-to-thermal_temp_invalid.patch
+usb-dwc3-gadget-properly-track-pending-and-queued-sg.patch
+usb-gadget-udc-renesas_usb3-fix-a-race-in-usb3_start_pipen.patch
--- /dev/null
+From eb8500b874cf295971a6a2a04e14eb0854197a3c Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Fri, 30 Apr 2021 05:23:43 -0700
+Subject: thermal/drivers/intel: Initialize RW trip to THERMAL_TEMP_INVALID
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+commit eb8500b874cf295971a6a2a04e14eb0854197a3c upstream.
+
+After commit 81ad4276b505 ("Thermal: Ignore invalid trip points") all
+user_space governor notifications via RW trip point is broken in intel
+thermal drivers. This commits marks trip_points with value of 0 during
+call to thermal_zone_device_register() as invalid. RW trip points can be
+0 as user space will set the correct trip temperature later.
+
+During driver init, x86_package_temp and all int340x drivers sets RW trip
+temperature as 0. This results in all these trips marked as invalid by
+the thermal core.
+
+To fix this initialize RW trips to THERMAL_TEMP_INVALID instead of 0.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/20210430122343.1789899-1-srinivas.pandruvada@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c | 4 ++++
+ drivers/thermal/intel/x86_pkg_temp_thermal.c | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
++++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
+@@ -237,6 +237,8 @@ struct int34x_thermal_zone *int340x_ther
+ if (ACPI_FAILURE(status))
+ trip_cnt = 0;
+ else {
++ int i;
++
+ int34x_thermal_zone->aux_trips =
+ kcalloc(trip_cnt,
+ sizeof(*int34x_thermal_zone->aux_trips),
+@@ -247,6 +249,8 @@ struct int34x_thermal_zone *int340x_ther
+ }
+ trip_mask = BIT(trip_cnt) - 1;
+ int34x_thermal_zone->aux_trip_nr = trip_cnt;
++ for (i = 0; i < trip_cnt; ++i)
++ int34x_thermal_zone->aux_trips[i] = THERMAL_TEMP_INVALID;
+ }
+
+ trip_cnt = int340x_thermal_read_trips(int34x_thermal_zone);
+--- a/drivers/thermal/intel/x86_pkg_temp_thermal.c
++++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c
+@@ -166,7 +166,7 @@ static int sys_get_trip_temp(struct ther
+ if (thres_reg_value)
+ *temp = zonedev->tj_max - thres_reg_value * 1000;
+ else
+- *temp = 0;
++ *temp = THERMAL_TEMP_INVALID;
+ pr_debug("sys_get_trip_temp %d\n", *temp);
+
+ return 0;
--- /dev/null
+From 25dda9fc56bd90d45f9a4516bcfa5211e61b4290 Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Wed, 12 May 2021 20:17:09 -0700
+Subject: usb: dwc3: gadget: Properly track pending and queued SG
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+commit 25dda9fc56bd90d45f9a4516bcfa5211e61b4290 upstream.
+
+The driver incorrectly uses req->num_pending_sgs to track both the
+number of pending and queued SG entries. It only prepares the next
+request if the previous is done, and it doesn't update num_pending_sgs
+until there is TRB completion interrupt. This may starve the controller
+of more TRBs until the num_pending_sgs is decremented.
+
+Fix this by decrementing the num_pending_sgs after they are queued and
+properly track both num_mapped_sgs and num_queued_sgs.
+
+Fixes: c96e6725db9d ("usb: dwc3: gadget: Correct the logic for queuing sgs")
+Cc: <stable@vger.kernel.org>
+Reported-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
+Tested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
+Acked-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Link: https://lore.kernel.org/r/ba24591dbcaad8f244a3e88bd449bb7205a5aec3.1620874069.git.Thinh.Nguyen@synopsys.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/dwc3/gadget.c | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/drivers/usb/dwc3/gadget.c
++++ b/drivers/usb/dwc3/gadget.c
+@@ -1236,6 +1236,7 @@ static int dwc3_prepare_trbs_sg(struct d
+ req->start_sg = sg_next(s);
+
+ req->num_queued_sgs++;
++ req->num_pending_sgs--;
+
+ /*
+ * The number of pending SG entries may not correspond to the
+@@ -1243,7 +1244,7 @@ static int dwc3_prepare_trbs_sg(struct d
+ * don't include unused SG entries.
+ */
+ if (length == 0) {
+- req->num_pending_sgs -= req->request.num_mapped_sgs - req->num_queued_sgs;
++ req->num_pending_sgs = 0;
+ break;
+ }
+
+@@ -2839,15 +2840,15 @@ static int dwc3_gadget_ep_reclaim_trb_sg
+ struct dwc3_trb *trb = &dep->trb_pool[dep->trb_dequeue];
+ struct scatterlist *sg = req->sg;
+ struct scatterlist *s;
+- unsigned int pending = req->num_pending_sgs;
++ unsigned int num_queued = req->num_queued_sgs;
+ unsigned int i;
+ int ret = 0;
+
+- for_each_sg(sg, s, pending, i) {
++ for_each_sg(sg, s, num_queued, i) {
+ trb = &dep->trb_pool[dep->trb_dequeue];
+
+ req->sg = sg_next(s);
+- req->num_pending_sgs--;
++ req->num_queued_sgs--;
+
+ ret = dwc3_gadget_ep_reclaim_completed_trb(dep, req,
+ trb, event, status, true);
+@@ -2870,7 +2871,7 @@ static int dwc3_gadget_ep_reclaim_trb_li
+
+ static bool dwc3_gadget_ep_request_completed(struct dwc3_request *req)
+ {
+- return req->num_pending_sgs == 0;
++ return req->num_pending_sgs == 0 && req->num_queued_sgs == 0;
+ }
+
+ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
+@@ -2879,7 +2880,7 @@ static int dwc3_gadget_ep_cleanup_comple
+ {
+ int ret;
+
+- if (req->num_pending_sgs)
++ if (req->request.num_mapped_sgs)
+ ret = dwc3_gadget_ep_reclaim_trb_sg(dep, req, event,
+ status);
+ else
--- /dev/null
+From e752dbc59e1241b13b8c4f7b6eb582862e7668fe Mon Sep 17 00:00:00 2001
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Date: Mon, 24 May 2021 15:01:55 +0900
+Subject: usb: gadget: udc: renesas_usb3: Fix a race in usb3_start_pipen()
+
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+commit e752dbc59e1241b13b8c4f7b6eb582862e7668fe upstream.
+
+The usb3_start_pipen() is called by renesas_usb3_ep_queue() and
+usb3_request_done_pipen() so that usb3_start_pipen() is possible
+to cause a race when getting usb3_first_req like below:
+
+renesas_usb3_ep_queue()
+ spin_lock_irqsave()
+ list_add_tail()
+ spin_unlock_irqrestore()
+ usb3_start_pipen()
+ usb3_first_req = usb3_get_request() --- [1]
+ --- interrupt ---
+ usb3_irq_dma_int()
+ usb3_request_done_pipen()
+ usb3_get_request()
+ usb3_start_pipen()
+ usb3_first_req = usb3_get_request()
+ ...
+ (the req is possible to be finished in the interrupt)
+
+The usb3_first_req [1] above may have been finished after the interrupt
+ended so that this driver caused to start a transfer wrongly. To fix this
+issue, getting/checking the usb3_first_req are under spin_lock_irqsave()
+in the same section.
+
+Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Link: https://lore.kernel.org/r/20210524060155.1178724-1-yoshihiro.shimoda.uh@renesas.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/udc/renesas_usb3.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/gadget/udc/renesas_usb3.c
++++ b/drivers/usb/gadget/udc/renesas_usb3.c
+@@ -1488,7 +1488,7 @@ static void usb3_start_pipen(struct rene
+ struct renesas_usb3_request *usb3_req)
+ {
+ struct renesas_usb3 *usb3 = usb3_ep_to_usb3(usb3_ep);
+- struct renesas_usb3_request *usb3_req_first = usb3_get_request(usb3_ep);
++ struct renesas_usb3_request *usb3_req_first;
+ unsigned long flags;
+ int ret = -EAGAIN;
+ u32 enable_bits = 0;
+@@ -1496,7 +1496,8 @@ static void usb3_start_pipen(struct rene
+ spin_lock_irqsave(&usb3->lock, flags);
+ if (usb3_ep->halt || usb3_ep->started)
+ goto out;
+- if (usb3_req != usb3_req_first)
++ usb3_req_first = __usb3_get_request(usb3_ep);
++ if (!usb3_req_first || usb3_req != usb3_req_first)
+ goto out;
+
+ if (usb3_pn_change(usb3, usb3_ep->num) < 0)
--- /dev/null
+From c5a80540e425a5f9a82b0f3163e3b6a4331f33bc Mon Sep 17 00:00:00 2001
+From: Dominik Andreas Schorpp <dominik.a.schorpp@ids.de>
+Date: Thu, 22 Apr 2021 09:58:52 +0200
+Subject: USB: serial: ftdi_sio: add IDs for IDS GmbH Products
+
+From: Dominik Andreas Schorpp <dominik.a.schorpp@ids.de>
+
+commit c5a80540e425a5f9a82b0f3163e3b6a4331f33bc upstream.
+
+Add the IDS GmbH Vendor ID and the Product IDs for SI31A (2xRS232)
+and CM31A (LoRaWAN Modem).
+
+Signed-off-by: Dominik Andreas Schorpp <dominik.a.schorpp@ids.de>
+Signed-off-by: Juergen Borleis <jbe@pengutronix.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/ftdi_sio.c | 3 +++
+ drivers/usb/serial/ftdi_sio_ids.h | 7 +++++++
+ 2 files changed, 10 insertions(+)
+
+--- a/drivers/usb/serial/ftdi_sio.c
++++ b/drivers/usb/serial/ftdi_sio.c
+@@ -1034,6 +1034,9 @@ static const struct usb_device_id id_tab
+ /* Sienna devices */
+ { USB_DEVICE(FTDI_VID, FTDI_SIENNA_PID) },
+ { USB_DEVICE(ECHELON_VID, ECHELON_U20_PID) },
++ /* IDS GmbH devices */
++ { USB_DEVICE(IDS_VID, IDS_SI31A_PID) },
++ { USB_DEVICE(IDS_VID, IDS_CM31A_PID) },
+ /* U-Blox devices */
+ { USB_DEVICE(UBLOX_VID, UBLOX_C099F9P_ZED_PID) },
+ { USB_DEVICE(UBLOX_VID, UBLOX_C099F9P_ODIN_PID) },
+--- a/drivers/usb/serial/ftdi_sio_ids.h
++++ b/drivers/usb/serial/ftdi_sio_ids.h
+@@ -1568,6 +1568,13 @@
+ #define UNJO_ISODEBUG_V1_PID 0x150D
+
+ /*
++ * IDS GmbH
++ */
++#define IDS_VID 0x2CAF
++#define IDS_SI31A_PID 0x13A2
++#define IDS_CM31A_PID 0x13A3
++
++/*
+ * U-Blox products (http://www.u-blox.com).
+ */
+ #define UBLOX_VID 0x1546
--- /dev/null
+From e467714f822b5d167a7fb03d34af91b5b6af1827 Mon Sep 17 00:00:00 2001
+From: Daniele Palmas <dnlplm@gmail.com>
+Date: Wed, 28 Apr 2021 09:26:34 +0200
+Subject: USB: serial: option: add Telit LE910-S1 compositions 0x7010, 0x7011
+
+From: Daniele Palmas <dnlplm@gmail.com>
+
+commit e467714f822b5d167a7fb03d34af91b5b6af1827 upstream.
+
+Add support for the following Telit LE910-S1 compositions:
+
+0x7010: rndis, tty, tty, tty
+0x7011: ecm, tty, tty, tty
+
+Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
+Link: https://lore.kernel.org/r/20210428072634.5091-1-dnlplm@gmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/option.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/usb/serial/option.c
++++ b/drivers/usb/serial/option.c
+@@ -1240,6 +1240,10 @@ static const struct usb_device_id option
+ .driver_info = NCTRL(0) | RSVD(1) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1901, 0xff), /* Telit LN940 (MBIM) */
+ .driver_info = NCTRL(0) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x7010, 0xff), /* Telit LE910-S1 (RNDIS) */
++ .driver_info = NCTRL(2) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x7011, 0xff), /* Telit LE910-S1 (ECM) */
++ .driver_info = NCTRL(2) },
+ { USB_DEVICE(TELIT_VENDOR_ID, 0x9010), /* Telit SBL FN980 flashing device */
+ .driver_info = NCTRL(0) | ZLP },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff, 0xff, 0xff) }, /* ZTE WCDMA products */
--- /dev/null
+From f8e8c1b2f782e7391e8a1c25648ce756e2a7d481 Mon Sep 17 00:00:00 2001
+From: Zolton Jheng <s6668c2t@gmail.com>
+Date: Mon, 10 May 2021 10:32:00 +0800
+Subject: USB: serial: pl2303: add device id for ADLINK ND-6530 GC
+
+From: Zolton Jheng <s6668c2t@gmail.com>
+
+commit f8e8c1b2f782e7391e8a1c25648ce756e2a7d481 upstream.
+
+This adds the device id for the ADLINK ND-6530 which is a PL2303GC based
+device.
+
+Signed-off-by: Zolton Jheng <s6668c2t@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/pl2303.c | 1 +
+ drivers/usb/serial/pl2303.h | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/usb/serial/pl2303.c
++++ b/drivers/usb/serial/pl2303.c
+@@ -113,6 +113,7 @@ static const struct usb_device_id id_tab
+ { USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },
+ { USB_DEVICE(SANWA_VENDOR_ID, SANWA_PRODUCT_ID) },
+ { USB_DEVICE(ADLINK_VENDOR_ID, ADLINK_ND6530_PRODUCT_ID) },
++ { USB_DEVICE(ADLINK_VENDOR_ID, ADLINK_ND6530GC_PRODUCT_ID) },
+ { USB_DEVICE(SMART_VENDOR_ID, SMART_PRODUCT_ID) },
+ { USB_DEVICE(AT_VENDOR_ID, AT_VTKIT3_PRODUCT_ID) },
+ { } /* Terminating entry */
+--- a/drivers/usb/serial/pl2303.h
++++ b/drivers/usb/serial/pl2303.h
+@@ -158,6 +158,7 @@
+ /* ADLINK ND-6530 RS232,RS485 and RS422 adapter */
+ #define ADLINK_VENDOR_ID 0x0b63
+ #define ADLINK_ND6530_PRODUCT_ID 0x6530
++#define ADLINK_ND6530GC_PRODUCT_ID 0x653a
+
+ /* SMART USB Serial Adapter */
+ #define SMART_VENDOR_ID 0x0b8c
--- /dev/null
+From 89b1a3d811e6f8065d6ae8a25e7682329b4a31e2 Mon Sep 17 00:00:00 2001
+From: Sean MacLennan <seanm@seanm.ca>
+Date: Sat, 1 May 2021 20:40:45 -0400
+Subject: USB: serial: ti_usb_3410_5052: add startech.com device id
+
+From: Sean MacLennan <seanm@seanm.ca>
+
+commit 89b1a3d811e6f8065d6ae8a25e7682329b4a31e2 upstream.
+
+This adds support for the Startech.com generic serial to USB converter.
+It seems to be a bone stock TI_3410. I have been using this patch for
+years.
+
+Signed-off-by: Sean MacLennan <seanm@seanm.ca>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/ti_usb_3410_5052.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/serial/ti_usb_3410_5052.c
++++ b/drivers/usb/serial/ti_usb_3410_5052.c
+@@ -37,6 +37,7 @@
+ /* Vendor and product ids */
+ #define TI_VENDOR_ID 0x0451
+ #define IBM_VENDOR_ID 0x04b3
++#define STARTECH_VENDOR_ID 0x14b0
+ #define TI_3410_PRODUCT_ID 0x3410
+ #define IBM_4543_PRODUCT_ID 0x4543
+ #define IBM_454B_PRODUCT_ID 0x454b
+@@ -372,6 +373,7 @@ static const struct usb_device_id ti_id_
+ { USB_DEVICE(MXU1_VENDOR_ID, MXU1_1131_PRODUCT_ID) },
+ { USB_DEVICE(MXU1_VENDOR_ID, MXU1_1150_PRODUCT_ID) },
+ { USB_DEVICE(MXU1_VENDOR_ID, MXU1_1151_PRODUCT_ID) },
++ { USB_DEVICE(STARTECH_VENDOR_ID, TI_3410_PRODUCT_ID) },
+ { } /* terminator */
+ };
+
+@@ -410,6 +412,7 @@ static const struct usb_device_id ti_id_
+ { USB_DEVICE(MXU1_VENDOR_ID, MXU1_1131_PRODUCT_ID) },
+ { USB_DEVICE(MXU1_VENDOR_ID, MXU1_1150_PRODUCT_ID) },
+ { USB_DEVICE(MXU1_VENDOR_ID, MXU1_1151_PRODUCT_ID) },
++ { USB_DEVICE(STARTECH_VENDOR_ID, TI_3410_PRODUCT_ID) },
+ { } /* terminator */
+ };
+
--- /dev/null
+From 4f2629ea67e7225c3fd292c7fe4f5b3c9d6392de Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Tue, 18 May 2021 16:18:35 -0400
+Subject: USB: usbfs: Don't WARN about excessively large memory allocations
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 4f2629ea67e7225c3fd292c7fe4f5b3c9d6392de upstream.
+
+Syzbot found that the kernel generates a WARNing if the user tries to
+submit a bulk transfer through usbfs with a buffer that is way too
+large. This isn't a bug in the kernel; it's merely an invalid request
+from the user and the usbfs code does handle it correctly.
+
+In theory the same thing can happen with async transfers, or with the
+packet descriptor table for isochronous transfers.
+
+To prevent the MM subsystem from complaining about these bad
+allocation requests, add the __GFP_NOWARN flag to the kmalloc calls
+for these buffers.
+
+CC: Andrew Morton <akpm@linux-foundation.org>
+CC: <stable@vger.kernel.org>
+Reported-and-tested-by: syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/20210518201835.GA1140918@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/devio.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/core/devio.c
++++ b/drivers/usb/core/devio.c
+@@ -1218,7 +1218,12 @@ static int do_proc_bulk(struct usb_dev_s
+ ret = usbfs_increase_memory_usage(len1 + sizeof(struct urb));
+ if (ret)
+ return ret;
+- tbuf = kmalloc(len1, GFP_KERNEL);
++
++ /*
++ * len1 can be almost arbitrarily large. Don't WARN if it's
++ * too big, just fail the request.
++ */
++ tbuf = kmalloc(len1, GFP_KERNEL | __GFP_NOWARN);
+ if (!tbuf) {
+ ret = -ENOMEM;
+ goto done;
+@@ -1696,7 +1701,7 @@ static int proc_do_submiturb(struct usb_
+ if (num_sgs) {
+ as->urb->sg = kmalloc_array(num_sgs,
+ sizeof(struct scatterlist),
+- GFP_KERNEL);
++ GFP_KERNEL | __GFP_NOWARN);
+ if (!as->urb->sg) {
+ ret = -ENOMEM;
+ goto error;
+@@ -1731,7 +1736,7 @@ static int proc_do_submiturb(struct usb_
+ (uurb_start - as->usbm->vm_start);
+ } else {
+ as->urb->transfer_buffer = kmalloc(uurb->buffer_length,
+- GFP_KERNEL);
++ GFP_KERNEL | __GFP_NOWARN);
+ if (!as->urb->transfer_buffer) {
+ ret = -ENOMEM;
+ goto error;
--- /dev/null
+From a7f2e9272aff1ccfe0fc801dab1d5a7a1c6b7ed2 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Tue, 25 May 2021 10:41:00 +0300
+Subject: xhci: Fix 5.12 regression of missing xHC cache clearing command after a Stall
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit a7f2e9272aff1ccfe0fc801dab1d5a7a1c6b7ed2 upstream.
+
+If endpoints halts due to a stall then the dequeue pointer read from
+hardware may already be set ahead of the stalled TRB.
+After commit 674f8438c121 ("xhci: split handling halted endpoints into two
+steps") in 5.12 xhci driver won't issue a Set TR Dequeue if hardware
+dequeue pointer is already in the right place.
+
+Turns out the "Set TR Dequeue pointer" command is anyway needed as it in
+addition to moving the dequeue pointer also clears endpoint state and
+cache.
+
+Fixes: 674f8438c121 ("xhci: split handling halted endpoints into two steps")
+Cc: <stable@vger.kernel.org> # 5.12
+Reported-by: Peter Ganzhorn <peter.ganzhorn@googlemail.com>
+Tested-by: Peter Ganzhorn <peter.ganzhorn@googlemail.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20210525074100.1154090-3-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-ring.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -934,14 +934,18 @@ static int xhci_invalidate_cancelled_tds
+ continue;
+ }
+ /*
+- * If ring stopped on the TD we need to cancel, then we have to
++ * If a ring stopped on the TD we need to cancel then we have to
+ * move the xHC endpoint ring dequeue pointer past this TD.
++ * Rings halted due to STALL may show hw_deq is past the stalled
++ * TD, but still require a set TR Deq command to flush xHC cache.
+ */
+ hw_deq = xhci_get_hw_deq(xhci, ep->vdev, ep->ep_index,
+ td->urb->stream_id);
+ hw_deq &= ~0xf;
+
+- if (trb_in_td(xhci, td->start_seg, td->first_trb,
++ if (td->cancel_status == TD_HALTED) {
++ cached_td = td;
++ } else if (trb_in_td(xhci, td->start_seg, td->first_trb,
+ td->last_trb, hw_deq, false)) {
+ switch (td->cancel_status) {
+ case TD_CLEARED: /* TD is already no-op */
--- /dev/null
+From a80c203c3f1c06d2201c19ae071d0ae770a2b1ca Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Tue, 25 May 2021 10:40:59 +0300
+Subject: xhci: fix giving back URB with incorrect status regression in 5.12
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit a80c203c3f1c06d2201c19ae071d0ae770a2b1ca upstream.
+
+5.12 kernel changes how xhci handles cancelled URBs and halted
+endpoints. Among these changes cancelled and stalled URBs are no longer
+given back before they are cleared from xHC hardware cache.
+
+These changes unfortunately cleared the -EPIPE status of a stalled
+transfer in one case before giving bak the URB, causing a USB card reader
+to fail from working.
+
+Fixes: 674f8438c121 ("xhci: split handling halted endpoints into two steps")
+Cc: <stable@vger.kernel.org> # 5.12
+Reported-by: Peter Ganzhorn <peter.ganzhorn@googlemail.com>
+Tested-by: Peter Ganzhorn <peter.ganzhorn@googlemail.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20210525074100.1154090-2-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-ring.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -829,14 +829,10 @@ static void xhci_giveback_invalidated_td
+ list_for_each_entry_safe(td, tmp_td, &ep->cancelled_td_list,
+ cancelled_td_list) {
+
+- /*
+- * Doesn't matter what we pass for status, since the core will
+- * just overwrite it (because the URB has been unlinked).
+- */
+ ring = xhci_urb_to_transfer_ring(ep->xhci, td->urb);
+
+ if (td->cancel_status == TD_CLEARED)
+- xhci_td_cleanup(ep->xhci, td, ring, 0);
++ xhci_td_cleanup(ep->xhci, td, ring, td->status);
+
+ if (ep->xhci->xhc_state & XHCI_STATE_DYING)
+ return;
projects / thirdparty / kernel / stable-queue.git / commitdiff
