--- /dev/null
+From b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 17 Jul 2019 13:23:39 +0100
+Subject: Btrfs: fix incremental send failure after deduplication
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 upstream.
+
+When doing an incremental send operation we can fail if we previously did
+deduplication operations against a file that exists in both snapshots. In
+that case we will fail the send operation with -EIO and print a message
+to dmesg/syslog like the following:
+
+ BTRFS error (device sdc): Send: inconsistent snapshot, found updated \
+ extent for inode 257 without updated inode item, send root is 258, \
+ parent root is 257
+
+This requires that we deduplicate to the same file in both snapshots for
+the same amount of times on each snapshot. The issue happens because a
+deduplication only updates the iversion of an inode and does not update
+any other field of the inode, therefore if we deduplicate the file on
+each snapshot for the same amount of time, the inode will have the same
+iversion value (stored as the "sequence" field on the inode item) on both
+snapshots, therefore it will be seen as unchanged between in the send
+snapshot while there are new/updated/deleted extent items when comparing
+to the parent snapshot. This makes the send operation return -EIO and
+print an error message.
+
+Example reproducer:
+
+ $ mkfs.btrfs -f /dev/sdb
+ $ mount /dev/sdb /mnt
+
+ # Create our first file. The first half of the file has several 64Kb
+ # extents while the second half as a single 512Kb extent.
+ $ xfs_io -f -s -c "pwrite -S 0xb8 -b 64K 0 512K" /mnt/foo
+ $ xfs_io -c "pwrite -S 0xb8 512K 512K" /mnt/foo
+
+ # Create the base snapshot and the parent send stream from it.
+ $ btrfs subvolume snapshot -r /mnt /mnt/mysnap1
+ $ btrfs send -f /tmp/1.snap /mnt/mysnap1
+
+ # Create our second file, that has exactly the same data as the first
+ # file.
+ $ xfs_io -f -c "pwrite -S 0xb8 0 1M" /mnt/bar
+
+ # Create the second snapshot, used for the incremental send, before
+ # doing the file deduplication.
+ $ btrfs subvolume snapshot -r /mnt /mnt/mysnap2
+
+ # Now before creating the incremental send stream:
+ #
+ # 1) Deduplicate into a subrange of file foo in snapshot mysnap1. This
+ # will drop several extent items and add a new one, also updating
+ # the inode's iversion (sequence field in inode item) by 1, but not
+ # any other field of the inode;
+ #
+ # 2) Deduplicate into a different subrange of file foo in snapshot
+ # mysnap2. This will replace an extent item with a new one, also
+ # updating the inode's iversion by 1 but not any other field of the
+ # inode.
+ #
+ # After these two deduplication operations, the inode items, for file
+ # foo, are identical in both snapshots, but we have different extent
+ # items for this inode in both snapshots. We want to check this doesn't
+ # cause send to fail with an error or produce an incorrect stream.
+
+ $ xfs_io -r -c "dedupe /mnt/bar 0 0 512K" /mnt/mysnap1/foo
+ $ xfs_io -r -c "dedupe /mnt/bar 512K 512K 512K" /mnt/mysnap2/foo
+
+ # Create the incremental send stream.
+ $ btrfs send -p /mnt/mysnap1 -f /tmp/2.snap /mnt/mysnap2
+ ERROR: send ioctl failed with -5: Input/output error
+
+This issue started happening back in 2015 when deduplication was updated
+to not update the inode's ctime and mtime and update only the iversion.
+Back then we would hit a BUG_ON() in send, but later in 2016 send was
+updated to return -EIO and print the error message instead of doing the
+BUG_ON().
+
+A test case for fstests follows soon.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203933
+Fixes: 1c919a5e13702c ("btrfs: don't update mtime/ctime on deduped inodes")
+CC: stable@vger.kernel.org # 4.4+
+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 | 77 ++++++++++----------------------------------------------
+ 1 file changed, 15 insertions(+), 62 deletions(-)
+
+--- a/fs/btrfs/send.c
++++ b/fs/btrfs/send.c
+@@ -6322,68 +6322,21 @@ static int changed_extent(struct send_ct
+ {
+ int ret = 0;
+
+- if (sctx->cur_ino != sctx->cmp_key->objectid) {
+-
+- if (result == BTRFS_COMPARE_TREE_CHANGED) {
+- struct extent_buffer *leaf_l;
+- struct extent_buffer *leaf_r;
+- struct btrfs_file_extent_item *ei_l;
+- struct btrfs_file_extent_item *ei_r;
+-
+- leaf_l = sctx->left_path->nodes[0];
+- leaf_r = sctx->right_path->nodes[0];
+- ei_l = btrfs_item_ptr(leaf_l,
+- sctx->left_path->slots[0],
+- struct btrfs_file_extent_item);
+- ei_r = btrfs_item_ptr(leaf_r,
+- sctx->right_path->slots[0],
+- struct btrfs_file_extent_item);
+-
+- /*
+- * We may have found an extent item that has changed
+- * only its disk_bytenr field and the corresponding
+- * inode item was not updated. This case happens due to
+- * very specific timings during relocation when a leaf
+- * that contains file extent items is COWed while
+- * relocation is ongoing and its in the stage where it
+- * updates data pointers. So when this happens we can
+- * safely ignore it since we know it's the same extent,
+- * but just at different logical and physical locations
+- * (when an extent is fully replaced with a new one, we
+- * know the generation number must have changed too,
+- * since snapshot creation implies committing the current
+- * transaction, and the inode item must have been updated
+- * as well).
+- * This replacement of the disk_bytenr happens at
+- * relocation.c:replace_file_extents() through
+- * relocation.c:btrfs_reloc_cow_block().
+- */
+- if (btrfs_file_extent_generation(leaf_l, ei_l) ==
+- btrfs_file_extent_generation(leaf_r, ei_r) &&
+- btrfs_file_extent_ram_bytes(leaf_l, ei_l) ==
+- btrfs_file_extent_ram_bytes(leaf_r, ei_r) &&
+- btrfs_file_extent_compression(leaf_l, ei_l) ==
+- btrfs_file_extent_compression(leaf_r, ei_r) &&
+- btrfs_file_extent_encryption(leaf_l, ei_l) ==
+- btrfs_file_extent_encryption(leaf_r, ei_r) &&
+- btrfs_file_extent_other_encoding(leaf_l, ei_l) ==
+- btrfs_file_extent_other_encoding(leaf_r, ei_r) &&
+- btrfs_file_extent_type(leaf_l, ei_l) ==
+- btrfs_file_extent_type(leaf_r, ei_r) &&
+- btrfs_file_extent_disk_bytenr(leaf_l, ei_l) !=
+- btrfs_file_extent_disk_bytenr(leaf_r, ei_r) &&
+- btrfs_file_extent_disk_num_bytes(leaf_l, ei_l) ==
+- btrfs_file_extent_disk_num_bytes(leaf_r, ei_r) &&
+- btrfs_file_extent_offset(leaf_l, ei_l) ==
+- btrfs_file_extent_offset(leaf_r, ei_r) &&
+- btrfs_file_extent_num_bytes(leaf_l, ei_l) ==
+- btrfs_file_extent_num_bytes(leaf_r, ei_r))
+- return 0;
+- }
+-
+- inconsistent_snapshot_error(sctx, result, "extent");
+- return -EIO;
+- }
++ /*
++ * We have found an extent item that changed without the inode item
++ * having changed. This can happen either after relocation (where the
++ * disk_bytenr of an extent item is replaced at
++ * relocation.c:replace_file_extents()) or after deduplication into a
++ * file in both the parent and send snapshots (where an extent item can
++ * get modified or replaced with a new one). Note that deduplication
++ * updates the inode item, but it only changes the iversion (sequence
++ * field in the inode item) of the inode, so if a file is deduplicated
++ * the same amount of times in both the parent and send snapshots, its
++ * iversion becames the same in both snapshots, whence the inode item is
++ * the same on both snapshots.
++ */
++ if (sctx->cur_ino != sctx->cmp_key->objectid)
++ return 0;
+
+ if (!sctx->cur_inode_new_gen && !sctx->cur_inode_deleted) {
+ if (result != BTRFS_COMPARE_TREE_DELETED)
--- /dev/null
+From cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 25 Jul 2019 11:27:04 +0100
+Subject: Btrfs: fix race leading to fs corruption after transaction abort
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 upstream.
+
+When one transaction is finishing its commit, it is possible for another
+transaction to start and enter its initial commit phase as well. If the
+first ends up getting aborted, we have a small time window where the second
+transaction commit does not notice that the previous transaction aborted
+and ends up committing, writing a superblock that points to btrees that
+reference extent buffers (nodes and leafs) that were not persisted to disk.
+The consequence is that after mounting the filesystem again, we will be
+unable to load some btree nodes/leafs, either because the content on disk
+is either garbage (or just zeroes) or corresponds to the old content of a
+previouly COWed or deleted node/leaf, resulting in the well known error
+messages "parent transid verify failed on ...".
+The following sequence diagram illustrates how this can happen.
+
+ CPU 1 CPU 2
+
+ <at transaction N>
+
+ btrfs_commit_transaction()
+ (...)
+ --> sets transaction state to
+ TRANS_STATE_UNBLOCKED
+ --> sets fs_info->running_transaction
+ to NULL
+
+ (...)
+ btrfs_start_transaction()
+ start_transaction()
+ wait_current_trans()
+ --> returns immediately
+ because
+ fs_info->running_transaction
+ is NULL
+ join_transaction()
+ --> creates transaction N + 1
+ --> sets
+ fs_info->running_transaction
+ to transaction N + 1
+ --> adds transaction N + 1 to
+ the fs_info->trans_list list
+ --> returns transaction handle
+ pointing to the new
+ transaction N + 1
+ (...)
+
+ btrfs_sync_file()
+ btrfs_start_transaction()
+ --> returns handle to
+ transaction N + 1
+ (...)
+
+ btrfs_write_and_wait_transaction()
+ --> writeback of some extent
+ buffer fails, returns an
+ error
+ btrfs_handle_fs_error()
+ --> sets BTRFS_FS_STATE_ERROR in
+ fs_info->fs_state
+ --> jumps to label "scrub_continue"
+ cleanup_transaction()
+ btrfs_abort_transaction(N)
+ --> sets BTRFS_FS_STATE_TRANS_ABORTED
+ flag in fs_info->fs_state
+ --> sets aborted field in the
+ transaction and transaction
+ handle structures, for
+ transaction N only
+ --> removes transaction from the
+ list fs_info->trans_list
+ btrfs_commit_transaction(N + 1)
+ --> transaction N + 1 was not
+ aborted, so it proceeds
+ (...)
+ --> sets the transaction's state
+ to TRANS_STATE_COMMIT_START
+ --> does not find the previous
+ transaction (N) in the
+ fs_info->trans_list, so it
+ doesn't know that transaction
+ was aborted, and the commit
+ of transaction N + 1 proceeds
+ (...)
+ --> sets transaction N + 1 state
+ to TRANS_STATE_UNBLOCKED
+ btrfs_write_and_wait_transaction()
+ --> succeeds writing all extent
+ buffers created in the
+ transaction N + 1
+ write_all_supers()
+ --> succeeds
+ --> we now have a superblock on
+ disk that points to trees
+ that refer to at least one
+ extent buffer that was
+ never persisted
+
+So fix this by updating the transaction commit path to check if the flag
+BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting
+the transaction to the TRANS_STATE_COMMIT_START we do not find any previous
+transaction in the fs_info->trans_list. If the flag is set, just fail the
+transaction commit with -EROFS, as we do in other places. The exact error
+code for the previous transaction abort was already logged and reported.
+
+Fixes: 49b25e0540904b ("btrfs: enhance transaction abort infrastructure")
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.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/transaction.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/fs/btrfs/transaction.c
++++ b/fs/btrfs/transaction.c
+@@ -2019,6 +2019,16 @@ int btrfs_commit_transaction(struct btrf
+ }
+ } else {
+ spin_unlock(&fs_info->trans_lock);
++ /*
++ * The previous transaction was aborted and was already removed
++ * from the list of transactions at fs_info->trans_list. So we
++ * abort to prevent writing a new superblock that reflects a
++ * corrupt state (pointing to trees with unwritten nodes/leafs).
++ */
++ if (test_bit(BTRFS_FS_STATE_TRANS_ABORTED, &fs_info->fs_state)) {
++ ret = -EROFS;
++ goto cleanup_transaction;
++ }
+ }
+
+ extwriter_counter_dec(cur_trans, trans->type);
--- /dev/null
+From 61c30c98ef17e5a330d7bb8494b78b3d6dffe9b8 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 29 Jul 2019 13:57:49 +0200
+Subject: dax: Fix missed wakeup in put_unlocked_entry()
+
+From: Jan Kara <jack@suse.cz>
+
+commit 61c30c98ef17e5a330d7bb8494b78b3d6dffe9b8 upstream.
+
+The condition checking whether put_unlocked_entry() needs to wake up
+following waiter got broken by commit 23c84eb78375 ("dax: Fix missed
+wakeup with PMD faults"). We need to wake the waiter whenever the passed
+entry is valid (i.e., non-NULL and not special conflict entry). This
+could lead to processes never being woken up when waiting for entry
+lock. Fix the condition.
+
+Cc: <stable@vger.kernel.org>
+Link: http://lore.kernel.org/r/20190729120228.GC17833@quack2.suse.cz
+Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults")
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/dax.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/dax.c
++++ b/fs/dax.c
+@@ -267,7 +267,7 @@ static void wait_entry_unlocked(struct x
+ static void put_unlocked_entry(struct xa_state *xas, void *entry)
+ {
+ /* If we were the only waiter woken, wake the next one */
+- if (entry && dax_is_conflict(entry))
++ if (entry && !dax_is_conflict(entry))
+ dax_wake_entry(xas, entry, false);
+ }
+
--- /dev/null
+From 412e85b605315fd129a849599cf4a5a7959573a8 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Thu, 1 Aug 2019 18:02:15 -0400
+Subject: drm/nouveau: Only release VCPI slots on mode changes
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 412e85b605315fd129a849599cf4a5a7959573a8 upstream.
+
+Looks like a regression got introduced into nv50_mstc_atomic_check()
+that somehow didn't get found until now. If userspace changes
+crtc_state->active to false but leaves the CRTC enabled, we end up
+calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in
+asyh->dp.pbn. However, if the display is inactive we end up calculating
+a PBN of 0, which inadvertently causes us to have an allocation of 0.
+>From there, if userspace then disables the CRTC afterwards we end up
+accidentally attempting to free the VCPI twice:
+
+WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336
+drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
+RIP: 0010:drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
+Call Trace:
+ drm_atomic_helper_check_modeset+0x3f3/0xa60 [drm_kms_helper]
+ ? drm_atomic_check_only+0x43/0x780 [drm]
+ drm_atomic_helper_check+0x15/0x90 [drm_kms_helper]
+ nv50_disp_atomic_check+0x83/0x1d0 [nouveau]
+ drm_atomic_check_only+0x54d/0x780 [drm]
+ ? drm_atomic_set_crtc_for_connector+0xec/0x100 [drm]
+ drm_atomic_commit+0x13/0x50 [drm]
+ drm_atomic_helper_set_config+0x81/0x90 [drm_kms_helper]
+ drm_mode_setcrtc+0x194/0x6a0 [drm]
+ ? vprintk_emit+0x16a/0x230
+ ? drm_ioctl+0x163/0x390 [drm]
+ ? drm_mode_getcrtc+0x180/0x180 [drm]
+ drm_ioctl_kernel+0xaa/0xf0 [drm]
+ drm_ioctl+0x208/0x390 [drm]
+ ? drm_mode_getcrtc+0x180/0x180 [drm]
+ nouveau_drm_ioctl+0x63/0xb0 [nouveau]
+ do_vfs_ioctl+0x405/0x660
+ ? recalc_sigpending+0x17/0x50
+ ? _copy_from_user+0x37/0x60
+ ksys_ioctl+0x5e/0x90
+ ? exit_to_usermode_loop+0x92/0xe0
+ __x64_sys_ioctl+0x16/0x20
+ do_syscall_64+0x59/0x190
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336
+drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper]
+---[ end trace 4c395c0c51b1f88d ]---
+[drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for
+[MST PORT:00000000e288eb7d] found in mst state 000000008e642070
+
+So, fix this by doing what we probably should have done from the start: only
+call drm_dp_atomic_find_vcpi_slots() when crtc_state->mode_changed is set, so
+that VCPI allocations remain for as long as the CRTC is enabled.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
+Cc: Lyude Paul <lyude@redhat.com>
+Cc: Ben Skeggs <bskeggs@redhat.com>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: David Airlie <airlied@redhat.com>
+Cc: Jerry Zuo <Jerry.Zuo@amd.com>
+Cc: Harry Wentland <harry.wentland@amd.com>
+Cc: Juston Li <juston.li@intel.com>
+Cc: Karol Herbst <karolherbst@gmail.com>
+Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Cc: Ilia Mirkin <imirkin@alum.mit.edu>
+Cc: <stable@vger.kernel.org> # v5.1+
+Acked-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190801220216.15323-1-lyude@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
++++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
+@@ -775,7 +775,7 @@ nv50_msto_atomic_check(struct drm_encode
+ drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+ connector->display_info.bpc * 3);
+
+- if (drm_atomic_crtc_needs_modeset(crtc_state)) {
++ if (crtc_state->mode_changed) {
+ slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
+ mstc->port,
+ asyh->dp.pbn);
--- /dev/null
+From 6c77221df96177da0520847ce91e33f539fb8b2d Mon Sep 17 00:00:00 2001
+From: Changbin Du <changbin.du@gmail.com>
+Date: Tue, 30 Jul 2019 22:08:50 +0800
+Subject: fgraph: Remove redundant ftrace_graph_notrace_addr() test
+
+From: Changbin Du <changbin.du@gmail.com>
+
+commit 6c77221df96177da0520847ce91e33f539fb8b2d upstream.
+
+We already have tested it before. The second one should be removed.
+With this change, the performance should have little improvement.
+
+Link: http://lkml.kernel.org/r/20190730140850.7927-1-changbin.du@gmail.com
+
+Cc: stable@vger.kernel.org
+Fixes: 9cd2992f2d6c ("fgraph: Have set_graph_notrace only affect function_graph tracer")
+Signed-off-by: Changbin Du <changbin.du@gmail.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_functions_graph.c | 17 +++++++----------
+ 1 file changed, 7 insertions(+), 10 deletions(-)
+
+--- a/kernel/trace/trace_functions_graph.c
++++ b/kernel/trace/trace_functions_graph.c
+@@ -137,6 +137,13 @@ int trace_graph_entry(struct ftrace_grap
+ if (trace_recursion_test(TRACE_GRAPH_NOTRACE_BIT))
+ return 0;
+
++ /*
++ * Do not trace a function if it's filtered by set_graph_notrace.
++ * Make the index of ret stack negative to indicate that it should
++ * ignore further functions. But it needs its own ret stack entry
++ * to recover the original index in order to continue tracing after
++ * returning from the function.
++ */
+ if (ftrace_graph_notrace_addr(trace->func)) {
+ trace_recursion_set(TRACE_GRAPH_NOTRACE_BIT);
+ /*
+@@ -156,16 +163,6 @@ int trace_graph_entry(struct ftrace_grap
+ return 0;
+
+ /*
+- * Do not trace a function if it's filtered by set_graph_notrace.
+- * Make the index of ret stack negative to indicate that it should
+- * ignore further functions. But it needs its own ret stack entry
+- * to recover the original index in order to continue tracing after
+- * returning from the function.
+- */
+- if (ftrace_graph_notrace_addr(trace->func))
+- return 1;
+-
+- /*
+ * Stop here if tracing_threshold is set. We only write function return
+ * events to the ring buffer.
+ */
--- /dev/null
+From ffe0bbabb0cffceceae07484fde1ec2a63b1537c Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Date: Mon, 8 Jul 2019 10:23:43 +0200
+Subject: gpio: don't WARN() on NULL descs if gpiolib is disabled
+
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+
+commit ffe0bbabb0cffceceae07484fde1ec2a63b1537c upstream.
+
+If gpiolib is disabled, we use the inline stubs from gpio/consumer.h
+instead of regular definitions of GPIO API. The stubs for 'optional'
+variants of gpiod_get routines return NULL in this case as if the
+relevant GPIO wasn't found. This is correct so far.
+
+Calling other (non-gpio_get) stubs from this header triggers a warning
+because the GPIO descriptor couldn't have been requested. The warning
+however is unconditional (WARN_ON(1)) and is emitted even if the passed
+descriptor pointer is NULL.
+
+We don't want to force the users of 'optional' gpio_get to check the
+returned pointer before calling e.g. gpiod_set_value() so let's only
+WARN on non-NULL descriptors.
+
+Cc: stable@vger.kernel.org
+Reported-by: Claus H. Stovgaard <cst@phaseone.com>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/gpio/consumer.h | 64 +++++++++++++++++++++---------------------
+ 1 file changed, 32 insertions(+), 32 deletions(-)
+
+--- a/include/linux/gpio/consumer.h
++++ b/include/linux/gpio/consumer.h
+@@ -247,7 +247,7 @@ static inline void gpiod_put(struct gpio
+ might_sleep();
+
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ }
+
+ static inline void devm_gpiod_unhinge(struct device *dev,
+@@ -256,7 +256,7 @@ static inline void devm_gpiod_unhinge(st
+ might_sleep();
+
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ }
+
+ static inline void gpiod_put_array(struct gpio_descs *descs)
+@@ -264,7 +264,7 @@ static inline void gpiod_put_array(struc
+ might_sleep();
+
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(descs);
+ }
+
+ static inline struct gpio_desc *__must_check
+@@ -317,7 +317,7 @@ static inline void devm_gpiod_put(struct
+ might_sleep();
+
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ }
+
+ static inline void devm_gpiod_put_array(struct device *dev,
+@@ -326,32 +326,32 @@ static inline void devm_gpiod_put_array(
+ might_sleep();
+
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(descs);
+ }
+
+
+ static inline int gpiod_get_direction(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -ENOSYS;
+ }
+ static inline int gpiod_direction_input(struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -ENOSYS;
+ }
+ static inline int gpiod_direction_output(struct gpio_desc *desc, int value)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -ENOSYS;
+ }
+ static inline int gpiod_direction_output_raw(struct gpio_desc *desc, int value)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -ENOSYS;
+ }
+
+@@ -359,7 +359,7 @@ static inline int gpiod_direction_output
+ static inline int gpiod_get_value(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return 0;
+ }
+ static inline int gpiod_get_array_value(unsigned int array_size,
+@@ -368,13 +368,13 @@ static inline int gpiod_get_array_value(
+ unsigned long *value_bitmap)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc_array);
+ return 0;
+ }
+ static inline void gpiod_set_value(struct gpio_desc *desc, int value)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ }
+ static inline int gpiod_set_array_value(unsigned int array_size,
+ struct gpio_desc **desc_array,
+@@ -382,13 +382,13 @@ static inline int gpiod_set_array_value(
+ unsigned long *value_bitmap)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc_array);
+ return 0;
+ }
+ static inline int gpiod_get_raw_value(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return 0;
+ }
+ static inline int gpiod_get_raw_array_value(unsigned int array_size,
+@@ -397,13 +397,13 @@ static inline int gpiod_get_raw_array_va
+ unsigned long *value_bitmap)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc_array);
+ return 0;
+ }
+ static inline void gpiod_set_raw_value(struct gpio_desc *desc, int value)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ }
+ static inline int gpiod_set_raw_array_value(unsigned int array_size,
+ struct gpio_desc **desc_array,
+@@ -411,14 +411,14 @@ static inline int gpiod_set_raw_array_va
+ unsigned long *value_bitmap)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc_array);
+ return 0;
+ }
+
+ static inline int gpiod_get_value_cansleep(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return 0;
+ }
+ static inline int gpiod_get_array_value_cansleep(unsigned int array_size,
+@@ -427,13 +427,13 @@ static inline int gpiod_get_array_value_
+ unsigned long *value_bitmap)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc_array);
+ return 0;
+ }
+ static inline void gpiod_set_value_cansleep(struct gpio_desc *desc, int value)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ }
+ static inline int gpiod_set_array_value_cansleep(unsigned int array_size,
+ struct gpio_desc **desc_array,
+@@ -441,13 +441,13 @@ static inline int gpiod_set_array_value_
+ unsigned long *value_bitmap)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc_array);
+ return 0;
+ }
+ static inline int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return 0;
+ }
+ static inline int gpiod_get_raw_array_value_cansleep(unsigned int array_size,
+@@ -456,14 +456,14 @@ static inline int gpiod_get_raw_array_va
+ unsigned long *value_bitmap)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc_array);
+ return 0;
+ }
+ static inline void gpiod_set_raw_value_cansleep(struct gpio_desc *desc,
+ int value)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ }
+ static inline int gpiod_set_raw_array_value_cansleep(unsigned int array_size,
+ struct gpio_desc **desc_array,
+@@ -471,41 +471,41 @@ static inline int gpiod_set_raw_array_va
+ unsigned long *value_bitmap)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc_array);
+ return 0;
+ }
+
+ static inline int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -ENOSYS;
+ }
+
+ static inline int gpiod_set_transitory(struct gpio_desc *desc, bool transitory)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -ENOSYS;
+ }
+
+ static inline int gpiod_is_active_low(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return 0;
+ }
+ static inline int gpiod_cansleep(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return 0;
+ }
+
+ static inline int gpiod_to_irq(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -EINVAL;
+ }
+
+@@ -513,7 +513,7 @@ static inline int gpiod_set_consumer_nam
+ const char *name)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -EINVAL;
+ }
+
+@@ -525,7 +525,7 @@ static inline struct gpio_desc *gpio_to_
+ static inline int desc_to_gpio(const struct gpio_desc *desc)
+ {
+ /* GPIO can never have been requested */
+- WARN_ON(1);
++ WARN_ON(desc);
+ return -EINVAL;
+ }
+
--- /dev/null
+From 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 Mon Sep 17 00:00:00 2001
+From: Michael Wu <michael.wu@vatics.com>
+Date: Mon, 8 Jul 2019 13:23:08 +0800
+Subject: gpiolib: fix incorrect IRQ requesting of an active-low lineevent
+
+From: Michael Wu <michael.wu@vatics.com>
+
+commit 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 upstream.
+
+When a pin is active-low, logical trigger edge should be inverted to match
+the same interrupt opportunity.
+
+For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in
+ACTIVE_LOW case, the button pushed triggers rising edge. For user space the
+IRQ requesting doesn't need to do any modification except to configuring
+GPIOHANDLE_REQUEST_ACTIVE_LOW.
+
+For example, we want to catch the event when the button is pushed. The
+button on the original board drives level to be low when it is pushed, and
+drives level to be high when it is released.
+
+In user space we can do:
+
+ req.handleflags = GPIOHANDLE_REQUEST_INPUT;
+ req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
+
+ while (1) {
+ read(fd, &dat, sizeof(dat));
+ if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE)
+ printf("button pushed\n");
+ }
+
+Run the same logic on another board which the polarity of the button is
+inverted; it drives level to be high when pushed, and level to be low when
+released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW:
+
+ req.handleflags = GPIOHANDLE_REQUEST_INPUT |
+ GPIOHANDLE_REQUEST_ACTIVE_LOW;
+ req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
+
+At the result, there are no any events caught when the button is pushed.
+By the way, button releasing will emit a "falling" event. The timing of
+"falling" catching is not expected.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Michael Wu <michael.wu@vatics.com>
+Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -956,9 +956,11 @@ static int lineevent_create(struct gpio_
+ }
+
+ if (eflags & GPIOEVENT_REQUEST_RISING_EDGE)
+- irqflags |= IRQF_TRIGGER_RISING;
++ irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ?
++ IRQF_TRIGGER_FALLING : IRQF_TRIGGER_RISING;
+ if (eflags & GPIOEVENT_REQUEST_FALLING_EDGE)
+- irqflags |= IRQF_TRIGGER_FALLING;
++ irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ?
++ IRQF_TRIGGER_RISING : IRQF_TRIGGER_FALLING;
+ irqflags |= IRQF_ONESHOT;
+
+ INIT_KFIFO(le->events);
--- /dev/null
+From d95da993383c78f7efd25957ba3af23af4b1c613 Mon Sep 17 00:00:00 2001
+From: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Date: Mon, 8 Jul 2019 08:35:58 +1200
+Subject: gpiolib: Preserve desc->flags when setting state
+
+From: Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+commit d95da993383c78f7efd25957ba3af23af4b1c613 upstream.
+
+desc->flags may already have values set by of_gpiochip_add() so make
+sure that this isn't undone when setting the initial direction.
+
+Cc: stable@vger.kernel.org
+Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning")
+Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Link: https://lore.kernel.org/r/20190707203558.10993-1-chris.packham@alliedtelesis.co.nz
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 17 +++++++++++------
+ 1 file changed, 11 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -1392,12 +1392,17 @@ int gpiochip_add_data_with_key(struct gp
+ for (i = 0; i < chip->ngpio; i++) {
+ struct gpio_desc *desc = &gdev->descs[i];
+
+- if (chip->get_direction && gpiochip_line_is_valid(chip, i))
+- desc->flags = !chip->get_direction(chip, i) ?
+- (1 << FLAG_IS_OUT) : 0;
+- else
+- desc->flags = !chip->direction_input ?
+- (1 << FLAG_IS_OUT) : 0;
++ if (chip->get_direction && gpiochip_line_is_valid(chip, i)) {
++ if (!chip->get_direction(chip, i))
++ set_bit(FLAG_IS_OUT, &desc->flags);
++ else
++ clear_bit(FLAG_IS_OUT, &desc->flags);
++ } else {
++ if (!chip->direction_input)
++ set_bit(FLAG_IS_OUT, &desc->flags);
++ else
++ clear_bit(FLAG_IS_OUT, &desc->flags);
++ }
+ }
+
+ acpi_gpiochip_add(chip);
--- /dev/null
+From 6497d0a9c53df6e98b25e2b79f2295d7caa47b6e Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Wed, 31 Jul 2019 12:54:28 -0500
+Subject: IB/hfi1: Fix Spectre v1 vulnerability
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 6497d0a9c53df6e98b25e2b79f2295d7caa47b6e upstream.
+
+sl is controlled by user-space, hence leading to a potential
+exploitation of the Spectre variant 1 vulnerability.
+
+Fix this by sanitizing sl before using it to index ibp->sl_to_sc.
+
+Notice that given that speculation windows are large, the policy is
+to kill the speculation on the first load and not worry if it can be
+completed with a dependent load/store [1].
+
+[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedor
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/hfi1/verbs.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/infiniband/hw/hfi1/verbs.c
++++ b/drivers/infiniband/hw/hfi1/verbs.c
+@@ -54,6 +54,7 @@
+ #include <linux/mm.h>
+ #include <linux/vmalloc.h>
+ #include <rdma/opa_addr.h>
++#include <linux/nospec.h>
+
+ #include "hfi.h"
+ #include "common.h"
+@@ -1536,6 +1537,7 @@ static int hfi1_check_ah(struct ib_devic
+ sl = rdma_ah_get_sl(ah_attr);
+ if (sl >= ARRAY_SIZE(ibp->sl_to_sc))
+ return -EINVAL;
++ sl = array_index_nospec(sl, ARRAY_SIZE(ibp->sl_to_sc));
+
+ sc5 = ibp->sl_to_sc[sl];
+ if (sc_to_vlt(dd, sc5) > num_vls && sc_to_vlt(dd, sc5) != 0xf)
--- /dev/null
+From 5241ab4cf42d3a93b933b55d3d53f43049081fa1 Mon Sep 17 00:00:00 2001
+From: Masahiro Yamada <yamada.masahiro@socionext.com>
+Date: Mon, 29 Jul 2019 18:15:17 +0900
+Subject: kbuild: initialize CLANG_FLAGS correctly in the top Makefile
+
+From: Masahiro Yamada <yamada.masahiro@socionext.com>
+
+commit 5241ab4cf42d3a93b933b55d3d53f43049081fa1 upstream.
+
+CLANG_FLAGS is initialized by the following line:
+
+ CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%))
+
+..., which is run only when CROSS_COMPILE is set.
+
+Some build targets (bindeb-pkg etc.) recurse to the top Makefile.
+
+When you build the kernel with Clang but without CROSS_COMPILE,
+the same compiler flags such as -no-integrated-as are accumulated
+into CLANG_FLAGS.
+
+If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg',
+Kbuild will recompile everything needlessly due to the build command
+change.
+
+Fix this by correctly initializing CLANG_FLAGS.
+
+Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags")
+Cc: <stable@vger.kernel.org> # v5.0+
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
+Acked-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Makefile | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/Makefile
++++ b/Makefile
+@@ -467,6 +467,7 @@ KBUILD_CFLAGS_MODULE := -DMODULE
+ KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
+ KBUILD_LDFLAGS :=
+ GCC_PLUGINS_CFLAGS :=
++CLANG_FLAGS :=
+
+ export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC
+ export CPP AR NM STRIP OBJCOPY OBJDUMP PAHOLE KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS
+@@ -519,7 +520,7 @@ endif
+
+ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
+ ifneq ($(CROSS_COMPILE),)
+-CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%))
++CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
+ GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
+ CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)
+ GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
--- /dev/null
+From 944cfe9be1fbbec73bab2f7e77fe2e8f9c72970f Mon Sep 17 00:00:00 2001
+From: Masahiro Yamada <yamada.masahiro@socionext.com>
+Date: Wed, 31 Jul 2019 00:58:59 +0900
+Subject: kbuild: modpost: include .*.cmd files only when targets exist
+
+From: Masahiro Yamada <yamada.masahiro@socionext.com>
+
+commit 944cfe9be1fbbec73bab2f7e77fe2e8f9c72970f upstream.
+
+If a build rule fails, the .DELETE_ON_ERROR special target removes the
+target, but does nothing for the .*.cmd file, which might be corrupted.
+So, .*.cmd files should be included only when the corresponding targets
+exist.
+
+Commit 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd
+files") missed to fix up this file.
+
+Fixes: 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd")
+Cc: <stable@vger.kernel.org> # v5.0+
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ scripts/Makefile.modpost | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/scripts/Makefile.modpost
++++ b/scripts/Makefile.modpost
+@@ -142,10 +142,8 @@ FORCE:
+ # optimization, we don't need to read them if the target does not
+ # exist, we will rebuild anyway in that case.
+
+-cmd_files := $(wildcard $(foreach f,$(sort $(targets)),$(dir $(f)).$(notdir $(f)).cmd))
++existing-targets := $(wildcard $(sort $(targets)))
+
+-ifneq ($(cmd_files),)
+- include $(cmd_files)
+-endif
++-include $(foreach f,$(existing-targets),$(dir $(f)).$(notdir $(f)).cmd)
+
+ .PHONY: $(PHONY)
--- /dev/null
+From 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce Mon Sep 17 00:00:00 2001
+From: "M. Vefa Bicakci" <m.v.b@runbox.com>
+Date: Sat, 3 Aug 2019 06:02:12 -0400
+Subject: kconfig: Clear "written" flag to avoid data loss
+
+From: M. Vefa Bicakci <m.v.b@runbox.com>
+
+commit 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce upstream.
+
+Prior to this commit, starting nconfig, xconfig or gconfig, and saving
+the .config file more than once caused data loss, where a .config file
+that contained only comments would be written to disk starting from the
+second save operation.
+
+This bug manifests itself because the SYMBOL_WRITTEN flag is never
+cleared after the first call to conf_write, and subsequent calls to
+conf_write then skip all of the configuration symbols due to the
+SYMBOL_WRITTEN flag being set.
+
+This commit resolves this issue by clearing the SYMBOL_WRITTEN flag
+from all symbols before conf_write returns.
+
+Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf")
+Cc: linux-stable <stable@vger.kernel.org> # 4.19+
+Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ scripts/kconfig/confdata.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/scripts/kconfig/confdata.c
++++ b/scripts/kconfig/confdata.c
+@@ -867,6 +867,7 @@ int conf_write(const char *name)
+ const char *str;
+ char tmpname[PATH_MAX + 1], oldname[PATH_MAX + 1];
+ char *env;
++ int i;
+ bool need_newline = false;
+
+ if (!name)
+@@ -949,6 +950,9 @@ next:
+ }
+ fclose(out);
+
++ for_all_symbols(i, sym)
++ sym->flags &= ~SYMBOL_WRITTEN;
++
+ if (*tmpname) {
+ if (is_same(name, tmpname)) {
+ conf_message("No change to %s", name);
--- /dev/null
+From ba2d139b02ba684c6c101de42fed782d6cd2b997 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Mon, 8 Jul 2019 12:56:13 -0700
+Subject: mmc: dw_mmc: Fix occasional hang after tuning on eMMC
+
+From: Douglas Anderson <dianders@chromium.org>
+
+commit ba2d139b02ba684c6c101de42fed782d6cd2b997 upstream.
+
+In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after
+response errors.") we fixed a tuning-induced hang that I saw when
+stress testing tuning on certain SD cards. I won't re-hash that whole
+commit, but the summary is that as a normal part of tuning you need to
+deal with transfer errors and there were cases where these transfer
+errors was putting my system into a bad state causing all future
+transfers to fail. That commit fixed handling of the transfer errors
+for me.
+
+In downstream Chrome OS my fix landed and had the same behavior for
+all SD/MMC commands. However, it looks like when the commit landed
+upstream we limited it to only SD tuning commands. Presumably this
+was to try to get around problems that Alim Akhtar reported on exynos
+[1].
+
+Unfortunately while stress testing reboots (and suspend/resume) on
+some rk3288-based Chromebooks I found the same problem on the eMMC on
+some of my Chromebooks (the ones with Hynix eMMC). Since the eMMC
+tuning command is different (MMC_SEND_TUNING_BLOCK_HS200
+vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the
+same situation.
+
+I'm hoping that whatever problems exynos was having in the past are
+somehow magically fixed now and we can make the behavior the same for
+all commands.
+
+[1] https://lkml.kernel.org/r/CAGOxZ53WfNbaMe0_AM0qBqU47kAfgmPBVZC8K8Y-_J3mDMqW4A@mail.gmail.com
+
+Fixes: 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response errors.")
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Cc: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: Alim Akhtar <alim.akhtar@gmail.com>
+Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/dw_mmc.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/dw_mmc.c
++++ b/drivers/mmc/host/dw_mmc.c
+@@ -2034,8 +2034,7 @@ static void dw_mci_tasklet_func(unsigned
+ * delayed. Allowing the transfer to take place
+ * avoids races and keeps things simple.
+ */
+- if ((err != -ETIMEDOUT) &&
+- (cmd->opcode == MMC_SEND_TUNING_BLOCK)) {
++ if (err != -ETIMEDOUT) {
+ state = STATE_SENDING_DATA;
+ continue;
+ }
--- /dev/null
+From fc62113b32c95906b3ea8ba42e91014c7d0c6fa6 Mon Sep 17 00:00:00 2001
+From: Baolin Wang <baolin.wang@linaro.org>
+Date: Mon, 15 Jul 2019 18:00:14 +0800
+Subject: mmc: host: sdhci-sprd: Fix the missing pm_runtime_put_noidle()
+
+From: Baolin Wang <baolin.wang@linaro.org>
+
+commit fc62113b32c95906b3ea8ba42e91014c7d0c6fa6 upstream.
+
+When the SD host controller tries to probe again due to the derferred
+probe mechanism, it will always keep the SD host device as runtime
+resume state due to missing the runtime put operation in error path
+last time.
+
+Thus add the pm_runtime_put_noidle() in error path to make the PM runtime
+counter balance, which can make the SD host device's PM runtime work well.
+
+Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-sprd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mmc/host/sdhci-sprd.c
++++ b/drivers/mmc/host/sdhci-sprd.c
+@@ -405,6 +405,7 @@ err_cleanup_host:
+ sdhci_cleanup_host(host);
+
+ pm_runtime_disable:
++ pm_runtime_put_noidle(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+
--- /dev/null
+From 665e985c2f41bebc3e6cee7e04c36a44afbc58f7 Mon Sep 17 00:00:00 2001
+From: Joe Perches <joe@perches.com>
+Date: Tue, 9 Jul 2019 22:04:19 -0700
+Subject: mmc: meson-mx-sdio: Fix misuse of GENMASK macro
+
+From: Joe Perches <joe@perches.com>
+
+commit 665e985c2f41bebc3e6cee7e04c36a44afbc58f7 upstream.
+
+Arguments are supposed to be ordered high then low.
+
+Signed-off-by: Joe Perches <joe@perches.com>
+Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
+Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic
+Meson8 and Meson8b SoCs")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/meson-mx-sdio.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/meson-mx-sdio.c
++++ b/drivers/mmc/host/meson-mx-sdio.c
+@@ -73,7 +73,7 @@
+ #define MESON_MX_SDIO_IRQC_IF_CONFIG_MASK GENMASK(7, 6)
+ #define MESON_MX_SDIO_IRQC_FORCE_DATA_CLK BIT(8)
+ #define MESON_MX_SDIO_IRQC_FORCE_DATA_CMD BIT(9)
+- #define MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK GENMASK(10, 13)
++ #define MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK GENMASK(13, 10)
+ #define MESON_MX_SDIO_IRQC_SOFT_RESET BIT(15)
+ #define MESON_MX_SDIO_IRQC_FORCE_HALT BIT(30)
+ #define MESON_MX_SDIO_IRQC_HALT_HOLE BIT(31)
--- /dev/null
+From 3a6ffb3c8c3274a39dc8f2514526e645c5d21753 Mon Sep 17 00:00:00 2001
+From: Andreas Koop <andreas.koop@zf.com>
+Date: Mon, 22 Jul 2019 12:03:06 +0800
+Subject: mmc: mmc_spi: Enable stable writes
+
+From: Andreas Koop <andreas.koop@zf.com>
+
+commit 3a6ffb3c8c3274a39dc8f2514526e645c5d21753 upstream.
+
+While using the mmc_spi driver occasionally errors like this popped up:
+
+mmcblk0: error -84 transferring data end_request: I/O error, dev mmcblk0, sector 581756
+
+I looked on the Internet for occurrences of the same problem and came
+across a helpful post [1]. It includes source code to reproduce the bug.
+There is also an analysis about the cause. During transmission data in the
+supplied buffer is being modified. Thus the previously calculated checksum
+is not correct anymore.
+
+After some digging I found out that device drivers are supposed to report
+they need stable writes. To fix this I set the appropriate flag at queue
+initialization if CRC checksumming is enabled for that SPI host.
+
+[1]
+https://groups.google.com/forum/#!msg/sim1/gLlzWeXGFr8/KevXinUXfc8J
+
+Signed-off-by: Andreas Koop <andreas.koop@zf.com>
+[shihpo: Rebase on top of v5.3-rc1]
+Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com>
+Cc: Paul Walmsley <paul.walmsley@sifive.com>
+CC: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/queue.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/mmc/core/queue.c
++++ b/drivers/mmc/core/queue.c
+@@ -10,6 +10,7 @@
+ #include <linux/kthread.h>
+ #include <linux/scatterlist.h>
+ #include <linux/dma-mapping.h>
++#include <linux/backing-dev.h>
+
+ #include <linux/mmc/card.h>
+ #include <linux/mmc/host.h>
+@@ -430,6 +431,10 @@ int mmc_init_queue(struct mmc_queue *mq,
+ goto free_tag_set;
+ }
+
++ if (mmc_host_is_spi(host) && host->use_spi_crc)
++ mq->queue->backing_dev_info->capabilities |=
++ BDI_CAP_STABLE_WRITES;
++
+ mq->queue->queuedata = mq;
+ blk_queue_rq_timeout(mq->queue, 60 * HZ);
+
drm-nouveau-fix-memory-leak-in-nouveau_conn_reset.patch
dma-direct-correct-the-physical-addr-in-dma_direct_s.patch
drm-nouveau-dmem-missing-mutex_lock-in-error-path.patch
+kconfig-clear-written-flag-to-avoid-data-loss.patch
+kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch
+kbuild-modpost-include-.-.cmd-files-only-when-targets-exist.patch
+tpm-fix-null-pointer-dereference-on-chip-register-error-path.patch
+btrfs-fix-incremental-send-failure-after-deduplication.patch
+btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch
+dax-fix-missed-wakeup-in-put_unlocked_entry.patch
+fgraph-remove-redundant-ftrace_graph_notrace_addr-test.patch
+mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch
+mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch
+mmc-host-sdhci-sprd-fix-the-missing-pm_runtime_put_noidle.patch
+mmc-mmc_spi-enable-stable-writes.patch
+gpiolib-preserve-desc-flags-when-setting-state.patch
+gpio-don-t-warn-on-null-descs-if-gpiolib-is-disabled.patch
+gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch
+ib-hfi1-fix-spectre-v1-vulnerability.patch
+drm-nouveau-only-release-vcpi-slots-on-mode-changes.patch
--- /dev/null
+From 1e5ac6300a07ceecfc70a893ebef3352be21e6f8 Mon Sep 17 00:00:00 2001
+From: Milan Broz <gmazyland@gmail.com>
+Date: Thu, 4 Jul 2019 09:26:15 +0200
+Subject: tpm: Fix null pointer dereference on chip register error path
+
+From: Milan Broz <gmazyland@gmail.com>
+
+commit 1e5ac6300a07ceecfc70a893ebef3352be21e6f8 upstream.
+
+If clk_enable is not defined and chip initialization
+is canceled code hits null dereference.
+
+Easily reproducible with vTPM init fail:
+ swtpm chardev --tpmstate dir=nonexistent_dir --tpm2 --vtpm-proxy
+
+BUG: kernel NULL pointer dereference, address: 00000000
+...
+Call Trace:
+ tpm_chip_start+0x9d/0xa0 [tpm]
+ tpm_chip_register+0x10/0x1a0 [tpm]
+ vtpm_proxy_work+0x11/0x30 [tpm_vtpm_proxy]
+ process_one_work+0x214/0x5a0
+ worker_thread+0x134/0x3e0
+ ? process_one_work+0x5a0/0x5a0
+ kthread+0xd4/0x100
+ ? process_one_work+0x5a0/0x5a0
+ ? kthread_park+0x90/0x90
+ ret_from_fork+0x19/0x24
+
+Fixes: 719b7d81f204 ("tpm: introduce tpm_chip_start() and tpm_chip_stop()")
+Cc: stable@vger.kernel.org # v5.1+
+Signed-off-by: Milan Broz <gmazyland@gmail.com>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/tpm-chip.c | 23 ++++++++++++++++-------
+ 1 file changed, 16 insertions(+), 7 deletions(-)
+
+--- a/drivers/char/tpm/tpm-chip.c
++++ b/drivers/char/tpm/tpm-chip.c
+@@ -77,6 +77,18 @@ static int tpm_go_idle(struct tpm_chip *
+ return chip->ops->go_idle(chip);
+ }
+
++static void tpm_clk_enable(struct tpm_chip *chip)
++{
++ if (chip->ops->clk_enable)
++ chip->ops->clk_enable(chip, true);
++}
++
++static void tpm_clk_disable(struct tpm_chip *chip)
++{
++ if (chip->ops->clk_enable)
++ chip->ops->clk_enable(chip, false);
++}
++
+ /**
+ * tpm_chip_start() - power on the TPM
+ * @chip: a TPM chip to use
+@@ -89,13 +101,12 @@ int tpm_chip_start(struct tpm_chip *chip
+ {
+ int ret;
+
+- if (chip->ops->clk_enable)
+- chip->ops->clk_enable(chip, true);
++ tpm_clk_enable(chip);
+
+ if (chip->locality == -1) {
+ ret = tpm_request_locality(chip);
+ if (ret) {
+- chip->ops->clk_enable(chip, false);
++ tpm_clk_disable(chip);
+ return ret;
+ }
+ }
+@@ -103,8 +114,7 @@ int tpm_chip_start(struct tpm_chip *chip
+ ret = tpm_cmd_ready(chip);
+ if (ret) {
+ tpm_relinquish_locality(chip);
+- if (chip->ops->clk_enable)
+- chip->ops->clk_enable(chip, false);
++ tpm_clk_disable(chip);
+ return ret;
+ }
+
+@@ -124,8 +134,7 @@ void tpm_chip_stop(struct tpm_chip *chip
+ {
+ tpm_go_idle(chip);
+ tpm_relinquish_locality(chip);
+- if (chip->ops->clk_enable)
+- chip->ops->clk_enable(chip, false);
++ tpm_clk_disable(chip);
+ }
+ EXPORT_SYMBOL_GPL(tpm_chip_stop);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
