From 814025a5379306a180fa7eadd4fbb24227f28a0e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 24 Jan 2021 14:36:44 +0100 Subject: [PATCH] 5.4-stable patches added patches: acpi-scan-make-acpi_bus_get_device-clear-return-pointer-on-error.patch alsa-hda-via-add-minimum-mute-flag.patch alsa-seq-oss-fix-missing-error-check-in-snd_seq_oss_synth_make_info.patch btrfs-don-t-clear-ret-in-btrfs_start_dirty_block_groups.patch btrfs-don-t-get-an-eintr-during-drop_snapshot-for-reloc.patch btrfs-fix-lockdep-splat-in-btrfs_recover_relocation.patch btrfs-send-fix-invalid-clone-operations-when-cloning-from-the-same-file-and-root.patch dm-avoid-filesystem-lookup-in-dm_get_dev_t.patch dm-integrity-fix-a-crash-if-recalculate-used-without-internal_hash.patch drm-atomic-put-state-on-error-path.patch drm-i915-gt-prevent-use-of-engine-wa_ctx-after-error.patch drm-syncobj-fix-use-after-free.patch i2c-bpmp-tegra-ignore-unknown-i2c_m-flags.patch mmc-core-don-t-initialize-block-size-from-ext_csd-if-not-present.patch mmc-sdhci-xenon-fix-1.8v-regulator-stabilization.patch platform-x86-i2c-multi-instantiate-don-t-create-platform-device-for-int3515-acpi-nodes.patch platform-x86-ideapad-laptop-disable-touchpad_switch-for-elan0634.patch --- ...device-clear-return-pointer-on-error.patch | 48 ++++ .../alsa-hda-via-add-minimum-mute-flag.patch | 33 +++ ...check-in-snd_seq_oss_synth_make_info.patch | 38 +++ ...et-in-btrfs_start_dirty_block_groups.patch | 38 +++ ...eintr-during-drop_snapshot-for-reloc.patch | 45 ++++ ...ep-splat-in-btrfs_recover_relocation.patch | 155 ++++++++++++ ...-cloning-from-the-same-file-and-root.patch | 226 ++++++++++++++++++ ...id-filesystem-lookup-in-dm_get_dev_t.patch | 66 +++++ ...calculate-used-without-internal_hash.patch | 35 +++ .../drm-atomic-put-state-on-error-path.patch | 33 +++ ...ent-use-of-engine-wa_ctx-after-error.patch | 45 ++++ .../drm-syncobj-fix-use-after-free.patch | 72 ++++++ ...pmp-tegra-ignore-unknown-i2c_m-flags.patch | 34 +++ ...ock-size-from-ext_csd-if-not-present.patch | 46 ++++ ...non-fix-1.8v-regulator-stabilization.patch | 45 ++++ ...atform-device-for-int3515-acpi-nodes.patch | 83 +++++++ ...disable-touchpad_switch-for-elan0634.patch | 84 +++++++ 17 files changed, 1126 insertions(+) create mode 100644 queue-5.4/acpi-scan-make-acpi_bus_get_device-clear-return-pointer-on-error.patch create mode 100644 queue-5.4/alsa-hda-via-add-minimum-mute-flag.patch create mode 100644 queue-5.4/alsa-seq-oss-fix-missing-error-check-in-snd_seq_oss_synth_make_info.patch create mode 100644 queue-5.4/btrfs-don-t-clear-ret-in-btrfs_start_dirty_block_groups.patch create mode 100644 queue-5.4/btrfs-don-t-get-an-eintr-during-drop_snapshot-for-reloc.patch create mode 100644 queue-5.4/btrfs-fix-lockdep-splat-in-btrfs_recover_relocation.patch create mode 100644 queue-5.4/btrfs-send-fix-invalid-clone-operations-when-cloning-from-the-same-file-and-root.patch create mode 100644 queue-5.4/dm-avoid-filesystem-lookup-in-dm_get_dev_t.patch create mode 100644 queue-5.4/dm-integrity-fix-a-crash-if-recalculate-used-without-internal_hash.patch create mode 100644 queue-5.4/drm-atomic-put-state-on-error-path.patch create mode 100644 queue-5.4/drm-i915-gt-prevent-use-of-engine-wa_ctx-after-error.patch create mode 100644 queue-5.4/drm-syncobj-fix-use-after-free.patch create mode 100644 queue-5.4/i2c-bpmp-tegra-ignore-unknown-i2c_m-flags.patch create mode 100644 queue-5.4/mmc-core-don-t-initialize-block-size-from-ext_csd-if-not-present.patch create mode 100644 queue-5.4/mmc-sdhci-xenon-fix-1.8v-regulator-stabilization.patch create mode 100644 queue-5.4/platform-x86-i2c-multi-instantiate-don-t-create-platform-device-for-int3515-acpi-nodes.patch create mode 100644 queue-5.4/platform-x86-ideapad-laptop-disable-touchpad_switch-for-elan0634.patch diff --git a/queue-5.4/acpi-scan-make-acpi_bus_get_device-clear-return-pointer-on-error.patch b/queue-5.4/acpi-scan-make-acpi_bus_get_device-clear-return-pointer-on-error.patch new file mode 100644 index 00000000000..02050858421 --- /dev/null +++ b/queue-5.4/acpi-scan-make-acpi_bus_get_device-clear-return-pointer-on-error.patch @@ -0,0 +1,48 @@ +From 78a18fec5258c8df9435399a1ea022d73d3eceb9 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Fri, 15 Jan 2021 22:57:52 +0100 +Subject: ACPI: scan: Make acpi_bus_get_device() clear return pointer on error + +From: Hans de Goede + +commit 78a18fec5258c8df9435399a1ea022d73d3eceb9 upstream. + +Set the acpi_device pointer which acpi_bus_get_device() returns-by- +reference to NULL on errors. + +We've recently had 2 cases where callers of acpi_bus_get_device() +did not properly error check the return value, so set the returned- +by-reference acpi_device pointer to NULL, because at least some +callers of acpi_bus_get_device() expect that to be done on errors. + +[ rjw: This issue was exposed by commit 71da201f38df ("ACPI: scan: + Defer enumeration of devices with _DEP lists") which caused it to + be much more likely to occur on some systems, but the real defect + had been introduced by an earlier commit. ] + +Fixes: 40e7fcb19293 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA") +Fixes: bcfcd409d4db ("usb: split code locating ACPI companion into port and device") +Reported-by: Pierre-Louis Bossart +Tested-by: Pierre-Louis Bossart +Diagnosed-by: Rafael J. Wysocki +Signed-off-by: Hans de Goede +Cc: All applicable +[ rjw: Subject and changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/scan.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/acpi/scan.c ++++ b/drivers/acpi/scan.c +@@ -587,6 +587,8 @@ static int acpi_get_device_data(acpi_han + if (!device) + return -EINVAL; + ++ *device = NULL; ++ + status = acpi_get_data_full(handle, acpi_scan_drop_device, + (void **)device, callback); + if (ACPI_FAILURE(status) || !*device) { diff --git a/queue-5.4/alsa-hda-via-add-minimum-mute-flag.patch b/queue-5.4/alsa-hda-via-add-minimum-mute-flag.patch new file mode 100644 index 00000000000..a6e1bd9b58a --- /dev/null +++ b/queue-5.4/alsa-hda-via-add-minimum-mute-flag.patch @@ -0,0 +1,33 @@ +From 67ea698c3950d10925be33c21ca49ffb64e21842 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 14 Jan 2021 08:24:53 +0100 +Subject: ALSA: hda/via: Add minimum mute flag + +From: Takashi Iwai + +commit 67ea698c3950d10925be33c21ca49ffb64e21842 upstream. + +It turned out that VIA codecs also mute the sound in the lowest mixer +level. Turn on the dac_min_mute flag to indicate the mute-as-minimum +in TLV like already done in Conexant and IDT codecs. + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210559 +Cc: +Link: https://lore.kernel.org/r/20210114072453.11379-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_via.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_via.c ++++ b/sound/pci/hda/patch_via.c +@@ -113,6 +113,7 @@ static struct via_spec *via_new_spec(str + spec->codec_type = VT1708S; + spec->gen.indep_hp = 1; + spec->gen.keep_eapd_on = 1; ++ spec->gen.dac_min_mute = 1; + spec->gen.pcm_playback_hook = via_playback_pcm_hook; + spec->gen.add_stereo_mix_input = HDA_HINT_STEREO_MIX_AUTO; + codec->power_save_node = 1; diff --git a/queue-5.4/alsa-seq-oss-fix-missing-error-check-in-snd_seq_oss_synth_make_info.patch b/queue-5.4/alsa-seq-oss-fix-missing-error-check-in-snd_seq_oss_synth_make_info.patch new file mode 100644 index 00000000000..8ef1c2107cb --- /dev/null +++ b/queue-5.4/alsa-seq-oss-fix-missing-error-check-in-snd_seq_oss_synth_make_info.patch @@ -0,0 +1,38 @@ +From 217bfbb8b0bfa24619b11ab75c135fec99b99b20 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 15 Jan 2021 10:34:28 +0100 +Subject: ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info() + +From: Takashi Iwai + +commit 217bfbb8b0bfa24619b11ab75c135fec99b99b20 upstream. + +snd_seq_oss_synth_make_info() didn't check the error code from +snd_seq_oss_midi_make_info(), and this leads to the call of strlcpy() +with the uninitialized string as the source, which may lead to the +access over the limit. + +Add the proper error check for avoiding the failure. + +Reported-by: syzbot+e42504ff21cff05a595f@syzkaller.appspotmail.com +Cc: +Link: https://lore.kernel.org/r/20210115093428.15882-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/core/seq/oss/seq_oss_synth.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/sound/core/seq/oss/seq_oss_synth.c ++++ b/sound/core/seq/oss/seq_oss_synth.c +@@ -611,7 +611,8 @@ snd_seq_oss_synth_make_info(struct seq_o + + if (info->is_midi) { + struct midi_info minf; +- snd_seq_oss_midi_make_info(dp, info->midi_mapped, &minf); ++ if (snd_seq_oss_midi_make_info(dp, info->midi_mapped, &minf)) ++ return -ENXIO; + inf->synth_type = SYNTH_TYPE_MIDI; + inf->synth_subtype = 0; + inf->nr_voices = 16; diff --git a/queue-5.4/btrfs-don-t-clear-ret-in-btrfs_start_dirty_block_groups.patch b/queue-5.4/btrfs-don-t-clear-ret-in-btrfs_start_dirty_block_groups.patch new file mode 100644 index 00000000000..13a0a1760aa --- /dev/null +++ b/queue-5.4/btrfs-don-t-clear-ret-in-btrfs_start_dirty_block_groups.patch @@ -0,0 +1,38 @@ +From 34d1eb0e599875064955a74712f08ff14c8e3d5f Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 16 Dec 2020 11:22:17 -0500 +Subject: btrfs: don't clear ret in btrfs_start_dirty_block_groups + +From: Josef Bacik + +commit 34d1eb0e599875064955a74712f08ff14c8e3d5f upstream. + +If we fail to update a block group item in the loop we'll break, however +we'll do btrfs_run_delayed_refs and lose our error value in ret, and +thus not clean up properly. Fix this by only running the delayed refs +if there was no failure. + +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Qu Wenruo +Reviewed-by: Johannes Thumshirn +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/block-group.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/block-group.c ++++ b/fs/btrfs/block-group.c +@@ -2497,7 +2497,8 @@ again: + * Go through delayed refs for all the stuff we've just kicked off + * and then loop back (just once) + */ +- ret = btrfs_run_delayed_refs(trans, 0); ++ if (!ret) ++ ret = btrfs_run_delayed_refs(trans, 0); + if (!ret && loops == 0) { + loops++; + spin_lock(&cur_trans->dirty_bgs_lock); diff --git a/queue-5.4/btrfs-don-t-get-an-eintr-during-drop_snapshot-for-reloc.patch b/queue-5.4/btrfs-don-t-get-an-eintr-during-drop_snapshot-for-reloc.patch new file mode 100644 index 00000000000..0268e11db4b --- /dev/null +++ b/queue-5.4/btrfs-don-t-get-an-eintr-during-drop_snapshot-for-reloc.patch @@ -0,0 +1,45 @@ +From 18d3bff411c8d46d40537483bdc0b61b33ce0371 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 16 Dec 2020 11:22:05 -0500 +Subject: btrfs: don't get an EINTR during drop_snapshot for reloc + +From: Josef Bacik + +commit 18d3bff411c8d46d40537483bdc0b61b33ce0371 upstream. + +This was partially fixed by f3e3d9cc3525 ("btrfs: avoid possible signal +interruption of btrfs_drop_snapshot() on relocation tree"), however it +missed a spot when we restart a trans handle because we need to end the +transaction. The fix is the same, simply use btrfs_join_transaction() +instead of btrfs_start_transaction() when deleting reloc roots. + +Fixes: f3e3d9cc3525 ("btrfs: avoid possible signal interruption of btrfs_drop_snapshot() on relocation tree") +CC: stable@vger.kernel.org # 5.4+ +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/extent-tree.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/extent-tree.c ++++ b/fs/btrfs/extent-tree.c +@@ -5390,7 +5390,15 @@ int btrfs_drop_snapshot(struct btrfs_roo + goto out_free; + } + +- trans = btrfs_start_transaction(tree_root, 0); ++ /* ++ * Use join to avoid potential EINTR from transaction ++ * start. See wait_reserve_ticket and the whole ++ * reservation callchain. ++ */ ++ if (for_reloc) ++ trans = btrfs_join_transaction(tree_root); ++ else ++ trans = btrfs_start_transaction(tree_root, 0); + if (IS_ERR(trans)) { + err = PTR_ERR(trans); + goto out_free; diff --git a/queue-5.4/btrfs-fix-lockdep-splat-in-btrfs_recover_relocation.patch b/queue-5.4/btrfs-fix-lockdep-splat-in-btrfs_recover_relocation.patch new file mode 100644 index 00000000000..ebe132eeb73 --- /dev/null +++ b/queue-5.4/btrfs-fix-lockdep-splat-in-btrfs_recover_relocation.patch @@ -0,0 +1,155 @@ +From fb286100974e7239af243bc2255a52f29442f9c8 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 16 Dec 2020 11:22:14 -0500 +Subject: btrfs: fix lockdep splat in btrfs_recover_relocation + +From: Josef Bacik + +commit fb286100974e7239af243bc2255a52f29442f9c8 upstream. + +While testing the error paths of relocation I hit the following lockdep +splat: + + ====================================================== + WARNING: possible circular locking dependency detected + 5.10.0-rc6+ #217 Not tainted + ------------------------------------------------------ + mount/779 is trying to acquire lock: + ffffa0e676945418 (&fs_info->balance_mutex){+.+.}-{3:3}, at: btrfs_recover_balance+0x2f0/0x340 + + but task is already holding lock: + ffffa0e60ee31da8 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x100 + + which lock already depends on the new lock. + + the existing dependency chain (in reverse order) is: + + -> #2 (btrfs-root-00){++++}-{3:3}: + down_read_nested+0x43/0x130 + __btrfs_tree_read_lock+0x27/0x100 + btrfs_read_lock_root_node+0x31/0x40 + btrfs_search_slot+0x462/0x8f0 + btrfs_update_root+0x55/0x2b0 + btrfs_drop_snapshot+0x398/0x750 + clean_dirty_subvols+0xdf/0x120 + btrfs_recover_relocation+0x534/0x5a0 + btrfs_start_pre_rw_mount+0xcb/0x170 + open_ctree+0x151f/0x1726 + btrfs_mount_root.cold+0x12/0xea + legacy_get_tree+0x30/0x50 + vfs_get_tree+0x28/0xc0 + vfs_kern_mount.part.0+0x71/0xb0 + btrfs_mount+0x10d/0x380 + legacy_get_tree+0x30/0x50 + vfs_get_tree+0x28/0xc0 + path_mount+0x433/0xc10 + __x64_sys_mount+0xe3/0x120 + do_syscall_64+0x33/0x40 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + -> #1 (sb_internal#2){.+.+}-{0:0}: + start_transaction+0x444/0x700 + insert_balance_item.isra.0+0x37/0x320 + btrfs_balance+0x354/0xf40 + btrfs_ioctl_balance+0x2cf/0x380 + __x64_sys_ioctl+0x83/0xb0 + do_syscall_64+0x33/0x40 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + -> #0 (&fs_info->balance_mutex){+.+.}-{3:3}: + __lock_acquire+0x1120/0x1e10 + lock_acquire+0x116/0x370 + __mutex_lock+0x7e/0x7b0 + btrfs_recover_balance+0x2f0/0x340 + open_ctree+0x1095/0x1726 + btrfs_mount_root.cold+0x12/0xea + legacy_get_tree+0x30/0x50 + vfs_get_tree+0x28/0xc0 + vfs_kern_mount.part.0+0x71/0xb0 + btrfs_mount+0x10d/0x380 + legacy_get_tree+0x30/0x50 + vfs_get_tree+0x28/0xc0 + path_mount+0x433/0xc10 + __x64_sys_mount+0xe3/0x120 + do_syscall_64+0x33/0x40 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + other info that might help us debug this: + + Chain exists of: + &fs_info->balance_mutex --> sb_internal#2 --> btrfs-root-00 + + Possible unsafe locking scenario: + + CPU0 CPU1 + ---- ---- + lock(btrfs-root-00); + lock(sb_internal#2); + lock(btrfs-root-00); + lock(&fs_info->balance_mutex); + + *** DEADLOCK *** + + 2 locks held by mount/779: + #0: ffffa0e60dc040e0 (&type->s_umount_key#47/1){+.+.}-{3:3}, at: alloc_super+0xb5/0x380 + #1: ffffa0e60ee31da8 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x100 + + stack backtrace: + CPU: 0 PID: 779 Comm: mount Not tainted 5.10.0-rc6+ #217 + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 + Call Trace: + dump_stack+0x8b/0xb0 + check_noncircular+0xcf/0xf0 + ? trace_call_bpf+0x139/0x260 + __lock_acquire+0x1120/0x1e10 + lock_acquire+0x116/0x370 + ? btrfs_recover_balance+0x2f0/0x340 + __mutex_lock+0x7e/0x7b0 + ? btrfs_recover_balance+0x2f0/0x340 + ? btrfs_recover_balance+0x2f0/0x340 + ? rcu_read_lock_sched_held+0x3f/0x80 + ? kmem_cache_alloc_trace+0x2c4/0x2f0 + ? btrfs_get_64+0x5e/0x100 + btrfs_recover_balance+0x2f0/0x340 + open_ctree+0x1095/0x1726 + btrfs_mount_root.cold+0x12/0xea + ? rcu_read_lock_sched_held+0x3f/0x80 + legacy_get_tree+0x30/0x50 + vfs_get_tree+0x28/0xc0 + vfs_kern_mount.part.0+0x71/0xb0 + btrfs_mount+0x10d/0x380 + ? __kmalloc_track_caller+0x2f2/0x320 + legacy_get_tree+0x30/0x50 + vfs_get_tree+0x28/0xc0 + ? capable+0x3a/0x60 + path_mount+0x433/0xc10 + __x64_sys_mount+0xe3/0x120 + do_syscall_64+0x33/0x40 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +This is straightforward to fix, simply release the path before we setup +the balance_ctl. + +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Qu Wenruo +Reviewed-by: Johannes Thumshirn +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/volumes.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -4409,6 +4409,8 @@ int btrfs_recover_balance(struct btrfs_f + btrfs_warn(fs_info, + "balance: cannot set exclusive op status, resume manually"); + ++ btrfs_release_path(path); ++ + mutex_lock(&fs_info->balance_mutex); + BUG_ON(fs_info->balance_ctl); + spin_lock(&fs_info->balance_lock); diff --git a/queue-5.4/btrfs-send-fix-invalid-clone-operations-when-cloning-from-the-same-file-and-root.patch b/queue-5.4/btrfs-send-fix-invalid-clone-operations-when-cloning-from-the-same-file-and-root.patch new file mode 100644 index 00000000000..71bc06746a5 --- /dev/null +++ b/queue-5.4/btrfs-send-fix-invalid-clone-operations-when-cloning-from-the-same-file-and-root.patch @@ -0,0 +1,226 @@ +From 518837e65068c385dddc0a87b3e577c8be7c13b1 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Mon, 11 Jan 2021 11:41:42 +0000 +Subject: btrfs: send: fix invalid clone operations when cloning from the same file and root + +From: Filipe Manana + +commit 518837e65068c385dddc0a87b3e577c8be7c13b1 upstream. + +When an incremental send finds an extent that is shared, it checks which +file extent items in the range refer to that extent, and for those it +emits clone operations, while for others it emits regular write operations +to avoid corruption at the destination (as described and fixed by commit +d906d49fc5f4 ("Btrfs: send, fix file corruption due to incorrect cloning +operations")). + +However when the root we are cloning from is the send root, we are cloning +from the inode currently being processed and the source file range has +several extent items that partially point to the desired extent, with an +offset smaller than the offset in the file extent item for the range we +want to clone into, it can cause the algorithm to issue a clone operation +that starts at the current eof of the file being processed in the receiver +side, in which case the receiver will fail, with EINVAL, when attempting +to execute the clone operation. + +Example reproducer: + + $ cat test-send-clone.sh + #!/bin/bash + + DEV=/dev/sdi + MNT=/mnt/sdi + + mkfs.btrfs -f $DEV >/dev/null + mount $DEV $MNT + + # Create our test file with a single and large extent (1M) and with + # different content for different file ranges that will be reflinked + # later. + xfs_io -f \ + -c "pwrite -S 0xab 0 128K" \ + -c "pwrite -S 0xcd 128K 128K" \ + -c "pwrite -S 0xef 256K 256K" \ + -c "pwrite -S 0x1a 512K 512K" \ + $MNT/foobar + + btrfs subvolume snapshot -r $MNT $MNT/snap1 + btrfs send -f /tmp/snap1.send $MNT/snap1 + + # Now do a series of changes to our file such that we end up with + # different parts of the extent reflinked into different file offsets + # and we overwrite a large part of the extent too, so no file extent + # items refer to that part that was overwritten. This used to confuse + # the algorithm used by the kernel to figure out which file ranges to + # clone, making it attempt to clone from a source range starting at + # the current eof of the file, resulting in the receiver to fail since + # it is an invalid clone operation. + # + xfs_io -c "reflink $MNT/foobar 64K 1M 960K" \ + -c "reflink $MNT/foobar 0K 512K 256K" \ + -c "reflink $MNT/foobar 512K 128K 256K" \ + -c "pwrite -S 0x73 384K 640K" \ + $MNT/foobar + + btrfs subvolume snapshot -r $MNT $MNT/snap2 + btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2 + + echo -e "\nFile digest in the original filesystem:" + md5sum $MNT/snap2/foobar + + # Now unmount the filesystem, create a new one, mount it and try to + # apply both send streams to recreate both snapshots. + umount $DEV + + mkfs.btrfs -f $DEV >/dev/null + mount $DEV $MNT + + btrfs receive -f /tmp/snap1.send $MNT + btrfs receive -f /tmp/snap2.send $MNT + + # Must match what we got in the original filesystem of course. + echo -e "\nFile digest in the new filesystem:" + md5sum $MNT/snap2/foobar + + umount $MNT + +When running the reproducer, the incremental send operation fails due to +an invalid clone operation: + + $ ./test-send-clone.sh + wrote 131072/131072 bytes at offset 0 + 128 KiB, 32 ops; 0.0015 sec (80.906 MiB/sec and 20711.9741 ops/sec) + wrote 131072/131072 bytes at offset 131072 + 128 KiB, 32 ops; 0.0013 sec (90.514 MiB/sec and 23171.6148 ops/sec) + wrote 262144/262144 bytes at offset 262144 + 256 KiB, 64 ops; 0.0025 sec (98.270 MiB/sec and 25157.2327 ops/sec) + wrote 524288/524288 bytes at offset 524288 + 512 KiB, 128 ops; 0.0052 sec (95.730 MiB/sec and 24506.9883 ops/sec) + Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1' + At subvol /mnt/sdi/snap1 + linked 983040/983040 bytes at offset 1048576 + 960 KiB, 1 ops; 0.0006 sec (1.419 GiB/sec and 1550.3876 ops/sec) + linked 262144/262144 bytes at offset 524288 + 256 KiB, 1 ops; 0.0020 sec (120.192 MiB/sec and 480.7692 ops/sec) + linked 262144/262144 bytes at offset 131072 + 256 KiB, 1 ops; 0.0018 sec (133.833 MiB/sec and 535.3319 ops/sec) + wrote 655360/655360 bytes at offset 393216 + 640 KiB, 160 ops; 0.0093 sec (66.781 MiB/sec and 17095.8436 ops/sec) + Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2' + At subvol /mnt/sdi/snap2 + + File digest in the original filesystem: + 9c13c61cb0b9f5abf45344375cb04dfa /mnt/sdi/snap2/foobar + At subvol snap1 + At snapshot snap2 + ERROR: failed to clone extents to foobar: Invalid argument + + File digest in the new filesystem: + 132f0396da8f48d2e667196bff882cfc /mnt/sdi/snap2/foobar + +The clone operation is invalid because its source range starts at the +current eof of the file in the receiver, causing the receiver to get +an EINVAL error from the clone operation when attempting it. + +For the example above, what happens is the following: + +1) When processing the extent at file offset 1M, the algorithm checks that + the extent is shared and can be (fully or partially) found at file + offset 0. + + At this point the file has a size (and eof) of 1M at the receiver; + +2) It finds that our extent item at file offset 1M has a data offset of + 64K and, since the file extent item at file offset 0 has a data offset + of 0, it issues a clone operation, from the same file and root, that + has a source range offset of 64K, destination offset of 1M and a length + of 64K, since the extent item at file offset 0 refers only to the first + 128K of the shared extent. + + After this clone operation, the file size (and eof) at the receiver is + increased from 1M to 1088K (1M + 64K); + +3) Now there's still 896K (960K - 64K) of data left to clone or write, so + it checks for the next file extent item, which starts at file offset + 128K. This file extent item has a data offset of 0 and a length of + 256K, so a clone operation with a source range offset of 256K, a + destination offset of 1088K (1M + 64K) and length of 128K is issued. + + After this operation the file size (and eof) at the receiver increases + from 1088K to 1216K (1088K + 128K); + +4) Now there's still 768K (896K - 128K) of data left to clone or write, so + it checks for the next file extent item, located at file offset 384K. + This file extent item points to a different extent, not the one we want + to clone, with a length of 640K. So we issue a write operation into the + file range 1216K (1088K + 128K, end of the last clone operation), with + a length of 640K and with a data matching the one we can find for that + range in send root. + + After this operation, the file size (and eof) at the receiver increases + from 1216K to 1856K (1216K + 640K); + +5) Now there's still 128K (768K - 640K) of data left to clone or write, so + we look into the file extent item, which is for file offset 1M and it + points to the extent we want to clone, with a data offset of 64K and a + length of 960K. + + However this matches the file offset we started with, the start of the + range to clone into. So we can't for sure find any file extent item + from here onwards with the rest of the data we want to clone, yet we + proceed and since the file extent item points to the shared extent, + with a data offset of 64K, we issue a clone operation with a source + range starting at file offset 1856K, which matches the file extent + item's offset, 1M, plus the amount of data cloned and written so far, + which is 64K (step 2) + 128K (step 3) + 640K (step 4). This clone + operation is invalid since the source range offset matches the current + eof of the file in the receiver. We should have stopped looking for + extents to clone at this point and instead fallback to write, which + would simply the contain the data in the file range from 1856K to + 1856K + 128K. + +So fix this by stopping the loop that looks for file ranges to clone at +clone_range() when we reach the current eof of the file being processed, +if we are cloning from the same file and using the send root as the clone +root. This ensures any data not yet cloned will be sent to the receiver +through a write operation. + +A test case for fstests will follow soon. + +Reported-by: Massimo B. +Link: https://lore.kernel.org/linux-btrfs/6ae34776e85912960a253a8327068a892998e685.camel@gmx.net/ +Fixes: 11f2069c113e ("Btrfs: send, allow clone operations within the same file") +CC: stable@vger.kernel.org # 5.5+ +Reviewed-by: Josef Bacik +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/send.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/fs/btrfs/send.c ++++ b/fs/btrfs/send.c +@@ -5519,6 +5519,21 @@ static int clone_range(struct send_ctx * + break; + offset += clone_len; + clone_root->offset += clone_len; ++ ++ /* ++ * If we are cloning from the file we are currently processing, ++ * and using the send root as the clone root, we must stop once ++ * the current clone offset reaches the current eof of the file ++ * at the receiver, otherwise we would issue an invalid clone ++ * operation (source range going beyond eof) and cause the ++ * receiver to fail. So if we reach the current eof, bail out ++ * and fallback to a regular write. ++ */ ++ if (clone_root->root == sctx->send_root && ++ clone_root->ino == sctx->cur_ino && ++ clone_root->offset >= sctx->cur_inode_next_write_offset) ++ break; ++ + data_offset += clone_len; + next: + path->slots[0]++; diff --git a/queue-5.4/dm-avoid-filesystem-lookup-in-dm_get_dev_t.patch b/queue-5.4/dm-avoid-filesystem-lookup-in-dm_get_dev_t.patch new file mode 100644 index 00000000000..e6dd74d59cb --- /dev/null +++ b/queue-5.4/dm-avoid-filesystem-lookup-in-dm_get_dev_t.patch @@ -0,0 +1,66 @@ +From 809b1e4945774c9ec5619a8f4e2189b7b3833c0c Mon Sep 17 00:00:00 2001 +From: Hannes Reinecke +Date: Thu, 21 Jan 2021 18:50:56 +0100 +Subject: dm: avoid filesystem lookup in dm_get_dev_t() + +From: Hannes Reinecke + +commit 809b1e4945774c9ec5619a8f4e2189b7b3833c0c upstream. + +This reverts commit +644bda6f3460 ("dm table: fall back to getting device using name_to_dev_t()") + +dm_get_dev_t() is just used to convert an arbitrary 'path' string +into a dev_t. It doesn't presume that the device is present; that +check will be done later, as the only caller is dm_get_device(), +which does a dm_get_table_device() later on, which will properly +open the device. + +So if the path string already _is_ in major:minor representation +we can convert it directly, avoiding a recursion into the filesystem +to lookup the block device. + +This avoids a hang in multipath_message() when the filesystem is +inaccessible. + +Fixes: 644bda6f3460 ("dm table: fall back to getting device using name_to_dev_t()") +Cc: stable@vger.kernel.org +Signed-off-by: Hannes Reinecke +Signed-off-by: Martin Wilck +Reviewed-by: Christoph Hellwig +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/dm-table.c | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +--- a/drivers/md/dm-table.c ++++ b/drivers/md/dm-table.c +@@ -428,14 +428,23 @@ int dm_get_device(struct dm_target *ti, + { + int r; + dev_t dev; ++ unsigned int major, minor; ++ char dummy; + struct dm_dev_internal *dd; + struct dm_table *t = ti->table; + + BUG_ON(!t); + +- dev = dm_get_dev_t(path); +- if (!dev) +- return -ENODEV; ++ if (sscanf(path, "%u:%u%c", &major, &minor, &dummy) == 2) { ++ /* Extract the major/minor numbers */ ++ dev = MKDEV(major, minor); ++ if (MAJOR(dev) != major || MINOR(dev) != minor) ++ return -EOVERFLOW; ++ } else { ++ dev = dm_get_dev_t(path); ++ if (!dev) ++ return -ENODEV; ++ } + + dd = find_device(&t->devices, dev); + if (!dd) { diff --git a/queue-5.4/dm-integrity-fix-a-crash-if-recalculate-used-without-internal_hash.patch b/queue-5.4/dm-integrity-fix-a-crash-if-recalculate-used-without-internal_hash.patch new file mode 100644 index 00000000000..94643a485cb --- /dev/null +++ b/queue-5.4/dm-integrity-fix-a-crash-if-recalculate-used-without-internal_hash.patch @@ -0,0 +1,35 @@ +From 2d06dfecb132a1cc2e374a44eae83b5c4356b8b4 Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Wed, 20 Jan 2021 06:02:31 -0500 +Subject: dm integrity: fix a crash if "recalculate" used without "internal_hash" + +From: Mikulas Patocka + +commit 2d06dfecb132a1cc2e374a44eae83b5c4356b8b4 upstream. + +Recalculate can only be specified with internal_hash. + +Cc: stable@vger.kernel.org # v4.19+ +Signed-off-by: Mikulas Patocka +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/dm-integrity.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/md/dm-integrity.c ++++ b/drivers/md/dm-integrity.c +@@ -4059,6 +4059,12 @@ try_smaller_buffer: + r = -ENOMEM; + goto bad; + } ++ } else { ++ if (ic->sb->flags & cpu_to_le32(SB_FLAG_RECALCULATING)) { ++ ti->error = "Recalculate can only be specified with internal_hash"; ++ r = -EINVAL; ++ goto bad; ++ } + } + + ic->bufio = dm_bufio_client_create(ic->meta_dev ? ic->meta_dev->bdev : ic->dev->bdev, diff --git a/queue-5.4/drm-atomic-put-state-on-error-path.patch b/queue-5.4/drm-atomic-put-state-on-error-path.patch new file mode 100644 index 00000000000..b93f7a8d859 --- /dev/null +++ b/queue-5.4/drm-atomic-put-state-on-error-path.patch @@ -0,0 +1,33 @@ +From 43b67309b6b2a3c08396cc9b3f83f21aa529d273 Mon Sep 17 00:00:00 2001 +From: Pan Bian +Date: Tue, 19 Jan 2021 04:11:27 -0800 +Subject: drm/atomic: put state on error path + +From: Pan Bian + +commit 43b67309b6b2a3c08396cc9b3f83f21aa529d273 upstream. + +Put the state before returning error code. + +Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.") +Signed-off-by: Pan Bian +Cc: stable@vger.kernel.org +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20210119121127.84127-1-bianpan2016@163.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_atomic_helper.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/drm_atomic_helper.c ++++ b/drivers/gpu/drm/drm_atomic_helper.c +@@ -2948,7 +2948,7 @@ int drm_atomic_helper_set_config(struct + + ret = handle_conflicting_encoders(state, true); + if (ret) +- return ret; ++ goto fail; + + ret = drm_atomic_commit(state); + diff --git a/queue-5.4/drm-i915-gt-prevent-use-of-engine-wa_ctx-after-error.patch b/queue-5.4/drm-i915-gt-prevent-use-of-engine-wa_ctx-after-error.patch new file mode 100644 index 00000000000..0fe86069a77 --- /dev/null +++ b/queue-5.4/drm-i915-gt-prevent-use-of-engine-wa_ctx-after-error.patch @@ -0,0 +1,45 @@ +From 488751a0ef9b5ce572c47301ce62d54fc6b5a74d Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Mon, 18 Jan 2021 09:53:32 +0000 +Subject: drm/i915/gt: Prevent use of engine->wa_ctx after error + +From: Chris Wilson + +commit 488751a0ef9b5ce572c47301ce62d54fc6b5a74d upstream. + +On error we unpin and free the wa_ctx.vma, but do not clear any of the +derived flags. During lrc_init, we look at the flags and attempt to +dereference the wa_ctx.vma if they are set. To protect the error path +where we try to limp along without the wa_ctx, make sure we clear those +flags! + +Reported-by: Matt Roper +Fixes: 604a8f6f1e33 ("drm/i915/lrc: Only enable per-context and per-bb buffers if set") +Signed-off-by: Chris Wilson +Cc: Matt Roper +Cc: Tvrtko Ursulin +Cc: Mika Kuoppala +Cc: # v4.15+ +Reviewed-by: Matt Roper +Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-1-chris@chris-wilson.co.uk +(cherry-picked from 5b4dc95cf7f573e927fbbd406ebe54225d41b9b2) +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/20210118095332.458813-1-chris@chris-wilson.co.uk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/i915/gt/intel_lrc.c ++++ b/drivers/gpu/drm/i915/gt/intel_lrc.c +@@ -2245,6 +2245,9 @@ err: + static void lrc_destroy_wa_ctx(struct intel_engine_cs *engine) + { + i915_vma_unpin_and_release(&engine->wa_ctx.vma, 0); ++ ++ /* Called on error unwind, clear all flags to prevent further use */ ++ memset(&engine->wa_ctx, 0, sizeof(engine->wa_ctx)); + } + + typedef u32 *(*wa_bb_func_t)(struct intel_engine_cs *engine, u32 *batch); diff --git a/queue-5.4/drm-syncobj-fix-use-after-free.patch b/queue-5.4/drm-syncobj-fix-use-after-free.patch new file mode 100644 index 00000000000..2e09f05d2b8 --- /dev/null +++ b/queue-5.4/drm-syncobj-fix-use-after-free.patch @@ -0,0 +1,72 @@ +From a37eef63bc9e16e06361b539e528058146af80ab Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Tue, 19 Jan 2021 14:03:18 +0100 +Subject: drm/syncobj: Fix use-after-free +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Daniel Vetter + +commit a37eef63bc9e16e06361b539e528058146af80ab upstream. + +While reviewing Christian's annotation patch I noticed that we have a +user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj +reference before we've completed the waiting. + +Of course usually there's nothing bad happening here since userspace +keeps the reference, but we can't rely on userspace to play nice here! + +Signed-off-by: Daniel Vetter +Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in drm_syncobj_find_fence v4") +Reviewed-by: Christian König +Cc: Christian König +Cc: Lionel Landwerlin +Cc: Maarten Lankhorst +Cc: Maxime Ripard +Cc: Thomas Zimmermann +Cc: David Airlie +Cc: Daniel Vetter +Cc: dri-devel@lists.freedesktop.org +Cc: # v5.2+ +Link: https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vetter@ffwll.ch +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_syncobj.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/drm_syncobj.c ++++ b/drivers/gpu/drm/drm_syncobj.c +@@ -326,19 +326,18 @@ int drm_syncobj_find_fence(struct drm_fi + return -ENOENT; + + *fence = drm_syncobj_fence_get(syncobj); +- drm_syncobj_put(syncobj); + + if (*fence) { + ret = dma_fence_chain_find_seqno(fence, point); + if (!ret) +- return 0; ++ goto out; + dma_fence_put(*fence); + } else { + ret = -EINVAL; + } + + if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)) +- return ret; ++ goto out; + + memset(&wait, 0, sizeof(wait)); + wait.task = current; +@@ -370,6 +369,9 @@ int drm_syncobj_find_fence(struct drm_fi + if (wait.node.next) + drm_syncobj_remove_wait(syncobj, &wait); + ++out: ++ drm_syncobj_put(syncobj); ++ + return ret; + } + EXPORT_SYMBOL(drm_syncobj_find_fence); diff --git a/queue-5.4/i2c-bpmp-tegra-ignore-unknown-i2c_m-flags.patch b/queue-5.4/i2c-bpmp-tegra-ignore-unknown-i2c_m-flags.patch new file mode 100644 index 00000000000..9802918cd5a --- /dev/null +++ b/queue-5.4/i2c-bpmp-tegra-ignore-unknown-i2c_m-flags.patch @@ -0,0 +1,34 @@ +From bc1c2048abbe3c3074b4de91d213595c57741a6b Mon Sep 17 00:00:00 2001 +From: Mikko Perttunen +Date: Tue, 12 Jan 2021 12:22:25 +0200 +Subject: i2c: bpmp-tegra: Ignore unknown I2C_M flags + +From: Mikko Perttunen + +commit bc1c2048abbe3c3074b4de91d213595c57741a6b upstream. + +In order to not to start returning errors when new I2C_M flags are +added, change behavior to just ignore all flags that we don't know +about. This includes the I2C_M_DMA_SAFE flag that already exists but +causes -EINVAL to be returned for valid transactions. + +Cc: stable@vger.kernel.org # v4.19+ +Signed-off-by: Mikko Perttunen +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-tegra-bpmp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/i2c/busses/i2c-tegra-bpmp.c ++++ b/drivers/i2c/busses/i2c-tegra-bpmp.c +@@ -80,7 +80,7 @@ static int tegra_bpmp_xlate_flags(u16 fl + flags &= ~I2C_M_RECV_LEN; + } + +- return (flags != 0) ? -EINVAL : 0; ++ return 0; + } + + /** diff --git a/queue-5.4/mmc-core-don-t-initialize-block-size-from-ext_csd-if-not-present.patch b/queue-5.4/mmc-core-don-t-initialize-block-size-from-ext_csd-if-not-present.patch new file mode 100644 index 00000000000..a21eaefadc9 --- /dev/null +++ b/queue-5.4/mmc-core-don-t-initialize-block-size-from-ext_csd-if-not-present.patch @@ -0,0 +1,46 @@ +From b503087445ce7e45fabdee87ca9e460d5b5b5168 Mon Sep 17 00:00:00 2001 +From: Peter Collingbourne +Date: Thu, 14 Jan 2021 12:14:05 -0800 +Subject: mmc: core: don't initialize block size from ext_csd if not present + +From: Peter Collingbourne + +commit b503087445ce7e45fabdee87ca9e460d5b5b5168 upstream. + +If extended CSD was not available, the eMMC driver would incorrectly +set the block size to 0, as the data_sector_size field of ext_csd +was never initialized. This issue was exposed by commit 817046ecddbc +("block: Align max_hw_sectors to logical blocksize") which caused +max_sectors and max_hw_sectors to be set to 0 after setting the block +size to 0, resulting in a kernel panic in bio_split when attempting +to read from the device. Fix it by only reading the block size from +ext_csd if it is available. + +Fixes: a5075eb94837 ("mmc: block: Allow disabling 512B sector size emulation") +Signed-off-by: Peter Collingbourne +Reviewed-by: Damien Le Moal +Link: https://linux-review.googlesource.com/id/If244d178da4d86b52034459438fec295b02d6e60 +Acked-by: Adrian Hunter +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210114201405.2934886-1-pcc@google.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/queue.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/mmc/core/queue.c ++++ b/drivers/mmc/core/queue.c +@@ -370,8 +370,10 @@ static void mmc_setup_queue(struct mmc_q + "merging was advertised but not possible"); + blk_queue_max_segments(mq->queue, mmc_get_max_segments(host)); + +- if (mmc_card_mmc(card)) ++ if (mmc_card_mmc(card) && card->ext_csd.data_sector_size) { + block_size = card->ext_csd.data_sector_size; ++ WARN_ON(block_size != 512 && block_size != 4096); ++ } + + blk_queue_logical_block_size(mq->queue, block_size); + /* diff --git a/queue-5.4/mmc-sdhci-xenon-fix-1.8v-regulator-stabilization.patch b/queue-5.4/mmc-sdhci-xenon-fix-1.8v-regulator-stabilization.patch new file mode 100644 index 00000000000..175e693f6b4 --- /dev/null +++ b/queue-5.4/mmc-sdhci-xenon-fix-1.8v-regulator-stabilization.patch @@ -0,0 +1,45 @@ +From 1a3ed0dc3594d99ff341ec63865a40519ea24b8d Mon Sep 17 00:00:00 2001 +From: Alex Leibovich +Date: Fri, 11 Dec 2020 15:16:56 +0100 +Subject: mmc: sdhci-xenon: fix 1.8v regulator stabilization + +From: Alex Leibovich + +commit 1a3ed0dc3594d99ff341ec63865a40519ea24b8d upstream. + +Automatic Clock Gating is a feature used for the power consumption +optimisation. It turned out that during early init phase it may prevent the +stable voltage switch to 1.8V - due to that on some platforms an endless +printout in dmesg can be observed: "mmc1: 1.8V regulator output did not +became stable" Fix the problem by disabling the ACG at very beginning of +the sdhci_init and let that be enabled later. + +Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") +Signed-off-by: Alex Leibovich +Signed-off-by: Marcin Wojtas +Cc: stable@vger.kernel.org +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/20201211141656.24915-1-mw@semihalf.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-xenon.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/mmc/host/sdhci-xenon.c ++++ b/drivers/mmc/host/sdhci-xenon.c +@@ -167,7 +167,12 @@ static void xenon_reset_exit(struct sdhc + /* Disable tuning request and auto-retuning again */ + xenon_retune_setup(host); + +- xenon_set_acg(host, true); ++ /* ++ * The ACG should be turned off at the early init time, in order ++ * to solve a possible issues with the 1.8V regulator stabilization. ++ * The feature is enabled in later stage. ++ */ ++ xenon_set_acg(host, false); + + xenon_set_sdclk_off_idle(host, sdhc_id, false); + diff --git a/queue-5.4/platform-x86-i2c-multi-instantiate-don-t-create-platform-device-for-int3515-acpi-nodes.patch b/queue-5.4/platform-x86-i2c-multi-instantiate-don-t-create-platform-device-for-int3515-acpi-nodes.patch new file mode 100644 index 00000000000..1c16369f69a --- /dev/null +++ b/queue-5.4/platform-x86-i2c-multi-instantiate-don-t-create-platform-device-for-int3515-acpi-nodes.patch @@ -0,0 +1,83 @@ +From 9bba96275576da0cf78ede62aeb2fc975ed8a32d Mon Sep 17 00:00:00 2001 +From: Heikki Krogerus +Date: Wed, 23 Dec 2020 17:36:44 +0300 +Subject: platform/x86: i2c-multi-instantiate: Don't create platform device for INT3515 ACPI nodes + +From: Heikki Krogerus + +commit 9bba96275576da0cf78ede62aeb2fc975ed8a32d upstream. + +There are several reports about the tps6598x causing +interrupt flood on boards with the INT3515 ACPI node, which +then causes instability. There appears to be several +problems with the interrupt. One problem is that the +I2CSerialBus resources do not always map to the Interrupt +resource with the same index, but that is not the only +problem. We have not been able to come up with a solution +for all the issues, and because of that disabling the device +for now. + +The PD controller on these platforms is autonomous, and the +purpose for the driver is primarily to supply status to the +userspace, so this will not affect any functionality. + +Reported-by: Moody Salem +Fixes: a3dd034a1707 ("ACPI / scan: Create platform device for INT3515 ACPI nodes") +Cc: stable@vger.kernel.org +BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1883511 +Signed-off-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20201223143644.33341-1-heikki.krogerus@linux.intel.com +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/platform/x86/i2c-multi-instantiate.c | 31 ++++++++++++++++++++------- + 1 file changed, 23 insertions(+), 8 deletions(-) + +--- a/drivers/platform/x86/i2c-multi-instantiate.c ++++ b/drivers/platform/x86/i2c-multi-instantiate.c +@@ -166,13 +166,29 @@ static const struct i2c_inst_data bsg215 + {} + }; + +-static const struct i2c_inst_data int3515_data[] = { +- { "tps6598x", IRQ_RESOURCE_APIC, 0 }, +- { "tps6598x", IRQ_RESOURCE_APIC, 1 }, +- { "tps6598x", IRQ_RESOURCE_APIC, 2 }, +- { "tps6598x", IRQ_RESOURCE_APIC, 3 }, +- {} +-}; ++/* ++ * Device with _HID INT3515 (TI PD controllers) has some unresolved interrupt ++ * issues. The most common problem seen is interrupt flood. ++ * ++ * There are at least two known causes. Firstly, on some boards, the ++ * I2CSerialBus resource index does not match the Interrupt resource, i.e. they ++ * are not one-to-one mapped like in the array below. Secondly, on some boards ++ * the IRQ line from the PD controller is not actually connected at all. But the ++ * interrupt flood is also seen on some boards where those are not a problem, so ++ * there are some other problems as well. ++ * ++ * Because of the issues with the interrupt, the device is disabled for now. If ++ * you wish to debug the issues, uncomment the below, and add an entry for the ++ * INT3515 device to the i2c_multi_instance_ids table. ++ * ++ * static const struct i2c_inst_data int3515_data[] = { ++ * { "tps6598x", IRQ_RESOURCE_APIC, 0 }, ++ * { "tps6598x", IRQ_RESOURCE_APIC, 1 }, ++ * { "tps6598x", IRQ_RESOURCE_APIC, 2 }, ++ * { "tps6598x", IRQ_RESOURCE_APIC, 3 }, ++ * { } ++ * }; ++ */ + + /* + * Note new device-ids must also be added to i2c_multi_instantiate_ids in +@@ -181,7 +197,6 @@ static const struct i2c_inst_data int351 + static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = { + { "BSG1160", (unsigned long)bsg1160_data }, + { "BSG2150", (unsigned long)bsg2150_data }, +- { "INT3515", (unsigned long)int3515_data }, + { } + }; + MODULE_DEVICE_TABLE(acpi, i2c_multi_inst_acpi_ids); diff --git a/queue-5.4/platform-x86-ideapad-laptop-disable-touchpad_switch-for-elan0634.patch b/queue-5.4/platform-x86-ideapad-laptop-disable-touchpad_switch-for-elan0634.patch new file mode 100644 index 00000000000..0d59a47e457 --- /dev/null +++ b/queue-5.4/platform-x86-ideapad-laptop-disable-touchpad_switch-for-elan0634.patch @@ -0,0 +1,84 @@ +From f419e5940f1d9892ea6f45acdaca572b9e73ff39 Mon Sep 17 00:00:00 2001 +From: Jiaxun Yang +Date: Thu, 7 Jan 2021 22:44:38 +0800 +Subject: platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634 + +From: Jiaxun Yang + +commit f419e5940f1d9892ea6f45acdaca572b9e73ff39 upstream. + +Newer ideapads (e.g.: Yoga 14s, 720S 14) come with ELAN0634 touchpad do not +use EC to switch touchpad. + +Reading VPCCMD_R_TOUCHPAD will return zero thus touchpad may be blocked +unexpectedly. +Writing VPCCMD_W_TOUCHPAD may cause a spurious key press. + +Add has_touchpad_switch to workaround these machines. + +Signed-off-by: Jiaxun Yang +Cc: stable@vger.kernel.org # 5.4+ +-- +v2: Specify touchpad to ELAN0634 +v3: Stupid missing ! in v2 +v4: Correct acpi_dev_present usage (Hans) +Link: https://lore.kernel.org/r/20210107144438.12605-1-jiaxun.yang@flygoat.com +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/platform/x86/ideapad-laptop.c | 15 ++++++++++++++- + 1 file changed, 14 insertions(+), 1 deletion(-) + +--- a/drivers/platform/x86/ideapad-laptop.c ++++ b/drivers/platform/x86/ideapad-laptop.c +@@ -92,6 +92,7 @@ struct ideapad_private { + struct dentry *debug; + unsigned long cfg; + bool has_hw_rfkill_switch; ++ bool has_touchpad_switch; + const char *fnesc_guid; + }; + +@@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct + } else if (attr == &dev_attr_fn_lock.attr) { + supported = acpi_has_method(priv->adev->handle, "HALS") && + acpi_has_method(priv->adev->handle, "SALS"); +- } else ++ } else if (attr == &dev_attr_touchpad.attr) ++ supported = priv->has_touchpad_switch; ++ else + supported = true; + + return supported ? attr->mode : 0; +@@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state( + { + unsigned long value; + ++ if (!priv->has_touchpad_switch) ++ return; ++ + /* Without reading from EC touchpad LED doesn't switch state */ + if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &value)) { + /* Some IdeaPads don't really turn off touchpad - they only +@@ -989,6 +995,9 @@ static int ideapad_acpi_add(struct platf + priv->platform_device = pdev; + priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list); + ++ /* Most ideapads with ELAN0634 touchpad don't use EC touchpad switch */ ++ priv->has_touchpad_switch = !acpi_dev_present("ELAN0634", NULL, -1); ++ + ret = ideapad_sysfs_init(priv); + if (ret) + return ret; +@@ -1006,6 +1015,10 @@ static int ideapad_acpi_add(struct platf + if (!priv->has_hw_rfkill_switch) + write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1); + ++ /* The same for Touchpad */ ++ if (!priv->has_touchpad_switch) ++ write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1); ++ + for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++) + if (test_bit(ideapad_rfk_data[i].cfgbit, &priv->cfg)) + ideapad_register_rfkill(priv, i); -- 2.47.3