--- /dev/null
+From c9c9762d4d44dcb1b2ba90cfb4122dc11ceebf31 Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Mon, 7 Jun 2021 12:34:05 -0700
+Subject: block: return the correct bvec when checking for gaps
+
+From: Long Li <longli@microsoft.com>
+
+commit c9c9762d4d44dcb1b2ba90cfb4122dc11ceebf31 upstream.
+
+After commit 07173c3ec276 ("block: enable multipage bvecs"), a bvec can
+have multiple pages. But bio_will_gap() still assumes one page bvec while
+checking for merging. If the pages in the bvec go across the
+seg_boundary_mask, this check for merging can potentially succeed if only
+the 1st page is tested, and can fail if all the pages are tested.
+
+Later, when SCSI builds the SG list the same check for merging is done in
+__blk_segment_map_sg_merge() with all the pages in the bvec tested. This
+time the check may fail if the pages in bvec go across the
+seg_boundary_mask (but tested okay in bio_will_gap() earlier, so those
+BIOs were merged). If this check fails, we end up with a broken SG list
+for drivers assuming the SG list not having offsets in intermediate pages.
+This results in incorrect pages written to the disk.
+
+Fix this by returning the multi-page bvec when testing gaps for merging.
+
+Cc: Jens Axboe <axboe@kernel.dk>
+Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Cc: Pavel Begunkov <asml.silence@gmail.com>
+Cc: Ming Lei <ming.lei@redhat.com>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
+Cc: Jeffle Xu <jefflexu@linux.alibaba.com>
+Cc: linux-kernel@vger.kernel.org
+Cc: stable@vger.kernel.org
+Fixes: 07173c3ec276 ("block: enable multipage bvecs")
+Signed-off-by: Long Li <longli@microsoft.com>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/1623094445-22332-1-git-send-email-longli@linuxonhyperv.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/bio.h | 12 ++++--------
+ 1 file changed, 4 insertions(+), 8 deletions(-)
+
+--- a/include/linux/bio.h
++++ b/include/linux/bio.h
+@@ -38,9 +38,6 @@
+ #define bio_offset(bio) bio_iter_offset((bio), (bio)->bi_iter)
+ #define bio_iovec(bio) bio_iter_iovec((bio), (bio)->bi_iter)
+
+-#define bio_multiple_segments(bio) \
+- ((bio)->bi_iter.bi_size != bio_iovec(bio).bv_len)
+-
+ #define bvec_iter_sectors(iter) ((iter).bi_size >> 9)
+ #define bvec_iter_end_sector(iter) ((iter).bi_sector + bvec_iter_sectors((iter)))
+
+@@ -252,7 +249,7 @@ static inline void bio_clear_flag(struct
+
+ static inline void bio_get_first_bvec(struct bio *bio, struct bio_vec *bv)
+ {
+- *bv = bio_iovec(bio);
++ *bv = mp_bvec_iter_bvec(bio->bi_io_vec, bio->bi_iter);
+ }
+
+ static inline void bio_get_last_bvec(struct bio *bio, struct bio_vec *bv)
+@@ -260,10 +257,9 @@ static inline void bio_get_last_bvec(str
+ struct bvec_iter iter = bio->bi_iter;
+ int idx;
+
+- if (unlikely(!bio_multiple_segments(bio))) {
+- *bv = bio_iovec(bio);
+- return;
+- }
++ bio_get_first_bvec(bio, bv);
++ if (bv->bv_len == bio->bi_iter.bi_size)
++ return; /* this bio only has a single bvec */
+
+ bio_advance_iter(bio, &iter, iter.bi_size);
+
--- /dev/null
+From 0508c1ad0f264a24c4643701823a45f6c9bd8146 Mon Sep 17 00:00:00 2001
+From: Wei Yongjun <weiyongjun1@huawei.com>
+Date: Wed, 19 May 2021 14:16:57 +0000
+Subject: erofs: fix error return code in erofs_read_superblock()
+
+From: Wei Yongjun <weiyongjun1@huawei.com>
+
+commit 0508c1ad0f264a24c4643701823a45f6c9bd8146 upstream.
+
+'ret' will be overwritten to 0 if erofs_sb_has_sb_chksum() return true,
+thus 0 will return in some error handling cases. Fix to return negative
+error code -EINVAL instead of 0.
+
+Link: https://lore.kernel.org/r/20210519141657.3062715-1-weiyongjun1@huawei.com
+Fixes: b858a4844cfb ("erofs: support superblock checksum")
+Cc: stable <stable@vger.kernel.org> # 5.5+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
+Reviewed-by: Gao Xiang <xiang@kernel.org>
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Gao Xiang <xiang@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/erofs/super.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/erofs/super.c
++++ b/fs/erofs/super.c
+@@ -155,6 +155,7 @@ static int erofs_read_superblock(struct
+ goto out;
+ }
+
++ ret = -EINVAL;
+ blkszbits = dsb->blkszbits;
+ /* 9(512 bytes) + LOG_SECTORS_PER_BLOCK == LOG_BLOCK_SIZE */
+ if (blkszbits != LOG_BLOCK_SIZE) {
--- /dev/null
+From 1e5654de0f51890f88abd409ebf4867782431e81 Mon Sep 17 00:00:00 2001
+From: Namjae Jeon <namjae.jeon@samsung.com>
+Date: Fri, 11 Jun 2021 09:40:24 +0900
+Subject: exfat: handle wrong stream entry size in exfat_readdir()
+
+From: Namjae Jeon <namjae.jeon@samsung.com>
+
+commit 1e5654de0f51890f88abd409ebf4867782431e81 upstream.
+
+The compatibility issue between linux exfat and exfat of some camera
+company was reported from Florian. In their exfat, if the number of files
+exceeds any limit, the DataLength in stream entry of the directory is
+no longer updated. So some files created from camera does not show in
+linux exfat. because linux exfat doesn't allow that cpos becomes larger
+than DataLength of stream entry. This patch check DataLength in stream
+entry only if the type is ALLOC_NO_FAT_CHAIN and add the check ensure
+that dentry offset does not exceed max dentries size(256 MB) to avoid
+the circular FAT chain issue.
+
+Fixes: ca06197382bd ("exfat: add directory operations")
+Cc: stable@vger.kernel.org # v5.9
+Reported-by: Florian Cramer <flrncrmr@gmail.com>
+Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
+Tested-by: Chris Down <chris@chrisdown.name>
+Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exfat/dir.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/fs/exfat/dir.c
++++ b/fs/exfat/dir.c
+@@ -62,7 +62,7 @@ static void exfat_get_uniname_from_ext_e
+ static int exfat_readdir(struct inode *inode, loff_t *cpos, struct exfat_dir_entry *dir_entry)
+ {
+ int i, dentries_per_clu, dentries_per_clu_bits = 0, num_ext;
+- unsigned int type, clu_offset;
++ unsigned int type, clu_offset, max_dentries;
+ sector_t sector;
+ struct exfat_chain dir, clu;
+ struct exfat_uni_name uni_name;
+@@ -85,6 +85,8 @@ static int exfat_readdir(struct inode *i
+
+ dentries_per_clu = sbi->dentries_per_clu;
+ dentries_per_clu_bits = ilog2(dentries_per_clu);
++ max_dentries = (unsigned int)min_t(u64, MAX_EXFAT_DENTRIES,
++ (u64)sbi->num_clusters << dentries_per_clu_bits);
+
+ clu_offset = dentry >> dentries_per_clu_bits;
+ exfat_chain_dup(&clu, &dir);
+@@ -108,7 +110,7 @@ static int exfat_readdir(struct inode *i
+ }
+ }
+
+- while (clu.dir != EXFAT_EOF_CLUSTER) {
++ while (clu.dir != EXFAT_EOF_CLUSTER && dentry < max_dentries) {
+ i = dentry & (dentries_per_clu - 1);
+
+ for ( ; i < dentries_per_clu; i++, dentry++) {
+@@ -244,7 +246,7 @@ static int exfat_iterate(struct file *fi
+ if (err)
+ goto unlock;
+ get_new:
+- if (cpos >= i_size_read(inode))
++ if (ei->flags == ALLOC_NO_FAT_CHAIN && cpos >= i_size_read(inode))
+ goto end_of_dir;
+
+ err = exfat_readdir(inode, &cpos, &de);
--- /dev/null
+From 77f30bfcfcf484da7208affd6a9e63406420bf91 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Thu, 27 May 2021 16:52:36 -0700
+Subject: fscrypt: don't ignore minor_hash when hash is 0
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 77f30bfcfcf484da7208affd6a9e63406420bf91 upstream.
+
+When initializing a no-key name, fscrypt_fname_disk_to_usr() sets the
+minor_hash to 0 if the (major) hash is 0.
+
+This doesn't make sense because 0 is a valid hash code, so we shouldn't
+ignore the filesystem-provided minor_hash in that case. Fix this by
+removing the special case for 'hash == 0'.
+
+This is an old bug that appears to have originated when the encryption
+code in ext4 and f2fs was moved into fs/crypto/. The original ext4 and
+f2fs code passed the hash by pointer instead of by value. So
+'if (hash)' actually made sense then, as it was checking whether a
+pointer was NULL. But now the hashes are passed by value, and
+filesystems just pass 0 for any hashes they don't have. There is no
+need to handle this any differently from the hashes actually being 0.
+
+It is difficult to reproduce this bug, as it only made a difference in
+the case where a filename's 32-bit major hash happened to be 0.
+However, it probably had the largest chance of causing problems on
+ubifs, since ubifs uses minor_hash to do lookups of no-key names, in
+addition to using it as a readdir cookie. ext4 only uses minor_hash as
+a readdir cookie, and f2fs doesn't use minor_hash at all.
+
+Fixes: 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto")
+Cc: <stable@vger.kernel.org> # v4.6+
+Link: https://lore.kernel.org/r/20210527235236.2376556-1-ebiggers@kernel.org
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/crypto/fname.c | 10 +++-------
+ 1 file changed, 3 insertions(+), 7 deletions(-)
+
+--- a/fs/crypto/fname.c
++++ b/fs/crypto/fname.c
+@@ -344,13 +344,9 @@ int fscrypt_fname_disk_to_usr(const stru
+ offsetof(struct fscrypt_nokey_name, sha256));
+ BUILD_BUG_ON(BASE64_CHARS(FSCRYPT_NOKEY_NAME_MAX) > NAME_MAX);
+
+- if (hash) {
+- nokey_name.dirhash[0] = hash;
+- nokey_name.dirhash[1] = minor_hash;
+- } else {
+- nokey_name.dirhash[0] = 0;
+- nokey_name.dirhash[1] = 0;
+- }
++ nokey_name.dirhash[0] = hash;
++ nokey_name.dirhash[1] = minor_hash;
++
+ if (iname->len <= sizeof(nokey_name.bytes)) {
+ memcpy(nokey_name.bytes, iname->name, iname->len);
+ size = offsetof(struct fscrypt_nokey_name, bytes[iname->len]);
--- /dev/null
+From 2fc2b430f559fdf32d5d1dd5ceaa40e12fb77bdf Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Sat, 5 Jun 2021 00:50:33 -0700
+Subject: fscrypt: fix derivation of SipHash keys on big endian CPUs
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 2fc2b430f559fdf32d5d1dd5ceaa40e12fb77bdf upstream.
+
+Typically, the cryptographic APIs that fscrypt uses take keys as byte
+arrays, which avoids endianness issues. However, siphash_key_t is an
+exception. It is defined as 'u64 key[2];', i.e. the 128-bit key is
+expected to be given directly as two 64-bit words in CPU endianness.
+
+fscrypt_derive_dirhash_key() and fscrypt_setup_iv_ino_lblk_32_key()
+forgot to take this into account. Therefore, the SipHash keys used to
+index encrypted+casefolded directories differ on big endian vs. little
+endian platforms, as do the SipHash keys used to hash inode numbers for
+IV_INO_LBLK_32-encrypted directories. This makes such directories
+non-portable between these platforms.
+
+Fix this by always using the little endian order. This is a breaking
+change for big endian platforms, but this should be fine in practice
+since these features (encrypt+casefold support, and the IV_INO_LBLK_32
+flag) aren't known to actually be used on any big endian platforms yet.
+
+Fixes: aa408f835d02 ("fscrypt: derive dirhash key for casefolded directories")
+Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies")
+Cc: <stable@vger.kernel.org> # v5.6+
+Link: https://lore.kernel.org/r/20210605075033.54424-1-ebiggers@kernel.org
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/crypto/keysetup.c | 40 ++++++++++++++++++++++++++++++++--------
+ 1 file changed, 32 insertions(+), 8 deletions(-)
+
+--- a/fs/crypto/keysetup.c
++++ b/fs/crypto/keysetup.c
+@@ -210,15 +210,40 @@ out_unlock:
+ return err;
+ }
+
++/*
++ * Derive a SipHash key from the given fscrypt master key and the given
++ * application-specific information string.
++ *
++ * Note that the KDF produces a byte array, but the SipHash APIs expect the key
++ * as a pair of 64-bit words. Therefore, on big endian CPUs we have to do an
++ * endianness swap in order to get the same results as on little endian CPUs.
++ */
++static int fscrypt_derive_siphash_key(const struct fscrypt_master_key *mk,
++ u8 context, const u8 *info,
++ unsigned int infolen, siphash_key_t *key)
++{
++ int err;
++
++ err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf, context, info, infolen,
++ (u8 *)key, sizeof(*key));
++ if (err)
++ return err;
++
++ BUILD_BUG_ON(sizeof(*key) != 16);
++ BUILD_BUG_ON(ARRAY_SIZE(key->key) != 2);
++ le64_to_cpus(&key->key[0]);
++ le64_to_cpus(&key->key[1]);
++ return 0;
++}
++
+ int fscrypt_derive_dirhash_key(struct fscrypt_info *ci,
+ const struct fscrypt_master_key *mk)
+ {
+ int err;
+
+- err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf, HKDF_CONTEXT_DIRHASH_KEY,
+- ci->ci_nonce, FSCRYPT_FILE_NONCE_SIZE,
+- (u8 *)&ci->ci_dirhash_key,
+- sizeof(ci->ci_dirhash_key));
++ err = fscrypt_derive_siphash_key(mk, HKDF_CONTEXT_DIRHASH_KEY,
++ ci->ci_nonce, FSCRYPT_FILE_NONCE_SIZE,
++ &ci->ci_dirhash_key);
+ if (err)
+ return err;
+ ci->ci_dirhash_key_initialized = true;
+@@ -253,10 +278,9 @@ static int fscrypt_setup_iv_ino_lblk_32_
+ if (mk->mk_ino_hash_key_initialized)
+ goto unlock;
+
+- err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf,
+- HKDF_CONTEXT_INODE_HASH_KEY, NULL, 0,
+- (u8 *)&mk->mk_ino_hash_key,
+- sizeof(mk->mk_ino_hash_key));
++ err = fscrypt_derive_siphash_key(mk,
++ HKDF_CONTEXT_INODE_HASH_KEY,
++ NULL, 0, &mk->mk_ino_hash_key);
+ if (err)
+ goto unlock;
+ /* pairs with smp_load_acquire() above */
--- /dev/null
+From 976517f162a05f4315b2373fd11585c395506259 Mon Sep 17 00:00:00 2001
+From: Pavel Begunkov <asml.silence@gmail.com>
+Date: Wed, 9 Jun 2021 12:07:25 +0100
+Subject: io_uring: fix blocking inline submission
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+commit 976517f162a05f4315b2373fd11585c395506259 upstream.
+
+There is a complaint against sys_io_uring_enter() blocking if it submits
+stdin reads. The problem is in __io_file_supports_async(), which
+sees that it's a cdev and allows it to be processed inline.
+
+Punt char devices using generic rules of io_file_supports_async(),
+including checking for presence of *_iter() versions of rw callbacks.
+Apparently, it will affect most of cdevs with some exceptions like
+null and zero devices.
+
+Cc: stable@vger.kernel.org
+Reported-by: Birk Hirdman <lonjil@gmail.com>
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Link: https://lore.kernel.org/r/d60270856b8a4560a639ef5f76e55eb563633599.1623236455.git.asml.silence@gmail.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/io_uring.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -2770,7 +2770,7 @@ static bool io_file_supports_async(struc
+ return true;
+ return false;
+ }
+- if (S_ISCHR(mode) || S_ISSOCK(mode))
++ if (S_ISSOCK(mode))
+ return true;
+ if (S_ISREG(mode)) {
+ if (io_bdev_nowait(file->f_inode->i_sb->s_bdev) &&
--- /dev/null
+From d6fbfdbc12745ce24bcd348dbf7e652353b3e59c Mon Sep 17 00:00:00 2001
+From: Sibi Sankar <sibis@codeaurora.org>
+Date: Wed, 16 Jun 2021 23:12:58 +0530
+Subject: mailbox: qcom-ipcc: Fix IPCC mbox channel exhaustion
+
+From: Sibi Sankar <sibis@codeaurora.org>
+
+commit d6fbfdbc12745ce24bcd348dbf7e652353b3e59c upstream.
+
+Fix IPCC (Inter-Processor Communication Controller) channel exhaustion by
+setting the channel private data to NULL on mbox shutdown.
+
+Err Logs:
+remoteproc: MBA booted without debug policy, loading mpss
+remoteproc: glink-edge: failed to acquire IPC channel
+remoteproc: failed to probe subdevices for remoteproc: -16
+
+Fixes: fa74a0257f45 ("mailbox: Add support for Qualcomm IPCC")
+Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
+Cc: stable@vger.kernel.org
+Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mailbox/qcom-ipcc.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/mailbox/qcom-ipcc.c
++++ b/drivers/mailbox/qcom-ipcc.c
+@@ -155,6 +155,11 @@ static int qcom_ipcc_mbox_send_data(stru
+ return 0;
+ }
+
++static void qcom_ipcc_mbox_shutdown(struct mbox_chan *chan)
++{
++ chan->con_priv = NULL;
++}
++
+ static struct mbox_chan *qcom_ipcc_mbox_xlate(struct mbox_controller *mbox,
+ const struct of_phandle_args *ph)
+ {
+@@ -184,6 +189,7 @@ static struct mbox_chan *qcom_ipcc_mbox_
+
+ static const struct mbox_chan_ops ipcc_mbox_chan_ops = {
+ .send_data = qcom_ipcc_mbox_send_data,
++ .shutdown = qcom_ipcc_mbox_shutdown,
+ };
+
+ static int qcom_ipcc_setup_mbox(struct qcom_ipcc *ipcc)
--- /dev/null
+From 29dd19e3ac7b2a8671ebeac02859232ce0e34f58 Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Date: Tue, 11 May 2021 17:03:21 +0200
+Subject: media: exynos4-is: remove a now unused integer
+
+From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+
+commit 29dd19e3ac7b2a8671ebeac02859232ce0e34f58 upstream.
+
+The usage of pm_runtime_resume_and_get() removed the need of a
+temporary integer. So, drop it.
+
+Fixes: 59f96244af94 ("media: exynos4-is: fix pm_runtime_get_sync() usage count")
+Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/exynos4-is/media-dev.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/media/platform/exynos4-is/media-dev.c
++++ b/drivers/media/platform/exynos4-is/media-dev.c
+@@ -1280,7 +1280,6 @@ static DEVICE_ATTR(subdev_conf_mode, S_I
+ static int cam_clk_prepare(struct clk_hw *hw)
+ {
+ struct cam_clk *camclk = to_cam_clk(hw);
+- int ret;
+
+ if (camclk->fmd->pmf == NULL)
+ return -ENODEV;
--- /dev/null
+From 70b52f09080565030a530a784f1c9948a7f48ca3 Mon Sep 17 00:00:00 2001
+From: Bean Huo <beanhuo@micron.com>
+Date: Tue, 4 May 2021 22:32:09 +0200
+Subject: mmc: block: Disable CMDQ on the ioctl path
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Bean Huo <beanhuo@micron.com>
+
+commit 70b52f09080565030a530a784f1c9948a7f48ca3 upstream.
+
+According to the eMMC Spec:
+"When command queuing is enabled (CMDQ Mode En bit in CMDQ_MODE_EN
+field is set to ‘1’) class 11 commands are the only method through
+which data transfer tasks can be issued. Existing data transfer
+commands, namely CMD18/CMD17 and CMD25/CMD24, are not supported when
+command queuing is enabled."
+which means if CMDQ is enabled, the FFU commands will not be supported.
+To fix this issue, just simply disable CMDQ on the ioctl path, and
+re-enable CMDQ once ioctl request is completed.
+
+Tested-by: Michael Brunner <Michael.Brunner@kontron.com>
+Signed-off-by: Bean Huo <beanhuo@micron.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Fixes: 1e8e55b67030 (mmc: block: Add CQE support)
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210504203209.361597-1-huobean@gmail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/block.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/mmc/core/block.c
++++ b/drivers/mmc/core/block.c
+@@ -1003,6 +1003,12 @@ static void mmc_blk_issue_drv_op(struct
+
+ switch (mq_rq->drv_op) {
+ case MMC_DRV_OP_IOCTL:
++ if (card->ext_csd.cmdq_en) {
++ ret = mmc_cmdq_disable(card);
++ if (ret)
++ break;
++ }
++ fallthrough;
+ case MMC_DRV_OP_IOCTL_RPMB:
+ idata = mq_rq->drv_op_data;
+ for (i = 0, ret = 0; i < mq_rq->ioc_count; i++) {
+@@ -1013,6 +1019,8 @@ static void mmc_blk_issue_drv_op(struct
+ /* Always switch back to main area after RPMB access */
+ if (rpmb_ioctl)
+ mmc_blk_part_switch(card, 0);
++ else if (card->reenable_cmdq && !card->ext_csd.cmdq_en)
++ mmc_cmdq_enable(card);
+ break;
+ case MMC_DRV_OP_BOOT_WP:
+ ret = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_WP,
--- /dev/null
+From 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 21 May 2021 15:30:26 +0200
+Subject: mmc: vub3000: fix control-request direction
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 upstream.
+
+The direction of the pipe argument must match the request-type direction
+bit or control requests may fail depending on the host-controller-driver
+implementation.
+
+Fix the SET_ROM_WAIT_STATES request which erroneously used
+usb_rcvctrlpipe().
+
+Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
+Cc: stable@vger.kernel.org # 3.0
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://lore.kernel.org/r/20210521133026.17296-1-johan@kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/vub300.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/vub300.c
++++ b/drivers/mmc/host/vub300.c
+@@ -2279,7 +2279,7 @@ static int vub300_probe(struct usb_inter
+ if (retval < 0)
+ goto error5;
+ retval =
+- usb_control_msg(vub300->udev, usb_rcvctrlpipe(vub300->udev, 0),
++ usb_control_msg(vub300->udev, usb_sndctrlpipe(vub300->udev, 0),
+ SET_ROM_WAIT_STATES,
+ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ firmware_rom_wait_states, 0x0000, NULL, 0, HZ);
--- /dev/null
+From 40445fd2c9fa427297acdfcc2c573ff10493f209 Mon Sep 17 00:00:00 2001
+From: Javed Hasan <jhasan@marvell.com>
+Date: Thu, 3 Jun 2021 03:14:03 -0700
+Subject: scsi: fc: Correct RHBA attributes length
+
+From: Javed Hasan <jhasan@marvell.com>
+
+commit 40445fd2c9fa427297acdfcc2c573ff10493f209 upstream.
+
+As per the FC-GS-5 specification, attribute lengths of node_name and
+manufacturer should in range of "4 to 64 Bytes" only.
+
+Link: https://lore.kernel.org/r/20210603101404.7841-2-jhasan@marvell.com
+Fixes: e721eb0616f6 ("scsi: scsi_transport_fc: Match HBA Attribute Length with HBAAPI V2.0 definitions")
+CC: stable@vger.kernel.org
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Javed Hasan <jhasan@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/scsi/fc/fc_ms.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/scsi/fc/fc_ms.h
++++ b/include/scsi/fc/fc_ms.h
+@@ -63,8 +63,8 @@ enum fc_fdmi_hba_attr_type {
+ * HBA Attribute Length
+ */
+ #define FC_FDMI_HBA_ATTR_NODENAME_LEN 8
+-#define FC_FDMI_HBA_ATTR_MANUFACTURER_LEN 80
+-#define FC_FDMI_HBA_ATTR_SERIALNUMBER_LEN 80
++#define FC_FDMI_HBA_ATTR_MANUFACTURER_LEN 64
++#define FC_FDMI_HBA_ATTR_SERIALNUMBER_LEN 64
+ #define FC_FDMI_HBA_ATTR_MODEL_LEN 256
+ #define FC_FDMI_HBA_ATTR_MODELDESCR_LEN 256
+ #define FC_FDMI_HBA_ATTR_HARDWAREVERSION_LEN 256
--- /dev/null
+From 6ecdafaec79d4b3388a5b017245f23a0ff9d852d Mon Sep 17 00:00:00 2001
+From: Varun Prakash <varun@chelsio.com>
+Date: Wed, 14 Apr 2021 18:09:09 +0530
+Subject: scsi: target: cxgbit: Unmap DMA buffer before calling target_execute_cmd()
+
+From: Varun Prakash <varun@chelsio.com>
+
+commit 6ecdafaec79d4b3388a5b017245f23a0ff9d852d upstream.
+
+Instead of calling dma_unmap_sg() after completing WRITE I/O, call
+dma_unmap_sg() before calling target_execute_cmd() to sync the DMA buffer.
+
+Link: https://lore.kernel.org/r/1618403949-3443-1-git-send-email-varun@chelsio.com
+Cc: <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Varun Prakash <varun@chelsio.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/target/iscsi/cxgbit/cxgbit_ddp.c | 19 ++++++++++---------
+ drivers/target/iscsi/cxgbit/cxgbit_target.c | 21 ++++++++++++++++++---
+ 2 files changed, 28 insertions(+), 12 deletions(-)
+
+--- a/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
++++ b/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
+@@ -265,12 +265,13 @@ void cxgbit_unmap_cmd(struct iscsi_conn
+ struct cxgbit_cmd *ccmd = iscsit_priv_cmd(cmd);
+
+ if (ccmd->release) {
+- struct cxgbi_task_tag_info *ttinfo = &ccmd->ttinfo;
+-
+- if (ttinfo->sgl) {
++ if (cmd->se_cmd.se_cmd_flags & SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC) {
++ put_page(sg_page(&ccmd->sg));
++ } else {
+ struct cxgbit_sock *csk = conn->context;
+ struct cxgbit_device *cdev = csk->com.cdev;
+ struct cxgbi_ppm *ppm = cdev2ppm(cdev);
++ struct cxgbi_task_tag_info *ttinfo = &ccmd->ttinfo;
+
+ /* Abort the TCP conn if DDP is not complete to
+ * avoid any possibility of DDP after freeing
+@@ -280,14 +281,14 @@ void cxgbit_unmap_cmd(struct iscsi_conn
+ cmd->se_cmd.data_length))
+ cxgbit_abort_conn(csk);
+
++ if (unlikely(ttinfo->sgl)) {
++ dma_unmap_sg(&ppm->pdev->dev, ttinfo->sgl,
++ ttinfo->nents, DMA_FROM_DEVICE);
++ ttinfo->nents = 0;
++ ttinfo->sgl = NULL;
++ }
+ cxgbi_ppm_ppod_release(ppm, ttinfo->idx);
+-
+- dma_unmap_sg(&ppm->pdev->dev, ttinfo->sgl,
+- ttinfo->nents, DMA_FROM_DEVICE);
+- } else {
+- put_page(sg_page(&ccmd->sg));
+ }
+-
+ ccmd->release = false;
+ }
+ }
+--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c
++++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c
+@@ -997,17 +997,18 @@ static int cxgbit_handle_iscsi_dataout(s
+ struct scatterlist *sg_start;
+ struct iscsi_conn *conn = csk->conn;
+ struct iscsi_cmd *cmd = NULL;
++ struct cxgbit_cmd *ccmd;
++ struct cxgbi_task_tag_info *ttinfo;
+ struct cxgbit_lro_pdu_cb *pdu_cb = cxgbit_rx_pdu_cb(csk->skb);
+ struct iscsi_data *hdr = (struct iscsi_data *)pdu_cb->hdr;
+ u32 data_offset = be32_to_cpu(hdr->offset);
+- u32 data_len = pdu_cb->dlen;
++ u32 data_len = ntoh24(hdr->dlength);
+ int rc, sg_nents, sg_off;
+ bool dcrc_err = false;
+
+ if (pdu_cb->flags & PDUCBF_RX_DDP_CMP) {
+ u32 offset = be32_to_cpu(hdr->offset);
+ u32 ddp_data_len;
+- u32 payload_length = ntoh24(hdr->dlength);
+ bool success = false;
+
+ cmd = iscsit_find_cmd_from_itt_or_dump(conn, hdr->itt, 0);
+@@ -1022,7 +1023,7 @@ static int cxgbit_handle_iscsi_dataout(s
+ cmd->data_sn = be32_to_cpu(hdr->datasn);
+
+ rc = __iscsit_check_dataout_hdr(conn, (unsigned char *)hdr,
+- cmd, payload_length, &success);
++ cmd, data_len, &success);
+ if (rc < 0)
+ return rc;
+ else if (!success)
+@@ -1060,6 +1061,20 @@ static int cxgbit_handle_iscsi_dataout(s
+ cxgbit_skb_copy_to_sg(csk->skb, sg_start, sg_nents, skip);
+ }
+
++ ccmd = iscsit_priv_cmd(cmd);
++ ttinfo = &ccmd->ttinfo;
++
++ if (ccmd->release && ttinfo->sgl &&
++ (cmd->se_cmd.data_length == (cmd->write_data_done + data_len))) {
++ struct cxgbit_device *cdev = csk->com.cdev;
++ struct cxgbi_ppm *ppm = cdev2ppm(cdev);
++
++ dma_unmap_sg(&ppm->pdev->dev, ttinfo->sgl, ttinfo->nents,
++ DMA_FROM_DEVICE);
++ ttinfo->nents = 0;
++ ttinfo->sgl = NULL;
++ }
++
+ check_payload:
+
+ rc = iscsit_check_dataout_payload(cmd, hdr, dcrc_err);
perf-llvm-return-enomem-when-asprintf-fails.patch
csky-fix-syscache.c-fallthrough-warning.patch
csky-syscache-fixup-duplicate-cache-flush.patch
+exfat-handle-wrong-stream-entry-size-in-exfat_readdir.patch
+scsi-fc-correct-rhba-attributes-length.patch
+scsi-target-cxgbit-unmap-dma-buffer-before-calling-target_execute_cmd.patch
+mailbox-qcom-ipcc-fix-ipcc-mbox-channel-exhaustion.patch
+fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch
+fscrypt-fix-derivation-of-siphash-keys-on-big-endian-cpus.patch
+tpm-replace-warn_once-with-dev_err_once-in-tpm_tis_status.patch
+erofs-fix-error-return-code-in-erofs_read_superblock.patch
+block-return-the-correct-bvec-when-checking-for-gaps.patch
+io_uring-fix-blocking-inline-submission.patch
+mmc-block-disable-cmdq-on-the-ioctl-path.patch
+mmc-vub3000-fix-control-request-direction.patch
+media-exynos4-is-remove-a-now-unused-integer.patch
--- /dev/null
+From 0178f9d0f60ba07e09bab57381a3ef18e2c1fd7f Mon Sep 17 00:00:00 2001
+From: Jarkko Sakkinen <jarkko@kernel.org>
+Date: Wed, 9 Jun 2021 16:26:19 +0300
+Subject: tpm: Replace WARN_ONCE() with dev_err_once() in tpm_tis_status()
+
+From: Jarkko Sakkinen <jarkko@kernel.org>
+
+commit 0178f9d0f60ba07e09bab57381a3ef18e2c1fd7f upstream.
+
+Do not tear down the system when getting invalid status from a TPM chip.
+This can happen when panic-on-warn is used.
+
+Instead, introduce TPM_TIS_INVALID_STATUS bitflag and use it to trigger
+once the error reporting per chip. In addition, print out the value of
+TPM_STS for improved forensics.
+
+Link: https://lore.kernel.org/keyrings/YKzlTR1AzUigShtZ@kroah.com/
+Fixes: 55707d531af6 ("tpm_tis: Add a check for invalid status")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/tpm_tis_core.c | 25 ++++++++++++++++++-------
+ drivers/char/tpm/tpm_tis_core.h | 3 ++-
+ 2 files changed, 20 insertions(+), 8 deletions(-)
+
+--- a/drivers/char/tpm/tpm_tis_core.c
++++ b/drivers/char/tpm/tpm_tis_core.c
+@@ -196,13 +196,24 @@ static u8 tpm_tis_status(struct tpm_chip
+ return 0;
+
+ if (unlikely((status & TPM_STS_READ_ZERO) != 0)) {
+- /*
+- * If this trips, the chances are the read is
+- * returning 0xff because the locality hasn't been
+- * acquired. Usually because tpm_try_get_ops() hasn't
+- * been called before doing a TPM operation.
+- */
+- WARN_ONCE(1, "TPM returned invalid status\n");
++ if (!test_and_set_bit(TPM_TIS_INVALID_STATUS, &priv->flags)) {
++ /*
++ * If this trips, the chances are the read is
++ * returning 0xff because the locality hasn't been
++ * acquired. Usually because tpm_try_get_ops() hasn't
++ * been called before doing a TPM operation.
++ */
++ dev_err(&chip->dev, "invalid TPM_STS.x 0x%02x, dumping stack for forensics\n",
++ status);
++
++ /*
++ * Dump stack for forensics, as invalid TPM_STS.x could be
++ * potentially triggered by impaired tpm_try_get_ops() or
++ * tpm_find_get_ops().
++ */
++ dump_stack();
++ }
++
+ return 0;
+ }
+
+--- a/drivers/char/tpm/tpm_tis_core.h
++++ b/drivers/char/tpm/tpm_tis_core.h
+@@ -83,6 +83,7 @@ enum tis_defaults {
+
+ enum tpm_tis_flags {
+ TPM_TIS_ITPM_WORKAROUND = BIT(0),
++ TPM_TIS_INVALID_STATUS = BIT(1),
+ };
+
+ struct tpm_tis_data {
+@@ -90,7 +91,7 @@ struct tpm_tis_data {
+ int locality;
+ int irq;
+ bool irq_tested;
+- unsigned int flags;
++ unsigned long flags;
+ void __iomem *ilb_base_addr;
+ u16 clkrun_enabled;
+ wait_queue_head_t int_queue;