From 63faea54e8843d1dbddc292cc004eaa7d6c2784e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 11 Apr 2022 09:40:47 +0200 Subject: [PATCH] 5.17-stable patches added patches: highmem-fix-checks-in-__kmap_local_sched_-in-out.patch io_uring-defer-splice-tee-file-validity-check-until-command-issue.patch io_uring-don-t-check-req-file-in-io_fsync_prep.patch lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch mmc-block-check-for-errors-after-write-on-spi.patch mmc-core-fixup-support-for-writeback-cache-for-emmc-and-sd.patch mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch mmc-renesas_sdhi-special-4tap-settings-only-apply-to-hs400.patch mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch scsi-mpt3sas-fix-use-after-free-in-_scsih_expander_node_remove.patch scsi-ufs-ufs-pci-add-support-for-intel-mtl.patch --- ...checks-in-__kmap_local_sched_-in-out.patch | 81 ++++++++++ ...e-validity-check-until-command-issue.patch | 147 ++++++++++++++++++ ...on-t-check-req-file-in-io_fsync_prep.patch | 32 ++++ ...press_safe_partial-read-out-of-bound.patch | 57 +++++++ ...ol_new-leak-in-shared_policy_replace.patch | 51 ++++++ ...-check-for-errors-after-write-on-spi.patch | 93 +++++++++++ ...-for-writeback-cache-for-emmc-and-sd.patch | 73 +++++++++ ...rectly-check-all-elements-of-sg-list.patch | 46 ++++++ ...ttings-when-hs400-tuning-is-complete.patch | 41 +++++ ...al-4tap-settings-only-apply-to-hs400.patch | 38 +++++ ...range_start-end-on-mremap-old_size-0.patch | 45 ++++++ ...-fix-annoying-1.8v-regulator-warning.patch | 49 ++++++ ...-free-in-_scsih_expander_node_remove.patch | 97 ++++++++++++ ...fs-ufs-pci-add-support-for-intel-mtl.patch | 62 ++++++++ queue-5.17/series | 14 ++ 15 files changed, 926 insertions(+) create mode 100644 queue-5.17/highmem-fix-checks-in-__kmap_local_sched_-in-out.patch create mode 100644 queue-5.17/io_uring-defer-splice-tee-file-validity-check-until-command-issue.patch create mode 100644 queue-5.17/io_uring-don-t-check-req-file-in-io_fsync_prep.patch create mode 100644 queue-5.17/lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch create mode 100644 queue-5.17/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch create mode 100644 queue-5.17/mmc-block-check-for-errors-after-write-on-spi.patch create mode 100644 queue-5.17/mmc-core-fixup-support-for-writeback-cache-for-emmc-and-sd.patch create mode 100644 queue-5.17/mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch create mode 100644 queue-5.17/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch create mode 100644 queue-5.17/mmc-renesas_sdhi-special-4tap-settings-only-apply-to-hs400.patch create mode 100644 queue-5.17/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch create mode 100644 queue-5.17/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch create mode 100644 queue-5.17/scsi-mpt3sas-fix-use-after-free-in-_scsih_expander_node_remove.patch create mode 100644 queue-5.17/scsi-ufs-ufs-pci-add-support-for-intel-mtl.patch diff --git a/queue-5.17/highmem-fix-checks-in-__kmap_local_sched_-in-out.patch b/queue-5.17/highmem-fix-checks-in-__kmap_local_sched_-in-out.patch new file mode 100644 index 00000000000..8080cceb9e3 --- /dev/null +++ b/queue-5.17/highmem-fix-checks-in-__kmap_local_sched_-in-out.patch @@ -0,0 +1,81 @@ +From 66f133ceab7456c789f70a242991ed1b27ba1c3d Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Fri, 8 Apr 2022 13:08:55 -0700 +Subject: highmem: fix checks in __kmap_local_sched_{in,out} + +From: Max Filippov + +commit 66f133ceab7456c789f70a242991ed1b27ba1c3d upstream. + +When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check +that even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots are +initialized with 0 value, but the check is done with pte_none. 0 pte +however does not necessarily mean that pte_none will return true. e.g. +on xtensa it returns false, resulting in the following runtime warnings: + + WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 + CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 + Call Trace: + dump_stack+0xc/0x40 + __warn+0x8f/0x174 + warn_slowpath_fmt+0x48/0xac + __kmap_local_sched_out+0x51/0x108 + __schedule+0x71a/0x9c4 + preempt_schedule_irq+0xa0/0xe0 + common_exception_return+0x5c/0x93 + do_wp_page+0x30e/0x330 + handle_mm_fault+0xa70/0xc3c + do_page_fault+0x1d8/0x3c4 + common_exception+0x7f/0x7f + + WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 + CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 + Call Trace: + dump_stack+0xc/0x40 + __warn+0x8f/0x174 + warn_slowpath_fmt+0x48/0xac + __kmap_local_sched_in+0x50/0xe0 + finish_task_switch$isra$0+0x1ce/0x2f8 + __schedule+0x86e/0x9c4 + preempt_schedule_irq+0xa0/0xe0 + common_exception_return+0x5c/0x93 + do_wp_page+0x30e/0x330 + handle_mm_fault+0xa70/0xc3c + do_page_fault+0x1d8/0x3c4 + common_exception+0x7f/0x7f + +Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0. + +Link: https://lkml.kernel.org/r/20220403235159.3498065-1-jcmvbkbc@gmail.com +Fixes: 5fbda3ecd14a ("sched: highmem: Store local kmaps in task struct") +Signed-off-by: Max Filippov +Reviewed-by: Thomas Gleixner +Cc: "Peter Zijlstra (Intel)" +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/highmem.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/highmem.c ++++ b/mm/highmem.c +@@ -624,7 +624,7 @@ void __kmap_local_sched_out(void) + + /* With debug all even slots are unmapped and act as guard */ + if (IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL) && !(i & 0x01)) { +- WARN_ON_ONCE(!pte_none(pteval)); ++ WARN_ON_ONCE(pte_val(pteval) != 0); + continue; + } + if (WARN_ON_ONCE(pte_none(pteval))) +@@ -661,7 +661,7 @@ void __kmap_local_sched_in(void) + + /* With debug all even slots are unmapped and act as guard */ + if (IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL) && !(i & 0x01)) { +- WARN_ON_ONCE(!pte_none(pteval)); ++ WARN_ON_ONCE(pte_val(pteval) != 0); + continue; + } + if (WARN_ON_ONCE(pte_none(pteval))) diff --git a/queue-5.17/io_uring-defer-splice-tee-file-validity-check-until-command-issue.patch b/queue-5.17/io_uring-defer-splice-tee-file-validity-check-until-command-issue.patch new file mode 100644 index 00000000000..e5eea6d8602 --- /dev/null +++ b/queue-5.17/io_uring-defer-splice-tee-file-validity-check-until-command-issue.patch @@ -0,0 +1,147 @@ +From a3e4bc23d5470b2beb7cc42a86b6a3e75b704c15 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Tue, 29 Mar 2022 10:59:20 -0600 +Subject: io_uring: defer splice/tee file validity check until command issue + +From: Jens Axboe + +commit a3e4bc23d5470b2beb7cc42a86b6a3e75b704c15 upstream. + +In preparation for not using the file at prep time, defer checking if this +file refers to a valid io_uring instance until issue time. + +This also means we can get rid of the cleanup flag for splice and tee. + +Cc: stable@vger.kernel.org # v5.15+ +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + fs/io_uring.c | 49 +++++++++++++++++++++---------------------------- + 1 file changed, 21 insertions(+), 28 deletions(-) + +--- a/fs/io_uring.c ++++ b/fs/io_uring.c +@@ -621,10 +621,10 @@ struct io_epoll { + + struct io_splice { + struct file *file_out; +- struct file *file_in; + loff_t off_out; + loff_t off_in; + u64 len; ++ int splice_fd_in; + unsigned int flags; + }; + +@@ -1551,14 +1551,6 @@ static void io_prep_async_work(struct io + if (def->unbound_nonreg_file) + req->work.flags |= IO_WQ_WORK_UNBOUND; + } +- +- switch (req->opcode) { +- case IORING_OP_SPLICE: +- case IORING_OP_TEE: +- if (!S_ISREG(file_inode(req->splice.file_in)->i_mode)) +- req->work.flags |= IO_WQ_WORK_UNBOUND; +- break; +- } + } + + static void io_prep_async_link(struct io_kiocb *req) +@@ -4144,18 +4136,11 @@ static int __io_splice_prep(struct io_ki + if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL)) + return -EINVAL; + +- sp->file_in = NULL; + sp->len = READ_ONCE(sqe->len); + sp->flags = READ_ONCE(sqe->splice_flags); +- + if (unlikely(sp->flags & ~valid_flags)) + return -EINVAL; +- +- sp->file_in = io_file_get(req->ctx, req, READ_ONCE(sqe->splice_fd_in), +- (sp->flags & SPLICE_F_FD_IN_FIXED)); +- if (!sp->file_in) +- return -EBADF; +- req->flags |= REQ_F_NEED_CLEANUP; ++ sp->splice_fd_in = READ_ONCE(sqe->splice_fd_in); + return 0; + } + +@@ -4170,20 +4155,27 @@ static int io_tee_prep(struct io_kiocb * + static int io_tee(struct io_kiocb *req, unsigned int issue_flags) + { + struct io_splice *sp = &req->splice; +- struct file *in = sp->file_in; + struct file *out = sp->file_out; + unsigned int flags = sp->flags & ~SPLICE_F_FD_IN_FIXED; ++ struct file *in; + long ret = 0; + + if (issue_flags & IO_URING_F_NONBLOCK) + return -EAGAIN; ++ ++ in = io_file_get(req->ctx, req, sp->splice_fd_in, ++ (sp->flags & SPLICE_F_FD_IN_FIXED)); ++ if (!in) { ++ ret = -EBADF; ++ goto done; ++ } ++ + if (sp->len) + ret = do_tee(in, out, sp->len, flags); + + if (!(sp->flags & SPLICE_F_FD_IN_FIXED)) + io_put_file(in); +- req->flags &= ~REQ_F_NEED_CLEANUP; +- ++done: + if (ret != sp->len) + req_set_fail(req); + io_req_complete(req, ret); +@@ -4202,15 +4194,22 @@ static int io_splice_prep(struct io_kioc + static int io_splice(struct io_kiocb *req, unsigned int issue_flags) + { + struct io_splice *sp = &req->splice; +- struct file *in = sp->file_in; + struct file *out = sp->file_out; + unsigned int flags = sp->flags & ~SPLICE_F_FD_IN_FIXED; + loff_t *poff_in, *poff_out; ++ struct file *in; + long ret = 0; + + if (issue_flags & IO_URING_F_NONBLOCK) + return -EAGAIN; + ++ in = io_file_get(req->ctx, req, sp->splice_fd_in, ++ (sp->flags & SPLICE_F_FD_IN_FIXED)); ++ if (!in) { ++ ret = -EBADF; ++ goto done; ++ } ++ + poff_in = (sp->off_in == -1) ? NULL : &sp->off_in; + poff_out = (sp->off_out == -1) ? NULL : &sp->off_out; + +@@ -4219,8 +4218,7 @@ static int io_splice(struct io_kiocb *re + + if (!(sp->flags & SPLICE_F_FD_IN_FIXED)) + io_put_file(in); +- req->flags &= ~REQ_F_NEED_CLEANUP; +- ++done: + if (ret != sp->len) + req_set_fail(req); + io_req_complete(req, ret); +@@ -6686,11 +6684,6 @@ static void io_clean_op(struct io_kiocb + kfree(io->free_iov); + break; + } +- case IORING_OP_SPLICE: +- case IORING_OP_TEE: +- if (!(req->splice.flags & SPLICE_F_FD_IN_FIXED)) +- io_put_file(req->splice.file_in); +- break; + case IORING_OP_OPENAT: + case IORING_OP_OPENAT2: + if (req->open.filename) diff --git a/queue-5.17/io_uring-don-t-check-req-file-in-io_fsync_prep.patch b/queue-5.17/io_uring-don-t-check-req-file-in-io_fsync_prep.patch new file mode 100644 index 00000000000..6cdaa6f4ac7 --- /dev/null +++ b/queue-5.17/io_uring-don-t-check-req-file-in-io_fsync_prep.patch @@ -0,0 +1,32 @@ +From ec858afda857e361182ceafc3d2ba2b164b8e889 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Wed, 30 Mar 2022 11:06:02 -0600 +Subject: io_uring: don't check req->file in io_fsync_prep() + +From: Jens Axboe + +commit ec858afda857e361182ceafc3d2ba2b164b8e889 upstream. + +This is a leftover from the really old days where we weren't able to +track and error early if we need a file and it wasn't assigned. Kill +the check. + +Cc: stable@vger.kernel.org # v5.15+ +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + fs/io_uring.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/fs/io_uring.c ++++ b/fs/io_uring.c +@@ -4245,9 +4245,6 @@ static int io_fsync_prep(struct io_kiocb + { + struct io_ring_ctx *ctx = req->ctx; + +- if (!req->file) +- return -EBADF; +- + if (unlikely(ctx->flags & IORING_SETUP_IOPOLL)) + return -EINVAL; + if (unlikely(sqe->addr || sqe->ioprio || sqe->buf_index || diff --git a/queue-5.17/lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch b/queue-5.17/lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch new file mode 100644 index 00000000000..bedfb5adda5 --- /dev/null +++ b/queue-5.17/lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch @@ -0,0 +1,57 @@ +From eafc0a02391b7b36617b36c97c4b5d6832cf5e24 Mon Sep 17 00:00:00 2001 +From: Guo Xuenan +Date: Fri, 8 Apr 2022 13:08:58 -0700 +Subject: lz4: fix LZ4_decompress_safe_partial read out of bound + +From: Guo Xuenan + +commit eafc0a02391b7b36617b36c97c4b5d6832cf5e24 upstream. + +When partialDecoding, it is EOF if we've either filled the output buffer +or can't proceed with reading an offset for following match. + +In some extreme corner cases when compressed data is suitably corrupted, +UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial +may lead to read out of bound problem during decoding. lz4 upstream has +fixed it [2] and this issue has been disscussed here [3] before. + +current decompression routine was ported from lz4 v1.8.3, bumping +lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd +better fix it first. + +[1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ +[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# +[3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ + +Link: https://lkml.kernel.org/r/20211111105048.2006070-1-guoxuenan@huawei.com +Reported-by: syzbot+63d688f1d899c588fb71@syzkaller.appspotmail.com +Signed-off-by: Guo Xuenan +Reviewed-by: Nick Terrell +Acked-by: Gao Xiang +Cc: Yann Collet +Cc: Chengyang Fan +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + lib/lz4/lz4_decompress.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/lib/lz4/lz4_decompress.c ++++ b/lib/lz4/lz4_decompress.c +@@ -271,8 +271,12 @@ static FORCE_INLINE int LZ4_decompress_g + ip += length; + op += length; + +- /* Necessarily EOF, due to parsing restrictions */ +- if (!partialDecoding || (cpy == oend)) ++ /* Necessarily EOF when !partialDecoding. ++ * When partialDecoding, it is EOF if we've either ++ * filled the output buffer or ++ * can't proceed with reading an offset for following match. ++ */ ++ if (!partialDecoding || (cpy == oend) || (ip >= (iend - 2))) + break; + } else { + /* may overwrite up to WILDCOPYLENGTH beyond cpy */ diff --git a/queue-5.17/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch b/queue-5.17/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch new file mode 100644 index 00000000000..b5d4b5a469f --- /dev/null +++ b/queue-5.17/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch @@ -0,0 +1,51 @@ +From 4ad099559b00ac01c3726e5c95dc3108ef47d03e Mon Sep 17 00:00:00 2001 +From: Miaohe Lin +Date: Fri, 8 Apr 2022 13:09:07 -0700 +Subject: mm/mempolicy: fix mpol_new leak in shared_policy_replace + +From: Miaohe Lin + +commit 4ad099559b00ac01c3726e5c95dc3108ef47d03e upstream. + +If mpol_new is allocated but not used in restart loop, mpol_new will be +freed via mpol_put before returning to the caller. But refcnt is not +initialized yet, so mpol_put could not do the right things and might +leak the unused mpol_new. This would happen if mempolicy was updated on +the shared shmem file while the sp->lock has been dropped during the +memory allocation. + +This issue could be triggered easily with the below code snippet if +there are many processes doing the below work at the same time: + + shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); + shm = shmat(shmid, 0, 0); + loop many times { + mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); + mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, + maxnode, 0); + } + +Link: https://lkml.kernel.org/r/20220329111416.27954-1-linmiaohe@huawei.com +Fixes: 42288fe366c4 ("mm: mempolicy: Convert shared_policy mutex to spinlock") +Signed-off-by: Miaohe Lin +Acked-by: Michal Hocko +Cc: KOSAKI Motohiro +Cc: Mel Gorman +Cc: [3.8] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/mempolicy.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/mempolicy.c ++++ b/mm/mempolicy.c +@@ -2736,6 +2736,7 @@ alloc_new: + mpol_new = kmem_cache_alloc(policy_cache, GFP_KERNEL); + if (!mpol_new) + goto err_out; ++ atomic_set(&mpol_new->refcnt, 1); + goto restart; + } + diff --git a/queue-5.17/mmc-block-check-for-errors-after-write-on-spi.patch b/queue-5.17/mmc-block-check-for-errors-after-write-on-spi.patch new file mode 100644 index 00000000000..62b3e4ec03a --- /dev/null +++ b/queue-5.17/mmc-block-check-for-errors-after-write-on-spi.patch @@ -0,0 +1,93 @@ +From 5d435933376962b107bd76970912e7e80247dcc7 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20L=C3=B6hle?= +Date: Thu, 24 Mar 2022 14:18:41 +0000 +Subject: mmc: block: Check for errors after write on SPI + +From: Christian Löhle + +commit 5d435933376962b107bd76970912e7e80247dcc7 upstream. + +Introduce a SEND_STATUS check for writes through SPI to not mark +an unsuccessful write as successful. + +Since SPI SD/MMC does not have states, after a write, the card will +just hold the line LOW until it is ready again. The driver marks the +write therefore as completed as soon as it reads something other than +all zeroes. +The driver does not distinguish from a card no longer signalling busy +and it being disconnected (and the line being pulled-up by the host). +This lead to writes being marked as successful when disconnecting +a busy card. +Now the card is ensured to be still connected by an additional CMD13, +just like non-SPI is ensured to go back to TRAN state. + +While at it and since we already poll for the post-write status anyway, +we might as well check for SPIs error bits (any of them). + +The disconnecting card problem is reproducable for me after continuous +write activity and randomly disconnecting, around every 20-50 tries +on SPI DS for some card. + +Fixes: 7213d175e3b6f ("MMC/SD card driver learns SPI") +Cc: stable@vger.kernel.org +Signed-off-by: Christian Loehle +Reviewed-by: Andy Shevchenko +Link: https://lore.kernel.org/r/76f6f5d2b35543bab3dfe438f268609c@hyperstone.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/block.c | 34 +++++++++++++++++++++++++++++++++- + 1 file changed, 33 insertions(+), 1 deletion(-) + +--- a/drivers/mmc/core/block.c ++++ b/drivers/mmc/core/block.c +@@ -1880,6 +1880,31 @@ static inline bool mmc_blk_rq_error(stru + brq->data.error || brq->cmd.resp[0] & CMD_ERRORS; + } + ++static int mmc_spi_err_check(struct mmc_card *card) ++{ ++ u32 status = 0; ++ int err; ++ ++ /* ++ * SPI does not have a TRAN state we have to wait on, instead the ++ * card is ready again when it no longer holds the line LOW. ++ * We still have to ensure two things here before we know the write ++ * was successful: ++ * 1. The card has not disconnected during busy and we actually read our ++ * own pull-up, thinking it was still connected, so ensure it ++ * still responds. ++ * 2. Check for any error bits, in particular R1_SPI_IDLE to catch a ++ * just reconnected card after being disconnected during busy. ++ */ ++ err = __mmc_send_status(card, &status, 0); ++ if (err) ++ return err; ++ /* All R1 and R2 bits of SPI are errors in our case */ ++ if (status) ++ return -EIO; ++ return 0; ++} ++ + static int mmc_blk_busy_cb(void *cb_data, bool *busy) + { + struct mmc_blk_busy_data *data = cb_data; +@@ -1903,9 +1928,16 @@ static int mmc_blk_card_busy(struct mmc_ + struct mmc_blk_busy_data cb_data; + int err; + +- if (mmc_host_is_spi(card->host) || rq_data_dir(req) == READ) ++ if (rq_data_dir(req) == READ) + return 0; + ++ if (mmc_host_is_spi(card->host)) { ++ err = mmc_spi_err_check(card); ++ if (err) ++ mqrq->brq.data.bytes_xfered = 0; ++ return err; ++ } ++ + cb_data.card = card; + cb_data.status = 0; + err = __mmc_poll_for_busy(card->host, 0, MMC_BLK_TIMEOUT_MS, diff --git a/queue-5.17/mmc-core-fixup-support-for-writeback-cache-for-emmc-and-sd.patch b/queue-5.17/mmc-core-fixup-support-for-writeback-cache-for-emmc-and-sd.patch new file mode 100644 index 00000000000..85664beb4ff --- /dev/null +++ b/queue-5.17/mmc-core-fixup-support-for-writeback-cache-for-emmc-and-sd.patch @@ -0,0 +1,73 @@ +From 08ebf903af57cda6d773f3dd1671b64f73b432b8 Mon Sep 17 00:00:00 2001 +From: Michael Wu +Date: Thu, 31 Mar 2022 15:32:23 +0800 +Subject: mmc: core: Fixup support for writeback-cache for eMMC and SD + +From: Michael Wu + +commit 08ebf903af57cda6d773f3dd1671b64f73b432b8 upstream. + +During the card initialization process, the mmc core checks whether the +eMMC/SD card supports an internal writeback-cache and then enables it +inside the card. + +Unfortunately, this isn't according to what the mmc core reports to the +upper block layer. Instead, the writeback-cache support with REQ_FLUSH and +REQ_FUA, are being enabled depending on whether the host supports the CMD23 +(MMC_CAP_CMD23) and whether an eMMC supports the reliable-write command. + +This is wrong and it may also sound awkward. In fact, it's a remnant +from when both eMMC/SD cards didn't have dedicated commands/support to +control the internal writeback-cache. In other words, it was the best we +could do at that point in time. + +To fix the problem, but also without breaking backwards compatibility, +let's align the REQ_FLUSH support with whether the writeback-cache became +successfully enabled - for both eMMC and SD cards. + +Cc: stable@kernel.org +Fixes: 881d1c25f765 ("mmc: core: Add cache control for eMMC4.5 device") +Fixes: 130206a615a9 ("mmc: core: Add support for cache ctrl for SD cards") +Depends-on: 97fce126e279 ("mmc: block: Issue a cache flush only when it's enabled") +Reviewed-by: Avri Altman +Signed-off-by: Michael Wu +Link: https://lore.kernel.org/r/20220331073223.106415-1-michael@allwinnertech.com +[Ulf: Re-wrote the commit message] +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/block.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +--- a/drivers/mmc/core/block.c ++++ b/drivers/mmc/core/block.c +@@ -2382,6 +2382,8 @@ static struct mmc_blk_data *mmc_blk_allo + struct mmc_blk_data *md; + int devidx, ret; + char cap_str[10]; ++ bool cache_enabled = false; ++ bool fua_enabled = false; + + devidx = ida_simple_get(&mmc_blk_ida, 0, max_devices, GFP_KERNEL); + if (devidx < 0) { +@@ -2461,13 +2463,17 @@ static struct mmc_blk_data *mmc_blk_allo + md->flags |= MMC_BLK_CMD23; + } + +- if (mmc_card_mmc(card) && +- md->flags & MMC_BLK_CMD23 && ++ if (md->flags & MMC_BLK_CMD23 && + ((card->ext_csd.rel_param & EXT_CSD_WR_REL_PARAM_EN) || + card->ext_csd.rel_sectors)) { + md->flags |= MMC_BLK_REL_WR; +- blk_queue_write_cache(md->queue.queue, true, true); ++ fua_enabled = true; ++ cache_enabled = true; + } ++ if (mmc_cache_enabled(card->host)) ++ cache_enabled = true; ++ ++ blk_queue_write_cache(md->queue.queue, cache_enabled, fua_enabled); + + string_get_size((u64)size, 512, STRING_UNITS_2, + cap_str, sizeof(cap_str)); diff --git a/queue-5.17/mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch b/queue-5.17/mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch new file mode 100644 index 00000000000..840ce644490 --- /dev/null +++ b/queue-5.17/mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch @@ -0,0 +1,46 @@ +From 0d319dd5a27183b75d984e3dc495248e59f99334 Mon Sep 17 00:00:00 2001 +From: Yann Gautier +Date: Thu, 17 Mar 2022 12:19:43 +0100 +Subject: mmc: mmci: stm32: correctly check all elements of sg list + +From: Yann Gautier + +commit 0d319dd5a27183b75d984e3dc495248e59f99334 upstream. + +Use sg and not data->sg when checking sg list elements. Else only the +first element alignment is checked. +The last element should be checked the same way, for_each_sg already set +sg to sg_next(sg). + +Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant") +Cc: stable@vger.kernel.org +Signed-off-by: Yann Gautier +Link: https://lore.kernel.org/r/20220317111944.116148-2-yann.gautier@foss.st.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/mmci_stm32_sdmmc.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/mmc/host/mmci_stm32_sdmmc.c ++++ b/drivers/mmc/host/mmci_stm32_sdmmc.c +@@ -62,8 +62,8 @@ static int sdmmc_idma_validate_data(stru + * excepted the last element which has no constraint on idmasize + */ + for_each_sg(data->sg, sg, data->sg_len - 1, i) { +- if (!IS_ALIGNED(data->sg->offset, sizeof(u32)) || +- !IS_ALIGNED(data->sg->length, SDMMC_IDMA_BURST)) { ++ if (!IS_ALIGNED(sg->offset, sizeof(u32)) || ++ !IS_ALIGNED(sg->length, SDMMC_IDMA_BURST)) { + dev_err(mmc_dev(host->mmc), + "unaligned scatterlist: ofst:%x length:%d\n", + data->sg->offset, data->sg->length); +@@ -71,7 +71,7 @@ static int sdmmc_idma_validate_data(stru + } + } + +- if (!IS_ALIGNED(data->sg->offset, sizeof(u32))) { ++ if (!IS_ALIGNED(sg->offset, sizeof(u32))) { + dev_err(mmc_dev(host->mmc), + "unaligned last scatterlist: ofst:%x length:%d\n", + data->sg->offset, data->sg->length); diff --git a/queue-5.17/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch b/queue-5.17/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch new file mode 100644 index 00000000000..943c3919d63 --- /dev/null +++ b/queue-5.17/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch @@ -0,0 +1,41 @@ +From 03e59b1e2f56245163b14c69e0a830c24b1a3a47 Mon Sep 17 00:00:00 2001 +From: Wolfram Sang +Date: Mon, 4 Apr 2022 13:49:02 +0200 +Subject: mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is complete + +From: Wolfram Sang + +commit 03e59b1e2f56245163b14c69e0a830c24b1a3a47 upstream. + +When HS400 tuning is complete and HS400 is going to be activated, we +have to keep the current number of TAPs and should not overwrite them +with a hardcoded value. This was probably a copy&paste mistake when +upporting HS400 support from the BSP. + +Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support") +Reported-by: Yoshihiro Shimoda +Signed-off-by: Wolfram Sang +Reviewed-by: Yoshihiro Shimoda +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220404114902.12175-1-wsa+renesas@sang-engineering.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/renesas_sdhi_core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/host/renesas_sdhi_core.c ++++ b/drivers/mmc/host/renesas_sdhi_core.c +@@ -396,10 +396,10 @@ static void renesas_sdhi_hs400_complete( + SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL) | + sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2)); + +- /* Set the sampling clock selection range of HS400 mode */ + sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL, + SH_MOBILE_SDHI_SCC_DTCNTL_TAPEN | +- 0x4 << SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT); ++ sd_scc_read32(host, priv, ++ SH_MOBILE_SDHI_SCC_DTCNTL)); + + /* Avoid bad TAP */ + if (bad_taps & BIT(priv->tap_set)) { diff --git a/queue-5.17/mmc-renesas_sdhi-special-4tap-settings-only-apply-to-hs400.patch b/queue-5.17/mmc-renesas_sdhi-special-4tap-settings-only-apply-to-hs400.patch new file mode 100644 index 00000000000..ee68fb891e3 --- /dev/null +++ b/queue-5.17/mmc-renesas_sdhi-special-4tap-settings-only-apply-to-hs400.patch @@ -0,0 +1,38 @@ +From 46d4820f949a3030b19ee482c68a50b06dd27590 Mon Sep 17 00:00:00 2001 +From: Wolfram Sang +Date: Mon, 4 Apr 2022 12:05:08 +0200 +Subject: mmc: renesas_sdhi: special 4tap settings only apply to HS400 + +From: Wolfram Sang + +commit 46d4820f949a3030b19ee482c68a50b06dd27590 upstream. + +Previous documentation was vague, so we included SDR104 for slow SDnH +clock settings. It turns out now, that it is only needed for HS400. + +Fixes: bb6d3fa98a41 ("clk: renesas: rcar-gen3: Switch to new SD clock handling") +Cc: stable@vger.kernel.org +Reported-by: Yoshihiro Shimoda +Signed-off-by: Wolfram Sang +Reviewed-by: Yoshihiro Shimoda +Link: https://lore.kernel.org/r/20220404100508.3209-1-wsa+renesas@sang-engineering.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/renesas_sdhi_core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/host/renesas_sdhi_core.c ++++ b/drivers/mmc/host/renesas_sdhi_core.c +@@ -144,9 +144,9 @@ static unsigned int renesas_sdhi_clk_upd + return clk_get_rate(priv->clk); + + if (priv->clkh) { ++ /* HS400 with 4TAP needs different clock settings */ + bool use_4tap = priv->quirks && priv->quirks->hs400_4taps; +- bool need_slow_clkh = (host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) || +- (host->mmc->ios.timing == MMC_TIMING_MMC_HS400); ++ bool need_slow_clkh = host->mmc->ios.timing == MMC_TIMING_MMC_HS400; + clkh_shift = use_4tap && need_slow_clkh ? 1 : 2; + ref_clk = priv->clkh; + } diff --git a/queue-5.17/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch b/queue-5.17/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch new file mode 100644 index 00000000000..83324537d63 --- /dev/null +++ b/queue-5.17/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch @@ -0,0 +1,45 @@ +From 01e67e04c28170c47700c2c226d732bbfedb1ad0 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Fri, 8 Apr 2022 13:09:04 -0700 +Subject: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0) + +From: Paolo Bonzini + +commit 01e67e04c28170c47700c2c226d732bbfedb1ad0 upstream. + +If an mremap() syscall with old_size=0 ends up in move_page_tables(), it +will call invalidate_range_start()/invalidate_range_end() unnecessarily, +i.e. with an empty range. + +This causes a WARN in KVM's mmu_notifier. In the past, empty ranges +have been diagnosed to be off-by-one bugs, hence the WARNing. Given the +low (so far) number of unique reports, the benefits of detecting more +buggy callers seem to outweigh the cost of having to fix cases such as +this one, where userspace is doing something silly. In this particular +case, an early return from move_page_tables() is enough to fix the +issue. + +Link: https://lkml.kernel.org/r/20220329173155.172439-1-pbonzini@redhat.com +Reported-by: syzbot+6bde52d89cfdf9f61425@syzkaller.appspotmail.com +Signed-off-by: Paolo Bonzini +Cc: Sean Christopherson +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/mremap.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/mm/mremap.c ++++ b/mm/mremap.c +@@ -486,6 +486,9 @@ unsigned long move_page_tables(struct vm + pmd_t *old_pmd, *new_pmd; + pud_t *old_pud, *new_pud; + ++ if (!len) ++ return 0; ++ + old_end = old_addr + len; + flush_cache_range(vma, old_addr, old_end); + diff --git a/queue-5.17/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch b/queue-5.17/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch new file mode 100644 index 00000000000..63b8d600263 --- /dev/null +++ b/queue-5.17/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch @@ -0,0 +1,49 @@ +From 7e2646ed47542123168d43916b84b954532e5386 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Fri, 18 Mar 2022 15:14:41 +0100 +Subject: Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning" +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit 7e2646ed47542123168d43916b84b954532e5386 upstream. + +This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f. + +Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") +contains proper fix for the issue described in commit bb32e1987bc5 ("mmc: +sdhci-xenon: fix annoying 1.8V regulator warning"). + +Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable") +Cc: stable@vger.kernel.org # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") +Signed-off-by: Pali Rohár +Reviewed-by: Marek Behún +Reviewed-by: Marcin Wojtas +Link: https://lore.kernel.org/r/20220318141441.32329-1-pali@kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/sdhci-xenon.c | 10 ---------- + 1 file changed, 10 deletions(-) + +--- a/drivers/mmc/host/sdhci-xenon.c ++++ b/drivers/mmc/host/sdhci-xenon.c +@@ -241,16 +241,6 @@ static void xenon_voltage_switch(struct + { + /* Wait for 5ms after set 1.8V signal enable bit */ + usleep_range(5000, 5500); +- +- /* +- * For some reason the controller's Host Control2 register reports +- * the bit representing 1.8V signaling as 0 when read after it was +- * written as 1. Subsequent read reports 1. +- * +- * Since this may cause some issues, do an empty read of the Host +- * Control2 register here to circumvent this. +- */ +- sdhci_readw(host, SDHCI_HOST_CONTROL2); + } + + static unsigned int xenon_get_max_clock(struct sdhci_host *host) diff --git a/queue-5.17/scsi-mpt3sas-fix-use-after-free-in-_scsih_expander_node_remove.patch b/queue-5.17/scsi-mpt3sas-fix-use-after-free-in-_scsih_expander_node_remove.patch new file mode 100644 index 00000000000..c4921054f17 --- /dev/null +++ b/queue-5.17/scsi-mpt3sas-fix-use-after-free-in-_scsih_expander_node_remove.patch @@ -0,0 +1,97 @@ +From 87d663d40801dffc99a5ad3b0188ad3e2b4d1557 Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Tue, 22 Mar 2022 14:57:02 +0900 +Subject: scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove() + +From: Damien Le Moal + +commit 87d663d40801dffc99a5ad3b0188ad3e2b4d1557 upstream. + +The function mpt3sas_transport_port_remove() called in +_scsih_expander_node_remove() frees the port field of the sas_expander +structure, leading to the following use-after-free splat from KASAN when +the ioc_info() call following that function is executed (e.g. when doing +rmmod of the driver module): + +[ 3479.371167] ================================================================== +[ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas] +[ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531 +[ 3479.393524] +[ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436 +[ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 +[ 3479.409263] Call Trace: +[ 3479.411743] +[ 3479.413875] dump_stack_lvl+0x45/0x59 +[ 3479.417582] print_address_description.constprop.0+0x1f/0x120 +[ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] +[ 3479.429469] kasan_report.cold+0x83/0xdf +[ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] +[ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas] +[ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40 +[ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas] +[ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas] +[ 3479.465529] ? down_write+0xde/0x150 +[ 3479.470746] ? up_write+0x14d/0x460 +[ 3479.475840] ? kernfs_find_ns+0x137/0x310 +[ 3479.481438] pci_device_remove+0x65/0x110 +[ 3479.487013] __device_release_driver+0x316/0x680 +[ 3479.493180] driver_detach+0x1ec/0x2d0 +[ 3479.498499] bus_remove_driver+0xe7/0x2d0 +[ 3479.504081] pci_unregister_driver+0x26/0x250 +[ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas] +[ 3479.516144] __x64_sys_delete_module+0x2fd/0x510 +[ 3479.522315] ? free_module+0xaa0/0xaa0 +[ 3479.527593] ? __cond_resched+0x1c/0x90 +[ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 +[ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70 +[ 3479.546161] ? trace_hardirqs_on+0x1c/0x110 +[ 3479.551828] do_syscall_64+0x35/0x80 +[ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae +[ 3479.563402] RIP: 0033:0x7f1fc482483b +... +[ 3479.943087] ================================================================== + +Fix this by introducing the local variable port_id to store the port ID +value before executing mpt3sas_transport_port_remove(). This local variable +is then used in the call to ioc_info() instead of dereferencing the freed +port structure. + +Link: https://lore.kernel.org/r/20220322055702.95276-1-damien.lemoal@opensource.wdc.com +Fixes: 7d310f241001 ("scsi: mpt3sas: Get device objects using sas_address & portID") +Cc: stable@vger.kernel.org +Acked-by: Sreekanth Reddy +Signed-off-by: Damien Le Moal +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/mpt3sas/mpt3sas_scsih.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c ++++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c +@@ -11035,6 +11035,7 @@ _scsih_expander_node_remove(struct MPT3S + { + struct _sas_port *mpt3sas_port, *next; + unsigned long flags; ++ int port_id; + + /* remove sibling ports attached to this expander */ + list_for_each_entry_safe(mpt3sas_port, next, +@@ -11055,6 +11056,8 @@ _scsih_expander_node_remove(struct MPT3S + mpt3sas_port->hba_port); + } + ++ port_id = sas_expander->port->port_id; ++ + mpt3sas_transport_port_remove(ioc, sas_expander->sas_address, + sas_expander->sas_address_parent, sas_expander->port); + +@@ -11062,7 +11065,7 @@ _scsih_expander_node_remove(struct MPT3S + "expander_remove: handle(0x%04x), sas_addr(0x%016llx), port:%d\n", + sas_expander->handle, (unsigned long long) + sas_expander->sas_address, +- sas_expander->port->port_id); ++ port_id); + + spin_lock_irqsave(&ioc->sas_node_lock, flags); + list_del(&sas_expander->list); diff --git a/queue-5.17/scsi-ufs-ufs-pci-add-support-for-intel-mtl.patch b/queue-5.17/scsi-ufs-ufs-pci-add-support-for-intel-mtl.patch new file mode 100644 index 00000000000..1ebd4bfae5e --- /dev/null +++ b/queue-5.17/scsi-ufs-ufs-pci-add-support-for-intel-mtl.patch @@ -0,0 +1,62 @@ +From 4049f7acef3eb37c1ea0df45f3ffc29404f4e708 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Mon, 4 Apr 2022 08:50:38 +0300 +Subject: scsi: ufs: ufs-pci: Add support for Intel MTL + +From: Adrian Hunter + +commit 4049f7acef3eb37c1ea0df45f3ffc29404f4e708 upstream. + +Add PCI ID and callbacks to support Intel Meteor Lake (MTL). + +Link: https://lore.kernel.org/r/20220404055038.2208051-1-adrian.hunter@intel.com +Cc: stable@vger.kernel.org # v5.15+ +Reviewed-by: Avri Altman +Reviewed-by: Bart Van Assche +Signed-off-by: Adrian Hunter +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/ufs/ufshcd-pci.c | 17 +++++++++++++++++ + 1 file changed, 17 insertions(+) + +--- a/drivers/scsi/ufs/ufshcd-pci.c ++++ b/drivers/scsi/ufs/ufshcd-pci.c +@@ -428,6 +428,12 @@ static int ufs_intel_adl_init(struct ufs + return ufs_intel_common_init(hba); + } + ++static int ufs_intel_mtl_init(struct ufs_hba *hba) ++{ ++ hba->caps |= UFSHCD_CAP_CRYPTO | UFSHCD_CAP_WB_EN; ++ return ufs_intel_common_init(hba); ++} ++ + static struct ufs_hba_variant_ops ufs_intel_cnl_hba_vops = { + .name = "intel-pci", + .init = ufs_intel_common_init, +@@ -465,6 +471,16 @@ static struct ufs_hba_variant_ops ufs_in + .device_reset = ufs_intel_device_reset, + }; + ++static struct ufs_hba_variant_ops ufs_intel_mtl_hba_vops = { ++ .name = "intel-pci", ++ .init = ufs_intel_mtl_init, ++ .exit = ufs_intel_common_exit, ++ .hce_enable_notify = ufs_intel_hce_enable_notify, ++ .link_startup_notify = ufs_intel_link_startup_notify, ++ .resume = ufs_intel_resume, ++ .device_reset = ufs_intel_device_reset, ++}; ++ + #ifdef CONFIG_PM_SLEEP + static int ufshcd_pci_restore(struct device *dev) + { +@@ -579,6 +595,7 @@ static const struct pci_device_id ufshcd + { PCI_VDEVICE(INTEL, 0x98FA), (kernel_ulong_t)&ufs_intel_lkf_hba_vops }, + { PCI_VDEVICE(INTEL, 0x51FF), (kernel_ulong_t)&ufs_intel_adl_hba_vops }, + { PCI_VDEVICE(INTEL, 0x54FF), (kernel_ulong_t)&ufs_intel_adl_hba_vops }, ++ { PCI_VDEVICE(INTEL, 0x7E47), (kernel_ulong_t)&ufs_intel_mtl_hba_vops }, + { } /* terminate list */ + }; + diff --git a/queue-5.17/series b/queue-5.17/series index c9c06aa5445..319e71e2a23 100644 --- a/queue-5.17/series +++ b/queue-5.17/series @@ -261,3 +261,17 @@ perf-arm-spe-fix-perf-report-mem-mode.patch perf-tools-fix-perf-s-libperf_print-callback.patch perf-session-remap-buf-if-there-is-no-space-for-even.patch arm64-add-part-number-for-arm-cortex-a78ae.patch +scsi-mpt3sas-fix-use-after-free-in-_scsih_expander_node_remove.patch +scsi-ufs-ufs-pci-add-support-for-intel-mtl.patch +revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch +mmc-block-check-for-errors-after-write-on-spi.patch +mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch +mmc-renesas_sdhi-special-4tap-settings-only-apply-to-hs400.patch +mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch +mmc-core-fixup-support-for-writeback-cache-for-emmc-and-sd.patch +lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch +highmem-fix-checks-in-__kmap_local_sched_-in-out.patch +mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch +mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch +io_uring-don-t-check-req-file-in-io_fsync_prep.patch +io_uring-defer-splice-tee-file-validity-check-until-command-issue.patch -- 2.47.3