--- /dev/null
+From 33fab972497ae66822c0b6846d4f9382938575b6 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Fri, 10 Dec 2021 19:02:18 +0000
+Subject: btrfs: fix double free of anon_dev after failure to create subvolume
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 33fab972497ae66822c0b6846d4f9382938575b6 upstream.
+
+When creating a subvolume, at create_subvol(), we allocate an anonymous
+device and later call btrfs_get_new_fs_root(), which in turn just calls
+btrfs_get_root_ref(). There we call btrfs_init_fs_root() which assigns
+the anonymous device to the root, but if after that call there's an error,
+when we jump to 'fail' label, we call btrfs_put_root(), which frees the
+anonymous device and then returns an error that is propagated back to
+create_subvol(). Than create_subvol() frees the anonymous device again.
+
+When this happens, if the anonymous device was not reallocated after
+the first time it was freed with btrfs_put_root(), we get a kernel
+message like the following:
+
+ (...)
+ [13950.282466] BTRFS: error (device dm-0) in create_subvol:663: errno=-5 IO failure
+ [13950.283027] ida_free called for id=65 which is not allocated.
+ [13950.285974] BTRFS info (device dm-0): forced readonly
+ (...)
+
+If the anonymous device gets reallocated by another btrfs filesystem
+or any other kernel subsystem, then bad things can happen.
+
+So fix this by setting the root's anonymous device to 0 at
+btrfs_get_root_ref(), before we call btrfs_put_root(), if an error
+happened.
+
+Fixes: 2dfb1e43f57dd3 ("btrfs: preallocate anon block device at first phase of snapshot creation")
+CC: stable@vger.kernel.org # 5.10+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/disk-io.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/btrfs/disk-io.c
++++ b/fs/btrfs/disk-io.c
+@@ -1603,6 +1603,14 @@ again:
+ }
+ return root;
+ fail:
++ /*
++ * If our caller provided us an anonymous device, then it's his
++ * responsability to free it in case we fail. So we have to set our
++ * root's anon_dev to 0 to avoid a double free, once by btrfs_put_root()
++ * and once again by our caller.
++ */
++ if (anon_dev)
++ root->anon_dev = 0;
+ btrfs_put_root(root);
+ return ERR_PTR(ret);
+ }
--- /dev/null
+From f35838a6930296fc1988764cfa54cb3f705c0665 Mon Sep 17 00:00:00 2001
+From: Jianglei Nie <niejianglei2021@163.com>
+Date: Thu, 9 Dec 2021 14:56:31 +0800
+Subject: btrfs: fix memory leak in __add_inode_ref()
+
+From: Jianglei Nie <niejianglei2021@163.com>
+
+commit f35838a6930296fc1988764cfa54cb3f705c0665 upstream.
+
+Line 1169 (#3) allocates a memory chunk for victim_name by kmalloc(),
+but when the function returns in line 1184 (#4) victim_name allocated
+by line 1169 (#3) is not freed, which will lead to a memory leak.
+There is a similar snippet of code in this function as allocating a memory
+chunk for victim_name in line 1104 (#1) as well as releasing the memory
+in line 1116 (#2).
+
+We should kfree() victim_name when the return value of backref_in_log()
+is less than zero and before the function returns in line 1184 (#4).
+
+1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans,
+1058 struct btrfs_root *root,
+1059 struct btrfs_path *path,
+1060 struct btrfs_root *log_root,
+1061 struct btrfs_inode *dir,
+1062 struct btrfs_inode *inode,
+1063 u64 inode_objectid, u64 parent_objectid,
+1064 u64 ref_index, char *name, int namelen,
+1065 int *search_done)
+1066 {
+
+1104 victim_name = kmalloc(victim_name_len, GFP_NOFS);
+ // #1: kmalloc (victim_name-1)
+1105 if (!victim_name)
+1106 return -ENOMEM;
+
+1112 ret = backref_in_log(log_root, &search_key,
+1113 parent_objectid, victim_name,
+1114 victim_name_len);
+1115 if (ret < 0) {
+1116 kfree(victim_name); // #2: kfree (victim_name-1)
+1117 return ret;
+1118 } else if (!ret) {
+
+1169 victim_name = kmalloc(victim_name_len, GFP_NOFS);
+ // #3: kmalloc (victim_name-2)
+1170 if (!victim_name)
+1171 return -ENOMEM;
+
+1180 ret = backref_in_log(log_root, &search_key,
+1181 parent_objectid, victim_name,
+1182 victim_name_len);
+1183 if (ret < 0) {
+1184 return ret; // #4: missing kfree (victim_name-2)
+1185 } else if (!ret) {
+
+1241 return 0;
+1242 }
+
+Fixes: d3316c8233bb ("btrfs: Properly handle backref_in_log retval")
+CC: stable@vger.kernel.org # 5.10+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/tree-log.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -1109,6 +1109,7 @@ again:
+ parent_objectid, victim_name,
+ victim_name_len);
+ if (ret < 0) {
++ kfree(victim_name);
+ return ret;
+ } else if (!ret) {
+ ret = -ENOENT;
--- /dev/null
+From f3a8076eb28cae1553958c629aecec479394bbe2 Mon Sep 17 00:00:00 2001
+From: Le Ma <le.ma@amd.com>
+Date: Sat, 4 Dec 2021 18:59:08 +0800
+Subject: drm/amdgpu: correct register access for RLC_JUMP_TABLE_RESTORE
+
+From: Le Ma <le.ma@amd.com>
+
+commit f3a8076eb28cae1553958c629aecec479394bbe2 upstream.
+
+should count on GC IP base address
+
+Signed-off-by: Le Ma <le.ma@amd.com>
+Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+@@ -3002,8 +3002,8 @@ static void gfx_v9_0_init_pg(struct amdg
+ AMD_PG_SUPPORT_CP |
+ AMD_PG_SUPPORT_GDS |
+ AMD_PG_SUPPORT_RLC_SMU_HS)) {
+- WREG32(mmRLC_JUMP_TABLE_RESTORE,
+- adev->gfx.rlc.cp_table_gpu_addr >> 8);
++ WREG32_SOC15(GC, 0, mmRLC_JUMP_TABLE_RESTORE,
++ adev->gfx.rlc.cp_table_gpu_addr >> 8);
+ gfx_v9_0_init_gfx_power_gating(adev);
+ }
+ }
--- /dev/null
+From edaa26334c117a584add6053f48d63a988d25a6e Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Mon, 13 Dec 2021 14:14:43 -1000
+Subject: iocost: Fix divide-by-zero on donation from low hweight cgroup
+
+From: Tejun Heo <tj@kernel.org>
+
+commit edaa26334c117a584add6053f48d63a988d25a6e upstream.
+
+The donation calculation logic assumes that the donor has non-zero
+after-donation hweight, so the lowest active hweight a donating cgroup can
+have is 2 so that it can donate 1 while keeping the other 1 for itself.
+Earlier, we only donated from cgroups with sizable surpluses so this
+condition was always true. However, with the precise donation algorithm
+implemented, f1de2439ec43 ("blk-iocost: revamp donation amount
+determination") made the donation amount calculation exact enabling even low
+hweight cgroups to donate.
+
+This means that in rare occasions, a cgroup with active hweight of 1 can
+enter donation calculation triggering the following warning and then a
+divide-by-zero oops.
+
+ WARNING: CPU: 4 PID: 0 at block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867]
+ ...
+ RIP: 0010:transfer_surpluses.cold+0x0/0x53
+ Code: 92 ff 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0
+4
+ ...
+ Call Trace:
+ <IRQ>
+ ioc_timer_fn+0x1043/0x1390
+ call_timer_fn+0xa1/0x2c0
+ __run_timers.part.0+0x1ec/0x2e0
+ run_timer_softirq+0x35/0x70
+ ...
+ iocg: invalid donation weights in /a/b: active=1 donating=1 after=0
+
+Fix it by excluding cgroups w/ active hweight < 2 from donating. Excluding
+these extreme low hweight donations shouldn't affect work conservation in
+any meaningful way.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Fixes: f1de2439ec43 ("blk-iocost: revamp donation amount determination")
+Cc: stable@vger.kernel.org # v5.10+
+Link: https://lore.kernel.org/r/Ybfh86iSvpWKxhVM@slm.duckdns.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/blk-iocost.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/block/blk-iocost.c
++++ b/block/blk-iocost.c
+@@ -2246,7 +2246,14 @@ static void ioc_timer_fn(struct timer_li
+ hwm = current_hweight_max(iocg);
+ new_hwi = hweight_after_donation(iocg, old_hwi, hwm,
+ usage, &now);
+- if (new_hwi < hwm) {
++ /*
++ * Donation calculation assumes hweight_after_donation
++ * to be positive, a condition that a donor w/ hwa < 2
++ * can't meet. Don't bother with donation if hwa is
++ * below 2. It's not gonna make a meaningful difference
++ * anyway.
++ */
++ if (new_hwi < hwm && hwa >= 2) {
+ iocg->hweight_donating = hwa;
+ iocg->hweight_after_donation = new_hwi;
+ list_add(&iocg->surplus_list, &surpluses);
--- /dev/null
+From 5da5231bb47864e5dd6c6731151e98b6ee498827 Mon Sep 17 00:00:00 2001
+From: George Kennedy <george.kennedy@oracle.com>
+Date: Tue, 14 Dec 2021 09:45:10 -0500
+Subject: libata: if T_LENGTH is zero, dma direction should be DMA_NONE
+
+From: George Kennedy <george.kennedy@oracle.com>
+
+commit 5da5231bb47864e5dd6c6731151e98b6ee498827 upstream.
+
+Avoid data corruption by rejecting pass-through commands where
+T_LENGTH is zero (No data is transferred) and the dma direction
+is not DMA_NONE.
+
+Cc: <stable@vger.kernel.org>
+Reported-by: syzkaller<syzkaller@googlegroups.com>
+Signed-off-by: George Kennedy<george.kennedy@oracle.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-scsi.c | 15 +++++++++++++--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+--- a/drivers/ata/libata-scsi.c
++++ b/drivers/ata/libata-scsi.c
+@@ -2870,8 +2870,19 @@ static unsigned int ata_scsi_pass_thru(s
+ goto invalid_fld;
+ }
+
+- if (ata_is_ncq(tf->protocol) && (cdb[2 + cdb_offset] & 0x3) == 0)
+- tf->protocol = ATA_PROT_NCQ_NODATA;
++ if ((cdb[2 + cdb_offset] & 0x3) == 0) {
++ /*
++ * When T_LENGTH is zero (No data is transferred), dir should
++ * be DMA_NONE.
++ */
++ if (scmd->sc_data_direction != DMA_NONE) {
++ fp = 2 + cdb_offset;
++ goto invalid_fld;
++ }
++
++ if (ata_is_ncq(tf->protocol))
++ tf->protocol = ATA_PROT_NCQ_NODATA;
++ }
+
+ /* enable LBA */
+ tf->flags |= ATA_TFLAG_LBA;
--- /dev/null
+From 94185adbfad56815c2c8401e16d81bdb74a79201 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 14 Dec 2021 12:42:14 +0100
+Subject: PCI/MSI: Clear PCI_MSIX_FLAGS_MASKALL on error
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 94185adbfad56815c2c8401e16d81bdb74a79201 upstream.
+
+PCI_MSIX_FLAGS_MASKALL is set in the MSI-X control register at MSI-X
+interrupt setup time. It's cleared on success, but the error handling path
+only clears the PCI_MSIX_FLAGS_ENABLE bit.
+
+That's incorrect as the reset state of the PCI_MSIX_FLAGS_MASKALL bit is
+zero. That can be observed via lspci:
+
+ Capabilities: [b0] MSI-X: Enable- Count=67 Masked+
+
+Clear the bit in the error path to restore the reset state.
+
+Fixes: 438553958ba1 ("PCI/MSI: Enable and mask MSI-X early")
+Reported-by: Stefan Roese <sr@denx.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Stefan Roese <sr@denx.de>
+Cc: linux-pci@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Michal Simek <michal.simek@xilinx.com>
+Cc: Marek Vasut <marex@denx.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/87tufevoqx.ffs@tglx
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/msi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pci/msi.c
++++ b/drivers/pci/msi.c
+@@ -879,7 +879,7 @@ out_free:
+ free_msi_irqs(dev);
+
+ out_disable:
+- pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
++ pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL | PCI_MSIX_FLAGS_ENABLE, 0);
+
+ return ret;
+ }
--- /dev/null
+From 83dbf898a2d45289be875deb580e93050ba67529 Mon Sep 17 00:00:00 2001
+From: Stefan Roese <sr@denx.de>
+Date: Tue, 14 Dec 2021 12:49:32 +0100
+Subject: PCI/MSI: Mask MSI-X vectors only on success
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stefan Roese <sr@denx.de>
+
+commit 83dbf898a2d45289be875deb580e93050ba67529 upstream.
+
+Masking all unused MSI-X entries is done to ensure that a crash kernel
+starts from a clean slate, which correponds to the reset state of the
+device as defined in the PCI-E specificion 3.0 and later:
+
+ Vector Control for MSI-X Table Entries
+ --------------------------------------
+
+ "00: Mask bit: When this bit is set, the function is prohibited from
+ sending a message using this MSI-X Table entry.
+ ...
+ This bit’s state after reset is 1 (entry is masked)."
+
+A Marvell NVME device fails to deliver MSI interrupts after trying to
+enable MSI-X interrupts due to that masking. It seems to take the MSI-X
+mask bits into account even when MSI-X is disabled.
+
+While not specification compliant, this can be cured by moving the masking
+into the success path, so that the MSI-X table entries stay in device reset
+state when the MSI-X setup fails.
+
+[ tglx: Move it into the success path, add comment and amend changelog ]
+
+Fixes: aa8092c1d1f1 ("PCI/MSI: Mask all unused MSI-X entries")
+Signed-off-by: Stefan Roese <sr@denx.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: linux-pci@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Michal Simek <michal.simek@xilinx.com>
+Cc: Marek Vasut <marex@denx.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20211210161025.3287927-1-sr@denx.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/msi.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/drivers/pci/msi.c
++++ b/drivers/pci/msi.c
+@@ -828,9 +828,6 @@ static int msix_capability_init(struct p
+ goto out_disable;
+ }
+
+- /* Ensure that all table entries are masked. */
+- msix_mask_all(base, tsize);
+-
+ ret = msix_setup_entries(dev, base, entries, nvec, affd);
+ if (ret)
+ goto out_disable;
+@@ -853,6 +850,16 @@ static int msix_capability_init(struct p
+ /* Set MSI-X enabled bits and unmask the function */
+ pci_intx_for_msi(dev, 0);
+ dev->msix_enabled = 1;
++
++ /*
++ * Ensure that all table entries are masked to prevent
++ * stale entries from firing in a crash kernel.
++ *
++ * Done late to deal with a broken Marvell NVME device
++ * which takes the MSI-X mask bits into account even
++ * when MSI-X is disabled, which prevents MSI delivery.
++ */
++ msix_mask_all(base, tsize);
+ pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
+
+ pcibios_free_irq(dev);
--- /dev/null
+From 6c33ff728812aa18792afffaf2c9873b898e7512 Mon Sep 17 00:00:00 2001
+From: "Ji-Ze Hong (Peter Hong)" <hpeter@gmail.com>
+Date: Wed, 15 Dec 2021 15:58:35 +0800
+Subject: serial: 8250_fintek: Fix garbled text for console
+
+From: Ji-Ze Hong (Peter Hong) <hpeter@gmail.com>
+
+commit 6c33ff728812aa18792afffaf2c9873b898e7512 upstream.
+
+Commit fab8a02b73eb ("serial: 8250_fintek: Enable high speed mode on Fintek F81866")
+introduced support to use high baudrate with Fintek SuperIO UARTs. It'll
+change clocksources when the UART probed.
+
+But when user add kernel parameter "console=ttyS0,115200 console=tty0" to make
+the UART as console output, the console will output garbled text after the
+following kernel message.
+
+[ 3.681188] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
+
+The issue is occurs in following step:
+ probe_setup_port() -> fintek_8250_goto_highspeed()
+
+It change clocksource from 115200 to 921600 with wrong time, it should change
+clocksource in set_termios() not in probed. The following 3 patches are
+implemented change clocksource in fintek_8250_set_termios().
+
+Commit 58178914ae5b ("serial: 8250_fintek: UART dynamic clocksource on Fintek F81216H")
+Commit 195638b6d44f ("serial: 8250_fintek: UART dynamic clocksource on Fintek F81866")
+Commit 423d9118c624 ("serial: 8250_fintek: Add F81966 Support")
+
+Due to the high baud rate had implemented above 3 patches and the patch
+Commit fab8a02b73eb ("serial: 8250_fintek: Enable high speed mode on Fintek F81866")
+is bugged, So this patch will remove it.
+
+Fixes: fab8a02b73eb ("serial: 8250_fintek: Enable high speed mode on Fintek F81866")
+Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
+Link: https://lore.kernel.org/r/20211215075835.2072-1-hpeter+linux_kernel@gmail.com
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_fintek.c | 20 --------------------
+ 1 file changed, 20 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_fintek.c
++++ b/drivers/tty/serial/8250/8250_fintek.c
+@@ -290,25 +290,6 @@ static void fintek_8250_set_max_fifo(str
+ }
+ }
+
+-static void fintek_8250_goto_highspeed(struct uart_8250_port *uart,
+- struct fintek_8250 *pdata)
+-{
+- sio_write_reg(pdata, LDN, pdata->index);
+-
+- switch (pdata->pid) {
+- case CHIP_ID_F81966:
+- case CHIP_ID_F81866: /* set uart clock for high speed serial mode */
+- sio_write_mask_reg(pdata, F81866_UART_CLK,
+- F81866_UART_CLK_MASK,
+- F81866_UART_CLK_14_769MHZ);
+-
+- uart->port.uartclk = 921600 * 16;
+- break;
+- default: /* leave clock speed untouched */
+- break;
+- }
+-}
+-
+ static void fintek_8250_set_termios(struct uart_port *port,
+ struct ktermios *termios,
+ struct ktermios *old)
+@@ -430,7 +411,6 @@ static int probe_setup_port(struct finte
+
+ fintek_8250_set_irq_mode(pdata, level_mode);
+ fintek_8250_set_max_fifo(pdata);
+- fintek_8250_goto_highspeed(uart, pdata);
+
+ fintek_8250_exit_key(addr[i]);
+
usb-gadget-brequesttype-is-a-bitfield-not-a-enum.patch
revert-usb-early-convert-to-readl_poll_timeout_atomi.patch
kvm-x86-drop-guest-cpuid-check-for-host-initiated-wr.patch
+tty-n_hdlc-make-n_hdlc_tty_wakeup-asynchronous.patch
+usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch
+usb-dwc2-fix-stm-id-vbus-detection-startup-delay-in-dwc2_driver_probe.patch
+pci-msi-clear-pci_msix_flags_maskall-on-error.patch
+pci-msi-mask-msi-x-vectors-only-on-success.patch
+usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch
+usb-serial-cp210x-fix-cp2105-gpio-registration.patch
+usb-serial-option-add-telit-fn990-compositions.patch
+btrfs-fix-memory-leak-in-__add_inode_ref.patch
+btrfs-fix-double-free-of-anon_dev-after-failure-to-create-subvolume.patch
+zonefs-add-module_alias_fs.patch
+iocost-fix-divide-by-zero-on-donation-from-low-hweight-cgroup.patch
+serial-8250_fintek-fix-garbled-text-for-console.patch
+timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch
+libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch
+drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch
--- /dev/null
+From 4e8c11b6b3f0b6a283e898344f154641eda94266 Mon Sep 17 00:00:00 2001
+From: Yu Liao <liaoyu15@huawei.com>
+Date: Mon, 13 Dec 2021 21:57:27 +0800
+Subject: timekeeping: Really make sure wall_to_monotonic isn't positive
+
+From: Yu Liao <liaoyu15@huawei.com>
+
+commit 4e8c11b6b3f0b6a283e898344f154641eda94266 upstream.
+
+Even after commit e1d7ba873555 ("time: Always make sure wall_to_monotonic
+isn't positive") it is still possible to make wall_to_monotonic positive
+by running the following code:
+
+ int main(void)
+ {
+ struct timespec time;
+
+ clock_gettime(CLOCK_MONOTONIC, &time);
+ time.tv_nsec = 0;
+ clock_settime(CLOCK_REALTIME, &time);
+ return 0;
+ }
+
+The reason is that the second parameter of timespec64_compare(), ts_delta,
+may be unnormalized because the delta is calculated with an open coded
+substraction which causes the comparison of tv_sec to yield the wrong
+result:
+
+ wall_to_monotonic = { .tv_sec = -10, .tv_nsec = 900000000 }
+ ts_delta = { .tv_sec = -9, .tv_nsec = -900000000 }
+
+That makes timespec64_compare() claim that wall_to_monotonic < ts_delta,
+but actually the result should be wall_to_monotonic > ts_delta.
+
+After normalization, the result of timespec64_compare() is correct because
+the tv_sec comparison is not longer misleading:
+
+ wall_to_monotonic = { .tv_sec = -10, .tv_nsec = 900000000 }
+ ts_delta = { .tv_sec = -10, .tv_nsec = 100000000 }
+
+Use timespec64_sub() to ensure that ts_delta is normalized, which fixes the
+issue.
+
+Fixes: e1d7ba873555 ("time: Always make sure wall_to_monotonic isn't positive")
+Signed-off-by: Yu Liao <liaoyu15@huawei.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20211213135727.1656662-1-liaoyu15@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/time/timekeeping.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/kernel/time/timekeeping.c
++++ b/kernel/time/timekeeping.c
+@@ -1310,8 +1310,7 @@ int do_settimeofday64(const struct times
+ timekeeping_forward_now(tk);
+
+ xt = tk_xtime(tk);
+- ts_delta.tv_sec = ts->tv_sec - xt.tv_sec;
+- ts_delta.tv_nsec = ts->tv_nsec - xt.tv_nsec;
++ ts_delta = timespec64_sub(*ts, xt);
+
+ if (timespec64_compare(&tk->wall_to_monotonic, &ts_delta) > 0) {
+ ret = -EINVAL;
--- /dev/null
+From 1ee33b1ca2b8dabfcc17198ffd049a6b55674a86 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Date: Wed, 15 Dec 2021 20:52:40 +0900
+Subject: tty: n_hdlc: make n_hdlc_tty_wakeup() asynchronous
+
+From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+
+commit 1ee33b1ca2b8dabfcc17198ffd049a6b55674a86 upstream.
+
+syzbot is reporting that an unprivileged user who logged in from tty
+console can crash the system using a reproducer shown below [1], for
+n_hdlc_tty_wakeup() is synchronously calling n_hdlc_send_frames().
+
+----------
+ #include <sys/ioctl.h>
+ #include <unistd.h>
+
+ int main(int argc, char *argv[])
+ {
+ const int disc = 0xd;
+
+ ioctl(1, TIOCSETD, &disc);
+ while (1) {
+ ioctl(1, TCXONC, 0);
+ write(1, "", 1);
+ ioctl(1, TCXONC, 1); /* Kernel panic - not syncing: scheduling while atomic */
+ }
+ }
+----------
+
+Linus suspected that "struct tty_ldisc"->ops->write_wakeup() must not
+sleep, and Jiri confirmed it from include/linux/tty_ldisc.h. Thus, defer
+n_hdlc_send_frames() from n_hdlc_tty_wakeup() to a WQ context like
+net/nfc/nci/uart.c does.
+
+Link: https://syzkaller.appspot.com/bug?extid=5f47a8cea6a12b77a876 [1]
+Reported-by: syzbot <syzbot+5f47a8cea6a12b77a876@syzkaller.appspotmail.com>
+Cc: stable <stable@vger.kernel.org>
+Analyzed-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
+Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
+Confirmed-by: Jiri Slaby <jirislaby@kernel.org>
+Reviewed-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Link: https://lore.kernel.org/r/40de8b7e-a3be-4486-4e33-1b1d1da452f8@i-love.sakura.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/n_hdlc.c | 23 ++++++++++++++++++++++-
+ 1 file changed, 22 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/n_hdlc.c
++++ b/drivers/tty/n_hdlc.c
+@@ -139,6 +139,8 @@ struct n_hdlc {
+ struct n_hdlc_buf_list rx_buf_list;
+ struct n_hdlc_buf_list tx_free_buf_list;
+ struct n_hdlc_buf_list rx_free_buf_list;
++ struct work_struct write_work;
++ struct tty_struct *tty_for_write_work;
+ };
+
+ /*
+@@ -153,6 +155,7 @@ static struct n_hdlc_buf *n_hdlc_buf_get
+ /* Local functions */
+
+ static struct n_hdlc *n_hdlc_alloc(void);
++static void n_hdlc_tty_write_work(struct work_struct *work);
+
+ /* max frame size for memory allocations */
+ static int maxframe = 4096;
+@@ -209,6 +212,8 @@ static void n_hdlc_tty_close(struct tty_
+ wake_up_interruptible(&tty->read_wait);
+ wake_up_interruptible(&tty->write_wait);
+
++ cancel_work_sync(&n_hdlc->write_work);
++
+ n_hdlc_free_buf_list(&n_hdlc->rx_free_buf_list);
+ n_hdlc_free_buf_list(&n_hdlc->tx_free_buf_list);
+ n_hdlc_free_buf_list(&n_hdlc->rx_buf_list);
+@@ -240,6 +245,8 @@ static int n_hdlc_tty_open(struct tty_st
+ return -ENFILE;
+ }
+
++ INIT_WORK(&n_hdlc->write_work, n_hdlc_tty_write_work);
++ n_hdlc->tty_for_write_work = tty;
+ tty->disc_data = n_hdlc;
+ tty->receive_room = 65536;
+
+@@ -334,6 +341,20 @@ check_again:
+ } /* end of n_hdlc_send_frames() */
+
+ /**
++ * n_hdlc_tty_write_work - Asynchronous callback for transmit wakeup
++ * @work: pointer to work_struct
++ *
++ * Called when low level device driver can accept more send data.
++ */
++static void n_hdlc_tty_write_work(struct work_struct *work)
++{
++ struct n_hdlc *n_hdlc = container_of(work, struct n_hdlc, write_work);
++ struct tty_struct *tty = n_hdlc->tty_for_write_work;
++
++ n_hdlc_send_frames(n_hdlc, tty);
++} /* end of n_hdlc_tty_write_work() */
++
++/**
+ * n_hdlc_tty_wakeup - Callback for transmit wakeup
+ * @tty: pointer to associated tty instance data
+ *
+@@ -343,7 +364,7 @@ static void n_hdlc_tty_wakeup(struct tty
+ {
+ struct n_hdlc *n_hdlc = tty->disc_data;
+
+- n_hdlc_send_frames(n_hdlc, tty);
++ schedule_work(&n_hdlc->write_work);
+ } /* end of n_hdlc_tty_wakeup() */
+
+ /**
--- /dev/null
+From fac6bf87c55f7f0733efb0375565fb6a50cf2caf Mon Sep 17 00:00:00 2001
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Date: Tue, 7 Dec 2021 13:45:10 +0100
+Subject: usb: dwc2: fix STM ID/VBUS detection startup delay in dwc2_driver_probe
+
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+commit fac6bf87c55f7f0733efb0375565fb6a50cf2caf upstream.
+
+When activate_stm_id_vb_detection is enabled, ID and Vbus detection relies
+on sensing comparators. This detection needs time to stabilize.
+A delay was already applied in dwc2_resume() when reactivating the
+detection, but it wasn't done in dwc2_probe().
+This patch adds delay after enabling STM ID/VBUS detection. Then, ID state
+is good when initializing gadget and host, and avoid to get a wrong
+Connector ID Status Change interrupt.
+
+Fixes: a415083a11cc ("usb: dwc2: add support for STM32MP15 SoCs USB OTG HS and FS")
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
+Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Link: https://lore.kernel.org/r/20211207124510.268841-1-amelie.delaunay@foss.st.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/dwc2/platform.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/dwc2/platform.c
++++ b/drivers/usb/dwc2/platform.c
+@@ -542,6 +542,9 @@ static int dwc2_driver_probe(struct plat
+ ggpio |= GGPIO_STM32_OTG_GCCFG_IDEN;
+ ggpio |= GGPIO_STM32_OTG_GCCFG_VBDEN;
+ dwc2_writel(hsotg, ggpio, GGPIO);
++
++ /* ID/VBUS detection startup time */
++ usleep_range(5000, 7000);
+ }
+
+ retval = dwc2_drd_init(hsotg);
--- /dev/null
+From 0ad3bd562bb91853b9f42bda145b5db6255aee90 Mon Sep 17 00:00:00 2001
+From: Jimmy Wang <wangjm221@gmail.com>
+Date: Tue, 14 Dec 2021 09:26:50 +0800
+Subject: USB: NO_LPM quirk Lenovo USB-C to Ethernet Adapher(RTL8153-04)
+
+From: Jimmy Wang <wangjm221@gmail.com>
+
+commit 0ad3bd562bb91853b9f42bda145b5db6255aee90 upstream.
+
+This device doesn't work well with LPM, losing connectivity intermittently.
+Disable LPM to resolve the issue.
+
+Reviewed-by: <markpearson@lenovo.com>
+Signed-off-by: Jimmy Wang <wangjm221@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211214012652.4898-1-wangjm221@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/quirks.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/core/quirks.c
++++ b/drivers/usb/core/quirks.c
+@@ -435,6 +435,9 @@ static const struct usb_device_id usb_qu
+ { USB_DEVICE(0x1532, 0x0116), .driver_info =
+ USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+
++ /* Lenovo USB-C to Ethernet Adapter RTL8153-04 */
++ { USB_DEVICE(0x17ef, 0x720c), .driver_info = USB_QUIRK_NO_LPM },
++
+ /* Lenovo Powered USB-C Travel Hub (4X90S92381, RTL8153 GigE) */
+ { USB_DEVICE(0x17ef, 0x721e), .driver_info = USB_QUIRK_NO_LPM },
+
--- /dev/null
+From 83b67041f3eaf33f98a075249aa7f4c7617c2f85 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 26 Nov 2021 10:43:48 +0100
+Subject: USB: serial: cp210x: fix CP2105 GPIO registration
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 83b67041f3eaf33f98a075249aa7f4c7617c2f85 upstream.
+
+When generalising GPIO support and adding support for CP2102N, the GPIO
+registration for some CP2105 devices accidentally broke. Specifically,
+when all the pins of a port are in "modem" mode, and thus unavailable
+for GPIO use, the GPIO chip would now be registered without having
+initialised the number of GPIO lines. This would in turn be rejected by
+gpiolib and some errors messages would be printed (but importantly probe
+would still succeed).
+
+Fix this by initialising the number of GPIO lines before registering the
+GPIO chip.
+
+Note that as for the other device types, and as when all CP2105 pins are
+muxed for LED function, the GPIO chip is registered also when no pins
+are available for GPIO use.
+
+Reported-by: Maarten Brock <m.brock@vanmierlo.com>
+Link: https://lore.kernel.org/r/5eb560c81d2ea1a2b4602a92d9f48a89@vanmierlo.com
+Fixes: c8acfe0aadbe ("USB: serial: cp210x: implement GPIO support for CP2102N")
+Cc: stable@vger.kernel.org # 4.19
+Cc: Karoly Pados <pados@pados.hu>
+Link: https://lore.kernel.org/r/20211126094348.31698-1-johan@kernel.org
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Tested-by: Maarten Brock <m.brock@vanmierlo.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/cp210x.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/serial/cp210x.c
++++ b/drivers/usb/serial/cp210x.c
+@@ -1750,6 +1750,8 @@ static int cp2105_gpioconf_init(struct u
+
+ /* 2 banks of GPIO - One for the pins taken from each serial port */
+ if (intf_num == 0) {
++ priv->gc.ngpio = 2;
++
+ if (mode.eci == CP210X_PIN_MODE_MODEM) {
+ /* mark all GPIOs of this interface as reserved */
+ priv->gpio_altfunc = 0xff;
+@@ -1760,8 +1762,9 @@ static int cp2105_gpioconf_init(struct u
+ priv->gpio_pushpull = (u8)((le16_to_cpu(config.gpio_mode) &
+ CP210X_ECI_GPIO_MODE_MASK) >>
+ CP210X_ECI_GPIO_MODE_OFFSET);
+- priv->gc.ngpio = 2;
+ } else if (intf_num == 1) {
++ priv->gc.ngpio = 3;
++
+ if (mode.sci == CP210X_PIN_MODE_MODEM) {
+ /* mark all GPIOs of this interface as reserved */
+ priv->gpio_altfunc = 0xff;
+@@ -1772,7 +1775,6 @@ static int cp2105_gpioconf_init(struct u
+ priv->gpio_pushpull = (u8)((le16_to_cpu(config.gpio_mode) &
+ CP210X_SCI_GPIO_MODE_MASK) >>
+ CP210X_SCI_GPIO_MODE_OFFSET);
+- priv->gc.ngpio = 3;
+ } else {
+ return -ENODEV;
+ }
--- /dev/null
+From 2b503c8598d1b232e7fc7526bce9326d92331541 Mon Sep 17 00:00:00 2001
+From: Daniele Palmas <dnlplm@gmail.com>
+Date: Fri, 10 Dec 2021 11:07:14 +0100
+Subject: USB: serial: option: add Telit FN990 compositions
+
+From: Daniele Palmas <dnlplm@gmail.com>
+
+commit 2b503c8598d1b232e7fc7526bce9326d92331541 upstream.
+
+Add the following Telit FN990 compositions:
+
+0x1070: tty, adb, rmnet, tty, tty, tty, tty
+0x1071: tty, adb, mbim, tty, tty, tty, tty
+0x1072: rndis, tty, adb, tty, tty, tty, tty
+0x1073: tty, adb, ecm, tty, tty, tty, tty
+
+Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
+Link: https://lore.kernel.org/r/20211210100714.22587-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 | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/usb/serial/option.c
++++ b/drivers/usb/serial/option.c
+@@ -1219,6 +1219,14 @@ static const struct usb_device_id option
+ .driver_info = NCTRL(2) | RSVD(3) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1063, 0xff), /* Telit LN920 (ECM) */
+ .driver_info = NCTRL(0) | RSVD(1) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1070, 0xff), /* Telit FN990 (rmnet) */
++ .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1071, 0xff), /* Telit FN990 (MBIM) */
++ .driver_info = NCTRL(0) | RSVD(1) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1072, 0xff), /* Telit FN990 (RNDIS) */
++ .driver_info = NCTRL(2) | RSVD(3) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1073, 0xff), /* Telit FN990 (ECM) */
++ .driver_info = NCTRL(0) | RSVD(1) },
+ { 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),
--- /dev/null
+From f886d4fbb7c97b8f5f447c92d2dab99c841803c0 Mon Sep 17 00:00:00 2001
+From: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
+Date: Wed, 15 Dec 2021 15:02:16 +0530
+Subject: usb: xhci: Extend support for runtime power management for AMD's Yellow carp.
+
+From: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
+
+commit f886d4fbb7c97b8f5f447c92d2dab99c841803c0 upstream.
+
+AMD's Yellow Carp platform has few more XHCI controllers,
+enable the runtime power management support for the same.
+
+Signed-off-by: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211215093216.1839065-1-Nehal-Bakulchandra.shah@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-pci.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -70,6 +70,8 @@
+ #define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_4 0x161e
+ #define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_5 0x15d6
+ #define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_6 0x15d7
++#define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_7 0x161c
++#define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_8 0x161f
+
+ #define PCI_DEVICE_ID_ASMEDIA_1042_XHCI 0x1042
+ #define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142
+@@ -325,7 +327,9 @@ static void xhci_pci_quirks(struct devic
+ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_3 ||
+ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_4 ||
+ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_5 ||
+- pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_6))
++ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_6 ||
++ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_7 ||
++ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_8))
+ xhci->quirks |= XHCI_DEFAULT_PM_RUNTIME_ALLOW;
+
+ if (xhci->quirks & XHCI_RESET_ON_RESUME)
--- /dev/null
+From 8ffea2599f63fdbee968b894eab78170abf3ec2c Mon Sep 17 00:00:00 2001
+From: Naohiro Aota <naohiro.aota@wdc.com>
+Date: Fri, 17 Dec 2021 15:15:45 +0900
+Subject: zonefs: add MODULE_ALIAS_FS
+
+From: Naohiro Aota <naohiro.aota@wdc.com>
+
+commit 8ffea2599f63fdbee968b894eab78170abf3ec2c upstream.
+
+Add MODULE_ALIAS_FS() to load the module automatically when you do "mount
+-t zonefs".
+
+Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system")
+Cc: stable <stable@vger.kernel.org> # 5.6+
+Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
+Reviewed-by: Johannes Thumshirn <jth@kernel.org>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/zonefs/super.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/zonefs/super.c
++++ b/fs/zonefs/super.c
+@@ -1799,5 +1799,6 @@ static void __exit zonefs_exit(void)
+ MODULE_AUTHOR("Damien Le Moal");
+ MODULE_DESCRIPTION("Zone file system for zoned block devices");
+ MODULE_LICENSE("GPL");
++MODULE_ALIAS_FS("zonefs");
+ module_init(zonefs_init);
+ module_exit(zonefs_exit);
projects / thirdparty / kernel / stable-queue.git / commitdiff
