--- /dev/null
+From 0d3bbd7488a071ed0b3a34c8385da7ff2437cfce Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Jul 2021 16:42:26 +0200
+Subject: ARM: tegra: tamonten: Fix UART pad setting
+
+From: Andreas Obergschwandtner <andreas.obergschwandtner@gmail.com>
+
+[ Upstream commit 2270ad2f4e123336af685ecedd1618701cb4ca1e ]
+
+This patch fixes the tristate and pullup configuration for UART 1 to 3
+on the Tamonten SOM.
+
+Signed-off-by: Andreas Obergschwandtner <andreas.obergschwandtner@gmail.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/tegra20-tamonten.dtsi | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
+index 13d4e6185275..c70d1ec02957 100644
+--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
++++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
+@@ -180,8 +180,9 @@ conf_ata {
+ nvidia,pins = "ata", "atb", "atc", "atd", "ate",
+ "cdev1", "cdev2", "dap1", "dtb", "gma",
+ "gmb", "gmc", "gmd", "gme", "gpu7",
+- "gpv", "i2cp", "pta", "rm", "slxa",
+- "slxk", "spia", "spib", "uac";
++ "gpv", "i2cp", "irrx", "irtx", "pta",
++ "rm", "slxa", "slxk", "spia", "spib",
++ "uac";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ };
+@@ -206,7 +207,7 @@ conf_crtp {
+ conf_ddc {
+ nvidia,pins = "ddc", "dta", "dtd", "kbca",
+ "kbcb", "kbcc", "kbcd", "kbce", "kbcf",
+- "sdc";
++ "sdc", "uad", "uca";
+ nvidia,pull = <TEGRA_PIN_PULL_UP>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ };
+@@ -216,10 +217,9 @@ conf_hdint {
+ "lvp0", "owc", "sdb";
+ nvidia,tristate = <TEGRA_PIN_ENABLE>;
+ };
+- conf_irrx {
+- nvidia,pins = "irrx", "irtx", "sdd", "spic",
+- "spie", "spih", "uaa", "uab", "uad",
+- "uca", "ucb";
++ conf_sdd {
++ nvidia,pins = "sdd", "spic", "spie", "spih",
++ "uaa", "uab", "ucb";
+ nvidia,pull = <TEGRA_PIN_PULL_UP>;
+ nvidia,tristate = <TEGRA_PIN_ENABLE>;
+ };
+--
+2.30.2
+
--- /dev/null
+From 249dab5edf8fbd0a247344d69442a0f61bc00155 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 19 Jun 2021 09:29:14 -0400
+Subject: ath9k: fix OOB read ar9300_eeprom_restore_internal
+
+From: Zekun Shen <bruceshenzk@gmail.com>
+
+[ Upstream commit 23151b9ae79e3bc4f6a0c4cd3a7f355f68dad128 ]
+
+Bad header can have large length field which can cause OOB.
+cptr is the last bytes for read, and the eeprom is parsed
+from high to low address. The OOB, triggered by the condition
+length > cptr could cause memory error with a read on
+negative index.
+
+There are some sanity check around length, but it is not
+compared with cptr (the remaining bytes). Here, the
+corrupted/bad EEPROM can cause panic.
+
+I was able to reproduce the crash, but I cannot find the
+log and the reproducer now. After I applied the patch, the
+bug is no longer reproducible.
+
+Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/YM3xKsQJ0Hw2hjrc@Zekuns-MBP-16.fios-router.home
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+index c876dc2437b0..96e1f54cccaf 100644
+--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
++++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+@@ -3345,7 +3345,8 @@ static int ar9300_eeprom_restore_internal(struct ath_hw *ah,
+ "Found block at %x: code=%d ref=%d length=%d major=%d minor=%d\n",
+ cptr, code, reference, length, major, minor);
+ if ((!AR_SREV_9485(ah) && length >= 1024) ||
+- (AR_SREV_9485(ah) && length > EEPROM_DATA_LEN_9485)) {
++ (AR_SREV_9485(ah) && length > EEPROM_DATA_LEN_9485) ||
++ (length > cptr)) {
+ ath_dbg(common, EEPROM, "Skipping bad header\n");
+ cptr -= COMP_HDR_LEN;
+ continue;
+--
+2.30.2
+
--- /dev/null
+From 03ec1314fb8090465244f271dea50dd51caf2d09 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 28 Jul 2021 15:51:04 +0800
+Subject: Bluetooth: skip invalid hci_sync_conn_complete_evt
+
+From: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
+
+[ Upstream commit 92fe24a7db751b80925214ede43f8d2be792ea7b ]
+
+Syzbot reported a corrupted list in kobject_add_internal [1]. This
+happens when multiple HCI_EV_SYNC_CONN_COMPLETE event packets with
+status 0 are sent for the same HCI connection. This causes us to
+register the device more than once which corrupts the kset list.
+
+As this is forbidden behavior, we add a check for whether we're
+trying to process the same HCI_EV_SYNC_CONN_COMPLETE event multiple
+times for one connection. If that's the case, the event is invalid, so
+we report an error that the device is misbehaving, and ignore the
+packet.
+
+Link: https://syzkaller.appspot.com/bug?extid=66264bf2fd0476be7e6c [1]
+Reported-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com
+Tested-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com
+Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/hci_event.c | 15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
+index 7ed3c7df271a..6528ecc3a3bc 100644
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3747,6 +3747,21 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev,
+
+ switch (ev->status) {
+ case 0x00:
++ /* The synchronous connection complete event should only be
++ * sent once per new connection. Receiving a successful
++ * complete event when the connection status is already
++ * BT_CONNECTED means that the device is misbehaving and sent
++ * multiple complete event packets for the same new connection.
++ *
++ * Registering the device more than once can corrupt kernel
++ * memory, hence upon detecting this invalid event, we report
++ * an error and ignore the packet.
++ */
++ if (conn->state == BT_CONNECTED) {
++ bt_dev_err(hdev, "Ignoring connect complete event for existing connection");
++ goto unlock;
++ }
++
+ conn->handle = __le16_to_cpu(ev->handle);
+ conn->state = BT_CONNECTED;
+ conn->type = ev->link_type;
+--
+2.30.2
+
--- /dev/null
+From c42bc9850984843a6e4ab50ed9a2dca0d7fe0d54 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 21 Jul 2021 12:38:22 +0200
+Subject: bpf/tests: Do not PASS tests without actually testing the result
+
+From: Johan Almbladh <johan.almbladh@anyfinetworks.com>
+
+[ Upstream commit 2b7e9f25e590726cca76700ebdb10e92a7a72ca1 ]
+
+Each test case can have a set of sub-tests, where each sub-test can
+run the cBPF/eBPF test snippet with its own data_size and expected
+result. Before, the end of the sub-test array was indicated by both
+data_size and result being zero. However, most or all of the internal
+eBPF tests has a data_size of zero already. When such a test also had
+an expected value of zero, the test was never run but reported as
+PASS anyway.
+
+Now the test runner always runs the first sub-test, regardless of the
+data_size and result values. The sub-test array zero-termination only
+applies for any additional sub-tests.
+
+There are other ways fix it of course, but this solution at least
+removes the surprise of eBPF tests with a zero result always succeeding.
+
+Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
+Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
+Link: https://lore.kernel.org/bpf/20210721103822.3755111-1-johan.almbladh@anyfinetworks.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/test_bpf.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/lib/test_bpf.c b/lib/test_bpf.c
+index 7db8d06006d8..cf2880d2ce3f 100644
+--- a/lib/test_bpf.c
++++ b/lib/test_bpf.c
+@@ -5399,7 +5399,14 @@ static int run_one(const struct bpf_prog *fp, struct bpf_test *test)
+ u64 duration;
+ u32 ret;
+
+- if (test->test[i].data_size == 0 &&
++ /*
++ * NOTE: Several sub-tests may be present, in which case
++ * a zero {data_size, result} tuple indicates the end of
++ * the sub-test array. The first test is always run,
++ * even if both data_size and result happen to be zero.
++ */
++ if (i > 0 &&
++ test->test[i].data_size == 0 &&
+ test->test[i].result == 0)
+ break;
+
+--
+2.30.2
+
--- /dev/null
+From b175f55df7a2859051b3aeca39236021cbae1b7f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 21 Jul 2021 12:40:58 +0200
+Subject: bpf/tests: Fix copy-and-paste error in double word test
+
+From: Johan Almbladh <johan.almbladh@anyfinetworks.com>
+
+[ Upstream commit ae7f47041d928b1a2f28717d095b4153c63cbf6a ]
+
+This test now operates on DW as stated instead of W, which was
+already covered by another test.
+
+Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
+Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
+Link: https://lore.kernel.org/bpf/20210721104058.3755254-1-johan.almbladh@anyfinetworks.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/test_bpf.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/test_bpf.c b/lib/test_bpf.c
+index b1495f586f29..7db8d06006d8 100644
+--- a/lib/test_bpf.c
++++ b/lib/test_bpf.c
+@@ -3983,8 +3983,8 @@ static struct bpf_test tests[] = {
+ .u.insns_int = {
+ BPF_LD_IMM64(R0, 0),
+ BPF_LD_IMM64(R1, 0xffffffffffffffffLL),
+- BPF_STX_MEM(BPF_W, R10, R1, -40),
+- BPF_LDX_MEM(BPF_W, R0, R10, -40),
++ BPF_STX_MEM(BPF_DW, R10, R1, -40),
++ BPF_LDX_MEM(BPF_DW, R0, R10, -40),
+ BPF_EXIT_INSN(),
+ },
+ INTERNAL,
+--
+2.30.2
+
--- /dev/null
+From 15d5931fc3d3df305323feea30e2c3fedc44e016 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 17 Aug 2021 22:55:10 +0800
+Subject: cifs: fix wrong release in sess_alloc_buffer() failed path
+
+From: Ding Hui <dinghui@sangfor.com.cn>
+
+[ Upstream commit d72c74197b70bc3c95152f351a568007bffa3e11 ]
+
+smb_buf is allocated by small_smb_init_no_tc(), and buf type is
+CIFS_SMALL_BUFFER, so we should use cifs_small_buf_release() to
+release it in failed path.
+
+Signed-off-by: Ding Hui <dinghui@sangfor.com.cn>
+Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/cifs/sess.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
+index 9bc7a29f88d6..2d3918cdcc28 100644
+--- a/fs/cifs/sess.c
++++ b/fs/cifs/sess.c
+@@ -602,7 +602,7 @@ sess_alloc_buffer(struct sess_data *sess_data, int wct)
+ return 0;
+
+ out_free_smb_buf:
+- kfree(smb_buf);
++ cifs_small_buf_release(smb_buf);
+ sess_data->iov[0].iov_base = NULL;
+ sess_data->iov[0].iov_len = 0;
+ sess_data->buf0_type = CIFS_NO_BUFFER;
+--
+2.30.2
+
--- /dev/null
+From df15af7adc108e304f8c39c49e3db12d2787c43e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 1 Jul 2021 14:56:38 -0400
+Subject: crypto: mxs-dcp - Use sg_mapping_iter to copy data
+
+From: Sean Anderson <sean.anderson@seco.com>
+
+[ Upstream commit 2e6d793e1bf07fe5e20cfbbdcec9e1af7e5097eb ]
+
+This uses the sg_pcopy_from_buffer to copy data, instead of doing it
+ourselves.
+
+In addition to reducing code size, this fixes the following oops
+resulting from failing to kmap the page:
+
+[ 68.896381] Unable to handle kernel NULL pointer dereference at virtual address 00000ab8
+[ 68.904539] pgd = 3561adb3
+[ 68.907475] [00000ab8] *pgd=00000000
+[ 68.911153] Internal error: Oops: 805 [#1] ARM
+[ 68.915618] Modules linked in: cfg80211 rfkill des_generic libdes arc4 libarc4 cbc ecb algif_skcipher sha256_generic libsha256 sha1_generic hmac aes_generic libaes cmac sha512_generic md5 md4 algif_hash af_alg i2c_imx i2c_core ci_hdrc_imx ci_hdrc mxs_dcp ulpi roles udc_core imx_sdma usbmisc_imx usb_common firmware_class virt_dma phy_mxs_usb nf_tables nfnetlink ip_tables x_tables ipv6 autofs4
+[ 68.950741] CPU: 0 PID: 139 Comm: mxs_dcp_chan/ae Not tainted 5.10.34 #296
+[ 68.958501] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
+[ 68.964710] PC is at memcpy+0xa8/0x330
+[ 68.968479] LR is at 0xd7b2bc9d
+[ 68.971638] pc : [<c053e7c8>] lr : [<d7b2bc9d>] psr: 000f0013
+[ 68.977920] sp : c2cbbee4 ip : 00000010 fp : 00000010
+[ 68.983159] r10: 00000000 r9 : c3283a40 r8 : 1a5a6f08
+[ 68.988402] r7 : 4bfe0ecc r6 : 76d8a220 r5 : c32f9050 r4 : 00000001
+[ 68.994945] r3 : 00000ab8 r2 : fffffff0 r1 : c32f9050 r0 : 00000ab8
+[ 69.001492] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
+[ 69.008646] Control: 10c53c7d Table: 83664059 DAC: 00000051
+[ 69.014414] Process mxs_dcp_chan/ae (pid: 139, stack limit = 0x667b57ab)
+[ 69.021133] Stack: (0xc2cbbee4 to 0xc2cbc000)
+[ 69.025519] bee0: c32f9050 c3235408 00000010 00000010 00000ab8 00000001 bf10406c
+[ 69.033720] bf00: 00000000 00000000 00000010 00000000 c32355d0 832fb080 00000000 c13de2fc
+[ 69.041921] bf20: c3628010 00000010 c33d5780 00000ab8 bf1067e8 00000002 c21e5010 c2cba000
+[ 69.050125] bf40: c32f8040 00000000 bf106a40 c32f9040 c3283a80 00000001 bf105240 c3234040
+[ 69.058327] bf60: ffffe000 c3204100 c2c69800 c2cba000 00000000 bf103b84 00000000 c2eddc54
+[ 69.066530] bf80: c3204144 c0140d1c c2cba000 c2c69800 c0140be8 00000000 00000000 00000000
+[ 69.074730] bfa0: 00000000 00000000 00000000 c0100114 00000000 00000000 00000000 00000000
+[ 69.082932] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+[ 69.091131] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
+[ 69.099364] [<c053e7c8>] (memcpy) from [<bf10406c>] (dcp_chan_thread_aes+0x4e8/0x840 [mxs_dcp])
+[ 69.108117] [<bf10406c>] (dcp_chan_thread_aes [mxs_dcp]) from [<c0140d1c>] (kthread+0x134/0x160)
+[ 69.116941] [<c0140d1c>] (kthread) from [<c0100114>] (ret_from_fork+0x14/0x20)
+[ 69.124178] Exception stack(0xc2cbbfb0 to 0xc2cbbff8)
+[ 69.129250] bfa0: 00000000 00000000 00000000 00000000
+[ 69.137450] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+[ 69.145648] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
+[ 69.152289] Code: e320f000 e4803004 e4804004 e4805004 (e4806004)
+
+Signed-off-by: Sean Anderson <sean.anderson@seco.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/crypto/mxs-dcp.c | 36 +++++++++---------------------------
+ 1 file changed, 9 insertions(+), 27 deletions(-)
+
+diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
+index c94db361138d..b83e8970a2db 100644
+--- a/drivers/crypto/mxs-dcp.c
++++ b/drivers/crypto/mxs-dcp.c
+@@ -297,21 +297,20 @@ static int mxs_dcp_aes_block_crypt(struct crypto_async_request *arq)
+
+ struct scatterlist *dst = req->dst;
+ struct scatterlist *src = req->src;
+- const int nents = sg_nents(req->src);
++ int dst_nents = sg_nents(dst);
+
+ const int out_off = DCP_BUF_SZ;
+ uint8_t *in_buf = sdcp->coh->aes_in_buf;
+ uint8_t *out_buf = sdcp->coh->aes_out_buf;
+
+- uint8_t *out_tmp, *src_buf, *dst_buf = NULL;
+ uint32_t dst_off = 0;
++ uint8_t *src_buf = NULL;
+ uint32_t last_out_len = 0;
+
+ uint8_t *key = sdcp->coh->aes_key;
+
+ int ret = 0;
+- int split = 0;
+- unsigned int i, len, clen, rem = 0, tlen = 0;
++ unsigned int i, len, clen, tlen = 0;
+ int init = 0;
+ bool limit_hit = false;
+
+@@ -329,7 +328,7 @@ static int mxs_dcp_aes_block_crypt(struct crypto_async_request *arq)
+ memset(key + AES_KEYSIZE_128, 0, AES_KEYSIZE_128);
+ }
+
+- for_each_sg(req->src, src, nents, i) {
++ for_each_sg(req->src, src, sg_nents(src), i) {
+ src_buf = sg_virt(src);
+ len = sg_dma_len(src);
+ tlen += len;
+@@ -354,34 +353,17 @@ static int mxs_dcp_aes_block_crypt(struct crypto_async_request *arq)
+ * submit the buffer.
+ */
+ if (actx->fill == out_off || sg_is_last(src) ||
+- limit_hit) {
++ limit_hit) {
+ ret = mxs_dcp_run_aes(actx, req, init);
+ if (ret)
+ return ret;
+ init = 0;
+
+- out_tmp = out_buf;
++ sg_pcopy_from_buffer(dst, dst_nents, out_buf,
++ actx->fill, dst_off);
++ dst_off += actx->fill;
+ last_out_len = actx->fill;
+- while (dst && actx->fill) {
+- if (!split) {
+- dst_buf = sg_virt(dst);
+- dst_off = 0;
+- }
+- rem = min(sg_dma_len(dst) - dst_off,
+- actx->fill);
+-
+- memcpy(dst_buf + dst_off, out_tmp, rem);
+- out_tmp += rem;
+- dst_off += rem;
+- actx->fill -= rem;
+-
+- if (dst_off == sg_dma_len(dst)) {
+- dst = sg_next(dst);
+- split = 0;
+- } else {
+- split = 1;
+- }
+- }
++ actx->fill = 0;
+ }
+ } while (len);
+
+--
+2.30.2
+
--- /dev/null
+From eef75cd4a8e9a67f469e2b32008f6f49cd1a506b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 30 Jul 2021 12:41:49 -0500
+Subject: gfs2: Don't call dlm after protocol is unmounted
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+[ Upstream commit d1340f80f0b8066321b499a376780da00560e857 ]
+
+In the gfs2 withdraw sequence, the dlm protocol is unmounted with a call
+to lm_unmount. After a withdraw, users are allowed to unmount the
+withdrawn file system. But at that point we may still have glocks left
+over that we need to free via unmount's call to gfs2_gl_hash_clear.
+These glocks may have never been completed because of whatever problem
+caused the withdraw (IO errors or whatever).
+
+Before this patch, function gdlm_put_lock would still try to call into
+dlm to unlock these leftover glocks, which resulted in dlm returning
+-EINVAL because the lock space was abandoned. These glocks were never
+freed because there was no mechanism after that to free them.
+
+This patch adds a check to gdlm_put_lock to see if the locking protocol
+was inactive (DFL_UNMOUNT flag) and if so, free the glock and not
+make the invalid call into dlm.
+
+I could have combined this "if" with the one that follows, related to
+leftover glock LVBs, but I felt the code was more readable with its own
+if clause.
+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/gfs2/lock_dlm.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/fs/gfs2/lock_dlm.c b/fs/gfs2/lock_dlm.c
+index 3cbc9147286d..da9f97911852 100644
+--- a/fs/gfs2/lock_dlm.c
++++ b/fs/gfs2/lock_dlm.c
+@@ -296,6 +296,11 @@ static void gdlm_put_lock(struct gfs2_glock *gl)
+ gfs2_sbstats_inc(gl, GFS2_LKS_DCOUNT);
+ gfs2_update_request_times(gl);
+
++ /* don't want to call dlm if we've unmounted the lock protocol */
++ if (test_bit(DFL_UNMOUNT, &ls->ls_recover_flags)) {
++ gfs2_glock_free(gl);
++ return;
++ }
+ /* don't want to skip dlm_unlock writing the lvb when lock has one */
+
+ if (test_bit(SDF_SKIP_DLM_UNLOCK, &sdp->sd_flags) &&
+--
+2.30.2
+
--- /dev/null
+From 9f161e3277800e6a1446db4575aab363a3d86b6a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Aug 2021 04:34:58 -0700
+Subject: gpu: drm: amd: amdgpu: amdgpu_i2c: fix possible
+ uninitialized-variable access in amdgpu_i2c_router_select_ddc_port()
+
+From: Tuo Li <islituo@gmail.com>
+
+[ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ]
+
+The variable val is declared without initialization, and its address is
+passed to amdgpu_i2c_get_byte(). In this function, the value of val is
+accessed in:
+ DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
+ addr, *val);
+
+Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized,
+but it is accessed in:
+ val &= ~amdgpu_connector->router.ddc_mux_control_pin;
+
+To fix this possible uninitialized-variable access, initialize val to 0 in
+amdgpu_i2c_router_select_ddc_port().
+
+Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
+Signed-off-by: Tuo Li <islituo@gmail.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
+index 31a676376d73..3490d300bed2 100644
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
+@@ -340,7 +340,7 @@ static void amdgpu_i2c_put_byte(struct amdgpu_i2c_chan *i2c_bus,
+ void
+ amdgpu_i2c_router_select_ddc_port(struct amdgpu_connector *amdgpu_connector)
+ {
+- u8 val;
++ u8 val = 0;
+
+ if (!amdgpu_connector->router.ddc_valid)
+ return;
+--
+2.30.2
+
--- /dev/null
+From f4e07166eb9939aa524a3431a855d030a786de54 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 23 Jul 2021 09:43:11 +0200
+Subject: hvsi: don't panic on tty_register_driver failure
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
+
+The alloc_tty_driver failure is handled gracefully in hvsi_init. But
+tty_register_driver is not. panic is called if that one fails.
+
+So handle the failure of tty_register_driver gracefully too. This will
+keep at least the console functional as it was enabled earlier by
+console_initcall in hvsi_console_init. Instead of shooting down the
+whole system.
+
+This means, we disable interrupts and restore hvsi_wait back to
+poll_for_state().
+
+Cc: linuxppc-dev@lists.ozlabs.org
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
+ 1 file changed, 16 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
+index a75146f600cb..3e29f5f0d4ca 100644
+--- a/drivers/tty/hvc/hvsi.c
++++ b/drivers/tty/hvc/hvsi.c
+@@ -1051,7 +1051,7 @@ static const struct tty_operations hvsi_ops = {
+
+ static int __init hvsi_init(void)
+ {
+- int i;
++ int i, ret;
+
+ hvsi_driver = alloc_tty_driver(hvsi_count);
+ if (!hvsi_driver)
+@@ -1082,12 +1082,25 @@ static int __init hvsi_init(void)
+ }
+ hvsi_wait = wait_for_state; /* irqs active now */
+
+- if (tty_register_driver(hvsi_driver))
+- panic("Couldn't register hvsi console driver\n");
++ ret = tty_register_driver(hvsi_driver);
++ if (ret) {
++ pr_err("Couldn't register hvsi console driver\n");
++ goto err_free_irq;
++ }
+
+ printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
+
+ return 0;
++err_free_irq:
++ hvsi_wait = poll_for_state;
++ for (i = 0; i < hvsi_count; i++) {
++ struct hvsi_struct *hp = &hvsi_ports[i];
++
++ free_irq(hp->virq, hp);
++ }
++ tty_driver_kref_put(hvsi_driver);
++
++ return ret;
+ }
+ device_initcall(hvsi_init);
+
+--
+2.30.2
+
--- /dev/null
+From f03ec04216be8e70b8deb502747a9ed49ef43acc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 27 Jun 2021 17:32:37 +0100
+Subject: iio: dac: ad5624r: Fix incorrect handling of an optional regulator.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+[ Upstream commit 97683c851f9cdbd3ea55697cbe2dcb6af4287bbd ]
+
+The naming of the regulator is problematic. VCC is usually a supply
+voltage whereas these devices have a separate VREF pin.
+
+Secondly, the regulator core might have provided a stub regulator if
+a real regulator wasn't provided. That would in turn have failed to
+provide a voltage when queried. So reality was that there was no way
+to use the internal reference.
+
+In order to avoid breaking any dts out in the wild, make sure to fallback
+to the original vcc naming if vref is not available.
+
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reported-by: kernel test robot <lkp@intel.com>
+Acked-by: Nuno Sá <nuno.sa@analog.com>
+Link: https://lore.kernel.org/r/20210627163244.1090296-9-jic23@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iio/dac/ad5624r_spi.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/iio/dac/ad5624r_spi.c b/drivers/iio/dac/ad5624r_spi.c
+index 5489ec43b95d..e5cefdb674f8 100644
+--- a/drivers/iio/dac/ad5624r_spi.c
++++ b/drivers/iio/dac/ad5624r_spi.c
+@@ -231,7 +231,7 @@ static int ad5624r_probe(struct spi_device *spi)
+ if (!indio_dev)
+ return -ENOMEM;
+ st = iio_priv(indio_dev);
+- st->reg = devm_regulator_get(&spi->dev, "vcc");
++ st->reg = devm_regulator_get_optional(&spi->dev, "vref");
+ if (!IS_ERR(st->reg)) {
+ ret = regulator_enable(st->reg);
+ if (ret)
+@@ -242,6 +242,22 @@ static int ad5624r_probe(struct spi_device *spi)
+ goto error_disable_reg;
+
+ voltage_uv = ret;
++ } else {
++ if (PTR_ERR(st->reg) != -ENODEV)
++ return PTR_ERR(st->reg);
++ /* Backwards compatibility. This naming is not correct */
++ st->reg = devm_regulator_get_optional(&spi->dev, "vcc");
++ if (!IS_ERR(st->reg)) {
++ ret = regulator_enable(st->reg);
++ if (ret)
++ return ret;
++
++ ret = regulator_get_voltage(st->reg);
++ if (ret < 0)
++ goto error_disable_reg;
++
++ voltage_uv = ret;
++ }
+ }
+
+ spi_set_drvdata(spi, indio_dev);
+--
+2.30.2
+
--- /dev/null
+From 554a167df8a015ea7f00f5fc5d2edc3f4583e05d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 26 Jul 2021 14:52:51 -0500
+Subject: ipv4: ip_output.c: Fix out-of-bounds warning in ip_copy_addrs()
+
+From: Gustavo A. R. Silva <gustavoars@kernel.org>
+
+[ Upstream commit 6321c7acb82872ef6576c520b0e178eaad3a25c0 ]
+
+Fix the following out-of-bounds warning:
+
+ In function 'ip_copy_addrs',
+ inlined from '__ip_queue_xmit' at net/ipv4/ip_output.c:517:2:
+net/ipv4/ip_output.c:449:2: warning: 'memcpy' offset [40, 43] from the object at 'fl' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 36 [-Warray-bounds]
+ 449 | memcpy(&iph->saddr, &fl4->saddr,
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 450 | sizeof(fl4->saddr) + sizeof(fl4->daddr));
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The problem is that the original code is trying to copy data into a
+couple of struct members adjacent to each other in a single call to
+memcpy(). This causes a legitimate compiler warning because memcpy()
+overruns the length of &iph->saddr and &fl4->saddr. As these are just
+a couple of struct members, fix this by using direct assignments,
+instead of memcpy().
+
+This helps with the ongoing efforts to globally enable -Warray-bounds
+and get us closer to being able to tighten the FORTIFY_SOURCE routines
+on memcpy().
+
+Link: https://github.com/KSPP/linux/issues/109
+Reported-by: kernel test robot <lkp@intel.com>
+Link: https://lore.kernel.org/lkml/d5ae2e65-1f18-2577-246f-bada7eee6ccd@intel.com/
+Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/ip_output.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
+index e808227c58d6..477540b3d320 100644
+--- a/net/ipv4/ip_output.c
++++ b/net/ipv4/ip_output.c
+@@ -376,8 +376,9 @@ static void ip_copy_addrs(struct iphdr *iph, const struct flowi4 *fl4)
+ {
+ BUILD_BUG_ON(offsetof(typeof(*fl4), daddr) !=
+ offsetof(typeof(*fl4), saddr) + sizeof(fl4->saddr));
+- memcpy(&iph->saddr, &fl4->saddr,
+- sizeof(fl4->saddr) + sizeof(fl4->daddr));
++
++ iph->saddr = fl4->saddr;
++ iph->daddr = fl4->daddr;
+ }
+
+ /* Note: skb->sk can be different from sk, in case of tunnels */
+--
+2.30.2
+
--- /dev/null
+From f7e549bfb4cb81bc36af5ecd895bc01390a961fb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 1 Aug 2021 04:46:14 -0700
+Subject: mmc: rtsx_pci: Fix long reads when clock is prescaled
+
+From: Thomas Hebb <tommyhebb@gmail.com>
+
+[ Upstream commit 3ac5e45291f3f0d699a721357380d4593bc2dcb3 ]
+
+For unexplained reasons, the prescaler register for this device needs to
+be cleared (set to 1) while performing a data read or else the command
+will hang. This does not appear to affect the real clock rate sent out
+on the bus, so I assume it's purely to work around a hardware bug.
+
+During normal operation, the prescaler is already set to 1, so nothing
+needs to be done. However, in "initial mode" (which is used for sub-MHz
+clock speeds, like the core sets while enumerating cards), it's set to
+128 and so we need to reset it during data reads. We currently fail to
+do this for long reads.
+
+This has no functional affect on the driver's operation currently
+written, as the MMC core always sets a clock above 1MHz before
+attempting any long reads. However, the core could conceivably set any
+clock speed at any time and the driver should still work, so I think
+this fix is worthwhile.
+
+I personally encountered this issue while performing data recovery on an
+external chip. My connections had poor signal integrity, so I modified
+the core code to reduce the clock speed. Without this change, I saw the
+card enumerate but was unable to actually read any data.
+
+Writes don't seem to work in the situation described above even with
+this change (and even if the workaround is extended to encompass data
+write commands). I was not able to find a way to get them working.
+
+Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
+Link: https://lore.kernel.org/r/2fef280d8409ab0100c26c6ac7050227defd098d.1627818365.git.tommyhebb@gmail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mmc/host/rtsx_pci_sdmmc.c | 36 ++++++++++++++++++++-----------
+ 1 file changed, 23 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c
+index 93137483ecde..10ec88833889 100644
+--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
++++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
+@@ -553,9 +553,22 @@ static int sd_write_long_data(struct realtek_pci_sdmmc *host,
+ return 0;
+ }
+
++static inline void sd_enable_initial_mode(struct realtek_pci_sdmmc *host)
++{
++ rtsx_pci_write_register(host->pcr, SD_CFG1,
++ SD_CLK_DIVIDE_MASK, SD_CLK_DIVIDE_128);
++}
++
++static inline void sd_disable_initial_mode(struct realtek_pci_sdmmc *host)
++{
++ rtsx_pci_write_register(host->pcr, SD_CFG1,
++ SD_CLK_DIVIDE_MASK, SD_CLK_DIVIDE_0);
++}
++
+ static int sd_rw_multi(struct realtek_pci_sdmmc *host, struct mmc_request *mrq)
+ {
+ struct mmc_data *data = mrq->data;
++ int err;
+
+ if (host->sg_count < 0) {
+ data->error = host->sg_count;
+@@ -564,22 +577,19 @@ static int sd_rw_multi(struct realtek_pci_sdmmc *host, struct mmc_request *mrq)
+ return data->error;
+ }
+
+- if (data->flags & MMC_DATA_READ)
+- return sd_read_long_data(host, mrq);
++ if (data->flags & MMC_DATA_READ) {
++ if (host->initial_mode)
++ sd_disable_initial_mode(host);
+
+- return sd_write_long_data(host, mrq);
+-}
++ err = sd_read_long_data(host, mrq);
+
+-static inline void sd_enable_initial_mode(struct realtek_pci_sdmmc *host)
+-{
+- rtsx_pci_write_register(host->pcr, SD_CFG1,
+- SD_CLK_DIVIDE_MASK, SD_CLK_DIVIDE_128);
+-}
++ if (host->initial_mode)
++ sd_enable_initial_mode(host);
+
+-static inline void sd_disable_initial_mode(struct realtek_pci_sdmmc *host)
+-{
+- rtsx_pci_write_register(host->pcr, SD_CFG1,
+- SD_CLK_DIVIDE_MASK, SD_CLK_DIVIDE_0);
++ return err;
++ }
++
++ return sd_write_long_data(host, mrq);
+ }
+
+ static void sd_normal_rw(struct realtek_pci_sdmmc *host,
+--
+2.30.2
+
--- /dev/null
+From 6c70c950872d1c7a0f0e8f36a8ecca56e3eb34d1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 30 Aug 2021 18:28:01 +0800
+Subject: net: fix NULL pointer reference in cipso_v4_doi_free
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: 王贇 <yun.wang@linux.alibaba.com>
+
+[ Upstream commit 733c99ee8be9a1410287cdbb943887365e83b2d6 ]
+
+In netlbl_cipsov4_add_std() when 'doi_def->map.std' alloc
+failed, we sometime observe panic:
+
+ BUG: kernel NULL pointer dereference, address:
+ ...
+ RIP: 0010:cipso_v4_doi_free+0x3a/0x80
+ ...
+ Call Trace:
+ netlbl_cipsov4_add_std+0xf4/0x8c0
+ netlbl_cipsov4_add+0x13f/0x1b0
+ genl_family_rcv_msg_doit.isra.15+0x132/0x170
+ genl_rcv_msg+0x125/0x240
+
+This is because in cipso_v4_doi_free() there is no check
+on 'doi_def->map.std' when 'doi_def->type' equal 1, which
+is possibe, since netlbl_cipsov4_add_std() haven't initialize
+it before alloc 'doi_def->map.std'.
+
+This patch just add the check to prevent panic happen for similar
+cases.
+
+Reported-by: Abaci <abaci@linux.alibaba.com>
+Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netlabel/netlabel_cipso_v4.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
+index d31cd4d509ca..422fac2a4a3c 100644
+--- a/net/netlabel/netlabel_cipso_v4.c
++++ b/net/netlabel/netlabel_cipso_v4.c
+@@ -163,8 +163,8 @@ static int netlbl_cipsov4_add_std(struct genl_info *info,
+ return -ENOMEM;
+ doi_def->map.std = kzalloc(sizeof(*doi_def->map.std), GFP_KERNEL);
+ if (doi_def->map.std == NULL) {
+- ret_val = -ENOMEM;
+- goto add_std_failure;
++ kfree(doi_def);
++ return -ENOMEM;
+ }
+ doi_def->type = CIPSO_V4_MAP_TRANS;
+
+--
+2.30.2
+
--- /dev/null
+From b1df8a551a3430a52eaef8841601dc3fb60ae8be Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 19 Jul 2021 13:18:16 +0800
+Subject: netlink: Deal with ESRCH error in nlmsg_notify()
+
+From: Yajun Deng <yajun.deng@linux.dev>
+
+[ Upstream commit fef773fc8110d8124c73a5e6610f89e52814637d ]
+
+Yonghong Song report:
+The bpf selftest tc_bpf failed with latest bpf-next.
+The following is the command to run and the result:
+$ ./test_progs -n 132
+[ 40.947571] bpf_testmod: loading out-of-tree module taints kernel.
+test_tc_bpf:PASS:test_tc_bpf__open_and_load 0 nsec
+test_tc_bpf:PASS:bpf_tc_hook_create(BPF_TC_INGRESS) 0 nsec
+test_tc_bpf:PASS:bpf_tc_hook_create invalid hook.attach_point 0 nsec
+test_tc_bpf_basic:PASS:bpf_obj_get_info_by_fd 0 nsec
+test_tc_bpf_basic:PASS:bpf_tc_attach 0 nsec
+test_tc_bpf_basic:PASS:handle set 0 nsec
+test_tc_bpf_basic:PASS:priority set 0 nsec
+test_tc_bpf_basic:PASS:prog_id set 0 nsec
+test_tc_bpf_basic:PASS:bpf_tc_attach replace mode 0 nsec
+test_tc_bpf_basic:PASS:bpf_tc_query 0 nsec
+test_tc_bpf_basic:PASS:handle set 0 nsec
+test_tc_bpf_basic:PASS:priority set 0 nsec
+test_tc_bpf_basic:PASS:prog_id set 0 nsec
+libbpf: Kernel error message: Failed to send filter delete notification
+test_tc_bpf_basic:FAIL:bpf_tc_detach unexpected error: -3 (errno 3)
+test_tc_bpf:FAIL:test_tc_internal ingress unexpected error: -3 (errno 3)
+
+The failure seems due to the commit
+ cfdf0d9ae75b ("rtnetlink: use nlmsg_notify() in rtnetlink_send()")
+
+Deal with ESRCH error in nlmsg_notify() even the report variable is zero.
+
+Reported-by: Yonghong Song <yhs@fb.com>
+Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
+Link: https://lore.kernel.org/r/20210719051816.11762-1-yajun.deng@linux.dev
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netlink/af_netlink.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
+index c20c41801845..260cba93a2cf 100644
+--- a/net/netlink/af_netlink.c
++++ b/net/netlink/af_netlink.c
+@@ -2405,13 +2405,15 @@ int nlmsg_notify(struct sock *sk, struct sk_buff *skb, u32 portid,
+ /* errors reported via destination sk->sk_err, but propagate
+ * delivery errors if NETLINK_BROADCAST_ERROR flag is set */
+ err = nlmsg_multicast(sk, skb, exclude_portid, group, flags);
++ if (err == -ESRCH)
++ err = 0;
+ }
+
+ if (report) {
+ int err2;
+
+ err2 = nlmsg_unicast(sk, skb, portid);
+- if (!err || err == -ESRCH)
++ if (!err)
+ err = err2;
+ }
+
+--
+2.30.2
+
--- /dev/null
+From 69164a097dee8a3e7722d1f1c3d99f11048c8349 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 18 Jul 2021 19:33:09 -0700
+Subject: openrisc: don't printk() unconditionally
+
+From: Randy Dunlap <rdunlap@infradead.org>
+
+[ Upstream commit 946e1052cdcc7e585ee5d1e72528ca49fb295243 ]
+
+Don't call printk() when CONFIG_PRINTK is not set.
+Fixes the following build errors:
+
+or1k-linux-ld: arch/openrisc/kernel/entry.o: in function `_external_irq_handler':
+(.text+0x804): undefined reference to `printk'
+(.text+0x804): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `printk'
+
+Fixes: 9d02a4283e9c ("OpenRISC: Boot code")
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Reported-by: kernel test robot <lkp@intel.com>
+Cc: Jonas Bonn <jonas@southpole.se>
+Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+Cc: Stafford Horne <shorne@gmail.com>
+Cc: openrisc@lists.librecores.org
+Signed-off-by: Stafford Horne <shorne@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/openrisc/kernel/entry.S | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/openrisc/kernel/entry.S b/arch/openrisc/kernel/entry.S
+index 3fbe420f49c4..92cdc1e56b60 100644
+--- a/arch/openrisc/kernel/entry.S
++++ b/arch/openrisc/kernel/entry.S
+@@ -491,6 +491,7 @@ EXCEPTION_ENTRY(_external_irq_handler)
+ l.bnf 1f // ext irq enabled, all ok.
+ l.nop
+
++#ifdef CONFIG_PRINTK
+ l.addi r1,r1,-0x8
+ l.movhi r3,hi(42f)
+ l.ori r3,r3,lo(42f)
+@@ -504,6 +505,7 @@ EXCEPTION_ENTRY(_external_irq_handler)
+ .string "\n\rESR interrupt bug: in _external_irq_handler (ESR %x)\n\r"
+ .align 4
+ .previous
++#endif
+
+ l.ori r4,r4,SPR_SR_IEE // fix the bug
+ // l.sw PT_SR(r1),r4
+--
+2.30.2
+
--- /dev/null
+From 49b729fbb93dbf981f8989a9f9f7951d58be9bc0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 30 Jul 2021 11:07:10 +0100
+Subject: parport: remove non-zero check on count
+
+From: Colin Ian King <colin.king@canonical.com>
+
+[ Upstream commit 0be883a0d795d9146f5325de582584147dd0dcdc ]
+
+The check for count appears to be incorrect since a non-zero count
+check occurs a couple of statements earlier. Currently the check is
+always false and the dev->port->irq != PARPORT_IRQ_NONE part of the
+check is never tested and the if statement is dead-code. Fix this
+by removing the check on count.
+
+Note that this code is pre-git history, so I can't find a sha for
+it.
+
+Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Addresses-Coverity: ("Logically dead code")
+Link: https://lore.kernel.org/r/20210730100710.27405-1-colin.king@canonical.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/parport/ieee1284_ops.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/parport/ieee1284_ops.c b/drivers/parport/ieee1284_ops.c
+index 2e21af43d91e..b6d808037045 100644
+--- a/drivers/parport/ieee1284_ops.c
++++ b/drivers/parport/ieee1284_ops.c
+@@ -534,7 +534,7 @@ size_t parport_ieee1284_ecp_read_data (struct parport *port,
+ goto out;
+
+ /* Yield the port for a while. */
+- if (count && dev->port->irq != PARPORT_IRQ_NONE) {
++ if (dev->port->irq != PARPORT_IRQ_NONE) {
+ parport_release (dev);
+ schedule_timeout_interruptible(msecs_to_jiffies(40));
+ parport_claim_or_block (dev);
+--
+2.30.2
+
--- /dev/null
+From 74a3506dd20a4f2e0b6531d9d03f12f62d08563b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 8 Jul 2021 15:25:06 +0200
+Subject: PCI: Use pci_update_current_state() in pci_enable_device_flags()
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+[ Upstream commit 14858dcc3b3587f4bb5c48e130ee7d68fc2b0a29 ]
+
+Updating the current_state field of struct pci_dev the way it is done
+in pci_enable_device_flags() before calling do_pci_enable_device() may
+not work. For example, if the given PCI device depends on an ACPI
+power resource whose _STA method initially returns 0 ("off"), but the
+config space of the PCI device is accessible and the power state
+retrieved from the PCI_PM_CTRL register is D0, the current_state
+field in the struct pci_dev representing that device will get out of
+sync with the power.state of its ACPI companion object and that will
+lead to power management issues going forward.
+
+To avoid such issues, make pci_enable_device_flags() call
+pci_update_current_state() which takes ACPI device power management
+into account, if present, to retrieve the current power state of the
+device.
+
+Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/
+Reported-by: Maximilian Luz <luzmaximilian@gmail.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Tested-by: Maximilian Luz <luzmaximilian@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/pci.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
+index 216a1c880924..21ad9fea7878 100644
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -1334,11 +1334,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
+ * so that things like MSI message writing will behave as expected
+ * (e.g. if the device really is in D0 at enable time).
+ */
+- if (dev->pm_cap) {
+- u16 pmcsr;
+- pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
+- dev->current_state = (pmcsr & PCI_PM_CTRL_STATE_MASK);
+- }
++ pci_update_current_state(dev, dev->current_state);
+
+ if (atomic_inc_return(&dev->enable_cnt) > 1)
+ return 0; /* already enabled */
+--
+2.30.2
+
--- /dev/null
+From a282e848279f39d0fefa6023aabd3fc1d15cd07b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Jul 2021 11:39:29 +0800
+Subject: pinctrl: single: Fix error return code in
+ pcs_parse_bits_in_pinctrl_entry()
+
+From: Zhen Lei <thunder.leizhen@huawei.com>
+
+[ Upstream commit d789a490d32fdf0465275e3607f8a3bc87d3f3ba ]
+
+Fix to return -ENOTSUPP instead of 0 when PCS_HAS_PINCONF is true, which
+is the same as that returned in pcs_parse_pinconf().
+
+Fixes: 4e7e8017a80e ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
+Link: https://lore.kernel.org/r/20210722033930.4034-2-thunder.leizhen@huawei.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pinctrl/pinctrl-single.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
+index 17714793c08e..9c6afaebc9cf 100644
+--- a/drivers/pinctrl/pinctrl-single.c
++++ b/drivers/pinctrl/pinctrl-single.c
+@@ -1328,6 +1328,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
+
+ if (PCS_HAS_PINCONF) {
+ dev_err(pcs->dev, "pinconf not supported\n");
++ res = -ENOTSUPP;
+ goto free_pingroups;
+ }
+
+--
+2.30.2
+
--- /dev/null
+From 92b3df0e56b7eef2d763cf73a231544bd8ebbb90 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Aug 2021 15:35:01 +0300
+Subject: Revert "USB: xhci: fix U1/U2 handling for hardware with
+ XHCI_INTEL_HOST quirk set"
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+[ Upstream commit 2847c46c61486fd8bca9136a6e27177212e78c69 ]
+
+This reverts commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760.
+
+That commit effectively disabled Intel host initiated U1/U2 lpm for devices
+with periodic endpoints.
+
+Before that commit we disabled host initiated U1/U2 lpm if the exit latency
+was larger than any periodic endpoint service interval, this is according
+to xhci spec xhci 1.1 specification section 4.23.5.2
+
+After that commit we incorrectly checked that service interval was smaller
+than U1/U2 inactivity timeout. This is not relevant, and can't happen for
+Intel hosts as previously set U1/U2 timeout = 105% * service interval.
+
+Patch claimed it solved cases where devices can't be enumerated because of
+bandwidth issues. This might be true but it's a side effect of accidentally
+turning off lpm.
+
+exit latency calculations have been revised since then
+
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20210820123503.2605901-5-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/host/xhci.c | 24 ++++++++++++------------
+ 1 file changed, 12 insertions(+), 12 deletions(-)
+
+diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
+index b1994b03341f..bd010f8caf87 100644
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -4438,19 +4438,19 @@ static u16 xhci_calculate_u1_timeout(struct xhci_hcd *xhci,
+ {
+ unsigned long long timeout_ns;
+
+- if (xhci->quirks & XHCI_INTEL_HOST)
+- timeout_ns = xhci_calculate_intel_u1_timeout(udev, desc);
+- else
+- timeout_ns = udev->u1_params.sel;
+-
+ /* Prevent U1 if service interval is shorter than U1 exit latency */
+ if (usb_endpoint_xfer_int(desc) || usb_endpoint_xfer_isoc(desc)) {
+- if (xhci_service_interval_to_ns(desc) <= timeout_ns) {
++ if (xhci_service_interval_to_ns(desc) <= udev->u1_params.mel) {
+ dev_dbg(&udev->dev, "Disable U1, ESIT shorter than exit latency\n");
+ return USB3_LPM_DISABLED;
+ }
+ }
+
++ if (xhci->quirks & XHCI_INTEL_HOST)
++ timeout_ns = xhci_calculate_intel_u1_timeout(udev, desc);
++ else
++ timeout_ns = udev->u1_params.sel;
++
+ /* The U1 timeout is encoded in 1us intervals.
+ * Don't return a timeout of zero, because that's USB3_LPM_DISABLED.
+ */
+@@ -4502,19 +4502,19 @@ static u16 xhci_calculate_u2_timeout(struct xhci_hcd *xhci,
+ {
+ unsigned long long timeout_ns;
+
+- if (xhci->quirks & XHCI_INTEL_HOST)
+- timeout_ns = xhci_calculate_intel_u2_timeout(udev, desc);
+- else
+- timeout_ns = udev->u2_params.sel;
+-
+ /* Prevent U2 if service interval is shorter than U2 exit latency */
+ if (usb_endpoint_xfer_int(desc) || usb_endpoint_xfer_isoc(desc)) {
+- if (xhci_service_interval_to_ns(desc) <= timeout_ns) {
++ if (xhci_service_interval_to_ns(desc) <= udev->u2_params.mel) {
+ dev_dbg(&udev->dev, "Disable U2, ESIT shorter than exit latency\n");
+ return USB3_LPM_DISABLED;
+ }
+ }
+
++ if (xhci->quirks & XHCI_INTEL_HOST)
++ timeout_ns = xhci_calculate_intel_u2_timeout(udev, desc);
++ else
++ timeout_ns = udev->u2_params.sel;
++
+ /* The U2 timeout is encoded in 256us intervals */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 256 * 1000);
+ /* If the necessary timeout value is bigger than what we can set in the
+--
+2.30.2
+
--- /dev/null
+From a8bc24924443d12b887b97fad449ab0f6de1bd6c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Aug 2021 16:41:42 -0400
+Subject: rpc: fix gss_svc_init cleanup on failure
+
+From: J. Bruce Fields <bfields@redhat.com>
+
+[ Upstream commit 5a4753446253a427c0ff1e433b9c4933e5af207c ]
+
+The failure case here should be rare, but it's obviously wrong.
+
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sunrpc/auth_gss/svcauth_gss.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
+index bb8b0ef5de82..daf0c1ea3917 100644
+--- a/net/sunrpc/auth_gss/svcauth_gss.c
++++ b/net/sunrpc/auth_gss/svcauth_gss.c
+@@ -1845,7 +1845,7 @@ gss_svc_init_net(struct net *net)
+ goto out2;
+ return 0;
+ out2:
+- destroy_use_gss_proxy_proc_entry(net);
++ rsi_cache_destroy_net(net);
+ out1:
+ rsc_cache_destroy_net(net);
+ return rv;
+--
+2.30.2
+
--- /dev/null
+From 31688104cf74948c92a875e4b11085b50a6150bd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 12 Jul 2021 19:26:01 +0200
+Subject: s390/jump_label: print real address in a case of a jump label bug
+
+From: Heiko Carstens <hca@linux.ibm.com>
+
+[ Upstream commit 5492886c14744d239e87f1b0b774b5a341e755cc ]
+
+In case of a jump label print the real address of the piece of code
+where a mismatch was detected. This is right before the system panics,
+so there is nothing revealed.
+
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/s390/kernel/jump_label.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/s390/kernel/jump_label.c b/arch/s390/kernel/jump_label.c
+index 083b05f5f5ab..cbc187706648 100644
+--- a/arch/s390/kernel/jump_label.c
++++ b/arch/s390/kernel/jump_label.c
+@@ -43,7 +43,7 @@ static void jump_label_bug(struct jump_entry *entry, struct insn *expected,
+ unsigned char *ipe = (unsigned char *)expected;
+ unsigned char *ipn = (unsigned char *)new;
+
+- pr_emerg("Jump label code mismatch at %pS [%p]\n", ipc, ipc);
++ pr_emerg("Jump label code mismatch at %pS [%px]\n", ipc, ipc);
+ pr_emerg("Found: %6ph\n", ipc);
+ pr_emerg("Expected: %6ph\n", ipe);
+ pr_emerg("New: %6ph\n", ipn);
+--
+2.30.2
+
--- /dev/null
+From 54cbfacf0aab593d9236f68132c3d8f28bce66ad Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 26 Jun 2021 06:11:51 +0200
+Subject: serial: 8250: Define RX trigger levels for OxSemi 950 devices
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+[ Upstream commit d7aff291d069c4418285f3c8ee27b0ff67ce5998 ]
+
+Oxford Semiconductor 950 serial port devices have a 128-byte FIFO and in
+the enhanced (650) mode, which we select in `autoconfig_has_efr' with
+the ECB bit set in the EFR register, they support the receive interrupt
+trigger level selectable with FCR bits 7:6 from the set of 16, 32, 112,
+120. This applies to the original OX16C950 discrete UART[1] as well as
+950 cores embedded into more complex devices.
+
+For these devices we set the default to 112, which sets an excessively
+high level of 112 or 7/8 of the FIFO capacity, unlike with other port
+types where we choose at most 1/2 of their respective FIFO capacities.
+Additionally we don't make the trigger level configurable. Consequently
+frequent input overruns happen with high bit rates where hardware flow
+control cannot be used (e.g. terminal applications) even with otherwise
+highly-performant systems.
+
+Lower the default receive interrupt trigger level to 32 then, and make
+it configurable. Document the trigger levels along with other port
+types, including the set of 16, 32, 64, 112 for the transmit interrupt
+as well[2].
+
+References:
+
+[1] "OX16C950 rev B High Performance UART with 128 byte FIFOs", Oxford
+ Semiconductor, Inc., DS-0031, Sep 05, Table 10: "Receiver Trigger
+ Levels", p. 22
+
+[2] same, Table 9: "Transmit Interrupt Trigger Levels", p. 22
+
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260608480.37803@angie.orcam.me.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/8250/8250_port.c | 3 ++-
+ include/uapi/linux/serial_reg.h | 1 +
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
+index 041bfe1d4191..d0d90752f9f3 100644
+--- a/drivers/tty/serial/8250/8250_port.c
++++ b/drivers/tty/serial/8250/8250_port.c
+@@ -124,7 +124,8 @@ static const struct serial8250_config uart_config[] = {
+ .name = "16C950/954",
+ .fifo_size = 128,
+ .tx_loadsz = 128,
+- .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
++ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01,
++ .rxtrig_bytes = {16, 32, 112, 120},
+ /* UART_CAP_EFR breaks billionon CF bluetooth card. */
+ .flags = UART_CAP_FIFO | UART_CAP_SLEEP,
+ },
+diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
+index 1e5ac4e776da..5bcc637cee46 100644
+--- a/include/uapi/linux/serial_reg.h
++++ b/include/uapi/linux/serial_reg.h
+@@ -61,6 +61,7 @@
+ * ST16C654: 8 16 56 60 8 16 32 56 PORT_16654
+ * TI16C750: 1 16 32 56 xx xx xx xx PORT_16750
+ * TI16C752: 8 16 56 60 8 16 32 56
++ * OX16C950: 16 32 112 120 16 32 64 112 PORT_16C950
+ * Tegra: 1 4 8 14 16 8 4 1 PORT_TEGRA
+ */
+ #define UART_FCR_R_TRIG_00 0x00
+--
+2.30.2
+
--- /dev/null
+From b6dcdd7a27d92e726899fb024aaa0464b949fb95 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 26 Jul 2021 15:07:17 +0200
+Subject: serial: 8250_pci: make setup_port() parameters explicitly unsigned
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+[ Upstream commit 3a96e97ab4e835078e6f27b7e1c0947814df3841 ]
+
+The bar and offset parameters to setup_port() are used in pointer math,
+and while it would be very difficult to get them to wrap as a negative
+number, just be "safe" and make them unsigned so that static checkers do
+not trip over them unintentionally.
+
+Cc: Jiri Slaby <jirislaby@kernel.org>
+Reported-by: Jordy Zomer <jordy@pwning.systems>
+Link: https://lore.kernel.org/r/20210726130717.2052096-1-gregkh@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/8250/8250_pci.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
+index 72f6cde146b5..db66e533319e 100644
+--- a/drivers/tty/serial/8250/8250_pci.c
++++ b/drivers/tty/serial/8250/8250_pci.c
+@@ -78,7 +78,7 @@ static void moan_device(const char *str, struct pci_dev *dev)
+
+ static int
+ setup_port(struct serial_private *priv, struct uart_8250_port *port,
+- int bar, int offset, int regshift)
++ u8 bar, unsigned int offset, int regshift)
+ {
+ struct pci_dev *dev = priv->dev;
+
+--
+2.30.2
+
arm-9105-1-atags_to_fdt-don-t-warn-about-stack-size.patch
pci-restrict-asmedia-asm1062-sata-max-payload-size-supported.patch
pci-return-0-data-on-pciconfig_read-cap_sys_admin-failure.patch
+openrisc-don-t-printk-unconditionally.patch
+pinctrl-single-fix-error-return-code-in-pcs_parse_bi.patch
+crypto-mxs-dcp-use-sg_mapping_iter-to-copy-data.patch
+pci-use-pci_update_current_state-in-pci_enable_devic.patch
+iio-dac-ad5624r-fix-incorrect-handling-of-an-optiona.patch
+video-fbdev-kyro-fix-a-dos-bug-by-restricting-user-i.patch
+netlink-deal-with-esrch-error-in-nlmsg_notify.patch
+smack-fix-wrong-semantics-in-smk_access_entry.patch
+usb-host-fotg210-fix-the-actual_length-of-an-iso-pac.patch
+usb-gadget-u_ether-fix-a-potential-null-pointer-dere.patch
+tty-serial-jsm-hold-port-lock-when-reporting-modem-l.patch
+bpf-tests-fix-copy-and-paste-error-in-double-word-te.patch
+bpf-tests-do-not-pass-tests-without-actually-testing.patch
+video-fbdev-asiliantfb-error-out-if-pixclock-equals-.patch
+video-fbdev-kyro-error-out-if-pixclock-equals-zero.patch
+video-fbdev-riva-error-out-if-pixclock-equals-zero.patch
+ipv4-ip_output.c-fix-out-of-bounds-warning-in-ip_cop.patch
+s390-jump_label-print-real-address-in-a-case-of-a-ju.patch
+serial-8250-define-rx-trigger-levels-for-oxsemi-950-.patch
+xtensa-iss-don-t-panic-in-rs_init.patch
+hvsi-don-t-panic-on-tty_register_driver-failure.patch
+serial-8250_pci-make-setup_port-parameters-explicitl.patch
+bluetooth-skip-invalid-hci_sync_conn_complete_evt.patch
+gpu-drm-amd-amdgpu-amdgpu_i2c-fix-possible-uninitial.patch
+arm-tegra-tamonten-fix-uart-pad-setting.patch
+rpc-fix-gss_svc_init-cleanup-on-failure.patch
+gfs2-don-t-call-dlm-after-protocol-is-unmounted.patch
+mmc-rtsx_pci-fix-long-reads-when-clock-is-prescaled.patch
+cifs-fix-wrong-release-in-sess_alloc_buffer-failed-p.patch
+revert-usb-xhci-fix-u1-u2-handling-for-hardware-with.patch
+parport-remove-non-zero-check-on-count.patch
+ath9k-fix-oob-read-ar9300_eeprom_restore_internal.patch
+net-fix-null-pointer-reference-in-cipso_v4_doi_free.patch
--- /dev/null
+From 71ba45454091713b7f1320fb2029b943f2cc018a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 15 Jul 2021 17:17:24 +0800
+Subject: Smack: Fix wrong semantics in smk_access_entry()
+
+From: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
+
+[ Upstream commit 6d14f5c7028eea70760df284057fe198ce7778dd ]
+
+In the smk_access_entry() function, if no matching rule is found
+in the rust_list, a negative error code will be used to perform bit
+operations with the MAY_ enumeration value. This is semantically
+wrong. This patch fixes this issue.
+
+Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
+Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ security/smack/smack_access.c | 17 ++++++++---------
+ 1 file changed, 8 insertions(+), 9 deletions(-)
+
+diff --git a/security/smack/smack_access.c b/security/smack/smack_access.c
+index 0df316c62005..84f38b694242 100644
+--- a/security/smack/smack_access.c
++++ b/security/smack/smack_access.c
+@@ -90,23 +90,22 @@ int log_policy = SMACK_AUDIT_DENIED;
+ int smk_access_entry(char *subject_label, char *object_label,
+ struct list_head *rule_list)
+ {
+- int may = -ENOENT;
+ struct smack_rule *srp;
+
+ list_for_each_entry_rcu(srp, rule_list, list) {
+ if (srp->smk_object->smk_known == object_label &&
+ srp->smk_subject->smk_known == subject_label) {
+- may = srp->smk_access;
+- break;
++ int may = srp->smk_access;
++ /*
++ * MAY_WRITE implies MAY_LOCK.
++ */
++ if ((may & MAY_WRITE) == MAY_WRITE)
++ may |= MAY_LOCK;
++ return may;
+ }
+ }
+
+- /*
+- * MAY_WRITE implies MAY_LOCK.
+- */
+- if ((may & MAY_WRITE) == MAY_WRITE)
+- may |= MAY_LOCK;
+- return may;
++ return -ENOENT;
+ }
+
+ /**
+--
+2.30.2
+
--- /dev/null
+From c58e1c8eef79499dff89cf3c2ea22f8ad080fc52 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Jul 2021 05:53:23 +0000
+Subject: tty: serial: jsm: hold port lock when reporting modem line changes
+
+From: Zheyu Ma <zheyuma97@gmail.com>
+
+[ Upstream commit 240e126c28df084222f0b661321e8e3ecb0d232e ]
+
+uart_handle_dcd_change() requires a port lock to be held and will emit a
+warning when lockdep is enabled.
+
+Held corresponding lock to fix the following warnings.
+
+[ 132.528648] WARNING: CPU: 5 PID: 11600 at drivers/tty/serial/serial_core.c:3046 uart_handle_dcd_change+0xf4/0x120
+[ 132.530482] Modules linked in:
+[ 132.531050] CPU: 5 PID: 11600 Comm: jsm Not tainted 5.14.0-rc1-00003-g7fef2edf7cc7-dirty #31
+[ 132.535268] RIP: 0010:uart_handle_dcd_change+0xf4/0x120
+[ 132.557100] Call Trace:
+[ 132.557562] ? __free_pages+0x83/0xb0
+[ 132.558213] neo_parse_modem+0x156/0x220
+[ 132.558897] neo_param+0x399/0x840
+[ 132.559495] jsm_tty_open+0x12f/0x2d0
+[ 132.560131] uart_startup.part.18+0x153/0x340
+[ 132.560888] ? lock_is_held_type+0xe9/0x140
+[ 132.561660] uart_port_activate+0x7f/0xe0
+[ 132.562351] ? uart_startup.part.18+0x340/0x340
+[ 132.563003] tty_port_open+0x8d/0xf0
+[ 132.563523] ? uart_set_options+0x1e0/0x1e0
+[ 132.564125] uart_open+0x24/0x40
+[ 132.564604] tty_open+0x15c/0x630
+
+Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
+Link: https://lore.kernel.org/r/1626242003-3809-1-git-send-email-zheyuma97@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/jsm/jsm_neo.c | 2 ++
+ drivers/tty/serial/jsm/jsm_tty.c | 3 +++
+ 2 files changed, 5 insertions(+)
+
+diff --git a/drivers/tty/serial/jsm/jsm_neo.c b/drivers/tty/serial/jsm/jsm_neo.c
+index 932b2accd06f..4ed0c099c757 100644
+--- a/drivers/tty/serial/jsm/jsm_neo.c
++++ b/drivers/tty/serial/jsm/jsm_neo.c
+@@ -827,7 +827,9 @@ static inline void neo_parse_isr(struct jsm_board *brd, u32 port)
+ /* Parse any modem signal changes */
+ jsm_dbg(INTR, &ch->ch_bd->pci_dev,
+ "MOD_STAT: sending to parse_modem_sigs\n");
++ spin_lock_irqsave(&ch->uart_port.lock, lock_flags);
+ neo_parse_modem(ch, readb(&ch->ch_neo_uart->msr));
++ spin_unlock_irqrestore(&ch->uart_port.lock, lock_flags);
+ }
+ }
+
+diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
+index 524e86ab3cae..dad3abab8280 100644
+--- a/drivers/tty/serial/jsm/jsm_tty.c
++++ b/drivers/tty/serial/jsm/jsm_tty.c
+@@ -195,6 +195,7 @@ static void jsm_tty_break(struct uart_port *port, int break_state)
+
+ static int jsm_tty_open(struct uart_port *port)
+ {
++ unsigned long lock_flags;
+ struct jsm_board *brd;
+ struct jsm_channel *channel =
+ container_of(port, struct jsm_channel, uart_port);
+@@ -248,6 +249,7 @@ static int jsm_tty_open(struct uart_port *port)
+ channel->ch_cached_lsr = 0;
+ channel->ch_stops_sent = 0;
+
++ spin_lock_irqsave(&port->lock, lock_flags);
+ termios = &port->state->port.tty->termios;
+ channel->ch_c_cflag = termios->c_cflag;
+ channel->ch_c_iflag = termios->c_iflag;
+@@ -267,6 +269,7 @@ static int jsm_tty_open(struct uart_port *port)
+ jsm_carrier(channel);
+
+ channel->ch_open_count++;
++ spin_unlock_irqrestore(&port->lock, lock_flags);
+
+ jsm_dbg(OPEN, &channel->ch_bd->pci_dev, "finish\n");
+ return 0;
+--
+2.30.2
+
--- /dev/null
+From 193d208bc7648c1fb803fa63bf02766fa8c883d5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 1 Jul 2021 04:48:34 -0700
+Subject: usb: gadget: u_ether: fix a potential null pointer dereference
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Maciej Żenczykowski <maze@google.com>
+
+[ Upstream commit 8ae01239609b29ec2eff55967c8e0fe3650cfa09 ]
+
+f_ncm tx timeout can call us with null skb to flush
+a pending frame. In this case skb is NULL to begin
+with but ceases to be null after dev->wrap() completes.
+
+In such a case in->maxpacket will be read, even though
+we've failed to check that 'in' is not NULL.
+
+Though I've never observed this fail in practice,
+however the 'flush operation' simply does not make sense with
+a null usb IN endpoint - there's nowhere to flush to...
+(note that we're the gadget/device, and IN is from the point
+ of view of the host, so here IN actually means outbound...)
+
+Cc: Brooke Basile <brookebasile@gmail.com>
+Cc: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
+Cc: Felipe Balbi <balbi@kernel.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Lorenzo Colitti <lorenzo@google.com>
+Signed-off-by: Maciej Żenczykowski <maze@google.com>
+Link: https://lore.kernel.org/r/20210701114834.884597-6-zenczykowski@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/gadget/function/u_ether.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
+index 46c50135ef9f..4bc95ac3d448 100644
+--- a/drivers/usb/gadget/function/u_ether.c
++++ b/drivers/usb/gadget/function/u_ether.c
+@@ -507,8 +507,9 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
+ }
+ spin_unlock_irqrestore(&dev->lock, flags);
+
+- if (skb && !in) {
+- dev_kfree_skb_any(skb);
++ if (!in) {
++ if (skb)
++ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+ }
+
+--
+2.30.2
+
--- /dev/null
+From e4a35a5231447a7ddaf7e51d8ec06fb518b50658 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 27 Jun 2021 20:57:47 +0800
+Subject: usb: host: fotg210: fix the actual_length of an iso packet
+
+From: Kelly Devilliv <kelly.devilliv@gmail.com>
+
+[ Upstream commit 091cb2f782f32ab68c6f5f326d7868683d3d4875 ]
+
+We should acquire the actual_length of an iso packet
+from the iTD directly using FOTG210_ITD_LENGTH() macro.
+
+Signed-off-by: Kelly Devilliv <kelly.devilliv@gmail.com>
+Link: https://lore.kernel.org/r/20210627125747.127646-4-kelly.devilliv@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/host/fotg210-hcd.c | 5 ++---
+ drivers/usb/host/fotg210.h | 5 -----
+ 2 files changed, 2 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
+index 5dacc3076efd..e081392ec830 100644
+--- a/drivers/usb/host/fotg210-hcd.c
++++ b/drivers/usb/host/fotg210-hcd.c
+@@ -4495,13 +4495,12 @@ static bool itd_complete(struct fotg210_hcd *fotg210, struct fotg210_itd *itd)
+
+ /* HC need not update length with this error */
+ if (!(t & FOTG210_ISOC_BABBLE)) {
+- desc->actual_length =
+- fotg210_itdlen(urb, desc, t);
++ desc->actual_length = FOTG210_ITD_LENGTH(t);
+ urb->actual_length += desc->actual_length;
+ }
+ } else if (likely((t & FOTG210_ISOC_ACTIVE) == 0)) {
+ desc->status = 0;
+- desc->actual_length = fotg210_itdlen(urb, desc, t);
++ desc->actual_length = FOTG210_ITD_LENGTH(t);
+ urb->actual_length += desc->actual_length;
+ } else {
+ /* URB was too late */
+diff --git a/drivers/usb/host/fotg210.h b/drivers/usb/host/fotg210.h
+index b5cfa7aeb277..1a3f94123c88 100644
+--- a/drivers/usb/host/fotg210.h
++++ b/drivers/usb/host/fotg210.h
+@@ -682,11 +682,6 @@ static inline unsigned fotg210_read_frame_index(struct fotg210_hcd *fotg210)
+ return fotg210_readl(fotg210, &fotg210->regs->frame_index);
+ }
+
+-#define fotg210_itdlen(urb, desc, t) ({ \
+- usb_pipein((urb)->pipe) ? \
+- (desc)->length - FOTG210_ITD_LENGTH(t) : \
+- FOTG210_ITD_LENGTH(t); \
+-})
+ /*-------------------------------------------------------------------------*/
+
+ #endif /* __LINUX_FOTG210_H */
+--
+2.30.2
+
--- /dev/null
+From 600aa1721d2965748d2e4c7a0e69efb5268ac16a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 26 Jul 2021 10:03:53 +0000
+Subject: video: fbdev: asiliantfb: Error out if 'pixclock' equals zero
+
+From: Zheyu Ma <zheyuma97@gmail.com>
+
+[ Upstream commit b36b242d4b8ea178f7fd038965e3cac7f30c3f09 ]
+
+The userspace program could pass any values to the driver through
+ioctl() interface. If the driver doesn't check the value of 'pixclock',
+it may cause divide error.
+
+Fix this by checking whether 'pixclock' is zero first.
+
+The following log reveals it:
+
+[ 43.861711] divide error: 0000 [#1] PREEMPT SMP KASAN PTI
+[ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #224
+[ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730
+[ 43.861843] Call Trace:
+[ 43.861848] ? asiliantfb_remove+0x190/0x190
+[ 43.861858] fb_set_var+0x2e4/0xeb0
+[ 43.861866] ? fb_blank+0x1a0/0x1a0
+[ 43.861873] ? lock_acquire+0x1ef/0x530
+[ 43.861884] ? lock_release+0x810/0x810
+[ 43.861892] ? lock_is_held_type+0x100/0x140
+[ 43.861903] ? ___might_sleep+0x1ee/0x2d0
+[ 43.861914] ? __mutex_lock+0x620/0x1190
+[ 43.861921] ? do_fb_ioctl+0x313/0x700
+[ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0
+[ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30
+[ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60
+[ 43.861952] ? lockdep_hardirqs_on+0x59/0x100
+[ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60
+[ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0
+[ 43.861978] do_fb_ioctl+0x31e/0x700
+
+Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
+Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-2-git-send-email-zheyuma97@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/asiliantfb.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/video/fbdev/asiliantfb.c b/drivers/video/fbdev/asiliantfb.c
+index 7e8ddf00ccc2..dbcc6ebaf904 100644
+--- a/drivers/video/fbdev/asiliantfb.c
++++ b/drivers/video/fbdev/asiliantfb.c
+@@ -227,6 +227,9 @@ static int asiliantfb_check_var(struct fb_var_screeninfo *var,
+ {
+ unsigned long Ftarget, ratio, remainder;
+
++ if (!var->pixclock)
++ return -EINVAL;
++
+ ratio = 1000000 / var->pixclock;
+ remainder = 1000000 % var->pixclock;
+ Ftarget = 1000000 * ratio + (1000000 * remainder) / var->pixclock;
+--
+2.30.2
+
--- /dev/null
+From ba2102debbec6d28f27d7109ddc35b52ccb118c0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 26 Jul 2021 10:03:54 +0000
+Subject: video: fbdev: kyro: Error out if 'pixclock' equals zero
+
+From: Zheyu Ma <zheyuma97@gmail.com>
+
+[ Upstream commit 1520b4b7ba964f8eec2e7dd14c571d50de3e5191 ]
+
+The userspace program could pass any values to the driver through
+ioctl() interface. if the driver doesn't check the value of 'pixclock',
+it may cause divide error because the value of 'lineclock' and
+'frameclock' will be zero.
+
+Fix this by checking whether 'pixclock' is zero in kyrofb_check_var().
+
+The following log reveals it:
+
+[ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI
+[ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty #118
+[ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80
+[ 103.074045] Call Trace:
+[ 103.074048] ? ___might_sleep+0x1ee/0x2d0
+[ 103.074060] ? kyrofb_ioctl+0x330/0x330
+[ 103.074069] fb_set_var+0x5bf/0xeb0
+[ 103.074078] ? fb_blank+0x1a0/0x1a0
+[ 103.074085] ? lock_acquire+0x3bd/0x530
+[ 103.074094] ? lock_release+0x810/0x810
+[ 103.074103] ? ___might_sleep+0x1ee/0x2d0
+[ 103.074114] ? __mutex_lock+0x620/0x1190
+[ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0
+[ 103.074137] do_fb_ioctl+0x31e/0x700
+[ 103.074144] ? fb_getput_cmap+0x280/0x280
+[ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80
+[ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80
+[ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0
+[ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80
+[ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0
+[ 103.074199] ? vfs_fileattr_set+0xb60/0xb60
+[ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80
+[ 103.074216] ? lock_release+0x483/0x810
+[ 103.074224] ? __fget_files+0x217/0x3d0
+[ 103.074234] ? __fget_files+0x239/0x3d0
+[ 103.074243] ? do_fb_ioctl+0x700/0x700
+[ 103.074250] fb_ioctl+0xe6/0x130
+
+Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
+Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-3-git-send-email-zheyuma97@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/kyro/fbdev.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
+index 8482444259ce..d98c3f5d80df 100644
+--- a/drivers/video/fbdev/kyro/fbdev.c
++++ b/drivers/video/fbdev/kyro/fbdev.c
+@@ -399,6 +399,9 @@ static int kyrofb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
+ {
+ struct kyrofb_info *par = info->par;
+
++ if (!var->pixclock)
++ return -EINVAL;
++
+ if (var->bits_per_pixel != 16 && var->bits_per_pixel != 32) {
+ printk(KERN_WARNING "kyrofb: depth not supported: %u\n", var->bits_per_pixel);
+ return -EINVAL;
+--
+2.30.2
+
--- /dev/null
+From 104c550fe82faebe8a5a6f714a68bb125d9bd102 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Jul 2021 04:09:22 +0000
+Subject: video: fbdev: kyro: fix a DoS bug by restricting user input
+
+From: Zheyu Ma <zheyuma97@gmail.com>
+
+[ Upstream commit 98a65439172dc69cb16834e62e852afc2adb83ed ]
+
+The user can pass in any value to the driver through the 'ioctl'
+interface. The driver dost not check, which may cause DoS bugs.
+
+The following log reveals it:
+
+divide error: 0000 [#1] PREEMPT SMP KASAN PTI
+RIP: 0010:SetOverlayViewPort+0x133/0x5f0 drivers/video/fbdev/kyro/STG4000OverlayDevice.c:476
+Call Trace:
+ kyro_dev_overlay_viewport_set drivers/video/fbdev/kyro/fbdev.c:378 [inline]
+ kyrofb_ioctl+0x2eb/0x330 drivers/video/fbdev/kyro/fbdev.c:603
+ do_fb_ioctl+0x1f3/0x700 drivers/video/fbdev/core/fbmem.c:1171
+ fb_ioctl+0xeb/0x130 drivers/video/fbdev/core/fbmem.c:1185
+ vfs_ioctl fs/ioctl.c:48 [inline]
+ __do_sys_ioctl fs/ioctl.c:753 [inline]
+ __se_sys_ioctl fs/ioctl.c:739 [inline]
+ __x64_sys_ioctl+0x19b/0x220 fs/ioctl.c:739
+ do_syscall_64+0x32/0x80 arch/x86/entry/common.c:46
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
+Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/1626235762-2590-1-git-send-email-zheyuma97@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/kyro/fbdev.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
+index 5bb01533271e..8482444259ce 100644
+--- a/drivers/video/fbdev/kyro/fbdev.c
++++ b/drivers/video/fbdev/kyro/fbdev.c
+@@ -372,6 +372,11 @@ static int kyro_dev_overlay_viewport_set(u32 x, u32 y, u32 ulWidth, u32 ulHeight
+ /* probably haven't called CreateOverlay yet */
+ return -EINVAL;
+
++ if (ulWidth == 0 || ulWidth == 0xffffffff ||
++ ulHeight == 0 || ulHeight == 0xffffffff ||
++ (x < 2 && ulWidth + 2 == 0))
++ return -EINVAL;
++
+ /* Stop Ramdac Output */
+ DisableRamdacOutput(deviceInfo.pSTGReg);
+
+--
+2.30.2
+
--- /dev/null
+From 59739ca449ea52a8e70e23caf7684c51aff87d56 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 26 Jul 2021 10:03:55 +0000
+Subject: video: fbdev: riva: Error out if 'pixclock' equals zero
+
+From: Zheyu Ma <zheyuma97@gmail.com>
+
+[ Upstream commit f92763cb0feba247e0939ed137b495601fd072a5 ]
+
+The userspace program could pass any values to the driver through
+ioctl() interface. If the driver doesn't check the value of 'pixclock',
+it may cause divide error.
+
+Fix this by checking whether 'pixclock' is zero first.
+
+The following log reveals it:
+
+[ 33.396850] divide error: 0000 [#1] PREEMPT SMP KASAN PTI
+[ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #222
+[ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70
+[ 33.396969] Call Trace:
+[ 33.396973] ? debug_smp_processor_id+0x1c/0x20
+[ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90
+[ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0
+[ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0
+[ 33.397014] ? vprintk_emit+0x110/0x4b0
+[ 33.397024] ? vprintk_default+0x26/0x30
+[ 33.397033] ? vprintk+0x9c/0x1f0
+[ 33.397041] ? printk+0xba/0xed
+[ 33.397054] ? record_print_text.cold+0x16/0x16
+[ 33.397063] ? __kasan_check_read+0x11/0x20
+[ 33.397074] ? profile_tick+0xc0/0x100
+[ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80
+[ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0
+[ 33.397102] rivafb_set_par+0xbe/0x610
+[ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0
+[ 33.397119] fb_set_var+0x5bf/0xeb0
+[ 33.397127] ? fb_blank+0x1a0/0x1a0
+[ 33.397134] ? lock_acquire+0x1ef/0x530
+[ 33.397143] ? lock_release+0x810/0x810
+[ 33.397151] ? lock_is_held_type+0x100/0x140
+[ 33.397159] ? ___might_sleep+0x1ee/0x2d0
+[ 33.397170] ? __mutex_lock+0x620/0x1190
+[ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0
+[ 33.397190] do_fb_ioctl+0x31e/0x700
+
+Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
+Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-4-git-send-email-zheyuma97@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/riva/fbdev.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
+index f1ad2747064b..6e5e29fe13db 100644
+--- a/drivers/video/fbdev/riva/fbdev.c
++++ b/drivers/video/fbdev/riva/fbdev.c
+@@ -1088,6 +1088,9 @@ static int rivafb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
+ int mode_valid = 0;
+
+ NVTRACE_ENTER();
++ if (!var->pixclock)
++ return -EINVAL;
++
+ switch (var->bits_per_pixel) {
+ case 1 ... 8:
+ var->red.offset = var->green.offset = var->blue.offset = 0;
+--
+2.30.2
+
--- /dev/null
+From 0e78595dbf4e7d404de7fd27a0a521c256cb7a2e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 23 Jul 2021 09:43:10 +0200
+Subject: xtensa: ISS: don't panic in rs_init
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+[ Upstream commit 23411c720052ad860b3e579ee4873511e367130a ]
+
+While alloc_tty_driver failure in rs_init would mean we have much bigger
+problem, there is no reason to panic when tty_register_driver fails
+there. It can fail for various reasons.
+
+So handle the failure gracefully. Actually handle them both while at it.
+This will make at least the console functional as it was enabled earlier
+by console_initcall in iss_console_init. Instead of shooting down the
+whole system.
+
+We move tty_port_init() after alloc_tty_driver(), so that we don't need
+to destroy the port in case the latter function fails.
+
+Cc: Chris Zankel <chris@zankel.net>
+Cc: Max Filippov <jcmvbkbc@gmail.com>
+Cc: linux-xtensa@linux-xtensa.org
+Acked-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Link: https://lore.kernel.org/r/20210723074317.32690-2-jslaby@suse.cz
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/xtensa/platforms/iss/console.c | 17 ++++++++++++++---
+ 1 file changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/arch/xtensa/platforms/iss/console.c b/arch/xtensa/platforms/iss/console.c
+index 92d785fefb6d..5d264ae517f5 100644
+--- a/arch/xtensa/platforms/iss/console.c
++++ b/arch/xtensa/platforms/iss/console.c
+@@ -186,9 +186,13 @@ static const struct tty_operations serial_ops = {
+
+ int __init rs_init(void)
+ {
+- tty_port_init(&serial_port);
++ int ret;
+
+ serial_driver = alloc_tty_driver(SERIAL_MAX_NUM_LINES);
++ if (!serial_driver)
++ return -ENOMEM;
++
++ tty_port_init(&serial_port);
+
+ printk ("%s %s\n", serial_name, serial_version);
+
+@@ -208,8 +212,15 @@ int __init rs_init(void)
+ tty_set_operations(serial_driver, &serial_ops);
+ tty_port_link_device(&serial_port, serial_driver, 0);
+
+- if (tty_register_driver(serial_driver))
+- panic("Couldn't register serial driver\n");
++ ret = tty_register_driver(serial_driver);
++ if (ret) {
++ pr_err("Couldn't register serial driver\n");
++ tty_driver_kref_put(serial_driver);
++ tty_port_destroy(&serial_port);
++
++ return ret;
++ }
++
+ return 0;
+ }
+
+--
+2.30.2
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
