From: Greg Kroah-Hartman Date: Mon, 20 Dec 2021 09:44:37 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v4.4.296~37 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=71697e04dd77adf9f6c44097cfce107117856eb1;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: btrfs-fix-double-free-of-anon_dev-after-failure-to-create-subvolume.patch btrfs-fix-memory-leak-in-__add_inode_ref.patch drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch iocost-fix-divide-by-zero-on-donation-from-low-hweight-cgroup.patch libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch pci-msi-clear-pci_msix_flags_maskall-on-error.patch pci-msi-mask-msi-x-vectors-only-on-success.patch serial-8250_fintek-fix-garbled-text-for-console.patch timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch tty-n_hdlc-make-n_hdlc_tty_wakeup-asynchronous.patch usb-dwc2-fix-stm-id-vbus-detection-startup-delay-in-dwc2_driver_probe.patch usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch usb-serial-cp210x-fix-cp2105-gpio-registration.patch usb-serial-option-add-telit-fn990-compositions.patch usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch zonefs-add-module_alias_fs.patch --- diff --git a/queue-5.10/btrfs-fix-double-free-of-anon_dev-after-failure-to-create-subvolume.patch b/queue-5.10/btrfs-fix-double-free-of-anon_dev-after-failure-to-create-subvolume.patch new file mode 100644 index 00000000000..88d79884762 --- /dev/null +++ b/queue-5.10/btrfs-fix-double-free-of-anon_dev-after-failure-to-create-subvolume.patch @@ -0,0 +1,62 @@ +From 33fab972497ae66822c0b6846d4f9382938575b6 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +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 + +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 +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-5.10/btrfs-fix-memory-leak-in-__add_inode_ref.patch b/queue-5.10/btrfs-fix-memory-leak-in-__add_inode_ref.patch new file mode 100644 index 00000000000..4f69d8d6f59 --- /dev/null +++ b/queue-5.10/btrfs-fix-memory-leak-in-__add_inode_ref.patch @@ -0,0 +1,80 @@ +From f35838a6930296fc1988764cfa54cb3f705c0665 Mon Sep 17 00:00:00 2001 +From: Jianglei Nie +Date: Thu, 9 Dec 2021 14:56:31 +0800 +Subject: btrfs: fix memory leak in __add_inode_ref() + +From: Jianglei Nie + +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 +Reviewed-by: Filipe Manana +Signed-off-by: Jianglei Nie +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.10/drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch b/queue-5.10/drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch new file mode 100644 index 00000000000..a80db2dc112 --- /dev/null +++ b/queue-5.10/drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch @@ -0,0 +1,34 @@ +From f3a8076eb28cae1553958c629aecec479394bbe2 Mon Sep 17 00:00:00 2001 +From: Le Ma +Date: Sat, 4 Dec 2021 18:59:08 +0800 +Subject: drm/amdgpu: correct register access for RLC_JUMP_TABLE_RESTORE + +From: Le Ma + +commit f3a8076eb28cae1553958c629aecec479394bbe2 upstream. + +should count on GC IP base address + +Signed-off-by: Le Ma +Signed-off-by: Hawking Zhang +Reviewed-by: Hawking Zhang +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + } diff --git a/queue-5.10/iocost-fix-divide-by-zero-on-donation-from-low-hweight-cgroup.patch b/queue-5.10/iocost-fix-divide-by-zero-on-donation-from-low-hweight-cgroup.patch new file mode 100644 index 00000000000..c8f2a618d79 --- /dev/null +++ b/queue-5.10/iocost-fix-divide-by-zero-on-donation-from-low-hweight-cgroup.patch @@ -0,0 +1,69 @@ +From edaa26334c117a584add6053f48d63a988d25a6e Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Mon, 13 Dec 2021 14:14:43 -1000 +Subject: iocost: Fix divide-by-zero on donation from low hweight cgroup + +From: Tejun Heo + +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: + + 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 +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch b/queue-5.10/libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch new file mode 100644 index 00000000000..7520d739493 --- /dev/null +++ b/queue-5.10/libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch @@ -0,0 +1,46 @@ +From 5da5231bb47864e5dd6c6731151e98b6ee498827 Mon Sep 17 00:00:00 2001 +From: George Kennedy +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 + +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: +Reported-by: syzkaller +Signed-off-by: George Kennedy +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.10/pci-msi-clear-pci_msix_flags_maskall-on-error.patch b/queue-5.10/pci-msi-clear-pci_msix_flags_maskall-on-error.patch new file mode 100644 index 00000000000..85cfcba148d --- /dev/null +++ b/queue-5.10/pci-msi-clear-pci_msix_flags_maskall-on-error.patch @@ -0,0 +1,46 @@ +From 94185adbfad56815c2c8401e16d81bdb74a79201 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Tue, 14 Dec 2021 12:42:14 +0100 +Subject: PCI/MSI: Clear PCI_MSIX_FLAGS_MASKALL on error + +From: Thomas Gleixner + +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 +Signed-off-by: Thomas Gleixner +Tested-by: Stefan Roese +Cc: linux-pci@vger.kernel.org +Cc: Bjorn Helgaas +Cc: Michal Simek +Cc: Marek Vasut +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/87tufevoqx.ffs@tglx +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.10/pci-msi-mask-msi-x-vectors-only-on-success.patch b/queue-5.10/pci-msi-mask-msi-x-vectors-only-on-success.patch new file mode 100644 index 00000000000..1c9abe44d68 --- /dev/null +++ b/queue-5.10/pci-msi-mask-msi-x-vectors-only-on-success.patch @@ -0,0 +1,77 @@ +From 83dbf898a2d45289be875deb580e93050ba67529 Mon Sep 17 00:00:00 2001 +From: Stefan Roese +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 + +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 +Signed-off-by: Thomas Gleixner +Cc: linux-pci@vger.kernel.org +Cc: Bjorn Helgaas +Cc: Michal Simek +Cc: Marek Vasut +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20211210161025.3287927-1-sr@denx.de +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/serial-8250_fintek-fix-garbled-text-for-console.patch b/queue-5.10/serial-8250_fintek-fix-garbled-text-for-console.patch new file mode 100644 index 00000000000..eef2f9cfdfa --- /dev/null +++ b/queue-5.10/serial-8250_fintek-fix-garbled-text-for-console.patch @@ -0,0 +1,79 @@ +From 6c33ff728812aa18792afffaf2c9873b898e7512 Mon Sep 17 00:00:00 2001 +From: "Ji-Ze Hong (Peter Hong)" +Date: Wed, 15 Dec 2021 15:58:35 +0800 +Subject: serial: 8250_fintek: Fix garbled text for console + +From: Ji-Ze Hong (Peter Hong) + +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) +Link: https://lore.kernel.org/r/20211215075835.2072-1-hpeter+linux_kernel@gmail.com +Cc: stable +Signed-off-by: Greg Kroah-Hartman +--- + 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]); + diff --git a/queue-5.10/series b/queue-5.10/series index 774b2c010ae..b0411f4547a 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -64,3 +64,19 @@ powerpc-85xx-fix-oops-when-config_fsl_pmc-n.patch 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 diff --git a/queue-5.10/timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch b/queue-5.10/timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch new file mode 100644 index 00000000000..5f19417c399 --- /dev/null +++ b/queue-5.10/timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch @@ -0,0 +1,65 @@ +From 4e8c11b6b3f0b6a283e898344f154641eda94266 Mon Sep 17 00:00:00 2001 +From: Yu Liao +Date: Mon, 13 Dec 2021 21:57:27 +0800 +Subject: timekeeping: Really make sure wall_to_monotonic isn't positive + +From: Yu Liao + +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 +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20211213135727.1656662-1-liaoyu15@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.10/tty-n_hdlc-make-n_hdlc_tty_wakeup-asynchronous.patch b/queue-5.10/tty-n_hdlc-make-n_hdlc_tty_wakeup-asynchronous.patch new file mode 100644 index 00000000000..73da9efee10 --- /dev/null +++ b/queue-5.10/tty-n_hdlc-make-n_hdlc_tty_wakeup-asynchronous.patch @@ -0,0 +1,116 @@ +From 1ee33b1ca2b8dabfcc17198ffd049a6b55674a86 Mon Sep 17 00:00:00 2001 +From: Tetsuo Handa +Date: Wed, 15 Dec 2021 20:52:40 +0900 +Subject: tty: n_hdlc: make n_hdlc_tty_wakeup() asynchronous + +From: Tetsuo Handa + +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 + #include + + 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 +Cc: stable +Analyzed-by: Fabio M. De Francesco +Suggested-by: Linus Torvalds +Confirmed-by: Jiri Slaby +Reviewed-by: Fabio M. De Francesco +Signed-off-by: Tetsuo Handa +Link: https://lore.kernel.org/r/40de8b7e-a3be-4486-4e33-1b1d1da452f8@i-love.sakura.ne.jp +Signed-off-by: Greg Kroah-Hartman +--- + 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() */ + + /** diff --git a/queue-5.10/usb-dwc2-fix-stm-id-vbus-detection-startup-delay-in-dwc2_driver_probe.patch b/queue-5.10/usb-dwc2-fix-stm-id-vbus-detection-startup-delay-in-dwc2_driver_probe.patch new file mode 100644 index 00000000000..c129e2ede03 --- /dev/null +++ b/queue-5.10/usb-dwc2-fix-stm-id-vbus-detection-startup-delay-in-dwc2_driver_probe.patch @@ -0,0 +1,39 @@ +From fac6bf87c55f7f0733efb0375565fb6a50cf2caf Mon Sep 17 00:00:00 2001 +From: Amelie Delaunay +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 + +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 +Acked-by: Minas Harutyunyan +Signed-off-by: Amelie Delaunay +Link: https://lore.kernel.org/r/20211207124510.268841-1-amelie.delaunay@foss.st.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch b/queue-5.10/usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch new file mode 100644 index 00000000000..26a8002c9d3 --- /dev/null +++ b/queue-5.10/usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch @@ -0,0 +1,33 @@ +From 0ad3bd562bb91853b9f42bda145b5db6255aee90 Mon Sep 17 00:00:00 2001 +From: Jimmy Wang +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 + +commit 0ad3bd562bb91853b9f42bda145b5db6255aee90 upstream. + +This device doesn't work well with LPM, losing connectivity intermittently. +Disable LPM to resolve the issue. + +Reviewed-by: +Signed-off-by: Jimmy Wang +Cc: stable +Link: https://lore.kernel.org/r/20211214012652.4898-1-wangjm221@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 }, + diff --git a/queue-5.10/usb-serial-cp210x-fix-cp2105-gpio-registration.patch b/queue-5.10/usb-serial-cp210x-fix-cp2105-gpio-registration.patch new file mode 100644 index 00000000000..d576560db90 --- /dev/null +++ b/queue-5.10/usb-serial-cp210x-fix-cp2105-gpio-registration.patch @@ -0,0 +1,68 @@ +From 83b67041f3eaf33f98a075249aa7f4c7617c2f85 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 26 Nov 2021 10:43:48 +0100 +Subject: USB: serial: cp210x: fix CP2105 GPIO registration + +From: Johan Hovold + +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 +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 +Link: https://lore.kernel.org/r/20211126094348.31698-1-johan@kernel.org +Reviewed-by: Greg Kroah-Hartman +Tested-by: Maarten Brock +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.10/usb-serial-option-add-telit-fn990-compositions.patch b/queue-5.10/usb-serial-option-add-telit-fn990-compositions.patch new file mode 100644 index 00000000000..1b6302d3fd4 --- /dev/null +++ b/queue-5.10/usb-serial-option-add-telit-fn990-compositions.patch @@ -0,0 +1,42 @@ +From 2b503c8598d1b232e7fc7526bce9326d92331541 Mon Sep 17 00:00:00 2001 +From: Daniele Palmas +Date: Fri, 10 Dec 2021 11:07:14 +0100 +Subject: USB: serial: option: add Telit FN990 compositions + +From: Daniele Palmas + +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 +Link: https://lore.kernel.org/r/20211210100714.22587-1-dnlplm@gmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-5.10/usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch b/queue-5.10/usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch new file mode 100644 index 00000000000..f34f892e566 --- /dev/null +++ b/queue-5.10/usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch @@ -0,0 +1,42 @@ +From f886d4fbb7c97b8f5f447c92d2dab99c841803c0 Mon Sep 17 00:00:00 2001 +From: Nehal Bakulchandra Shah +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 + +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 +Cc: stable +Link: https://lore.kernel.org/r/20211215093216.1839065-1-Nehal-Bakulchandra.shah@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/zonefs-add-module_alias_fs.patch b/queue-5.10/zonefs-add-module_alias_fs.patch new file mode 100644 index 00000000000..09c93965faa --- /dev/null +++ b/queue-5.10/zonefs-add-module_alias_fs.patch @@ -0,0 +1,31 @@ +From 8ffea2599f63fdbee968b894eab78170abf3ec2c Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Fri, 17 Dec 2021 15:15:45 +0900 +Subject: zonefs: add MODULE_ALIAS_FS + +From: Naohiro Aota + +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 # 5.6+ +Signed-off-by: Naohiro Aota +Reviewed-by: Johannes Thumshirn +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + 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);