From: Sasha Levin Date: Tue, 24 Aug 2021 02:59:51 +0000 (-0400) Subject: Fixes for 5.10 X-Git-Tag: v5.13.13~14 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=90f96d46e4de7e3932fec67a6812c46b723f3bdd;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.10 Signed-off-by: Sasha Levin --- diff --git a/queue-5.10/alsa-hda-fix-the-capture-switch-value-change-notific.patch b/queue-5.10/alsa-hda-fix-the-capture-switch-value-change-notific.patch new file mode 100644 index 00000000000..8ee4ccbaa00 --- /dev/null +++ b/queue-5.10/alsa-hda-fix-the-capture-switch-value-change-notific.patch @@ -0,0 +1,57 @@ +From b3f21a90a8f6d4cfb3f85a85538da9fb5b164ae6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 11 Aug 2021 18:14:41 +0200 +Subject: ALSA: hda - fix the 'Capture Switch' value change notifications + +From: Jaroslav Kysela + +[ 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: +Signed-off-by: Jaroslav Kysela +Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + 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 7c49a7e92dd2..323df011b94a 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 + diff --git a/queue-5.10/alsa-hda-realtek-enable-4-speaker-output-for-dell-xp.patch b/queue-5.10/alsa-hda-realtek-enable-4-speaker-output-for-dell-xp.patch new file mode 100644 index 00000000000..79403938483 --- /dev/null +++ b/queue-5.10/alsa-hda-realtek-enable-4-speaker-output-for-dell-xp.patch @@ -0,0 +1,38 @@ +From ca3ede98881297ac3ef0d060291087245cd49f10 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 14 Aug 2021 15:46:05 -0700 +Subject: ALSA: hda/realtek: Enable 4-speaker output for Dell XPS 15 9510 + laptop + +From: Kristin Paget + +[ Upstream commit da94692001ea45ffa1f5e9f17ecdef7aecd90c27 ] + +The 2021-model XPS 15 appears to use the same 4-speakers-on-ALC289 audio +setup as the Precision models, so requires the same quirk to enable woofer +output. Tested on my own 9510. + +Signed-off-by: Kristin Paget +Cc: +Link: https://lore.kernel.org/r/e1fc95c5-c10a-1f98-a5c2-dd6e336157e1@tombom.co.uk +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/patch_realtek.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c +index beb5fb03e388..de4cd91b9ba8 100644 +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -8258,6 +8258,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { + SND_PCI_QUIRK(0x1028, 0x0a2e, "Dell", ALC236_FIXUP_DELL_AIO_HEADSET_MIC), + SND_PCI_QUIRK(0x1028, 0x0a30, "Dell", ALC236_FIXUP_DELL_AIO_HEADSET_MIC), + SND_PCI_QUIRK(0x1028, 0x0a58, "Dell", ALC255_FIXUP_DELL_HEADSET_MIC), ++ SND_PCI_QUIRK(0x1028, 0x0a61, "Dell XPS 15 9510", ALC289_FIXUP_DUAL_SPK), + SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2), +-- +2.30.2 + diff --git a/queue-5.10/alsa-hda-realtek-limit-mic-boost-on-hp-probook-445-g.patch b/queue-5.10/alsa-hda-realtek-limit-mic-boost-on-hp-probook-445-g.patch new file mode 100644 index 00000000000..cf48d15c136 --- /dev/null +++ b/queue-5.10/alsa-hda-realtek-limit-mic-boost-on-hp-probook-445-g.patch @@ -0,0 +1,60 @@ +From c49a67e47faea26144148091071cd42cc2d34da0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 18 Aug 2021 22:41:18 +0800 +Subject: ALSA: hda/realtek: Limit mic boost on HP ProBook 445 G8 + +From: Kai-Heng Feng + +[ Upstream commit 8903376dc69949199301b290cc22dc64ae5d8a6d ] + +The mic has lots of noises if mic boost is enabled. So disable mic boost +to get crystal clear audio capture. + +Signed-off-by: Kai-Heng Feng +Cc: +Link: https://lore.kernel.org/r/20210818144119.121738-1-kai.heng.feng@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/patch_realtek.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c +index de4cd91b9ba8..6219d0311c9a 100644 +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -6590,6 +6590,7 @@ enum { + ALC287_FIXUP_IDEAPAD_BASS_SPK_AMP, + ALC623_FIXUP_LENOVO_THINKSTATION_P340, + ALC255_FIXUP_ACER_HEADPHONE_AND_MIC, ++ ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST, + }; + + static const struct hda_fixup alc269_fixups[] = { +@@ -8168,6 +8169,12 @@ static const struct hda_fixup alc269_fixups[] = { + .chained = true, + .chain_id = ALC255_FIXUP_XIAOMI_HEADSET_MIC + }, ++ [ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST] = { ++ .type = HDA_FIXUP_FUNC, ++ .v.func = alc269_fixup_limit_int_mic_boost, ++ .chained = true, ++ .chain_id = ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF, ++ }, + }; + + static const struct snd_pci_quirk alc269_fixup_tbl[] = { +@@ -8364,8 +8371,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { + SND_PCI_QUIRK(0x103c, 0x8847, "HP EliteBook x360 830 G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x884b, "HP EliteBook 840 Aero G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x884c, "HP EliteBook 840 G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED), +- SND_PCI_QUIRK(0x103c, 0x8862, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), +- SND_PCI_QUIRK(0x103c, 0x8863, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), ++ SND_PCI_QUIRK(0x103c, 0x8862, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST), ++ SND_PCI_QUIRK(0x103c, 0x8863, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST), + SND_PCI_QUIRK(0x103c, 0x886d, "HP ZBook Fury 17.3 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT), + SND_PCI_QUIRK(0x103c, 0x8870, "HP ZBook Fury 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT), + SND_PCI_QUIRK(0x103c, 0x8873, "HP ZBook Studio 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT), +-- +2.30.2 + diff --git a/queue-5.10/alsa-hda-via-apply-runtime-pm-workaround-for-asus-b2.patch b/queue-5.10/alsa-hda-via-apply-runtime-pm-workaround-for-asus-b2.patch new file mode 100644 index 00000000000..d125c6d7157 --- /dev/null +++ b/queue-5.10/alsa-hda-via-apply-runtime-pm-workaround-for-asus-b2.patch @@ -0,0 +1,38 @@ +From 835ccafbb7c027a02f383c1c46d055af2cebcb0e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 17 Aug 2021 07:24:32 +0200 +Subject: ALSA: hda/via: Apply runtime PM workaround for ASUS B23E + +From: Takashi Iwai + +[ Upstream commit 4bf61ad5f0204b67ba570da6e5c052c2095e29df ] + +ASUS B23E requires the same workaround like other machines with +VT1802, otherwise it looses the codec power on a few nodes and the +sound kept silence. + +Fixes: a0645daf1610 ("ALSA: HDA: Early Forbid of runtime PM") +Link: https://lore.kernel.org/r/ac2232f142efcd67fe6ac38897f704f7176bd200.camel@gmail.com +Cc: +Link: https://lore.kernel.org/r/20210817052432.14751-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/patch_via.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c +index a5c1a2c4eae4..773a136161f1 100644 +--- a/sound/pci/hda/patch_via.c ++++ b/sound/pci/hda/patch_via.c +@@ -1041,6 +1041,7 @@ static const struct hda_fixup via_fixups[] = { + }; + + static const struct snd_pci_quirk vt2002p_fixups[] = { ++ SND_PCI_QUIRK(0x1043, 0x13f7, "Asus B23E", VIA_FIXUP_POWER_SAVE), + SND_PCI_QUIRK(0x1043, 0x1487, "Asus G75", VIA_FIXUP_ASUS_G75), + SND_PCI_QUIRK(0x1043, 0x8532, "Asus X202E", VIA_FIXUP_INTMIC_BOOST), + SND_PCI_QUIRK_VENDOR(0x1558, "Clevo", VIA_FIXUP_POWER_SAVE), +-- +2.30.2 + diff --git a/queue-5.10/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch b/queue-5.10/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch new file mode 100644 index 00000000000..d3ab24c7982 --- /dev/null +++ b/queue-5.10/asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch @@ -0,0 +1,48 @@ +From 2fcfb659ed3092ce23d9edee379bee22aa86c714 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Aug 2021 17:29:45 +0200 +Subject: ASoC: intel: atom: Fix breakage for PCM buffer address setup + +From: Takashi Iwai + +[ 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 +Cc: +Acked-by: Mark Brown +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 +Signed-off-by: Sasha Levin +--- + 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 2784611196f0..255b4d528a66 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 + diff --git a/queue-5.10/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch b/queue-5.10/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch new file mode 100644 index 00000000000..6675c3df355 --- /dev/null +++ b/queue-5.10/btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch @@ -0,0 +1,124 @@ +From 5ea3b2beef60515e3ee84e01813c7c424af93801 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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): [] console_trylock_spinning+0x185/0x1a0 + [1194842.672477] hardirqs last disabled at (1740): [] console_trylock_spinning+0x15c/0x1a0 + [1194842.672482] softirqs last enabled at (1666): [] __do_softirq+0x2e1/0x50a + [1194842.672491] softirqs last disabled at (1651): [] __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 +Signed-off-by: NeilBrown +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + 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 4f21b8fbfd4b..fc4311415fc6 100644 +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -8904,8 +8904,14 @@ static int btrfs_rename_exchange(struct inode *old_dir, + bool dest_log_pinned = false; + bool need_abort = 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 + diff --git a/queue-5.10/clk-imx6q-fix-uart-earlycon-unwork.patch b/queue-5.10/clk-imx6q-fix-uart-earlycon-unwork.patch new file mode 100644 index 00000000000..e7e9bcdd405 --- /dev/null +++ b/queue-5.10/clk-imx6q-fix-uart-earlycon-unwork.patch @@ -0,0 +1,41 @@ +From e002560a110111315185ad24d86e16c434a1fc19 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 2 Jul 2021 16:54:38 +0800 +Subject: clk: imx6q: fix uart earlycon unwork + +From: Dong Aisheng + +[ Upstream commit 283f1b9a0401859c53fdd6483ab66f1c4fadaea5 ] + +The earlycon depends on the bootloader setup UART clocks being retained. +There're actually two uart clocks (ipg, per) on MX6QDL, +but the 'Fixes' commit change to register only one which means +another clock may be disabled during booting phase +and result in the earlycon unwork. + +Cc: stable@vger.kernel.org # v5.10+ +Fixes: 379c9a24cc23 ("clk: imx: Fix reparenting of UARTs not associated with stdout") +Signed-off-by: Dong Aisheng +Link: https://lore.kernel.org/r/20210702085438.1988087-1-aisheng.dong@nxp.com +Reviewed-by: Abel Vesa +Signed-off-by: Stephen Boyd +Signed-off-by: Sasha Levin +--- + drivers/clk/imx/clk-imx6q.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c +index f444bbe8244c..7d07dd92a7b4 100644 +--- a/drivers/clk/imx/clk-imx6q.c ++++ b/drivers/clk/imx/clk-imx6q.c +@@ -974,6 +974,6 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node) + hws[IMX6QDL_CLK_PLL3_USB_OTG]->clk); + } + +- imx_register_uart_clocks(1); ++ imx_register_uart_clocks(2); + } + CLK_OF_DECLARE(imx6q, "fsl,imx6q-ccm", imx6q_clocks_init); +-- +2.30.2 + diff --git a/queue-5.10/clk-qcom-gdsc-ensure-regulator-init-state-matches-gd.patch b/queue-5.10/clk-qcom-gdsc-ensure-regulator-init-state-matches-gd.patch new file mode 100644 index 00000000000..c37849f8902 --- /dev/null +++ b/queue-5.10/clk-qcom-gdsc-ensure-regulator-init-state-matches-gd.patch @@ -0,0 +1,122 @@ +From bb857e60acd26ac68012bd8ca90602cb6420fde8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 21 Jul 2021 15:40:56 -0700 +Subject: clk: qcom: gdsc: Ensure regulator init state matches GDSC state + +From: Bjorn Andersson + +[ Upstream commit 9711759a87a041705148161b937ec847048d882e ] + +As GDSCs are registered and found to be already enabled gdsc_init() +ensures that 1) the kernel state matches the hardware state, and 2) +votable GDSCs are properly enabled from this master as well. + +But as the (optional) supply regulator is enabled deep into +gdsc_toggle_logic(), which is only executed for votable GDSCs, the +kernel's state of the regulator might not match the hardware. The +regulator might be automatically turned off if no other users are +present or the next call to gdsc_disable() would cause an unbalanced +regulator_disable(). + +Given that the votable case deals with an already enabled GDSC, most of +gdsc_enable() and gdsc_toggle_logic() can be skipped. Reduce it to just +clearing the SW_COLLAPSE_MASK and enabling hardware control to simply +call regulator_enable() in both cases. + +The enablement of hardware control seems to be an independent property +from the GDSC being enabled, so this is moved outside that conditional +segment. + +Lastly, as the propagation of ALWAYS_ON to GENPD_FLAG_ALWAYS_ON needs to +happen regardless of the initial state this is grouped together with the +other sc->pd updates at the end of the function. + +Cc: stable@vger.kernel.org +Fixes: 37416e554961 ("clk: qcom: gdsc: Handle GDSC regulator supplies") +Signed-off-by: Bjorn Andersson +Link: https://lore.kernel.org/r/20210721224056.3035016-1-bjorn.andersson@linaro.org +[sboyd@kernel.org: Rephrase commit text] +Signed-off-by: Stephen Boyd +Signed-off-by: Sasha Levin +--- + drivers/clk/qcom/gdsc.c | 54 +++++++++++++++++++++++++++-------------- + 1 file changed, 36 insertions(+), 18 deletions(-) + +diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c +index 51ed640e527b..4ece326ea233 100644 +--- a/drivers/clk/qcom/gdsc.c ++++ b/drivers/clk/qcom/gdsc.c +@@ -357,27 +357,43 @@ static int gdsc_init(struct gdsc *sc) + if (on < 0) + return on; + +- /* +- * Votable GDSCs can be ON due to Vote from other masters. +- * If a Votable GDSC is ON, make sure we have a Vote. +- */ +- if ((sc->flags & VOTABLE) && on) +- gdsc_enable(&sc->pd); ++ if (on) { ++ /* The regulator must be on, sync the kernel state */ ++ if (sc->rsupply) { ++ ret = regulator_enable(sc->rsupply); ++ if (ret < 0) ++ return ret; ++ } + +- /* +- * Make sure the retain bit is set if the GDSC is already on, otherwise +- * we end up turning off the GDSC and destroying all the register +- * contents that we thought we were saving. +- */ +- if ((sc->flags & RETAIN_FF_ENABLE) && on) +- gdsc_retain_ff_on(sc); ++ /* ++ * Votable GDSCs can be ON due to Vote from other masters. ++ * If a Votable GDSC is ON, make sure we have a Vote. ++ */ ++ if (sc->flags & VOTABLE) { ++ ret = regmap_update_bits(sc->regmap, sc->gdscr, ++ SW_COLLAPSE_MASK, val); ++ if (ret) ++ return ret; ++ } ++ ++ /* Turn on HW trigger mode if supported */ ++ if (sc->flags & HW_CTRL) { ++ ret = gdsc_hwctrl(sc, true); ++ if (ret < 0) ++ return ret; ++ } + +- /* If ALWAYS_ON GDSCs are not ON, turn them ON */ +- if (sc->flags & ALWAYS_ON) { +- if (!on) +- gdsc_enable(&sc->pd); ++ /* ++ * Make sure the retain bit is set if the GDSC is already on, ++ * otherwise we end up turning off the GDSC and destroying all ++ * the register contents that we thought we were saving. ++ */ ++ if (sc->flags & RETAIN_FF_ENABLE) ++ gdsc_retain_ff_on(sc); ++ } else if (sc->flags & ALWAYS_ON) { ++ /* If ALWAYS_ON GDSCs are not ON, turn them ON */ ++ gdsc_enable(&sc->pd); + on = true; +- sc->pd.flags |= GENPD_FLAG_ALWAYS_ON; + } + + if (on || (sc->pwrsts & PWRSTS_RET)) +@@ -385,6 +401,8 @@ static int gdsc_init(struct gdsc *sc) + else + gdsc_clear_mem_on(sc); + ++ if (sc->flags & ALWAYS_ON) ++ sc->pd.flags |= GENPD_FLAG_ALWAYS_ON; + if (!sc->pd.power_off) + sc->pd.power_off = gdsc_disable; + if (!sc->pd.power_on) +-- +2.30.2 + diff --git a/queue-5.10/fs-warn-about-impending-deprecation-of-mandatory-loc.patch b/queue-5.10/fs-warn-about-impending-deprecation-of-mandatory-loc.patch new file mode 100644 index 00000000000..0807b57b106 --- /dev/null +++ b/queue-5.10/fs-warn-about-impending-deprecation-of-mandatory-loc.patch @@ -0,0 +1,41 @@ +From ec017d848a30b82681ed35d4f1cf43ebe1f35342 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 20 Aug 2021 09:29:50 -0400 +Subject: fs: warn about impending deprecation of mandatory locks + +From: Jeff Layton + +[ 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 +Signed-off-by: Sasha Levin +--- + fs/namespace.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/fs/namespace.c b/fs/namespace.c +index 175312428cdf..046b084136c5 100644 +--- a/fs/namespace.c ++++ b/fs/namespace.c +@@ -1697,8 +1697,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 + diff --git a/queue-5.10/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch b/queue-5.10/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch new file mode 100644 index 00000000000..0613a2f833b --- /dev/null +++ b/queue-5.10/ipack-tpci200-fix-many-double-free-issues-in-tpci200.patch @@ -0,0 +1,140 @@ +From 0d1de514ffd34b6dd62a5381d8a81856031252a7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Aug 2021 18:03:18 +0800 +Subject: ipack: tpci200: fix many double free issues in tpci200_pci_probe + +From: Dongliang Mu + +[ 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 +Signed-off-by: Dongliang Mu +Link: https://lore.kernel.org/r/20210810100323.3938492-1-mudongliangabcd@gmail.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 e1822e87ec3d..33a1b17a2628 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( + 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 + diff --git a/queue-5.10/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch b/queue-5.10/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch new file mode 100644 index 00000000000..86b4842d1f2 --- /dev/null +++ b/queue-5.10/ipack-tpci200-fix-memory-leak-in-the-tpci200_registe.patch @@ -0,0 +1,107 @@ +From b5e3ca3ef6f46212dc5772ccc17e420cf2d0c53f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Aug 2021 18:03:19 +0800 +Subject: ipack: tpci200: fix memory leak in the tpci200_register + +From: Dongliang Mu + +[ 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 +Signed-off-by: Dongliang Mu +Link: https://lore.kernel.org/r/20210810100323.3938492-2-mudongliangabcd@gmail.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 33a1b17a2628..c1098f40e03f 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 + diff --git a/queue-5.10/mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch b/queue-5.10/mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch new file mode 100644 index 00000000000..d82b9d496c2 --- /dev/null +++ b/queue-5.10/mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch @@ -0,0 +1,164 @@ +From 2abfd7808ee7cc2b34b199735cceddb8f8185b50 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Aug 2021 19:04:21 -0700 +Subject: mm: memcontrol: fix occasional OOMs due to proportional memory.low + reclaim + +From: Johannes Weiner + +[ 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 +Reported-by: Leon Yang +Reviewed-by: Rik van Riel +Reviewed-by: Shakeel Butt +Acked-by: Roman Gushchin +Acked-by: Chris Down +Acked-by: Michal Hocko +Cc: [5.4+] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 c691b1ac95f8..4b975111b536 100644 +--- a/include/linux/memcontrol.h ++++ b/include/linux/memcontrol.h +@@ -360,12 +360,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. +@@ -401,13 +404,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); + } + + void mem_cgroup_calculate_protection(struct mem_cgroup *root, +@@ -966,11 +966,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 void mem_cgroup_calculate_protection(struct mem_cgroup *root, +diff --git a/mm/vmscan.c b/mm/vmscan.c +index 67d38334052e..7fb9af001ed5 100644 +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -102,9 +102,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; +@@ -2323,15 +2326,14 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, + 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 +@@ -2362,6 +2364,15 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, + * 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 + diff --git a/queue-5.10/mmc-dw_mmc-fix-hang-on-data-crc-error.patch b/queue-5.10/mmc-dw_mmc-fix-hang-on-data-crc-error.patch new file mode 100644 index 00000000000..5d2a3631112 --- /dev/null +++ b/queue-5.10/mmc-dw_mmc-fix-hang-on-data-crc-error.patch @@ -0,0 +1,73 @@ +From f8d25253b4a971acf9ec6bb6f2fceb3bda0dbe3a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 30 Jun 2021 12:22:32 +0200 +Subject: mmc: dw_mmc: Fix hang on data CRC error + +From: Vincent Whitchurch + +[ 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 +Reviewed-by: Jaehoon Chung +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210630102232.16011-1-vincent.whitchurch@axis.com +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + 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 43c5795691fb..8b5d542e20f3 100644 +--- a/drivers/mmc/host/dw_mmc.c ++++ b/drivers/mmc/host/dw_mmc.c +@@ -2018,8 +2018,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; + } +@@ -2043,10 +2043,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; + } +@@ -2079,10 +2079,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 + diff --git a/queue-5.10/mmc-mmci-stm32-check-when-the-voltage-switch-procedu.patch b/queue-5.10/mmc-mmci-stm32-check-when-the-voltage-switch-procedu.patch new file mode 100644 index 00000000000..957f824179b --- /dev/null +++ b/queue-5.10/mmc-mmci-stm32-check-when-the-voltage-switch-procedu.patch @@ -0,0 +1,57 @@ +From fc3e7207cb935df48413d3dc16eb067e4656a009 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 1 Jul 2021 16:33:53 +0200 +Subject: mmc: mmci: stm32: Check when the voltage switch procedure should be + done + +From: Christophe Kerello + +[ Upstream commit d8e193f13b07e6c0ffaa1a999386f1989f2b4c5e ] + +If the card has not been power cycled, it may still be using 1.8V +signaling. This situation is detected in mmc_sd_init_card function and +should be handled in mmci stm32 variant. The host->pwr_reg variable is +also correctly protected with spin locks. + +Fixes: 94b94a93e355 ("mmc: mmci_sdmmc: Implement signal voltage callbacks") +Signed-off-by: Christophe Kerello +Signed-off-by: Yann Gautier +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210701143353.13188-1-yann.gautier@foss.st.com +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/mmci_stm32_sdmmc.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c +index 51db30acf4dc..fdaa11f92fe6 100644 +--- a/drivers/mmc/host/mmci_stm32_sdmmc.c ++++ b/drivers/mmc/host/mmci_stm32_sdmmc.c +@@ -479,8 +479,9 @@ static int sdmmc_post_sig_volt_switch(struct mmci_host *host, + u32 status; + int ret = 0; + +- if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180) { +- spin_lock_irqsave(&host->lock, flags); ++ spin_lock_irqsave(&host->lock, flags); ++ if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180 && ++ host->pwr_reg & MCI_STM32_VSWITCHEN) { + mmci_write_pwrreg(host, host->pwr_reg | MCI_STM32_VSWITCH); + spin_unlock_irqrestore(&host->lock, flags); + +@@ -492,9 +493,11 @@ static int sdmmc_post_sig_volt_switch(struct mmci_host *host, + + writel_relaxed(MCI_STM32_VSWENDC | MCI_STM32_CKSTOPC, + host->base + MMCICLEAR); ++ spin_lock_irqsave(&host->lock, flags); + mmci_write_pwrreg(host, host->pwr_reg & + ~(MCI_STM32_VSWITCHEN | MCI_STM32_VSWITCH)); + } ++ spin_unlock_irqrestore(&host->lock, flags); + + return ret; + } +-- +2.30.2 + diff --git a/queue-5.10/mmc-sdhci-iproc-cap-min-clock-frequency-on-bcm2711.patch b/queue-5.10/mmc-sdhci-iproc-cap-min-clock-frequency-on-bcm2711.patch new file mode 100644 index 00000000000..3d8776c1b63 --- /dev/null +++ b/queue-5.10/mmc-sdhci-iproc-cap-min-clock-frequency-on-bcm2711.patch @@ -0,0 +1,73 @@ +From 5ebe7e4ef9fef9fede2745bdafe296f5a34c3ebb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Aug 2021 13:06:35 +0200 +Subject: mmc: sdhci-iproc: Cap min clock frequency on BCM2711 + +From: Nicolas Saenz Julienne + +[ Upstream commit c9107dd0b851777d7e134420baf13a5c5343bc16 ] + +There is a known bug on BCM2711's SDHCI core integration where the +controller will hang when the difference between the core clock and the +bus clock is too great. Specifically this can be reproduced under the +following conditions: + +- No SD card plugged in, polling thread is running, probing cards at + 100 kHz. +- BCM2711's core clock configured at 500MHz or more. + +So set 200 kHz as the minimum clock frequency available for that board. + +For more information on the issue see this: +https://lore.kernel.org/linux-mmc/20210322185816.27582-1-nsaenz@kernel.org/T/#m11f2783a09b581da6b8a15f302625b43a6ecdeca + +Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711") +Signed-off-by: Nicolas Saenz Julienne +Signed-off-by: Stefan Wahren +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/1628334401-6577-5-git-send-email-stefan.wahren@i2se.com +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/sdhci-iproc.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c +index ddeaf8e1f72f..b9eb2ec61a83 100644 +--- a/drivers/mmc/host/sdhci-iproc.c ++++ b/drivers/mmc/host/sdhci-iproc.c +@@ -173,6 +173,23 @@ static unsigned int sdhci_iproc_get_max_clock(struct sdhci_host *host) + return pltfm_host->clock; + } + ++/* ++ * There is a known bug on BCM2711's SDHCI core integration where the ++ * controller will hang when the difference between the core clock and the bus ++ * clock is too great. Specifically this can be reproduced under the following ++ * conditions: ++ * ++ * - No SD card plugged in, polling thread is running, probing cards at ++ * 100 kHz. ++ * - BCM2711's core clock configured at 500MHz or more ++ * ++ * So we set 200kHz as the minimum clock frequency available for that SoC. ++ */ ++static unsigned int sdhci_iproc_bcm2711_get_min_clock(struct sdhci_host *host) ++{ ++ return 200000; ++} ++ + static const struct sdhci_ops sdhci_iproc_ops = { + .set_clock = sdhci_set_clock, + .get_max_clock = sdhci_iproc_get_max_clock, +@@ -271,6 +288,7 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops = { + .set_clock = sdhci_set_clock, + .set_power = sdhci_set_power_and_bus_voltage, + .get_max_clock = sdhci_iproc_get_max_clock, ++ .get_min_clock = sdhci_iproc_bcm2711_get_min_clock, + .set_bus_width = sdhci_set_bus_width, + .reset = sdhci_reset, + .set_uhs_signaling = sdhci_set_uhs_signaling, +-- +2.30.2 + diff --git a/queue-5.10/mmc-sdhci-iproc-set-sdhci_quirk_cap_clock_base_broke.patch b/queue-5.10/mmc-sdhci-iproc-set-sdhci_quirk_cap_clock_base_broke.patch new file mode 100644 index 00000000000..9018334299f --- /dev/null +++ b/queue-5.10/mmc-sdhci-iproc-set-sdhci_quirk_cap_clock_base_broke.patch @@ -0,0 +1,41 @@ +From 5318e1a218811a5bf56616b6002541dcfdec2c04 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Aug 2021 13:06:36 +0200 +Subject: mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711 + +From: Nicolas Saenz Julienne + +[ Upstream commit 419dd626e357e89fc9c4e3863592c8b38cfe1571 ] + +The controller doesn't seem to pick-up on clock changes, so set the +SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN flag to query the clock frequency +directly from the clock. + +Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711") +Signed-off-by: Nicolas Saenz Julienne +Signed-off-by: Stefan Wahren +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/1628334401-6577-6-git-send-email-stefan.wahren@i2se.com +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/sdhci-iproc.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c +index b9eb2ec61a83..9f0eef97ebdd 100644 +--- a/drivers/mmc/host/sdhci-iproc.c ++++ b/drivers/mmc/host/sdhci-iproc.c +@@ -295,7 +295,8 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops = { + }; + + static const struct sdhci_pltfm_data sdhci_bcm2711_pltfm_data = { +- .quirks = SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12, ++ .quirks = SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 | ++ SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN, + .ops = &sdhci_iproc_bcm2711_ops, + }; + +-- +2.30.2 + diff --git a/queue-5.10/mmc-sdhci-msm-update-the-software-timeout-value-for-.patch b/queue-5.10/mmc-sdhci-msm-update-the-software-timeout-value-for-.patch new file mode 100644 index 00000000000..c4465c86438 --- /dev/null +++ b/queue-5.10/mmc-sdhci-msm-update-the-software-timeout-value-for-.patch @@ -0,0 +1,94 @@ +From 47d77798ec9414d5bf117edcc4a01e5e1592aa46 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 16 Jul 2021 17:16:14 +0530 +Subject: mmc: sdhci-msm: Update the software timeout value for sdhc + +From: Shaik Sajida Bhanu + +[ Upstream commit 67b13f3e221ed81b46a657e2b499bf8b20162476 ] + +Whenever SDHC run at clock rate 50MHZ or below, the hardware data +timeout value will be 21.47secs, which is approx. 22secs and we have +a current software timeout value as 10secs. We have to set software +timeout value more than the hardware data timeout value to avioid seeing +the below register dumps. + +[ 332.953670] mmc2: Timeout waiting for hardware interrupt. +[ 332.959608] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== +[ 332.966450] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00007202 +[ 332.973256] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001 +[ 332.980054] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000027 +[ 332.986864] mmc2: sdhci: Present: 0x01f801f6 | Host ctl: 0x0000001f +[ 332.993671] mmc2: sdhci: Power: 0x00000001 | Blk gap: 0x00000000 +[ 333.000583] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 +[ 333.007386] mmc2: sdhci: Timeout: 0x0000000e | Int stat: 0x00000000 +[ 333.014182] mmc2: sdhci: Int enab: 0x03ff100b | Sig enab: 0x03ff100b +[ 333.020976] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 +[ 333.027771] mmc2: sdhci: Caps: 0x322dc8b2 | Caps_1: 0x0000808f +[ 333.034561] mmc2: sdhci: Cmd: 0x0000183a | Max curr: 0x00000000 +[ 333.041359] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x00000000 +[ 333.048157] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 +[ 333.054945] mmc2: sdhci: Host ctl2: 0x00000000 +[ 333.059657] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: +0x0000000ffffff218 +[ 333.067178] mmc2: sdhci_msm: ----------- VENDOR REGISTER DUMP +----------- +[ 333.074343] mmc2: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: +0x6000642c | DLL cfg2: 0x0020a000 +[ 333.083417] mmc2: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: +0x00000000 | DDR cfg: 0x80040873 +[ 333.092850] mmc2: sdhci_msm: Vndr func: 0x00008a9c | Vndr func2 : +0xf88218a8 Vndr func3: 0x02626040 +[ 333.102371] mmc2: sdhci: ============================================ + +So, set software timeout value more than hardware timeout value. + +Signed-off-by: Shaik Sajida Bhanu +Acked-by: Adrian Hunter +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/1626435974-14462-1-git-send-email-sbhanu@codeaurora.org +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/sdhci-msm.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c +index 3451eb325513..588b9a564117 100644 +--- a/drivers/mmc/host/sdhci-msm.c ++++ b/drivers/mmc/host/sdhci-msm.c +@@ -1834,6 +1834,23 @@ static void sdhci_msm_cqe_disable(struct mmc_host *mmc, bool recovery) + sdhci_cqe_disable(mmc, recovery); + } + ++static void sdhci_msm_set_timeout(struct sdhci_host *host, struct mmc_command *cmd) ++{ ++ u32 count, start = 15; ++ ++ __sdhci_set_timeout(host, cmd); ++ count = sdhci_readb(host, SDHCI_TIMEOUT_CONTROL); ++ /* ++ * Update software timeout value if its value is less than hardware data ++ * timeout value. Qcom SoC hardware data timeout value was calculated ++ * using 4 * MCLK * 2^(count + 13). where MCLK = 1 / host->clock. ++ */ ++ if (cmd && cmd->data && host->clock > 400000 && ++ host->clock <= 50000000 && ++ ((1 << (count + start)) > (10 * host->clock))) ++ host->data_timeout = 22LL * NSEC_PER_SEC; ++} ++ + static const struct cqhci_host_ops sdhci_msm_cqhci_ops = { + .enable = sdhci_cqe_enable, + .disable = sdhci_msm_cqe_disable, +@@ -2184,6 +2201,7 @@ static const struct sdhci_ops sdhci_msm_ops = { + .irq = sdhci_msm_cqe_irq, + .dump_vendor_regs = sdhci_msm_dump_vendor_regs, + .set_power = sdhci_set_power_noreg, ++ .set_timeout = sdhci_msm_set_timeout, + }; + + static const struct sdhci_pltfm_data sdhci_msm_pdata = { +-- +2.30.2 + diff --git a/queue-5.10/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch b/queue-5.10/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch new file mode 100644 index 00000000000..e7e71b9a00c --- /dev/null +++ b/queue-5.10/pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch @@ -0,0 +1,45 @@ +From b27a2612f457a0fdb38bfe9b9bd8d43d7b8e0769 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 21 Jul 2021 22:58:58 -0400 +Subject: PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI + +From: Marcin Bachry + +[ 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 +Signed-off-by: Alex Deucher +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org +Cc: Mario Limonciello +Cc: Prike Liang +Cc: Shyam Sundar S K +Signed-off-by: Sasha Levin +--- + drivers/pci/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c +index bb1122e257dd..cd2401d4764f 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 + diff --git a/queue-5.10/s390-pci-fix-use-after-free-of-zpci_dev.patch b/queue-5.10/s390-pci-fix-use-after-free-of-zpci_dev.patch new file mode 100644 index 00000000000..a53edeb5f3b --- /dev/null +++ b/queue-5.10/s390-pci-fix-use-after-free-of-zpci_dev.patch @@ -0,0 +1,89 @@ +From 0828e50e72dd62ab4f5928f5e721a9d11aebf51f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Aug 2021 12:11:16 +0200 +Subject: s390/pci: fix use after free of zpci_dev + +From: Niklas Schnelle + +[ Upstream commit 2a671f77ee49f3e78997b77fdee139467ff6a598 ] + +The struct pci_dev uses reference counting but zPCI assumed erroneously +that the last reference would always be the local reference after +calling pci_stop_and_remove_bus_device(). This is usually the case but +not how reference counting works and thus inherently fragile. + +In fact one case where this causes a NULL pointer dereference when on an +SRIOV device the function 0 was hot unplugged before another function of +the same multi-function device. In this case the second function's +pdev->sriov->dev reference keeps the struct pci_dev of function 0 alive +even after the unplug. This bug was previously hidden by the fact that +we were leaking the struct pci_dev which in turn means that it always +outlived the struct zpci_dev. This was fixed in commit 0b13525c20fe +("s390/pci: fix leak of PCI device structure") exposing the broken +behavior. + +Fix this by accounting for the long living reference a struct pci_dev +has to its underlying struct zpci_dev via the zbus->function[] array and +only release that in pcibios_release_device() ensuring that the struct +pci_dev is not left with a dangling reference. This is a minimal fix in +the future it would probably better to use fine grained reference +counting for struct zpci_dev. + +Fixes: 05bc1be6db4b2 ("s390/pci: create zPCI bus") +Cc: stable@vger.kernel.org +Reviewed-by: Matthew Rosato +Signed-off-by: Niklas Schnelle +Signed-off-by: Vasily Gorbik +Signed-off-by: Sasha Levin +--- + arch/s390/pci/pci.c | 6 ++++++ + arch/s390/pci/pci_bus.h | 5 +++++ + 2 files changed, 11 insertions(+) + +diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c +index 1ae7a76ae97b..ca1a105e3b5d 100644 +--- a/arch/s390/pci/pci.c ++++ b/arch/s390/pci/pci.c +@@ -558,9 +558,12 @@ static void zpci_cleanup_bus_resources(struct zpci_dev *zdev) + + int pcibios_add_device(struct pci_dev *pdev) + { ++ struct zpci_dev *zdev = to_zpci(pdev); + struct resource *res; + int i; + ++ /* The pdev has a reference to the zdev via its bus */ ++ zpci_zdev_get(zdev); + if (pdev->is_physfn) + pdev->no_vf_scan = 1; + +@@ -580,7 +583,10 @@ int pcibios_add_device(struct pci_dev *pdev) + + void pcibios_release_device(struct pci_dev *pdev) + { ++ struct zpci_dev *zdev = to_zpci(pdev); ++ + zpci_unmap_resources(pdev); ++ zpci_zdev_put(zdev); + } + + int pcibios_enable_device(struct pci_dev *pdev, int mask) +diff --git a/arch/s390/pci/pci_bus.h b/arch/s390/pci/pci_bus.h +index f8dfac0b5b71..55c9488e504c 100644 +--- a/arch/s390/pci/pci_bus.h ++++ b/arch/s390/pci/pci_bus.h +@@ -16,6 +16,11 @@ static inline void zpci_zdev_put(struct zpci_dev *zdev) + kref_put(&zdev->kref, zpci_release_device); + } + ++static inline void zpci_zdev_get(struct zpci_dev *zdev) ++{ ++ kref_get(&zdev->kref); ++} ++ + int zpci_alloc_domain(int domain); + void zpci_free_domain(int domain); + int zpci_setup_bus_resources(struct zpci_dev *zdev, +-- +2.30.2 + diff --git a/queue-5.10/series b/queue-5.10/series index 2203c204a43..5653644865a 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -70,3 +70,26 @@ r8152-fix-writing-usb_bp2_en.patch i40e-fix-atr-queue-selection.patch iavf-fix-ping-is-lost-after-untrusted-vf-had-tried-t.patch revert-flow_offload-action-should-not-be-null-when-i.patch +mmc-dw_mmc-fix-hang-on-data-crc-error.patch +mmc-mmci-stm32-check-when-the-voltage-switch-procedu.patch +mmc-sdhci-msm-update-the-software-timeout-value-for-.patch +clk-imx6q-fix-uart-earlycon-unwork.patch +clk-qcom-gdsc-ensure-regulator-init-state-matches-gd.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 +alsa-hda-realtek-enable-4-speaker-output-for-dell-xp.patch +mmc-sdhci-iproc-cap-min-clock-frequency-on-bcm2711.patch +mmc-sdhci-iproc-set-sdhci_quirk_cap_clock_base_broke.patch +btrfs-prevent-rename2-from-exchanging-a-subvol-with-.patch +alsa-hda-via-apply-runtime-pm-workaround-for-asus-b2.patch +s390-pci-fix-use-after-free-of-zpci_dev.patch +pci-increase-d3-delay-for-amd-renoir-cezanne-xhci.patch +alsa-hda-realtek-limit-mic-boost-on-hp-probook-445-g.patch +asoc-intel-atom-fix-breakage-for-pcm-buffer-address-.patch +mm-memcontrol-fix-occasional-ooms-due-to-proportiona.patch +fs-warn-about-impending-deprecation-of-mandatory-loc.patch diff --git a/queue-5.10/slimbus-messaging-check-for-valid-transaction-id.patch b/queue-5.10/slimbus-messaging-check-for-valid-transaction-id.patch new file mode 100644 index 00000000000..cede5f2322a --- /dev/null +++ b/queue-5.10/slimbus-messaging-check-for-valid-transaction-id.patch @@ -0,0 +1,53 @@ +From 0486b72d66f094b598af1bab526a5d3e49ca3194 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Aug 2021 09:24:26 +0100 +Subject: slimbus: messaging: check for valid transaction id + +From: Srinivas Kandagatla + +[ 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: +Signed-off-by: Srinivas Kandagatla +Link: https://lore.kernel.org/r/20210809082428.11236-3-srinivas.kandagatla@linaro.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/slimbus-messaging-start-transaction-ids-from-1-inste.patch b/queue-5.10/slimbus-messaging-start-transaction-ids-from-1-inste.patch new file mode 100644 index 00000000000..0e8bc0f14d5 --- /dev/null +++ b/queue-5.10/slimbus-messaging-start-transaction-ids-from-1-inste.patch @@ -0,0 +1,42 @@ +From cc96a8c43e88c79756084c8c0f7ec91f850b57b7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Aug 2021 09:24:25 +0100 +Subject: slimbus: messaging: start transaction ids from 1 instead of zero + +From: Srinivas Kandagatla + +[ 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: +Signed-off-by: Srinivas Kandagatla +Link: https://lore.kernel.org/r/20210809082428.11236-2-srinivas.kandagatla@linaro.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch b/queue-5.10/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch new file mode 100644 index 00000000000..bad27ae9fed --- /dev/null +++ b/queue-5.10/slimbus-ngd-reset-dma-setup-during-runtime-pm.patch @@ -0,0 +1,59 @@ +From c443e6832a596855e8d350b6a4abe1f4fccdbe40 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Aug 2021 09:24:28 +0100 +Subject: slimbus: ngd: reset dma setup during runtime pm + +From: Srinivas Kandagatla + +[ 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: +Signed-off-by: Srinivas Kandagatla +Link: https://lore.kernel.org/r/20210809082428.11236-5-srinivas.kandagatla@linaro.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 50cfd67c2871..d0540376221c 100644 +--- a/drivers/slimbus/qcom-ngd-ctrl.c ++++ b/drivers/slimbus/qcom-ngd-ctrl.c +@@ -1065,7 +1065,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 */ +@@ -1116,6 +1117,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; + } + +@@ -1506,6 +1508,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 + diff --git a/queue-5.10/tracing-histogram-fix-null-pointer-dereference-on-st.patch b/queue-5.10/tracing-histogram-fix-null-pointer-dereference-on-st.patch new file mode 100644 index 00000000000..22c9a0922f4 --- /dev/null +++ b/queue-5.10/tracing-histogram-fix-null-pointer-dereference-on-st.patch @@ -0,0 +1,92 @@ +From 1551d85ed47f47c1dda6b951e2ef545a96e36803 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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) + +[ 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 +Cc: stable@vger.kernel.org +Fixes: 50450603ec9cb tracing: Add 'onmax' hist trigger action support +Reviewed-by: Tom Zanussi +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Sasha Levin +--- + 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 75529b311769..1b7f90e00eb0 100644 +--- a/kernel/trace/trace_events_hist.c ++++ b/kernel/trace/trace_events_hist.c +@@ -3405,6 +3405,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 +