--- /dev/null
+From 78a18fec5258c8df9435399a1ea022d73d3eceb9 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+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 <hdegoede@redhat.com>
+
+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 <pierre-louis.bossart@linux.intel.com>
+Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Diagnosed-by: Rafael J. Wysocki <rafael@kernel.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Cc: All applicable <stable@vger.kernel.org>
+[ rjw: Subject and changelog edits ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From 67ea698c3950d10925be33c21ca49ffb64e21842 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 14 Jan 2021 08:24:53 +0100
+Subject: ALSA: hda/via: Add minimum mute flag
+
+From: Takashi Iwai <tiwai@suse.de>
+
+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: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210114072453.11379-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 217bfbb8b0bfa24619b11ab75c135fec99b99b20 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+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 <tiwai@suse.de>
+
+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: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210115093428.15882-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 34d1eb0e599875064955a74712f08ff14c8e3d5f Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Wed, 16 Dec 2020 11:22:17 -0500
+Subject: btrfs: don't clear ret in btrfs_start_dirty_block_groups
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+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 <wqu@suse.com>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 18d3bff411c8d46d40537483bdc0b61b33ce0371 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Wed, 16 Dec 2020 11:22:05 -0500
+Subject: btrfs: don't get an EINTR during drop_snapshot for reloc
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+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 <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From fb286100974e7239af243bc2255a52f29442f9c8 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Wed, 16 Dec 2020 11:22:14 -0500
+Subject: btrfs: fix lockdep splat in btrfs_recover_relocation
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+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 <wqu@suse.com>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 518837e65068c385dddc0a87b3e577c8be7c13b1 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+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 <fdmanana@suse.com>
+
+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. <massimo.b@gmx.net>
+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 <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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]++;
--- /dev/null
+From 809b1e4945774c9ec5619a8f4e2189b7b3833c0c Mon Sep 17 00:00:00 2001
+From: Hannes Reinecke <hare@suse.de>
+Date: Thu, 21 Jan 2021 18:50:56 +0100
+Subject: dm: avoid filesystem lookup in dm_get_dev_t()
+
+From: Hannes Reinecke <hare@suse.de>
+
+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 <hare@suse.de>
+Signed-off-by: Martin Wilck <mwilck@suse.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From 2d06dfecb132a1cc2e374a44eae83b5c4356b8b4 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Wed, 20 Jan 2021 06:02:31 -0500
+Subject: dm integrity: fix a crash if "recalculate" used without "internal_hash"
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 2d06dfecb132a1cc2e374a44eae83b5c4356b8b4 upstream.
+
+Recalculate can only be specified with internal_hash.
+
+Cc: stable@vger.kernel.org # v4.19+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 43b67309b6b2a3c08396cc9b3f83f21aa529d273 Mon Sep 17 00:00:00 2001
+From: Pan Bian <bianpan2016@163.com>
+Date: Tue, 19 Jan 2021 04:11:27 -0800
+Subject: drm/atomic: put state on error path
+
+From: Pan Bian <bianpan2016@163.com>
+
+commit 43b67309b6b2a3c08396cc9b3f83f21aa529d273 upstream.
+
+Put the state before returning error code.
+
+Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.")
+Signed-off-by: Pan Bian <bianpan2016@163.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210119121127.84127-1-bianpan2016@163.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From 488751a0ef9b5ce572c47301ce62d54fc6b5a74d Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Mon, 18 Jan 2021 09:53:32 +0000
+Subject: drm/i915/gt: Prevent use of engine->wa_ctx after error
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+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 <matthew.d.roper@intel.com>
+Fixes: 604a8f6f1e33 ("drm/i915/lrc: Only enable per-context and per-bb buffers if set")
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Matt Roper <matthew.d.roper@intel.com>
+Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+Cc: <stable@vger.kernel.org> # v4.15+
+Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-1-chris@chris-wilson.co.uk
+(cherry-picked from 5b4dc95cf7f573e927fbbd406ebe54225d41b9b2)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210118095332.458813-1-chris@chris-wilson.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From a37eef63bc9e16e06361b539e528058146af80ab Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+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 <daniel.vetter@ffwll.ch>
+
+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 <daniel.vetter@intel.com>
+Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in drm_syncobj_find_fence v4")
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Cc: Christian König <christian.koenig@amd.com>
+Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
+Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Cc: Maxime Ripard <mripard@kernel.org>
+Cc: Thomas Zimmermann <tzimmermann@suse.de>
+Cc: David Airlie <airlied@linux.ie>
+Cc: Daniel Vetter <daniel@ffwll.ch>
+Cc: dri-devel@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v5.2+
+Link: https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vetter@ffwll.ch
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From bc1c2048abbe3c3074b4de91d213595c57741a6b Mon Sep 17 00:00:00 2001
+From: Mikko Perttunen <mperttunen@nvidia.com>
+Date: Tue, 12 Jan 2021 12:22:25 +0200
+Subject: i2c: bpmp-tegra: Ignore unknown I2C_M flags
+
+From: Mikko Perttunen <mperttunen@nvidia.com>
+
+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 <mperttunen@nvidia.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
+ /**
--- /dev/null
+From b503087445ce7e45fabdee87ca9e460d5b5b5168 Mon Sep 17 00:00:00 2001
+From: Peter Collingbourne <pcc@google.com>
+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 <pcc@google.com>
+
+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 <pcc@google.com>
+Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
+Link: https://linux-review.googlesource.com/id/If244d178da4d86b52034459438fec295b02d6e60
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210114201405.2934886-1-pcc@google.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ /*
--- /dev/null
+From 1a3ed0dc3594d99ff341ec63865a40519ea24b8d Mon Sep 17 00:00:00 2001
+From: Alex Leibovich <alexl@marvell.com>
+Date: Fri, 11 Dec 2020 15:16:56 +0100
+Subject: mmc: sdhci-xenon: fix 1.8v regulator stabilization
+
+From: Alex Leibovich <alexl@marvell.com>
+
+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 <alexl@marvell.com>
+Signed-off-by: Marcin Wojtas <mw@semihalf.com>
+Cc: stable@vger.kernel.org
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/20201211141656.24915-1-mw@semihalf.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From 9bba96275576da0cf78ede62aeb2fc975ed8a32d Mon Sep 17 00:00:00 2001
+From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+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 <heikki.krogerus@linux.intel.com>
+
+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 <moody@uniswap.org>
+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 <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20201223143644.33341-1-heikki.krogerus@linux.intel.com
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From f419e5940f1d9892ea6f45acdaca572b9e73ff39 Mon Sep 17 00:00:00 2001
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Date: Thu, 7 Jan 2021 22:44:38 +0800
+Subject: platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634
+
+From: Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+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 <jiaxun.yang@flygoat.com>
+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 <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
projects / thirdparty / kernel / stable-queue.git / commitdiff
