--- /dev/null
+From 434a3bca9c5c811eafa49aaf05f1ab36226dca34 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Aug 2021 18:14:41 +0200
+Subject: ALSA: hda - fix the 'Capture Switch' value change notifications
+
+From: Jaroslav Kysela <perex@perex.cz>
+
+[ Upstream commit a2befe9380dd04ee76c871568deca00eedf89134 ]
+
+The original code in the cap_put_caller() function does not
+handle correctly the positive values returned from the passed
+function for multiple iterations. It means that the change
+notifications may be lost.
+
+Fixes: 352f7f914ebb ("ALSA: hda - Merge Realtek parser code to generic parser")
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213851
+Cc: <stable@kernel.org>
+Signed-off-by: Jaroslav Kysela <perex@perex.cz>
+Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/pci/hda/hda_generic.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c
+index 7ac3f04ca8c0..e92fcb150e57 100644
+--- a/sound/pci/hda/hda_generic.c
++++ b/sound/pci/hda/hda_generic.c
+@@ -3458,7 +3458,7 @@ static int cap_put_caller(struct snd_kcontrol *kcontrol,
+ struct hda_gen_spec *spec = codec->spec;
+ const struct hda_input_mux *imux;
+ struct nid_path *path;
+- int i, adc_idx, err = 0;
++ int i, adc_idx, ret, err = 0;
+
+ imux = &spec->input_mux;
+ adc_idx = kcontrol->id.index;
+@@ -3468,9 +3468,13 @@ static int cap_put_caller(struct snd_kcontrol *kcontrol,
+ if (!path || !path->ctls[type])
+ continue;
+ kcontrol->private_value = path->ctls[type];
+- err = func(kcontrol, ucontrol);
+- if (err < 0)
++ ret = func(kcontrol, ucontrol);
++ if (ret < 0) {
++ err = ret;
+ break;
++ }
++ if (ret > 0)
++ err = 1;
+ }
+ mutex_unlock(&codec->control_mutex);
+ if (err >= 0 && spec->cap_sync_hook)
+--
+2.30.2
+
--- /dev/null
+From e4315b501baa4cd85d0466295ec30992c610bd76 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Aug 2021 17:29:45 +0200
+Subject: ASoC: intel: atom: Fix breakage for PCM buffer address setup
+
+From: Takashi Iwai <tiwai@suse.de>
+
+[ Upstream commit 65ca89c2b12cca0d473f3dd54267568ad3af55cc ]
+
+The commit 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM
+buffer address") changed the reference of PCM buffer address to
+substream->runtime->dma_addr as the buffer address may change
+dynamically. However, I forgot that the dma_addr field is still not
+set up for the CONTINUOUS buffer type (that this driver uses) yet in
+5.14 and earlier kernels, and it resulted in garbage I/O. The problem
+will be fixed in 5.15, but we need to address it quickly for now.
+
+The fix is to deduce the address again from the DMA pointer with
+virt_to_phys(), but from the right one, substream->runtime->dma_area.
+
+Fixes: 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address")
+Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com>
+Cc: <stable@vger.kernel.org>
+Acked-by: Mark Brown <broonie@kernel.org>
+Link: https://lore.kernel.org/r/2048c6aa-2187-46bd-6772-36a4fb3c5aeb@redhat.com
+Link: https://lore.kernel.org/r/20210819152945.8510-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/intel/atom/sst-mfld-platform-pcm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+index 216e88624c5f..7d59846808b5 100644
+--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
++++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+@@ -127,7 +127,7 @@ static void sst_fill_alloc_params(struct snd_pcm_substream *substream,
+ snd_pcm_uframes_t period_size;
+ ssize_t periodbytes;
+ ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream);
+- u32 buffer_addr = substream->runtime->dma_addr;
++ u32 buffer_addr = virt_to_phys(substream->runtime->dma_area);
+
+ channels = substream->runtime->channels;
+ period_size = substream->runtime->period_size;
+--
+2.30.2
+
--- /dev/null
+From 18499f192e90aa0cdb275483fb117bf1ddf4d8ab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Aug 2021 14:26:24 +1000
+Subject: btrfs: prevent rename2 from exchanging a subvol with a directory from
+ different parents
+
+From: NeilBrown <neilb@suse.de>
+
+[ Upstream commit 3f79f6f6247c83f448c8026c3ee16d4636ef8d4f ]
+
+Cross-rename lacks a check when that would prevent exchanging a
+directory and subvolume from different parent subvolume. This causes
+data inconsistencies and is caught before commit by tree-checker,
+turning the filesystem to read-only.
+
+Calling the renameat2 with RENAME_EXCHANGE flags like
+
+ renameat2(AT_FDCWD, namesrc, AT_FDCWD, namedest, (1 << 1))
+
+on two paths:
+
+ namesrc = dir1/subvol1/dir2
+ namedest = subvol2/subvol3
+
+will cause key order problem with following write time tree-checker
+report:
+
+ [1194842.307890] BTRFS critical (device loop1): corrupt leaf: root=5 block=27574272 slot=10 ino=258, invalid previous key objectid, have 257 expect 258
+ [1194842.322221] BTRFS info (device loop1): leaf 27574272 gen 8 total ptrs 11 free space 15444 owner 5
+ [1194842.331562] BTRFS info (device loop1): refs 2 lock_owner 0 current 26561
+ [1194842.338772] item 0 key (256 1 0) itemoff 16123 itemsize 160
+ [1194842.338793] inode generation 3 size 16 mode 40755
+ [1194842.338801] item 1 key (256 12 256) itemoff 16111 itemsize 12
+ [1194842.338809] item 2 key (256 84 2248503653) itemoff 16077 itemsize 34
+ [1194842.338817] dir oid 258 type 2
+ [1194842.338823] item 3 key (256 84 2363071922) itemoff 16043 itemsize 34
+ [1194842.338830] dir oid 257 type 2
+ [1194842.338836] item 4 key (256 96 2) itemoff 16009 itemsize 34
+ [1194842.338843] item 5 key (256 96 3) itemoff 15975 itemsize 34
+ [1194842.338852] item 6 key (257 1 0) itemoff 15815 itemsize 160
+ [1194842.338863] inode generation 6 size 8 mode 40755
+ [1194842.338869] item 7 key (257 12 256) itemoff 15801 itemsize 14
+ [1194842.338876] item 8 key (257 84 2505409169) itemoff 15767 itemsize 34
+ [1194842.338883] dir oid 256 type 2
+ [1194842.338888] item 9 key (257 96 2) itemoff 15733 itemsize 34
+ [1194842.338895] item 10 key (258 12 256) itemoff 15719 itemsize 14
+ [1194842.339163] BTRFS error (device loop1): block=27574272 write time tree block corruption detected
+ [1194842.339245] ------------[ cut here ]------------
+ [1194842.443422] WARNING: CPU: 6 PID: 26561 at fs/btrfs/disk-io.c:449 csum_one_extent_buffer+0xed/0x100 [btrfs]
+ [1194842.511863] CPU: 6 PID: 26561 Comm: kworker/u17:2 Not tainted 5.14.0-rc3-git+ #793
+ [1194842.511870] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008
+ [1194842.511876] Workqueue: btrfs-worker-high btrfs_work_helper [btrfs]
+ [1194842.511976] RIP: 0010:csum_one_extent_buffer+0xed/0x100 [btrfs]
+ [1194842.512068] RSP: 0018:ffffa2c284d77da0 EFLAGS: 00010282
+ [1194842.512074] RAX: 0000000000000000 RBX: 0000000000001000 RCX: ffff928867bd9978
+ [1194842.512078] RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff928867bd9970
+ [1194842.512081] RBP: ffff92876b958000 R08: 0000000000000001 R09: 00000000000c0003
+ [1194842.512085] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
+ [1194842.512088] R13: ffff92875f989f98 R14: 0000000000000000 R15: 0000000000000000
+ [1194842.512092] FS: 0000000000000000(0000) GS:ffff928867a00000(0000) knlGS:0000000000000000
+ [1194842.512095] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ [1194842.512099] CR2: 000055f5384da1f0 CR3: 0000000102fe4000 CR4: 00000000000006e0
+ [1194842.512103] Call Trace:
+ [1194842.512128] ? run_one_async_free+0x10/0x10 [btrfs]
+ [1194842.631729] btree_csum_one_bio+0x1ac/0x1d0 [btrfs]
+ [1194842.631837] run_one_async_start+0x18/0x30 [btrfs]
+ [1194842.631938] btrfs_work_helper+0xd5/0x1d0 [btrfs]
+ [1194842.647482] process_one_work+0x262/0x5e0
+ [1194842.647520] worker_thread+0x4c/0x320
+ [1194842.655935] ? process_one_work+0x5e0/0x5e0
+ [1194842.655946] kthread+0x135/0x160
+ [1194842.655953] ? set_kthread_struct+0x40/0x40
+ [1194842.655965] ret_from_fork+0x1f/0x30
+ [1194842.672465] irq event stamp: 1729
+ [1194842.672469] hardirqs last enabled at (1735): [<ffffffffbd1104f5>] console_trylock_spinning+0x185/0x1a0
+ [1194842.672477] hardirqs last disabled at (1740): [<ffffffffbd1104cc>] console_trylock_spinning+0x15c/0x1a0
+ [1194842.672482] softirqs last enabled at (1666): [<ffffffffbdc002e1>] __do_softirq+0x2e1/0x50a
+ [1194842.672491] softirqs last disabled at (1651): [<ffffffffbd08aab7>] __irq_exit_rcu+0xa7/0xd0
+
+The corrupted data will not be written, and filesystem can be unmounted
+and mounted again (all changes since the last commit will be lost).
+
+Add the missing check for new_ino so that all non-subvolumes must reside
+under the same parent subvolume. There's an exception allowing to
+exchange two subvolumes from any parents as the directory representing a
+subvolume is only a logical link and does not have any other structures
+related to the parent subvolume, unlike files, directories etc, that
+are always in the inode namespace of the parent subvolume.
+
+Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT")
+CC: stable@vger.kernel.org # 4.7+
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/inode.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
+index b044b1d910de..54b607a3cc3f 100644
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -9702,8 +9702,14 @@ static int btrfs_rename_exchange(struct inode *old_dir,
+ bool root_log_pinned = false;
+ bool dest_log_pinned = false;
+
+- /* we only allow rename subvolume link between subvolumes */
+- if (old_ino != BTRFS_FIRST_FREE_OBJECTID && root != dest)
++ /*
++ * For non-subvolumes allow exchange only within one subvolume, in the
++ * same inode namespace. Two subvolumes (represented as directory) can
++ * be exchanged as they're a logical link and have a fixed inode number.
++ */
++ if (root != dest &&
++ (old_ino != BTRFS_FIRST_FREE_OBJECTID ||
++ new_ino != BTRFS_FIRST_FREE_OBJECTID))
+ return -EXDEV;
+
+ /* close the race window with snapshot create/destroy ioctl */
+--
+2.30.2
+
--- /dev/null
+From 07470cb55a781b86b85e3aac13959fe6d2f4c30a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Aug 2021 09:29:50 -0400
+Subject: fs: warn about impending deprecation of mandatory locks
+
+From: Jeff Layton <jlayton@kernel.org>
+
+[ Upstream commit fdd92b64d15bc4aec973caa25899afd782402e68 ]
+
+We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros
+have disabled it. Warn the stragglers that still use "-o mand" that
+we'll be dropping support for that mount option.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/namespace.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/fs/namespace.c b/fs/namespace.c
+index a092611d89e7..5782cd55dfdb 100644
+--- a/fs/namespace.c
++++ b/fs/namespace.c
+@@ -1647,8 +1647,12 @@ static inline bool may_mount(void)
+ }
+
+ #ifdef CONFIG_MANDATORY_FILE_LOCKING
+-static inline bool may_mandlock(void)
++static bool may_mandlock(void)
+ {
++ pr_warn_once("======================================================\n"
++ "WARNING: the mand mount option is being deprecated and\n"
++ " will be removed in v5.15!\n"
++ "======================================================\n");
+ return capable(CAP_SYS_ADMIN);
+ }
+ #else
+--
+2.30.2
+
--- /dev/null
+From 1d811da298bca5b92902f12672b0060b27327667 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Aug 2021 18:03:18 +0800
+Subject: ipack: tpci200: fix many double free issues in tpci200_pci_probe
+
+From: Dongliang Mu <mudongliangabcd@gmail.com>
+
+[ Upstream commit 57a1681095f912239c7fb4d66683ab0425973838 ]
+
+The function tpci200_register called by tpci200_install and
+tpci200_unregister called by tpci200_uninstall are in pair. However,
+tpci200_unregister has some cleanup operations not in the
+tpci200_register. So the error handling code of tpci200_pci_probe has
+many different double free issues.
+
+Fix this problem by moving those cleanup operations out of
+tpci200_unregister, into tpci200_pci_remove and reverting
+the previous commit 9272e5d0028d ("ipack/carriers/tpci200:
+Fix a double free in tpci200_pci_probe").
+
+Fixes: 9272e5d0028d ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe")
+Cc: stable@vger.kernel.org
+Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Link: https://lore.kernel.org/r/20210810100323.3938492-1-mudongliangabcd@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ipack/carriers/tpci200.c | 36 ++++++++++++++++----------------
+ 1 file changed, 18 insertions(+), 18 deletions(-)
+
+diff --git a/drivers/ipack/carriers/tpci200.c b/drivers/ipack/carriers/tpci200.c
+index b05d6125c787..80cd0150f592 100644
+--- a/drivers/ipack/carriers/tpci200.c
++++ b/drivers/ipack/carriers/tpci200.c
+@@ -91,16 +91,13 @@ static void tpci200_unregister(struct tpci200_board *tpci200)
+ free_irq(tpci200->info->pdev->irq, (void *) tpci200);
+
+ pci_iounmap(tpci200->info->pdev, tpci200->info->interface_regs);
+- pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs);
+
+ pci_release_region(tpci200->info->pdev, TPCI200_IP_INTERFACE_BAR);
+ pci_release_region(tpci200->info->pdev, TPCI200_IO_ID_INT_SPACES_BAR);
+ pci_release_region(tpci200->info->pdev, TPCI200_MEM16_SPACE_BAR);
+ pci_release_region(tpci200->info->pdev, TPCI200_MEM8_SPACE_BAR);
+- pci_release_region(tpci200->info->pdev, TPCI200_CFG_MEM_BAR);
+
+ pci_disable_device(tpci200->info->pdev);
+- pci_dev_put(tpci200->info->pdev);
+ }
+
+ static void tpci200_enable_irq(struct tpci200_board *tpci200,
+@@ -529,7 +526,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
+ tpci200->info = kzalloc(sizeof(struct tpci200_infos), GFP_KERNEL);
+ if (!tpci200->info) {
+ ret = -ENOMEM;
+- goto out_err_info;
++ goto err_tpci200;
+ }
+
+ pci_dev_get(pdev);
+@@ -540,7 +537,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to allocate PCI Configuration Memory");
+ ret = -EBUSY;
+- goto out_err_pci_request;
++ goto err_tpci200_info;
+ }
+ tpci200->info->cfg_regs = ioremap_nocache(
+ pci_resource_start(pdev, TPCI200_CFG_MEM_BAR),
+@@ -548,7 +545,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
+ if (!tpci200->info->cfg_regs) {
+ dev_err(&pdev->dev, "Failed to map PCI Configuration Memory");
+ ret = -EFAULT;
+- goto out_err_ioremap;
++ goto err_request_region;
+ }
+
+ /* Disable byte swapping for 16 bit IP module access. This will ensure
+@@ -571,7 +568,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
+ if (ret) {
+ dev_err(&pdev->dev, "error during tpci200 install\n");
+ ret = -ENODEV;
+- goto out_err_install;
++ goto err_cfg_regs;
+ }
+
+ /* Register the carrier in the industry pack bus driver */
+@@ -583,7 +580,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
+ dev_err(&pdev->dev,
+ "error registering the carrier on ipack driver\n");
+ ret = -EFAULT;
+- goto out_err_bus_register;
++ goto err_tpci200_install;
+ }
+
+ /* save the bus number given by ipack to logging purpose */
+@@ -594,19 +591,16 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
+ tpci200_create_device(tpci200, i);
+ return 0;
+
+-out_err_bus_register:
++err_tpci200_install:
+ tpci200_uninstall(tpci200);
+- /* tpci200->info->cfg_regs is unmapped in tpci200_uninstall */
+- tpci200->info->cfg_regs = NULL;
+-out_err_install:
+- if (tpci200->info->cfg_regs)
+- iounmap(tpci200->info->cfg_regs);
+-out_err_ioremap:
++err_cfg_regs:
++ pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs);
++err_request_region:
+ pci_release_region(pdev, TPCI200_CFG_MEM_BAR);
+-out_err_pci_request:
+- pci_dev_put(pdev);
++err_tpci200_info:
+ kfree(tpci200->info);
+-out_err_info:
++ pci_dev_put(pdev);
++err_tpci200:
+ kfree(tpci200);
+ return ret;
+ }
+@@ -616,6 +610,12 @@ static void __tpci200_pci_remove(struct tpci200_board *tpci200)
+ ipack_bus_unregister(tpci200->info->ipack_bus);
+ tpci200_uninstall(tpci200);
+
++ pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs);
++
++ pci_release_region(tpci200->info->pdev, TPCI200_CFG_MEM_BAR);
++
++ pci_dev_put(tpci200->info->pdev);
++
+ kfree(tpci200->info);
+ kfree(tpci200);
+ }
+--
+2.30.2
+
--- /dev/null
+From fbdf1cccb251dc03ba404b0a05f87f33ce5db7e3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Aug 2021 18:03:19 +0800
+Subject: ipack: tpci200: fix memory leak in the tpci200_register
+
+From: Dongliang Mu <mudongliangabcd@gmail.com>
+
+[ Upstream commit 50f05bd114a46a74726e432bf81079d3f13a55b7 ]
+
+The error handling code in tpci200_register does not free interface_regs
+allocated by ioremap and the current version of error handling code is
+problematic.
+
+Fix this by refactoring the error handling code and free interface_regs
+when necessary.
+
+Fixes: 43986798fd50 ("ipack: add error handling for ioremap_nocache")
+Cc: stable@vger.kernel.org
+Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Link: https://lore.kernel.org/r/20210810100323.3938492-2-mudongliangabcd@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ipack/carriers/tpci200.c | 24 ++++++++++++++----------
+ 1 file changed, 14 insertions(+), 10 deletions(-)
+
+diff --git a/drivers/ipack/carriers/tpci200.c b/drivers/ipack/carriers/tpci200.c
+index 80cd0150f592..46665b1cef85 100644
+--- a/drivers/ipack/carriers/tpci200.c
++++ b/drivers/ipack/carriers/tpci200.c
+@@ -256,7 +256,7 @@ static int tpci200_register(struct tpci200_board *tpci200)
+ "(bn 0x%X, sn 0x%X) failed to allocate PCI resource for BAR 2 !",
+ tpci200->info->pdev->bus->number,
+ tpci200->info->pdev->devfn);
+- goto out_disable_pci;
++ goto err_disable_device;
+ }
+
+ /* Request IO ID INT space (Bar 3) */
+@@ -268,7 +268,7 @@ static int tpci200_register(struct tpci200_board *tpci200)
+ "(bn 0x%X, sn 0x%X) failed to allocate PCI resource for BAR 3 !",
+ tpci200->info->pdev->bus->number,
+ tpci200->info->pdev->devfn);
+- goto out_release_ip_space;
++ goto err_ip_interface_bar;
+ }
+
+ /* Request MEM8 space (Bar 5) */
+@@ -279,7 +279,7 @@ static int tpci200_register(struct tpci200_board *tpci200)
+ "(bn 0x%X, sn 0x%X) failed to allocate PCI resource for BAR 5!",
+ tpci200->info->pdev->bus->number,
+ tpci200->info->pdev->devfn);
+- goto out_release_ioid_int_space;
++ goto err_io_id_int_spaces_bar;
+ }
+
+ /* Request MEM16 space (Bar 4) */
+@@ -290,7 +290,7 @@ static int tpci200_register(struct tpci200_board *tpci200)
+ "(bn 0x%X, sn 0x%X) failed to allocate PCI resource for BAR 4!",
+ tpci200->info->pdev->bus->number,
+ tpci200->info->pdev->devfn);
+- goto out_release_mem8_space;
++ goto err_mem8_space_bar;
+ }
+
+ /* Map internal tpci200 driver user space */
+@@ -304,7 +304,7 @@ static int tpci200_register(struct tpci200_board *tpci200)
+ tpci200->info->pdev->bus->number,
+ tpci200->info->pdev->devfn);
+ res = -ENOMEM;
+- goto out_release_mem8_space;
++ goto err_mem16_space_bar;
+ }
+
+ /* Initialize lock that protects interface_regs */
+@@ -343,18 +343,22 @@ static int tpci200_register(struct tpci200_board *tpci200)
+ "(bn 0x%X, sn 0x%X) unable to register IRQ !",
+ tpci200->info->pdev->bus->number,
+ tpci200->info->pdev->devfn);
+- goto out_release_ioid_int_space;
++ goto err_interface_regs;
+ }
+
+ return 0;
+
+-out_release_mem8_space:
++err_interface_regs:
++ pci_iounmap(tpci200->info->pdev, tpci200->info->interface_regs);
++err_mem16_space_bar:
++ pci_release_region(tpci200->info->pdev, TPCI200_MEM16_SPACE_BAR);
++err_mem8_space_bar:
+ pci_release_region(tpci200->info->pdev, TPCI200_MEM8_SPACE_BAR);
+-out_release_ioid_int_space:
++err_io_id_int_spaces_bar:
+ pci_release_region(tpci200->info->pdev, TPCI200_IO_ID_INT_SPACES_BAR);
+-out_release_ip_space:
++err_ip_interface_bar:
+ pci_release_region(tpci200->info->pdev, TPCI200_IP_INTERFACE_BAR);
+-out_disable_pci:
++err_disable_device:
+ pci_disable_device(tpci200->info->pdev);
+ return res;
+ }
+--
+2.30.2
+
--- /dev/null
+From d988f6b259f6f6b32e7c6e6e06686004de8f172c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 6 Aug 2020 23:22:01 -0700
+Subject: mm, memcg: avoid stale protection values when cgroup is above
+ protection
+
+From: Yafang Shao <laoar.shao@gmail.com>
+
+[ Upstream commit 22f7496f0b901249f23c5251eb8a10aae126b909 ]
+
+Patch series "mm, memcg: memory.{low,min} reclaim fix & cleanup", v4.
+
+This series contains a fix for a edge case in my earlier protection
+calculation patches, and a patch to make the area overall a little more
+robust to hopefully help avoid this in future.
+
+This patch (of 2):
+
+A cgroup can have both memory protection and a memory limit to isolate it
+from its siblings in both directions - for example, to prevent it from
+being shrunk below 2G under high pressure from outside, but also from
+growing beyond 4G under low pressure.
+
+Commit 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim")
+implemented proportional scan pressure so that multiple siblings in excess
+of their protection settings don't get reclaimed equally but instead in
+accordance to their unprotected portion.
+
+During limit reclaim, this proportionality shouldn't apply of course:
+there is no competition, all pressure is from within the cgroup and should
+be applied as such. Reclaim should operate at full efficiency.
+
+However, mem_cgroup_protected() never expected anybody to look at the
+effective protection values when it indicated that the cgroup is above its
+protection. As a result, a query during limit reclaim may return stale
+protection values that were calculated by a previous reclaim cycle in
+which the cgroup did have siblings.
+
+When this happens, reclaim is unnecessarily hesitant and potentially slow
+to meet the desired limit. In theory this could lead to premature OOM
+kills, although it's not obvious this has occurred in practice.
+
+Workaround the problem by special casing reclaim roots in
+mem_cgroup_protection. These memcgs are never participating in the
+reclaim protection because the reclaim is internal.
+
+We have to ignore effective protection values for reclaim roots because
+mem_cgroup_protected might be called from racing reclaim contexts with
+different roots. Calculation is relying on root -> leaf tree traversal
+therefore top-down reclaim protection invariants should hold. The only
+exception is the reclaim root which should have effective protection set
+to 0 but that would be problematic for the following setup:
+
+ Let's have global and A's reclaim in parallel:
+ |
+ A (low=2G, usage = 3G, max = 3G, children_low_usage = 1.5G)
+ |\
+ | C (low = 1G, usage = 2.5G)
+ B (low = 1G, usage = 0.5G)
+
+ for A reclaim we have
+ B.elow = B.low
+ C.elow = C.low
+
+ For the global reclaim
+ A.elow = A.low
+ B.elow = min(B.usage, B.low) because children_low_usage <= A.elow
+ C.elow = min(C.usage, C.low)
+
+ With the effective values resetting we have A reclaim
+ A.elow = 0
+ B.elow = B.low
+ C.elow = C.low
+
+ and global reclaim could see the above and then
+ B.elow = C.elow = 0 because children_low_usage > A.elow
+
+Which means that protected memcgs would get reclaimed.
+
+In future we would like to make mem_cgroup_protected more robust against
+racing reclaim contexts but that is likely more complex solution than this
+simple workaround.
+
+[hannes@cmpxchg.org - large part of the changelog]
+[mhocko@suse.com - workaround explanation]
+[chris@chrisdown.name - retitle]
+
+Fixes: 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim")
+Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
+Signed-off-by: Chris Down <chris@chrisdown.name>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Chris Down <chris@chrisdown.name>
+Acked-by: Roman Gushchin <guro@fb.com>
+Link: http://lkml.kernel.org/r/cover.1594638158.git.chris@chrisdown.name
+Link: http://lkml.kernel.org/r/044fb8ecffd001c7905d27c0c2ad998069fdc396.1594638158.git.chris@chrisdown.name
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/memcontrol.h | 42 ++++++++++++++++++++++++++++++++++++--
+ mm/memcontrol.c | 8 ++++++++
+ mm/vmscan.c | 3 ++-
+ 3 files changed, 50 insertions(+), 3 deletions(-)
+
+diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
+index fb5b2a41bd45..059f55841cc8 100644
+--- a/include/linux/memcontrol.h
++++ b/include/linux/memcontrol.h
+@@ -356,12 +356,49 @@ static inline bool mem_cgroup_disabled(void)
+ return !cgroup_subsys_enabled(memory_cgrp_subsys);
+ }
+
+-static inline unsigned long mem_cgroup_protection(struct mem_cgroup *memcg,
++static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root,
++ struct mem_cgroup *memcg,
+ bool in_low_reclaim)
+ {
+ if (mem_cgroup_disabled())
+ return 0;
+
++ /*
++ * There is no reclaim protection applied to a targeted reclaim.
++ * We are special casing this specific case here because
++ * mem_cgroup_protected calculation is not robust enough to keep
++ * the protection invariant for calculated effective values for
++ * parallel reclaimers with different reclaim target. This is
++ * especially a problem for tail memcgs (as they have pages on LRU)
++ * which would want to have effective values 0 for targeted reclaim
++ * but a different value for external reclaim.
++ *
++ * Example
++ * Let's have global and A's reclaim in parallel:
++ * |
++ * A (low=2G, usage = 3G, max = 3G, children_low_usage = 1.5G)
++ * |\
++ * | C (low = 1G, usage = 2.5G)
++ * B (low = 1G, usage = 0.5G)
++ *
++ * For the global reclaim
++ * A.elow = A.low
++ * B.elow = min(B.usage, B.low) because children_low_usage <= A.elow
++ * C.elow = min(C.usage, C.low)
++ *
++ * With the effective values resetting we have A reclaim
++ * A.elow = 0
++ * B.elow = B.low
++ * C.elow = C.low
++ *
++ * If the global reclaim races with A's reclaim then
++ * B.elow = C.elow = 0 because children_low_usage > A.elow)
++ * is possible and reclaiming B would be violating the protection.
++ *
++ */
++ if (root == memcg)
++ return 0;
++
+ if (in_low_reclaim)
+ return READ_ONCE(memcg->memory.emin);
+
+@@ -847,7 +884,8 @@ static inline void memcg_memory_event_mm(struct mm_struct *mm,
+ {
+ }
+
+-static inline unsigned long mem_cgroup_protection(struct mem_cgroup *memcg,
++static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root,
++ struct mem_cgroup *memcg,
+ bool in_low_reclaim)
+ {
+ return 0;
+diff --git a/mm/memcontrol.c b/mm/memcontrol.c
+index 2701497edda5..6d7fe3589e4a 100644
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -6446,6 +6446,14 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
+
+ if (!root)
+ root = root_mem_cgroup;
++
++ /*
++ * Effective values of the reclaim targets are ignored so they
++ * can be stale. Have a look at mem_cgroup_protection for more
++ * details.
++ * TODO: calculation should be more robust so that we do not need
++ * that special casing.
++ */
+ if (memcg == root)
+ return MEMCG_PROT_NONE;
+
+diff --git a/mm/vmscan.c b/mm/vmscan.c
+index 10feb872d9a4..dc44da27673d 100644
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -2462,7 +2462,8 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
+ unsigned long protection;
+
+ lruvec_size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx);
+- protection = mem_cgroup_protection(memcg,
++ protection = mem_cgroup_protection(sc->target_mem_cgroup,
++ memcg,
+ sc->memcg_low_reclaim);
+
+ if (protection) {
+--
+2.30.2
+
--- /dev/null
+From 5b460856aae2dc4707c8e1f2264c75535ae98942 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Aug 2021 19:04:21 -0700
+Subject: mm: memcontrol: fix occasional OOMs due to proportional memory.low
+ reclaim
+
+From: Johannes Weiner <hannes@cmpxchg.org>
+
+[ Upstream commit f56ce412a59d7d938b81de8878faef128812482c ]
+
+We've noticed occasional OOM killing when memory.low settings are in
+effect for cgroups. This is unexpected and undesirable as memory.low is
+supposed to express non-OOMing memory priorities between cgroups.
+
+The reason for this is proportional memory.low reclaim. When cgroups
+are below their memory.low threshold, reclaim passes them over in the
+first round, and then retries if it couldn't find pages anywhere else.
+But when cgroups are slightly above their memory.low setting, page scan
+force is scaled down and diminished in proportion to the overage, to the
+point where it can cause reclaim to fail as well - only in that case we
+currently don't retry, and instead trigger OOM.
+
+To fix this, hook proportional reclaim into the same retry logic we have
+in place for when cgroups are skipped entirely. This way if reclaim
+fails and some cgroups were scanned with diminished pressure, we'll try
+another full-force cycle before giving up and OOMing.
+
+[akpm@linux-foundation.org: coding-style fixes]
+
+Link: https://lkml.kernel.org/r/20210817180506.220056-1-hannes@cmpxchg.org
+Fixes: 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim")
+Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
+Reported-by: Leon Yang <lnyng@fb.com>
+Reviewed-by: Rik van Riel <riel@surriel.com>
+Reviewed-by: Shakeel Butt <shakeelb@google.com>
+Acked-by: Roman Gushchin <guro@fb.com>
+Acked-by: Chris Down <chris@chrisdown.name>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: <stable@vger.kernel.org> [5.4+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/memcontrol.h | 29 +++++++++++++++--------------
+ mm/vmscan.c | 27 +++++++++++++++++++--------
+ 2 files changed, 34 insertions(+), 22 deletions(-)
+
+diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
+index 059f55841cc8..b6d0b68f5503 100644
+--- a/include/linux/memcontrol.h
++++ b/include/linux/memcontrol.h
+@@ -356,12 +356,15 @@ static inline bool mem_cgroup_disabled(void)
+ return !cgroup_subsys_enabled(memory_cgrp_subsys);
+ }
+
+-static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root,
+- struct mem_cgroup *memcg,
+- bool in_low_reclaim)
++static inline void mem_cgroup_protection(struct mem_cgroup *root,
++ struct mem_cgroup *memcg,
++ unsigned long *min,
++ unsigned long *low)
+ {
++ *min = *low = 0;
++
+ if (mem_cgroup_disabled())
+- return 0;
++ return;
+
+ /*
+ * There is no reclaim protection applied to a targeted reclaim.
+@@ -397,13 +400,10 @@ static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root,
+ *
+ */
+ if (root == memcg)
+- return 0;
+-
+- if (in_low_reclaim)
+- return READ_ONCE(memcg->memory.emin);
++ return;
+
+- return max(READ_ONCE(memcg->memory.emin),
+- READ_ONCE(memcg->memory.elow));
++ *min = READ_ONCE(memcg->memory.emin);
++ *low = READ_ONCE(memcg->memory.elow);
+ }
+
+ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
+@@ -884,11 +884,12 @@ static inline void memcg_memory_event_mm(struct mm_struct *mm,
+ {
+ }
+
+-static inline unsigned long mem_cgroup_protection(struct mem_cgroup *root,
+- struct mem_cgroup *memcg,
+- bool in_low_reclaim)
++static inline void mem_cgroup_protection(struct mem_cgroup *root,
++ struct mem_cgroup *memcg,
++ unsigned long *min,
++ unsigned long *low)
+ {
+- return 0;
++ *min = *low = 0;
+ }
+
+ static inline enum mem_cgroup_protection mem_cgroup_protected(
+diff --git a/mm/vmscan.c b/mm/vmscan.c
+index dc44da27673d..fad9be4703ec 100644
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -89,9 +89,12 @@ struct scan_control {
+ unsigned int may_swap:1;
+
+ /*
+- * Cgroups are not reclaimed below their configured memory.low,
+- * unless we threaten to OOM. If any cgroups are skipped due to
+- * memory.low and nothing was reclaimed, go back for memory.low.
++ * Cgroup memory below memory.low is protected as long as we
++ * don't threaten to OOM. If any cgroup is reclaimed at
++ * reduced force or passed over entirely due to its memory.low
++ * setting (memcg_low_skipped), and nothing is reclaimed as a
++ * result, then go back for one more cycle that reclaims the protected
++ * memory (memcg_low_reclaim) to avert OOM.
+ */
+ unsigned int memcg_low_reclaim:1;
+ unsigned int memcg_low_skipped:1;
+@@ -2458,15 +2461,14 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
+ for_each_evictable_lru(lru) {
+ int file = is_file_lru(lru);
+ unsigned long lruvec_size;
++ unsigned long low, min;
+ unsigned long scan;
+- unsigned long protection;
+
+ lruvec_size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx);
+- protection = mem_cgroup_protection(sc->target_mem_cgroup,
+- memcg,
+- sc->memcg_low_reclaim);
++ mem_cgroup_protection(sc->target_mem_cgroup, memcg,
++ &min, &low);
+
+- if (protection) {
++ if (min || low) {
+ /*
+ * Scale a cgroup's reclaim pressure by proportioning
+ * its current usage to its memory.low or memory.min
+@@ -2497,6 +2499,15 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
+ * hard protection.
+ */
+ unsigned long cgroup_size = mem_cgroup_size(memcg);
++ unsigned long protection;
++
++ /* memory.low scaling, make sure we retry before OOM */
++ if (!sc->memcg_low_reclaim && low > min) {
++ protection = low;
++ sc->memcg_low_skipped = 1;
++ } else {
++ protection = min;
++ }
+
+ /* Avoid TOCTOU with earlier protection check */
+ cgroup_size = max(cgroup_size, protection);
+--
+2.30.2
+
--- /dev/null
+From 3aa6331ec33676186ca14ad731fde810253b9e0f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 30 Jun 2021 12:22:32 +0200
+Subject: mmc: dw_mmc: Fix hang on data CRC error
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+[ Upstream commit 25f8203b4be1937c4939bb98623e67dcfd7da4d1 ]
+
+When a Data CRC interrupt is received, the driver disables the DMA, then
+sends the stop/abort command and then waits for Data Transfer Over.
+
+However, sometimes, when a data CRC error is received in the middle of a
+multi-block write transfer, the Data Transfer Over interrupt is never
+received, and the driver hangs and never completes the request.
+
+The driver sets the BMOD.SWR bit (SDMMC_IDMAC_SWRESET) when stopping the
+DMA, but according to the manual CMD.STOP_ABORT_CMD should be programmed
+"before assertion of SWR". Do these operations in the recommended
+order. With this change the Data Transfer Over is always received
+correctly in my tests.
+
+Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
+Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210630102232.16011-1-vincent.whitchurch@axis.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mmc/host/dw_mmc.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
+index 79c55c7b4afd..6ace82028667 100644
+--- a/drivers/mmc/host/dw_mmc.c
++++ b/drivers/mmc/host/dw_mmc.c
+@@ -2017,8 +2017,8 @@ static void dw_mci_tasklet_func(unsigned long priv)
+ continue;
+ }
+
+- dw_mci_stop_dma(host);
+ send_stop_abort(host, data);
++ dw_mci_stop_dma(host);
+ state = STATE_SENDING_STOP;
+ break;
+ }
+@@ -2042,10 +2042,10 @@ static void dw_mci_tasklet_func(unsigned long priv)
+ */
+ if (test_and_clear_bit(EVENT_DATA_ERROR,
+ &host->pending_events)) {
+- dw_mci_stop_dma(host);
+ if (!(host->data_status & (SDMMC_INT_DRTO |
+ SDMMC_INT_EBE)))
+ send_stop_abort(host, data);
++ dw_mci_stop_dma(host);
+ state = STATE_DATA_ERROR;
+ break;
+ }
+@@ -2078,10 +2078,10 @@ static void dw_mci_tasklet_func(unsigned long priv)
+ */
+ if (test_and_clear_bit(EVENT_DATA_ERROR,
+ &host->pending_events)) {
+- dw_mci_stop_dma(host);
+ if (!(host->data_status & (SDMMC_INT_DRTO |
+ SDMMC_INT_EBE)))
+ send_stop_abort(host, data);
++ dw_mci_stop_dma(host);
+ state = STATE_DATA_ERROR;
+ break;
+ }
+--
+2.30.2
+
--- /dev/null
+From 7389f03a99e8000a699e14ea5119c699a1ade98f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 21 Jul 2021 22:58:58 -0400
+Subject: PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI
+
+From: Marcin Bachry <hegel666@gmail.com>
+
+[ Upstream commit e0bff43220925b7e527f9d3bc9f5c624177c959e ]
+
+The Renoir XHCI controller apparently doesn't resume reliably with the
+standard D3hot-to-D0 delay. Increase it to 20ms.
+
+[Alex: I talked to the AMD USB hardware team and the AMD Windows team and
+they are not aware of any HW errata or specific issues. The HW works fine
+in Windows. I was told Windows uses a rather generous default delay of
+100ms for PCI state transitions.]
+
+Link: https://lore.kernel.org/r/20210722025858.220064-1-alexander.deucher@amd.com
+Signed-off-by: Marcin Bachry <hegel666@gmail.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Prike Liang <prike.liang@amd.com>
+Cc: Shyam Sundar S K <shyam-sundar.s-k@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
+index 6c1b936a94fa..0241f0dcc093 100644
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -1905,6 +1905,7 @@ static void quirk_ryzen_xhci_d3hot(struct pci_dev *dev)
+ }
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15e0, quirk_ryzen_xhci_d3hot);
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15e1, quirk_ryzen_xhci_d3hot);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1639, quirk_ryzen_xhci_d3hot);
+
+ #ifdef CONFIG_X86_IO_APIC
+ static int dmi_disable_ioapicreroute(const struct dmi_system_id *d)
+--
+2.30.2
+
i40e-fix-atr-queue-selection.patch
iavf-fix-ping-is-lost-after-untrusted-vf-had-tried-t.patch
ovl-add-splice-file-read-write-helper.patch
+mmc-dw_mmc-fix-hang-on-data-crc-error.patch
+alsa-hda-fix-the-capture-switch-value-change-notific.patch
+tracing-histogram-fix-null-pointer-dereference-on-st.patch
+slimbus-messaging-start-transaction-ids-from-1-inste.patch
+slimbus-messaging-check-for-valid-transaction-id.patch
+slimbus-ngd-reset-dma-setup-during-runtime-pm.patch
+ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch
+ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch
+btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch
+pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch
+asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch
+mm-memcg-avoid-stale-protection-values-when-cgroup-i.patch
+mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch
+fs-warn-about-impending-deprecation-of-mandatory-loc.patch
--- /dev/null
+From 0eda62ad1e83457e1f5274c7bee9e5cda080943d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Aug 2021 09:24:26 +0100
+Subject: slimbus: messaging: check for valid transaction id
+
+From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+[ Upstream commit a263c1ff6abe0e66712f40d595bbddc7a35907f8 ]
+
+In some usecases transaction ids are dynamically allocated inside
+the controller driver after sending the messages which have generic
+acknowledge responses. So check for this before refcounting pm_runtime.
+
+Without this we would end up imbalancing runtime pm count by
+doing pm_runtime_put() in both slim_do_transfer() and slim_msg_response()
+for a single pm_runtime_get() in slim_do_transfer()
+
+Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Link: https://lore.kernel.org/r/20210809082428.11236-3-srinivas.kandagatla@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/slimbus/messaging.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c
+index 3b77713f1e3f..ddf0371ad52b 100644
+--- a/drivers/slimbus/messaging.c
++++ b/drivers/slimbus/messaging.c
+@@ -131,7 +131,8 @@ int slim_do_transfer(struct slim_controller *ctrl, struct slim_msg_txn *txn)
+ goto slim_xfer_err;
+ }
+ }
+-
++ /* Initialize tid to invalid value */
++ txn->tid = 0;
+ need_tid = slim_tid_txn(txn->mt, txn->mc);
+
+ if (need_tid) {
+@@ -163,7 +164,7 @@ int slim_do_transfer(struct slim_controller *ctrl, struct slim_msg_txn *txn)
+ txn->mt, txn->mc, txn->la, ret);
+
+ slim_xfer_err:
+- if (!clk_pause_msg && (!need_tid || ret == -ETIMEDOUT)) {
++ if (!clk_pause_msg && (txn->tid == 0 || ret == -ETIMEDOUT)) {
+ /*
+ * remove runtime-pm vote if this was TX only, or
+ * if there was error during this transaction
+--
+2.30.2
+
--- /dev/null
+From 6782778bd76c04b521b67ac83dd7b42656973afd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Aug 2021 09:24:25 +0100
+Subject: slimbus: messaging: start transaction ids from 1 instead of zero
+
+From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+[ Upstream commit 9659281ce78de0f15a4aa124da8f7450b1399c09 ]
+
+As tid is unsigned its hard to figure out if the tid is valid or
+invalid. So Start the transaction ids from 1 instead of zero
+so that we could differentiate between a valid tid and invalid tids
+
+This is useful in cases where controller would add a tid for controller
+specific transfers.
+
+Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Link: https://lore.kernel.org/r/20210809082428.11236-2-srinivas.kandagatla@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/slimbus/messaging.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c
+index d5879142dbef..3b77713f1e3f 100644
+--- a/drivers/slimbus/messaging.c
++++ b/drivers/slimbus/messaging.c
+@@ -66,7 +66,7 @@ int slim_alloc_txn_tid(struct slim_controller *ctrl, struct slim_msg_txn *txn)
+ int ret = 0;
+
+ spin_lock_irqsave(&ctrl->txn_lock, flags);
+- ret = idr_alloc_cyclic(&ctrl->tid_idr, txn, 0,
++ ret = idr_alloc_cyclic(&ctrl->tid_idr, txn, 1,
+ SLIM_MAX_TIDS, GFP_ATOMIC);
+ if (ret < 0) {
+ spin_unlock_irqrestore(&ctrl->txn_lock, flags);
+--
+2.30.2
+
--- /dev/null
+From c1388104b0c03aeedb6d7618434661b8aeb2397c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Aug 2021 09:24:28 +0100
+Subject: slimbus: ngd: reset dma setup during runtime pm
+
+From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+[ Upstream commit d77772538f00b7265deace6e77e555ee18365ad0 ]
+
+During suspend/resume NGD remote instance is power cycled along
+with remotely controlled bam dma engine.
+So Reset the dma configuration during this suspend resume path
+so that we are not dealing with any stale dma setup.
+
+Without this transactions timeout after first suspend resume path.
+
+Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Link: https://lore.kernel.org/r/20210809082428.11236-5-srinivas.kandagatla@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/slimbus/qcom-ngd-ctrl.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
+index b60541c3f72d..09ecd1fb24ae 100644
+--- a/drivers/slimbus/qcom-ngd-ctrl.c
++++ b/drivers/slimbus/qcom-ngd-ctrl.c
+@@ -1061,7 +1061,8 @@ static void qcom_slim_ngd_setup(struct qcom_slim_ngd_ctrl *ctrl)
+ {
+ u32 cfg = readl_relaxed(ctrl->ngd->base);
+
+- if (ctrl->state == QCOM_SLIM_NGD_CTRL_DOWN)
++ if (ctrl->state == QCOM_SLIM_NGD_CTRL_DOWN ||
++ ctrl->state == QCOM_SLIM_NGD_CTRL_ASLEEP)
+ qcom_slim_ngd_init_dma(ctrl);
+
+ /* By default enable message queues */
+@@ -1112,6 +1113,7 @@ static int qcom_slim_ngd_power_up(struct qcom_slim_ngd_ctrl *ctrl)
+ dev_info(ctrl->dev, "Subsys restart: ADSP active framer\n");
+ return 0;
+ }
++ qcom_slim_ngd_setup(ctrl);
+ return 0;
+ }
+
+@@ -1500,6 +1502,7 @@ static int __maybe_unused qcom_slim_ngd_runtime_suspend(struct device *dev)
+ struct qcom_slim_ngd_ctrl *ctrl = dev_get_drvdata(dev);
+ int ret = 0;
+
++ qcom_slim_ngd_exit_dma(ctrl);
+ if (!ctrl->qmi.handle)
+ return 0;
+
+--
+2.30.2
+
--- /dev/null
+From 6acf6d440e544a9a71a23538d6536142dd8cb23e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 8 Aug 2021 00:30:11 -0400
+Subject: tracing / histogram: Fix NULL pointer dereference on strcmp() on NULL
+ event name
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+[ Upstream commit 5acce0bff2a0420ce87d4591daeb867f47d552c2 ]
+
+The following commands:
+
+ # echo 'read_max u64 size;' > synthetic_events
+ # echo 'hist:keys=common_pid:count=count:onmax($count).trace(read_max,count)' > events/syscalls/sys_enter_read/trigger
+
+Causes:
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000000
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ PGD 0 P4D 0
+ Oops: 0000 [#1] PREEMPT SMP
+ CPU: 4 PID: 1763 Comm: bash Not tainted 5.14.0-rc2-test+ #155
+ Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
+v03.03 07/14/2016
+ RIP: 0010:strcmp+0xc/0x20
+ Code: 75 f7 31 c0 0f b6 0c 06 88 0c 02 48 83 c0 01 84 c9 75 f1 4c 89 c0
+c3 0f 1f 80 00 00 00 00 31 c0 eb 08 48 83 c0 01 84 d2 74 0f <0f> b6 14 07
+3a 14 06 74 ef 19 c0 83 c8 01 c3 31 c0 c3 66 90 48 89
+ RSP: 0018:ffffb5fdc0963ca8 EFLAGS: 00010246
+ RAX: 0000000000000000 RBX: ffffffffb3a4e040 RCX: 0000000000000000
+ RDX: 0000000000000000 RSI: ffff9714c0d0b640 RDI: 0000000000000000
+ RBP: 0000000000000000 R08: 00000022986b7cde R09: ffffffffb3a4dff8
+ R10: 0000000000000000 R11: 0000000000000000 R12: ffff9714c50603c8
+ R13: 0000000000000000 R14: ffff97143fdf9e48 R15: ffff9714c01a2210
+ FS: 00007f1fa6785740(0000) GS:ffff9714da400000(0000)
+knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000000000 CR3: 000000002d863004 CR4: 00000000001706e0
+ Call Trace:
+ __find_event_file+0x4e/0x80
+ action_create+0x6b7/0xeb0
+ ? kstrdup+0x44/0x60
+ event_hist_trigger_func+0x1a07/0x2130
+ trigger_process_regex+0xbd/0x110
+ event_trigger_write+0x71/0xd0
+ vfs_write+0xe9/0x310
+ ksys_write+0x68/0xe0
+ do_syscall_64+0x3b/0x90
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+ RIP: 0033:0x7f1fa6879e87
+
+The problem was the "trace(read_max,count)" where the "count" should be
+"$count" as "onmax()" only handles variables (although it really should be
+able to figure out that "count" is a field of sys_enter_read). But there's
+a path that does not find the variable and ends up passing a NULL for the
+event, which ends up getting passed to "strcmp()".
+
+Add a check for NULL to return and error on the command with:
+
+ # cat error_log
+ hist:syscalls:sys_enter_read: error: Couldn't create or find variable
+ Command: hist:keys=common_pid:count=count:onmax($count).trace(read_max,count)
+ ^
+Link: https://lkml.kernel.org/r/20210808003011.4037f8d0@oasis.local.home
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 50450603ec9cb tracing: Add 'onmax' hist trigger action support
+Reviewed-by: Tom Zanussi <zanussi@kernel.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/trace/trace_events_hist.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
+index e40712abe089..f63766366e23 100644
+--- a/kernel/trace/trace_events_hist.c
++++ b/kernel/trace/trace_events_hist.c
+@@ -4291,6 +4291,8 @@ trace_action_create_field_var(struct hist_trigger_data *hist_data,
+ event = data->match_data.event;
+ }
+
++ if (!event)
++ goto free;
+ /*
+ * At this point, we're looking at a field on another
+ * event. Because we can't modify a hist trigger on
+--
+2.30.2
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
