--- /dev/null
+From 349ae63f40638a28c6fce52e8447c2d14b84cc0c Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <jthumshirn@suse.de>
+Date: Mon, 18 Feb 2019 11:28:37 +0100
+Subject: btrfs: ensure that a DUP or RAID1 block group has exactly two stripes
+
+From: Johannes Thumshirn <jthumshirn@suse.de>
+
+commit 349ae63f40638a28c6fce52e8447c2d14b84cc0c upstream.
+
+We recently had a customer issue with a corrupted filesystem. When
+trying to mount this image btrfs panicked with a division by zero in
+calc_stripe_length().
+
+The corrupt chunk had a 'num_stripes' value of 1. calc_stripe_length()
+takes this value and divides it by the number of copies the RAID profile
+is expected to have to calculate the amount of data stripes. As a DUP
+profile is expected to have 2 copies this division resulted in 1/2 = 0.
+Later then the 'data_stripes' variable is used as a divisor in the
+stripe length calculation which results in a division by 0 and thus a
+kernel panic.
+
+When encountering a filesystem with a DUP block group and a
+'num_stripes' value unequal to 2, refuse mounting as the image is
+corrupted and will lead to unexpected behaviour.
+
+Code inspection showed a RAID1 block group has the same issues.
+
+Fixes: e06cd3dd7cea ("Btrfs: add validadtion checks for chunk loading")
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
+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 | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -6420,10 +6420,10 @@ static int btrfs_check_chunk_valid(struc
+ }
+
+ if ((type & BTRFS_BLOCK_GROUP_RAID10 && sub_stripes != 2) ||
+- (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) ||
++ (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes != 2) ||
+ (type & BTRFS_BLOCK_GROUP_RAID5 && num_stripes < 2) ||
+ (type & BTRFS_BLOCK_GROUP_RAID6 && num_stripes < 3) ||
+- (type & BTRFS_BLOCK_GROUP_DUP && num_stripes > 2) ||
++ (type & BTRFS_BLOCK_GROUP_DUP && num_stripes != 2) ||
+ ((type & BTRFS_BLOCK_GROUP_PROFILE_MASK) == 0 &&
+ num_stripes != 1)) {
+ btrfs_err(fs_info,
--- /dev/null
+From 8e928218780e2f1cf2f5891c7575e8f0b284fcce Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 14 Feb 2019 15:17:20 +0000
+Subject: Btrfs: fix corruption reading shared and compressed extents after hole punching
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
+
+In the past we had data corruption when reading compressed extents that
+are shared within the same file and they are consecutive, this got fixed
+by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and
+shared extents") and by commit 808f80b46790f ("Btrfs: update fix for read
+corruption of compressed and shared extents"). However there was a case
+that was missing in those fixes, which is when the shared and compressed
+extents are referenced with a non-zero offset. The following shell script
+creates a reproducer for this issue:
+
+ #!/bin/bash
+
+ mkfs.btrfs -f /dev/sdc &> /dev/null
+ mount -o compress /dev/sdc /mnt/sdc
+
+ # Create a file with 3 consecutive compressed extents, each has an
+ # uncompressed size of 128Kb and a compressed size of 4Kb.
+ for ((i = 1; i <= 3; i++)); do
+ head -c 4096 /dev/zero
+ for ((j = 1; j <= 31; j++)); do
+ head -c 4096 /dev/zero | tr '\0' "\377"
+ done
+ done > /mnt/sdc/foobar
+ sync
+
+ echo "Digest after file creation: $(md5sum /mnt/sdc/foobar)"
+
+ # Clone the first extent into offsets 128K and 256K.
+ xfs_io -c "reflink /mnt/sdc/foobar 0 128K 128K" /mnt/sdc/foobar
+ xfs_io -c "reflink /mnt/sdc/foobar 0 256K 128K" /mnt/sdc/foobar
+ sync
+
+ echo "Digest after cloning: $(md5sum /mnt/sdc/foobar)"
+
+ # Punch holes into the regions that are already full of zeroes.
+ xfs_io -c "fpunch 0 4K" /mnt/sdc/foobar
+ xfs_io -c "fpunch 128K 4K" /mnt/sdc/foobar
+ xfs_io -c "fpunch 256K 4K" /mnt/sdc/foobar
+ sync
+
+ echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)"
+
+ echo "Dropping page cache..."
+ sysctl -q vm.drop_caches=1
+ echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)"
+
+ umount /dev/sdc
+
+When running the script we get the following output:
+
+ Digest after file creation: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
+ linked 131072/131072 bytes at offset 131072
+ 128 KiB, 1 ops; 0.0033 sec (36.960 MiB/sec and 295.6830 ops/sec)
+ linked 131072/131072 bytes at offset 262144
+ 128 KiB, 1 ops; 0.0015 sec (78.567 MiB/sec and 628.5355 ops/sec)
+ Digest after cloning: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
+ Digest after hole punching: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
+ Dropping page cache...
+ Digest after hole punching: fba694ae8664ed0c2e9ff8937e7f1484 /mnt/sdc/foobar
+
+This happens because after reading all the pages of the extent in the
+range from 128K to 256K for example, we read the hole at offset 256K
+and then when reading the page at offset 260K we don't submit the
+existing bio, which is responsible for filling all the page in the
+range 128K to 256K only, therefore adding the pages from range 260K
+to 384K to the existing bio and submitting it after iterating over the
+entire range. Once the bio completes, the uncompressed data fills only
+the pages in the range 128K to 256K because there's no more data read
+from disk, leaving the pages in the range 260K to 384K unfilled. It is
+just a slightly different variant of what was solved by commit
+005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared
+extents").
+
+Fix this by forcing a bio submit, during readpages(), whenever we find a
+compressed extent map for a page that is different from the extent map
+for the previous page or has a different starting offset (in case it's
+the same compressed extent), instead of the extent map's original start
+offset.
+
+A test case for fstests follows soon.
+
+Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
+Fixes: 808f80b46790f ("Btrfs: update fix for read corruption of compressed and shared extents")
+Fixes: 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents")
+Cc: stable@vger.kernel.org # 4.3+
+Tested-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
+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/extent_io.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/extent_io.c
++++ b/fs/btrfs/extent_io.c
+@@ -3014,11 +3014,11 @@ static int __do_readpage(struct extent_i
+ */
+ if (test_bit(EXTENT_FLAG_COMPRESSED, &em->flags) &&
+ prev_em_start && *prev_em_start != (u64)-1 &&
+- *prev_em_start != em->orig_start)
++ *prev_em_start != em->start)
+ force_bio_submit = true;
+
+ if (prev_em_start)
+- *prev_em_start = em->orig_start;
++ *prev_em_start = em->start;
+
+ free_extent_map(em);
+ em = NULL;
--- /dev/null
+From a0873490660246db587849a9e172f2b7b21fa88a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 13 Dec 2018 21:16:56 +0000
+Subject: Btrfs: setup a nofs context for memory allocation at __btrfs_set_acl
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit a0873490660246db587849a9e172f2b7b21fa88a upstream.
+
+We are holding a transaction handle when setting an acl, therefore we can
+not allocate the xattr value buffer using GFP_KERNEL, as we could deadlock
+if reclaim is triggered by the allocation, therefore setup a nofs context.
+
+Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xattr and acl allocations")
+CC: stable@vger.kernel.org # 4.9+
+Reviewed-by: Nikolay Borisov <nborisov@suse.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/acl.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/btrfs/acl.c
++++ b/fs/btrfs/acl.c
+@@ -22,6 +22,7 @@
+ #include <linux/posix_acl_xattr.h>
+ #include <linux/posix_acl.h>
+ #include <linux/sched.h>
++#include <linux/sched/mm.h>
+ #include <linux/slab.h>
+
+ #include "ctree.h"
+@@ -89,8 +90,16 @@ static int __btrfs_set_acl(struct btrfs_
+ }
+
+ if (acl) {
++ unsigned int nofs_flag;
++
+ size = posix_acl_xattr_size(acl->a_count);
++ /*
++ * We're holding a transaction handle, so use a NOFS memory
++ * allocation context to avoid deadlock if reclaim happens.
++ */
++ nofs_flag = memalloc_nofs_save();
+ value = kmalloc(size, GFP_KERNEL);
++ memalloc_nofs_restore(nofs_flag);
+ if (!value) {
+ ret = -ENOMEM;
+ goto out;
--- /dev/null
+From c950ca8c35eeb32224a63adc47e12f9e226da241 Mon Sep 17 00:00:00 2001
+From: Samuel Holland <samuel@sholland.org>
+Date: Sat, 12 Jan 2019 20:17:18 -0600
+Subject: clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Samuel Holland <samuel@sholland.org>
+
+commit c950ca8c35eeb32224a63adc47e12f9e226da241 upstream.
+
+The Allwinner A64 SoC is known[1] to have an unstable architectural
+timer, which manifests itself most obviously in the time jumping forward
+a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
+timer frequency of 24 MHz, implying that the time went slightly backward
+(and this was interpreted by the kernel as it jumping forward and
+wrapping around past the epoch).
+
+Investigation revealed instability in the low bits of CNTVCT at the
+point a high bit rolls over. This leads to power-of-two cycle forward
+and backward jumps. (Testing shows that forward jumps are about twice as
+likely as backward jumps.) Since the counter value returns to normal
+after an indeterminate read, each "jump" really consists of both a
+forward and backward jump from the software perspective.
+
+Unless the kernel is trapping CNTVCT reads, a userspace program is able
+to read the register in a loop faster than it changes. A test program
+running on all 4 CPU cores that reported jumps larger than 100 ms was
+run for 13.6 hours and reported the following:
+
+ Count | Event
+-------+---------------------------
+ 9940 | jumped backward 699ms
+ 268 | jumped backward 1398ms
+ 1 | jumped backward 2097ms
+ 16020 | jumped forward 175ms
+ 6443 | jumped forward 699ms
+ 2976 | jumped forward 1398ms
+ 9 | jumped forward 356516ms
+ 9 | jumped forward 357215ms
+ 4 | jumped forward 714430ms
+ 1 | jumped forward 3578440ms
+
+This works out to a jump larger than 100 ms about every 5.5 seconds on
+each CPU core.
+
+The largest jump (almost an hour!) was the following sequence of reads:
+ 0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
+
+Note that the middle bits don't necessarily all read as all zeroes or
+all ones during the anomalous behavior; however the low 10 bits checked
+by the function in this patch have never been observed with any other
+value.
+
+Also note that smaller jumps are much more common, with backward jumps
+of 2048 (2^11) cycles observed over 400 times per second on each core.
+(Of course, this is partially explained by lower bits rolling over more
+frequently.) Any one of these could have caused the 95 year time skip.
+
+Similar anomalies were observed while reading CNTPCT (after patching the
+kernel to allow reads from userspace). However, the CNTPCT jumps are
+much less frequent, and only small jumps were observed. The same program
+as before (except now reading CNTPCT) observed after 72 hours:
+
+ Count | Event
+-------+---------------------------
+ 17 | jumped backward 699ms
+ 52 | jumped forward 175ms
+ 2831 | jumped forward 699ms
+ 5 | jumped forward 1398ms
+
+Further investigation showed that the instability in CNTPCT/CNTVCT also
+affected the respective timer's TVAL register. The following values were
+observed immediately after writing CNVT_TVAL to 0x10000000:
+
+ CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
+--------------------+------------+--------------------+-----------------
+ 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
+ 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
+ 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
+ 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000
+
+The pattern of errors in CNTV_TVAL seemed to depend on exactly which
+value was written to it. For example, after writing 0x10101010:
+
+ CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
+--------------------+------------+--------------------+-----------------
+ 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
+ 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
+ 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
+ 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
+ 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
+ 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000
+
+I was also twice able to reproduce the issue covered by Allwinner's
+workaround[4], that writing to TVAL sometimes fails, and both CVAL and
+TVAL are left with entirely bogus values. One was the following values:
+
+ CNTVCT | CNTV_TVAL | CNTV_CVAL
+--------------------+------------+--------------------------------------
+ 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
+Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
+
+========================================================================
+
+Because the CPU can read the CNTPCT/CNTVCT registers faster than they
+change, performing two reads of the register and comparing the high bits
+(like other workarounds) is not a workable solution. And because the
+timer can jump both forward and backward, no pair of reads can
+distinguish a good value from a bad one. The only way to guarantee a
+good value from consecutive reads would be to read _three_ times, and
+take the middle value only if the three values are 1) each unique and
+2) increasing. This takes at minimum 3 counter cycles (125 ns), or more
+if an anomaly is detected.
+
+However, since there is a distinct pattern to the bad values, we can
+optimize the common case (1022/1024 of the time) to a single read by
+simply ignoring values that match the error pattern. This still takes no
+more than 3 cycles in the worst case, and requires much less code. As an
+additional safety check, we still limit the loop iteration to the number
+of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.
+
+For the TVAL registers, the simple solution is to not use them. Instead,
+read or write the CVAL and calculate the TVAL value in software.
+
+Although the manufacturer is aware of at least part of the erratum[4],
+there is no official name for it. For now, use the kernel-internal name
+"UNKNOWN1".
+
+[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
+[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
+[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
+[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272
+
+Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Tested-by: Andre Przywara <andre.przywara@arm.com>
+Signed-off-by: Samuel Holland <samuel@sholland.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/arm64/silicon-errata.txt | 2 +
+ drivers/clocksource/Kconfig | 10 ++++++
+ drivers/clocksource/arm_arch_timer.c | 55 +++++++++++++++++++++++++++++++++
+ 3 files changed, 67 insertions(+)
+
+--- a/Documentation/arm64/silicon-errata.txt
++++ b/Documentation/arm64/silicon-errata.txt
+@@ -44,6 +44,8 @@ stable kernels.
+
+ | Implementor | Component | Erratum ID | Kconfig |
+ +----------------+-----------------+-----------------+-----------------------------+
++| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
++| | | | |
+ | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+ | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
+ | ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
+--- a/drivers/clocksource/Kconfig
++++ b/drivers/clocksource/Kconfig
+@@ -374,6 +374,16 @@ config ARM64_ERRATUM_858921
+ The workaround will be dynamically enabled when an affected
+ core is detected.
+
++config SUN50I_ERRATUM_UNKNOWN1
++ bool "Workaround for Allwinner A64 erratum UNKNOWN1"
++ default y
++ depends on ARM_ARCH_TIMER && ARM64 && ARCH_SUNXI
++ select ARM_ARCH_TIMER_OOL_WORKAROUND
++ help
++ This option enables a workaround for instability in the timer on
++ the Allwinner A64 SoC. The workaround will only be active if the
++ allwinner,erratum-unknown1 property is found in the timer node.
++
+ config ARM_GLOBAL_TIMER
+ bool "Support for the ARM global timer" if COMPILE_TEST
+ select TIMER_OF if OF
+--- a/drivers/clocksource/arm_arch_timer.c
++++ b/drivers/clocksource/arm_arch_timer.c
+@@ -298,6 +298,48 @@ static u64 notrace arm64_858921_read_cnt
+ }
+ #endif
+
++#ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1
++/*
++ * The low bits of the counter registers are indeterminate while bit 10 or
++ * greater is rolling over. Since the counter value can jump both backward
++ * (7ff -> 000 -> 800) and forward (7ff -> fff -> 800), ignore register values
++ * with all ones or all zeros in the low bits. Bound the loop by the maximum
++ * number of CPU cycles in 3 consecutive 24 MHz counter periods.
++ */
++#define __sun50i_a64_read_reg(reg) ({ \
++ u64 _val; \
++ int _retries = 150; \
++ \
++ do { \
++ _val = read_sysreg(reg); \
++ _retries--; \
++ } while (((_val + 1) & GENMASK(9, 0)) <= 1 && _retries); \
++ \
++ WARN_ON_ONCE(!_retries); \
++ _val; \
++})
++
++static u64 notrace sun50i_a64_read_cntpct_el0(void)
++{
++ return __sun50i_a64_read_reg(cntpct_el0);
++}
++
++static u64 notrace sun50i_a64_read_cntvct_el0(void)
++{
++ return __sun50i_a64_read_reg(cntvct_el0);
++}
++
++static u32 notrace sun50i_a64_read_cntp_tval_el0(void)
++{
++ return read_sysreg(cntp_cval_el0) - sun50i_a64_read_cntpct_el0();
++}
++
++static u32 notrace sun50i_a64_read_cntv_tval_el0(void)
++{
++ return read_sysreg(cntv_cval_el0) - sun50i_a64_read_cntvct_el0();
++}
++#endif
++
+ #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
+ DEFINE_PER_CPU(const struct arch_timer_erratum_workaround *,
+ timer_unstable_counter_workaround);
+@@ -381,6 +423,19 @@ static const struct arch_timer_erratum_w
+ .read_cntvct_el0 = arm64_858921_read_cntvct_el0,
+ },
+ #endif
++#ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1
++ {
++ .match_type = ate_match_dt,
++ .id = "allwinner,erratum-unknown1",
++ .desc = "Allwinner erratum UNKNOWN1",
++ .read_cntp_tval_el0 = sun50i_a64_read_cntp_tval_el0,
++ .read_cntv_tval_el0 = sun50i_a64_read_cntv_tval_el0,
++ .read_cntpct_el0 = sun50i_a64_read_cntpct_el0,
++ .read_cntvct_el0 = sun50i_a64_read_cntvct_el0,
++ .set_next_event_phys = erratum_set_next_event_tval_phys,
++ .set_next_event_virt = erratum_set_next_event_tval_virt,
++ },
++#endif
+ };
+
+ typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *,
--- /dev/null
+From d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Sun, 10 Feb 2019 22:51:14 +0000
+Subject: clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c upstream.
+
+When shutting down the timer, ensure that after we have stopped the
+timer any pending interrupts are cleared. This fixes a problem when
+suspending, as interrupts are disabled before the timer is stopped,
+so the timer interrupt may still be asserted, preventing the system
+entering a low power state when the wfi is executed.
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: <stable@vger.kernel.org> # v4.3+
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clocksource/exynos_mct.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/clocksource/exynos_mct.c
++++ b/drivers/clocksource/exynos_mct.c
+@@ -411,6 +411,7 @@ static int set_state_shutdown(struct clo
+
+ mevt = container_of(evt, struct mct_clock_event_device, evt);
+ exynos4_mct_tick_stop(mevt);
++ exynos4_mct_tick_clear(mevt);
+ return 0;
+ }
+
--- /dev/null
+From a5719a40aef956ba704f2aa1c7b977224d60fa96 Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Sun, 10 Feb 2019 22:51:13 +0000
+Subject: clocksource/drivers/exynos_mct: Move one-shot check from tick clear to ISR
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit a5719a40aef956ba704f2aa1c7b977224d60fa96 upstream.
+
+When a timer tick occurs and the clock is in one-shot mode, the timer
+needs to be stopped to prevent it triggering subsequent interrupts.
+Currently this code is in exynos4_mct_tick_clear(), but as it is
+only needed when an ISR occurs move it into exynos4_mct_tick_isr(),
+leaving exynos4_mct_tick_clear() just doing what its name suggests it
+should.
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: stable@vger.kernel.org # v4.3+
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clocksource/exynos_mct.c | 22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+--- a/drivers/clocksource/exynos_mct.c
++++ b/drivers/clocksource/exynos_mct.c
+@@ -388,6 +388,13 @@ static void exynos4_mct_tick_start(unsig
+ exynos4_mct_write(tmp, mevt->base + MCT_L_TCON_OFFSET);
+ }
+
++static void exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
++{
++ /* Clear the MCT tick interrupt */
++ if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1)
++ exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
++}
++
+ static int exynos4_tick_set_next_event(unsigned long cycles,
+ struct clock_event_device *evt)
+ {
+@@ -420,8 +427,11 @@ static int set_state_periodic(struct clo
+ return 0;
+ }
+
+-static void exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
++static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
+ {
++ struct mct_clock_event_device *mevt = dev_id;
++ struct clock_event_device *evt = &mevt->evt;
++
+ /*
+ * This is for supporting oneshot mode.
+ * Mct would generate interrupt periodically
+@@ -430,16 +440,6 @@ static void exynos4_mct_tick_clear(struc
+ if (!clockevent_state_periodic(&mevt->evt))
+ exynos4_mct_tick_stop(mevt);
+
+- /* Clear the MCT tick interrupt */
+- if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1)
+- exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
+-}
+-
+-static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
+-{
+- struct mct_clock_event_device *mevt = dev_id;
+- struct clock_event_device *evt = &mevt->evt;
+-
+ exynos4_mct_tick_clear(mevt);
+
+ evt->event_handler(evt);
--- /dev/null
+From 251b7aea34ba3c4d4fdfa9447695642eb8b8b098 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Thu, 3 Jan 2019 20:16:13 -0800
+Subject: crypto: pcbc - remove bogus memcpy()s with src == dest
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 251b7aea34ba3c4d4fdfa9447695642eb8b8b098 upstream.
+
+The memcpy()s in the PCBC implementation use walk->iv as both the source
+and destination, which has undefined behavior. These memcpy()'s are
+actually unneeded, because walk->iv is already used to hold the previous
+plaintext block XOR'd with the previous ciphertext block. Thus,
+walk->iv is already updated to its final value.
+
+So remove the broken and unnecessary memcpy()s.
+
+Fixes: 91652be5d1b9 ("[CRYPTO] pcbc: Add Propagated CBC template")
+Cc: <stable@vger.kernel.org> # v2.6.21+
+Cc: David Howells <dhowells@redhat.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Maxim Zhukov <mussitantesmortem@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/pcbc.c | 14 ++++----------
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+--- a/crypto/pcbc.c
++++ b/crypto/pcbc.c
+@@ -50,7 +50,7 @@ static int crypto_pcbc_encrypt_segment(s
+ unsigned int nbytes = walk->nbytes;
+ u8 *src = walk->src.virt.addr;
+ u8 *dst = walk->dst.virt.addr;
+- u8 *iv = walk->iv;
++ u8 * const iv = walk->iv;
+
+ do {
+ crypto_xor(iv, src, bsize);
+@@ -71,7 +71,7 @@ static int crypto_pcbc_encrypt_inplace(s
+ int bsize = crypto_cipher_blocksize(tfm);
+ unsigned int nbytes = walk->nbytes;
+ u8 *src = walk->src.virt.addr;
+- u8 *iv = walk->iv;
++ u8 * const iv = walk->iv;
+ u8 tmpbuf[bsize];
+
+ do {
+@@ -83,8 +83,6 @@ static int crypto_pcbc_encrypt_inplace(s
+ src += bsize;
+ } while ((nbytes -= bsize) >= bsize);
+
+- memcpy(walk->iv, iv, bsize);
+-
+ return nbytes;
+ }
+
+@@ -120,7 +118,7 @@ static int crypto_pcbc_decrypt_segment(s
+ unsigned int nbytes = walk->nbytes;
+ u8 *src = walk->src.virt.addr;
+ u8 *dst = walk->dst.virt.addr;
+- u8 *iv = walk->iv;
++ u8 * const iv = walk->iv;
+
+ do {
+ crypto_cipher_decrypt_one(tfm, dst, src);
+@@ -131,8 +129,6 @@ static int crypto_pcbc_decrypt_segment(s
+ dst += bsize;
+ } while ((nbytes -= bsize) >= bsize);
+
+- memcpy(walk->iv, iv, bsize);
+-
+ return nbytes;
+ }
+
+@@ -143,7 +139,7 @@ static int crypto_pcbc_decrypt_inplace(s
+ int bsize = crypto_cipher_blocksize(tfm);
+ unsigned int nbytes = walk->nbytes;
+ u8 *src = walk->src.virt.addr;
+- u8 *iv = walk->iv;
++ u8 * const iv = walk->iv;
+ u8 tmpbuf[bsize] __aligned(__alignof__(u32));
+
+ do {
+@@ -155,8 +151,6 @@ static int crypto_pcbc_decrypt_inplace(s
+ src += bsize;
+ } while ((nbytes -= bsize) >= bsize);
+
+- memcpy(walk->iv, iv, bsize);
+-
+ return nbytes;
+ }
+
--- /dev/null
+From 73052b0daee0b750b39af18460dfec683e4f5887 Mon Sep 17 00:00:00 2001
+From: Varad Gautam <vrd@amazon.de>
+Date: Thu, 24 Jan 2019 14:03:06 +0100
+Subject: fs/devpts: always delete dcache dentry-s in dput()
+
+From: Varad Gautam <vrd@amazon.de>
+
+commit 73052b0daee0b750b39af18460dfec683e4f5887 upstream.
+
+d_delete only unhashes an entry if it is reached with
+dentry->d_lockref.count != 1. Prior to commit 8ead9dd54716 ("devpts:
+more pty driver interface cleanups"), d_delete was called on a dentry
+from devpts_pty_kill with two references held, which would trigger the
+unhashing, and the subsequent dputs would release it.
+
+Commit 8ead9dd54716 reworked devpts_pty_kill to stop acquiring the second
+reference from d_find_alias, and the d_delete call left the dentries
+still on the hashed list without actually ever being dropped from dcache
+before explicit cleanup. This causes the number of negative dentries for
+devpts to pile up, and an `ls /dev/pts` invocation can take seconds to
+return.
+
+Provide always_delete_dentry() from simple_dentry_operations
+as .d_delete for devpts, to make the dentry be dropped from dcache.
+
+Without this cleanup, the number of dentries in /dev/pts/ can be grown
+arbitrarily as:
+
+`python -c 'import pty; pty.spawn(["ls", "/dev/pts"])'`
+
+A systemtap probe on dcache_readdir to count d_subdirs shows this count
+to increase with each pty spawn invocation above:
+
+probe kernel.function("dcache_readdir") {
+ subdirs = &@cast($file->f_path->dentry, "dentry")->d_subdirs;
+ p = subdirs;
+ p = @cast(p, "list_head")->next;
+ i = 0
+ while (p != subdirs) {
+ p = @cast(p, "list_head")->next;
+ i = i+1;
+ }
+ printf("number of dentries: %d\n", i);
+}
+
+Fixes: 8ead9dd54716 ("devpts: more pty driver interface cleanups")
+Signed-off-by: Varad Gautam <vrd@amazon.de>
+Reported-by: Zheng Wang <wanz@amazon.de>
+Reported-by: Brandon Schwartz <bsschwar@amazon.de>
+Root-caused-by: Maximilian Heyne <mheyne@amazon.de>
+Root-caused-by: Nicolas Pernas Maradei <npernas@amazon.de>
+CC: David Woodhouse <dwmw@amazon.co.uk>
+CC: Maximilian Heyne <mheyne@amazon.de>
+CC: Stefan Nuernberger <snu@amazon.de>
+CC: Amit Shah <aams@amazon.de>
+CC: Linus Torvalds <torvalds@linux-foundation.org>
+CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+CC: Al Viro <viro@ZenIV.linux.org.uk>
+CC: Christian Brauner <christian.brauner@ubuntu.com>
+CC: Eric W. Biederman <ebiederm@xmission.com>
+CC: Matthew Wilcox <willy@infradead.org>
+CC: Eric Biggers <ebiggers@google.com>
+CC: <stable@vger.kernel.org> # 4.9+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/devpts/inode.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/devpts/inode.c
++++ b/fs/devpts/inode.c
+@@ -439,6 +439,7 @@ devpts_fill_super(struct super_block *s,
+ s->s_blocksize_bits = 10;
+ s->s_magic = DEVPTS_SUPER_MAGIC;
+ s->s_op = &devpts_sops;
++ s->s_d_op = &simple_dentry_operations;
+ s->s_time_gran = 1;
+
+ error = -ENOMEM;
--- /dev/null
+From 28713169d879b67be2ef2f84dcf54905de238294 Mon Sep 17 00:00:00 2001
+From: Finn Thain <fthain@telegraphics.com.au>
+Date: Wed, 16 Jan 2019 16:23:24 +1100
+Subject: m68k: Add -ffreestanding to CFLAGS
+
+From: Finn Thain <fthain@telegraphics.com.au>
+
+commit 28713169d879b67be2ef2f84dcf54905de238294 upstream.
+
+This patch fixes a build failure when using GCC 8.1:
+
+/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock':
+block/partitions/ldm.c:153: undefined reference to `strcmp'
+
+This is caused by a new optimization which effectively replaces a
+strncmp() call with a strcmp() call. This affects a number of strncmp()
+call sites in the kernel.
+
+The entire class of optimizations is avoided with -fno-builtin, which
+gets enabled by -ffreestanding. This may avoid possible future build
+failures in case new optimizations appear in future compilers.
+
+I haven't done any performance measurements with this patch but I did
+count the function calls in a defconfig build. For example, there are now
+23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the
+other libc functions is smaller.
+
+If this harms performance we can tackle that regression by optimizing
+the call sites, ideally using semantic patches. That way, clang and ICC
+builds might benfit too.
+
+Cc: stable@vger.kernel.org
+Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2
+Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/m68k/Makefile | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/m68k/Makefile
++++ b/arch/m68k/Makefile
+@@ -58,7 +58,10 @@ cpuflags-$(CONFIG_M5206e) := $(call cc-o
+ cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200)
+
+ KBUILD_AFLAGS += $(cpuflags-y)
+-KBUILD_CFLAGS += $(cpuflags-y) -pipe
++KBUILD_CFLAGS += $(cpuflags-y)
++
++KBUILD_CFLAGS += -pipe -ffreestanding
++
+ ifdef CONFIG_MMU
+ # without -fno-strength-reduce the 53c7xx.c driver fails ;-(
+ KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2
--- /dev/null
+From de0a0decf2edfc5b0c782915f4120cf990a9bd13 Mon Sep 17 00:00:00 2001
+From: BOUGH CHEN <haibo.chen@nxp.com>
+Date: Thu, 27 Dec 2018 11:20:24 +0000
+Subject: mmc: sdhci-esdhc-imx: fix HS400 timing issue
+
+From: BOUGH CHEN <haibo.chen@nxp.com>
+
+commit de0a0decf2edfc5b0c782915f4120cf990a9bd13 upstream.
+
+Now tuning reset will be done when the timing is MMC_TIMING_LEGACY/
+MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. But for timing MMC_TIMING_MMC_HS,
+we can not do tuning reset, otherwise HS400 timing is not right.
+
+Here is the process of init HS400, first finish tuning in HS200 mode,
+then switch to HS mode and 8 bit DDR mode, finally switch to HS400
+mode. If we do tuning reset in HS mode, this will cause HS400 mode
+lost the tuning setting, which will cause CRC error.
+
+Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
+Cc: stable@vger.kernel.org # v4.12+
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card")
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-esdhc-imx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mmc/host/sdhci-esdhc-imx.c
++++ b/drivers/mmc/host/sdhci-esdhc-imx.c
+@@ -961,6 +961,7 @@ static void esdhc_set_uhs_signaling(stru
+ case MMC_TIMING_UHS_SDR25:
+ case MMC_TIMING_UHS_SDR50:
+ case MMC_TIMING_UHS_SDR104:
++ case MMC_TIMING_MMC_HS:
+ case MMC_TIMING_MMC_HS200:
+ writel(m, host->ioaddr + ESDHC_MIX_CTRL);
+ break;
--- /dev/null
+From 0ab66b3c326ef8f77dae9f528118966365757c0c Mon Sep 17 00:00:00 2001
+From: Mark Zhang <markz@nvidia.com>
+Date: Thu, 10 Jan 2019 12:11:16 +0800
+Subject: regulator: max77620: Initialize values for DT properties
+
+From: Mark Zhang <markz@nvidia.com>
+
+commit 0ab66b3c326ef8f77dae9f528118966365757c0c upstream.
+
+If regulator DT node doesn't exist, its of_parse_cb callback
+function isn't called. Then all values for DT properties are
+filled with zero. This leads to wrong register update for
+FPS and POK settings.
+
+Signed-off-by: Jinyoung Park <jinyoungp@nvidia.com>
+Signed-off-by: Mark Zhang <markz@nvidia.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/max77620-regulator.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/regulator/max77620-regulator.c
++++ b/drivers/regulator/max77620-regulator.c
+@@ -1,7 +1,7 @@
+ /*
+ * Maxim MAX77620 Regulator driver
+ *
+- * Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved.
++ * Copyright (c) 2016-2018, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Author: Mallikarjun Kasoju <mkasoju@nvidia.com>
+ * Laxman Dewangan <ldewangan@nvidia.com>
+@@ -803,6 +803,14 @@ static int max77620_regulator_probe(stru
+ rdesc = &rinfo[id].desc;
+ pmic->rinfo[id] = &max77620_regs_info[id];
+ pmic->enable_power_mode[id] = MAX77620_POWER_MODE_NORMAL;
++ pmic->reg_pdata[id].active_fps_src = -1;
++ pmic->reg_pdata[id].active_fps_pd_slot = -1;
++ pmic->reg_pdata[id].active_fps_pu_slot = -1;
++ pmic->reg_pdata[id].suspend_fps_src = -1;
++ pmic->reg_pdata[id].suspend_fps_pd_slot = -1;
++ pmic->reg_pdata[id].suspend_fps_pu_slot = -1;
++ pmic->reg_pdata[id].power_ok = -1;
++ pmic->reg_pdata[id].ramp_rate_setting = -1;
+
+ ret = max77620_read_slew_rate(pmic, id);
+ if (ret < 0)
--- /dev/null
+From 28c4f730d2a44f2591cb104091da29a38dac49fe Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Tue, 12 Feb 2019 21:51:18 +0000
+Subject: regulator: s2mpa01: Fix step values for some LDOs
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit 28c4f730d2a44f2591cb104091da29a38dac49fe upstream.
+
+The step values for some of the LDOs appears to be incorrect, resulting
+in incorrect voltages (or at least, ones which are different from the
+Samsung 3.4 vendor kernel).
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/s2mpa01.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/regulator/s2mpa01.c
++++ b/drivers/regulator/s2mpa01.c
+@@ -304,13 +304,13 @@ static const struct regulator_desc regul
+ regulator_desc_ldo(2, STEP_50_MV),
+ regulator_desc_ldo(3, STEP_50_MV),
+ regulator_desc_ldo(4, STEP_50_MV),
+- regulator_desc_ldo(5, STEP_50_MV),
++ regulator_desc_ldo(5, STEP_25_MV),
+ regulator_desc_ldo(6, STEP_25_MV),
+ regulator_desc_ldo(7, STEP_50_MV),
+ regulator_desc_ldo(8, STEP_50_MV),
+ regulator_desc_ldo(9, STEP_50_MV),
+ regulator_desc_ldo(10, STEP_50_MV),
+- regulator_desc_ldo(11, STEP_25_MV),
++ regulator_desc_ldo(11, STEP_50_MV),
+ regulator_desc_ldo(12, STEP_50_MV),
+ regulator_desc_ldo(13, STEP_50_MV),
+ regulator_desc_ldo(14, STEP_50_MV),
+@@ -321,11 +321,11 @@ static const struct regulator_desc regul
+ regulator_desc_ldo(19, STEP_50_MV),
+ regulator_desc_ldo(20, STEP_50_MV),
+ regulator_desc_ldo(21, STEP_50_MV),
+- regulator_desc_ldo(22, STEP_25_MV),
+- regulator_desc_ldo(23, STEP_25_MV),
++ regulator_desc_ldo(22, STEP_50_MV),
++ regulator_desc_ldo(23, STEP_50_MV),
+ regulator_desc_ldo(24, STEP_50_MV),
+ regulator_desc_ldo(25, STEP_50_MV),
+- regulator_desc_ldo(26, STEP_50_MV),
++ regulator_desc_ldo(26, STEP_25_MV),
+ regulator_desc_buck1_4(1),
+ regulator_desc_buck1_4(2),
+ regulator_desc_buck1_4(3),
--- /dev/null
+From 56b5d4ea778c1b0989c5cdb5406d4a488144c416 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzk@kernel.org>
+Date: Sat, 9 Feb 2019 18:14:14 +0100
+Subject: regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
+
+From: Krzysztof Kozlowski <krzk@kernel.org>
+
+commit 56b5d4ea778c1b0989c5cdb5406d4a488144c416 upstream.
+
+LDO35 uses 25 mV step, not 50 mV. Bucks 7 and 8 use 12.5 mV step
+instead of 6.25 mV. Wrong step caused over-voltage (LDO35) or
+under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420
+Arndale Octa board).
+
+Cc: <stable@vger.kernel.org>
+Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver")
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/s2mps11.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/regulator/s2mps11.c
++++ b/drivers/regulator/s2mps11.c
+@@ -376,7 +376,7 @@ static const struct regulator_desc s2mps
+ regulator_desc_s2mps11_ldo(32, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(33, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(34, STEP_50_MV),
+- regulator_desc_s2mps11_ldo(35, STEP_50_MV),
++ regulator_desc_s2mps11_ldo(35, STEP_25_MV),
+ regulator_desc_s2mps11_ldo(36, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(37, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(38, STEP_50_MV),
+@@ -386,8 +386,8 @@ static const struct regulator_desc s2mps
+ regulator_desc_s2mps11_buck1_4(4),
+ regulator_desc_s2mps11_buck5,
+ regulator_desc_s2mps11_buck67810(6, MIN_600_MV, STEP_6_25_MV),
+- regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_6_25_MV),
+- regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_6_25_MV),
++ regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_12_5_MV),
++ regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_12_5_MV),
+ regulator_desc_s2mps11_buck9,
+ regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV),
+ };
--- /dev/null
+From 8727638426b0aea59d7f904ad8ddf483f9234f88 Mon Sep 17 00:00:00 2001
+From: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Date: Thu, 14 Feb 2019 15:40:56 +0100
+Subject: s390/setup: fix early warning messages
+
+From: Martin Schwidefsky <schwidefsky@de.ibm.com>
+
+commit 8727638426b0aea59d7f904ad8ddf483f9234f88 upstream.
+
+The setup_lowcore() function creates a new prefix page for the boot CPU.
+The PSW mask for the system_call, external interrupt, i/o interrupt and
+the program check handler have the DAT bit set in this new prefix page.
+
+At the time setup_lowcore is called the system still runs without virtual
+address translation, the paging_init() function creates the kernel page
+table and loads the CR13 with the kernel ASCE.
+
+Any code between setup_lowcore() and the end of paging_init() that has
+a BUG or WARN statement will create a program check that can not be
+handled correctly as there is no kernel page table yet.
+
+To allow early WARN statements initially setup the lowcore with DAT off
+and set the DAT bit only after paging_init() has completed.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/setup.c | 32 +++++++++++++++++++++++---------
+ 1 file changed, 23 insertions(+), 9 deletions(-)
+
+--- a/arch/s390/kernel/setup.c
++++ b/arch/s390/kernel/setup.c
+@@ -300,7 +300,7 @@ early_param("vmalloc", parse_vmalloc);
+
+ void *restart_stack __section(.data);
+
+-static void __init setup_lowcore(void)
++static void __init setup_lowcore_dat_off(void)
+ {
+ struct lowcore *lc;
+
+@@ -311,19 +311,16 @@ static void __init setup_lowcore(void)
+ lc = memblock_virt_alloc_low(sizeof(*lc), sizeof(*lc));
+ lc->restart_psw.mask = PSW_KERNEL_BITS;
+ lc->restart_psw.addr = (unsigned long) restart_int_handler;
+- lc->external_new_psw.mask = PSW_KERNEL_BITS |
+- PSW_MASK_DAT | PSW_MASK_MCHECK;
++ lc->external_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK;
+ lc->external_new_psw.addr = (unsigned long) ext_int_handler;
+ lc->svc_new_psw.mask = PSW_KERNEL_BITS |
+- PSW_MASK_DAT | PSW_MASK_IO | PSW_MASK_EXT | PSW_MASK_MCHECK;
++ PSW_MASK_IO | PSW_MASK_EXT | PSW_MASK_MCHECK;
+ lc->svc_new_psw.addr = (unsigned long) system_call;
+- lc->program_new_psw.mask = PSW_KERNEL_BITS |
+- PSW_MASK_DAT | PSW_MASK_MCHECK;
++ lc->program_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK;
+ lc->program_new_psw.addr = (unsigned long) pgm_check_handler;
+ lc->mcck_new_psw.mask = PSW_KERNEL_BITS;
+ lc->mcck_new_psw.addr = (unsigned long) mcck_int_handler;
+- lc->io_new_psw.mask = PSW_KERNEL_BITS |
+- PSW_MASK_DAT | PSW_MASK_MCHECK;
++ lc->io_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK;
+ lc->io_new_psw.addr = (unsigned long) io_int_handler;
+ lc->clock_comparator = clock_comparator_max;
+ lc->kernel_stack = ((unsigned long) &init_thread_union)
+@@ -391,6 +388,17 @@ static void __init setup_lowcore(void)
+ lowcore_ptr[0] = lc;
+ }
+
++static void __init setup_lowcore_dat_on(void)
++{
++ struct lowcore *lc;
++
++ lc = lowcore_ptr[0];
++ lc->external_new_psw.mask |= PSW_MASK_DAT;
++ lc->svc_new_psw.mask |= PSW_MASK_DAT;
++ lc->program_new_psw.mask |= PSW_MASK_DAT;
++ lc->io_new_psw.mask |= PSW_MASK_DAT;
++}
++
+ static struct resource code_resource = {
+ .name = "Kernel code",
+ .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+@@ -948,7 +956,7 @@ void __init setup_arch(char **cmdline_p)
+ #endif
+
+ setup_resources();
+- setup_lowcore();
++ setup_lowcore_dat_off();
+ smp_fill_possible_mask();
+ cpu_detect_mhz_feature();
+ cpu_init();
+@@ -961,6 +969,12 @@ void __init setup_arch(char **cmdline_p)
+ */
+ paging_init();
+
++ /*
++ * After paging_init created the kernel page table, the new PSWs
++ * in lowcore can now run with DAT enabled.
++ */
++ setup_lowcore_dat_on();
++
+ /* Setup default console */
+ conmode_default();
+ set_preferred_console();
--- /dev/null
+From 3438b2c039b4bf26881786a1f3450f016d66ad11 Mon Sep 17 00:00:00 2001
+From: Halil Pasic <pasic@linux.ibm.com>
+Date: Mon, 21 Jan 2019 13:19:43 +0100
+Subject: s390/virtio: handle find on invalid queue gracefully
+
+From: Halil Pasic <pasic@linux.ibm.com>
+
+commit 3438b2c039b4bf26881786a1f3450f016d66ad11 upstream.
+
+A queue with a capacity of zero is clearly not a valid virtio queue.
+Some emulators report zero queue size if queried with an invalid queue
+index. Instead of crashing in this case let us just return -ENOENT. To
+make that work properly, let us fix the notifier cleanup logic as well.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
+Signed-off-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/virtio/virtio_ccw.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/s390/virtio/virtio_ccw.c
++++ b/drivers/s390/virtio/virtio_ccw.c
+@@ -275,6 +275,8 @@ static void virtio_ccw_drop_indicators(s
+ {
+ struct virtio_ccw_vq_info *info;
+
++ if (!vcdev->airq_info)
++ return;
+ list_for_each_entry(info, &vcdev->virtqueues, node)
+ drop_airq_indicator(info->vq, vcdev->airq_info);
+ }
+@@ -416,7 +418,7 @@ static int virtio_ccw_read_vq_conf(struc
+ ret = ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_READ_VQ_CONF);
+ if (ret)
+ return ret;
+- return vcdev->config_block->num;
++ return vcdev->config_block->num ?: -ENOENT;
+ }
+
+ static void virtio_ccw_del_vq(struct virtqueue *vq, struct ccw1 *ccw)
--- /dev/null
+From 0015437cc046e5ec2b57b00ff8312b8d432eac7c Mon Sep 17 00:00:00 2001
+From: Sagar Biradar <sagar.biradar@microchip.com>
+Date: Thu, 7 Mar 2019 23:26:41 -0800
+Subject: scsi: aacraid: Fix performance issue on logical drives
+
+From: Sagar Biradar <sagar.biradar@microchip.com>
+
+commit 0015437cc046e5ec2b57b00ff8312b8d432eac7c upstream.
+
+Fix performance issue where the queue depth for SmartIOC logical volumes is
+set to 1, and allow the usual logical volume code to be executed
+
+Fixes: a052865fe287 (aacraid: Set correct Queue Depth for HBA1000 RAW disks)
+Cc: stable@vger.kernel.org
+Signed-off-by: Sagar Biradar <Sagar.Biradar@microchip.com>
+Reviewed-by: Dave Carroll <david.carroll@microsemi.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/aacraid/linit.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/scsi/aacraid/linit.c
++++ b/drivers/scsi/aacraid/linit.c
+@@ -413,13 +413,16 @@ static int aac_slave_configure(struct sc
+ if (chn < AAC_MAX_BUSES && tid < AAC_MAX_TARGETS && aac->sa_firmware) {
+ devtype = aac->hba_map[chn][tid].devtype;
+
+- if (devtype == AAC_DEVTYPE_NATIVE_RAW)
++ if (devtype == AAC_DEVTYPE_NATIVE_RAW) {
+ depth = aac->hba_map[chn][tid].qd_limit;
+- else if (devtype == AAC_DEVTYPE_ARC_RAW)
++ set_timeout = 1;
++ goto common_config;
++ }
++ if (devtype == AAC_DEVTYPE_ARC_RAW) {
+ set_qd_dev_type = true;
+-
+- set_timeout = 1;
+- goto common_config;
++ set_timeout = 1;
++ goto common_config;
++ }
+ }
+
+ if (aac->jbod && (sdev->type == TYPE_DISK))
--- /dev/null
+From a83da8a4509d3ebfe03bb7fffce022e4d5d4764f Mon Sep 17 00:00:00 2001
+From: "Martin K. Petersen" <martin.petersen@oracle.com>
+Date: Tue, 12 Feb 2019 16:21:05 -0500
+Subject: scsi: sd: Optimal I/O size should be a multiple of physical block size
+
+From: Martin K. Petersen <martin.petersen@oracle.com>
+
+commit a83da8a4509d3ebfe03bb7fffce022e4d5d4764f upstream.
+
+It was reported that some devices report an OPTIMAL TRANSFER LENGTH of
+0xFFFF blocks. That looks bogus, especially for a device with a
+4096-byte physical block size.
+
+Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's
+reported physical block size.
+
+To make the sanity checking conditionals more readable--and to
+facilitate printing warnings--relocate the checking to a helper
+function. No functional change aside from the printks.
+
+Cc: <stable@vger.kernel.org>
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759
+Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/sd.c | 59 +++++++++++++++++++++++++++++++++++++++++++++---------
+ 1 file changed, 50 insertions(+), 9 deletions(-)
+
+--- a/drivers/scsi/sd.c
++++ b/drivers/scsi/sd.c
+@@ -3077,6 +3077,55 @@ static void sd_read_security(struct scsi
+ sdkp->security = 1;
+ }
+
++/*
++ * Determine the device's preferred I/O size for reads and writes
++ * unless the reported value is unreasonably small, large, not a
++ * multiple of the physical block size, or simply garbage.
++ */
++static bool sd_validate_opt_xfer_size(struct scsi_disk *sdkp,
++ unsigned int dev_max)
++{
++ struct scsi_device *sdp = sdkp->device;
++ unsigned int opt_xfer_bytes =
++ logical_to_bytes(sdp, sdkp->opt_xfer_blocks);
++
++ if (sdkp->opt_xfer_blocks > dev_max) {
++ sd_first_printk(KERN_WARNING, sdkp,
++ "Optimal transfer size %u logical blocks " \
++ "> dev_max (%u logical blocks)\n",
++ sdkp->opt_xfer_blocks, dev_max);
++ return false;
++ }
++
++ if (sdkp->opt_xfer_blocks > SD_DEF_XFER_BLOCKS) {
++ sd_first_printk(KERN_WARNING, sdkp,
++ "Optimal transfer size %u logical blocks " \
++ "> sd driver limit (%u logical blocks)\n",
++ sdkp->opt_xfer_blocks, SD_DEF_XFER_BLOCKS);
++ return false;
++ }
++
++ if (opt_xfer_bytes < PAGE_SIZE) {
++ sd_first_printk(KERN_WARNING, sdkp,
++ "Optimal transfer size %u bytes < " \
++ "PAGE_SIZE (%u bytes)\n",
++ opt_xfer_bytes, (unsigned int)PAGE_SIZE);
++ return false;
++ }
++
++ if (opt_xfer_bytes & (sdkp->physical_block_size - 1)) {
++ sd_first_printk(KERN_WARNING, sdkp,
++ "Optimal transfer size %u bytes not a " \
++ "multiple of physical block size (%u bytes)\n",
++ opt_xfer_bytes, sdkp->physical_block_size);
++ return false;
++ }
++
++ sd_first_printk(KERN_INFO, sdkp, "Optimal transfer size %u bytes\n",
++ opt_xfer_bytes);
++ return true;
++}
++
+ /**
+ * sd_revalidate_disk - called the first time a new disk is seen,
+ * performs disk spin up, read_capacity, etc.
+@@ -3146,15 +3195,7 @@ static int sd_revalidate_disk(struct gen
+ dev_max = min_not_zero(dev_max, sdkp->max_xfer_blocks);
+ q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max);
+
+- /*
+- * Determine the device's preferred I/O size for reads and writes
+- * unless the reported value is unreasonably small, large, or
+- * garbage.
+- */
+- if (sdkp->opt_xfer_blocks &&
+- sdkp->opt_xfer_blocks <= dev_max &&
+- sdkp->opt_xfer_blocks <= SD_DEF_XFER_BLOCKS &&
+- logical_to_bytes(sdp, sdkp->opt_xfer_blocks) >= PAGE_SIZE) {
++ if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
+ q->limits.io_opt = logical_to_bytes(sdp, sdkp->opt_xfer_blocks);
+ rw_max = logical_to_sectors(sdp, sdkp->opt_xfer_blocks);
+ } else
--- /dev/null
+From 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bvanassche@acm.org>
+Date: Fri, 25 Jan 2019 10:34:56 -0800
+Subject: scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+commit 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 upstream.
+
+When using SCSI passthrough in combination with the iSCSI target driver
+then cmd->t_state_lock may be obtained from interrupt context. Hence, all
+code that obtains cmd->t_state_lock from thread context must disable
+interrupts first. This patch avoids that lockdep reports the following:
+
+WARNING: inconsistent lock state
+4.18.0-dbg+ #1 Not tainted
+--------------------------------
+inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
+iscsi_ttx/1800 [HC1[1]:SC0[2]:HE0:SE0] takes:
+000000006e7b0ceb (&(&cmd->t_state_lock)->rlock){?...}, at: target_complete_cmd+0x47/0x2c0 [target_core_mod]
+{HARDIRQ-ON-W} state was registered at:
+ lock_acquire+0xd2/0x260
+ _raw_spin_lock+0x32/0x50
+ iscsit_close_connection+0x97e/0x1020 [iscsi_target_mod]
+ iscsit_take_action_for_connection_exit+0x108/0x200 [iscsi_target_mod]
+ iscsi_target_rx_thread+0x180/0x190 [iscsi_target_mod]
+ kthread+0x1cf/0x1f0
+ ret_from_fork+0x24/0x30
+irq event stamp: 1281
+hardirqs last enabled at (1279): [<ffffffff970ade79>] __local_bh_enable_ip+0xa9/0x160
+hardirqs last disabled at (1281): [<ffffffff97a008a5>] interrupt_entry+0xb5/0xd0
+softirqs last enabled at (1278): [<ffffffff977cd9a1>] lock_sock_nested+0x51/0xc0
+softirqs last disabled at (1280): [<ffffffffc07a6e04>] ip6_finish_output2+0x124/0xe40 [ipv6]
+
+other info that might help us debug this:
+Possible unsafe locking scenario:
+
+ CPU0
+ ----
+ lock(&(&cmd->t_state_lock)->rlock);
+ <Interrupt>
+ lock(&(&cmd->t_state_lock)->rlock);
+
+---
+ drivers/target/iscsi/iscsi_target.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/target/iscsi/iscsi_target.c
++++ b/drivers/target/iscsi/iscsi_target.c
+@@ -4077,9 +4077,9 @@ static void iscsit_release_commands_from
+ struct se_cmd *se_cmd = &cmd->se_cmd;
+
+ if (se_cmd->se_tfo != NULL) {
+- spin_lock(&se_cmd->t_state_lock);
++ spin_lock_irq(&se_cmd->t_state_lock);
+ se_cmd->transport_state |= CMD_T_FABRIC_STOP;
+- spin_unlock(&se_cmd->t_state_lock);
++ spin_unlock_irq(&se_cmd->t_state_lock);
+ }
+ }
+ spin_unlock_bh(&conn->cmd_lock);
--- /dev/null
+From 3722e6a52174d7c3a00e6f5efd006ca093f346c1 Mon Sep 17 00:00:00 2001
+From: Felipe Franciosi <felipe@nutanix.com>
+Date: Wed, 27 Feb 2019 16:10:34 +0000
+Subject: scsi: virtio_scsi: don't send sc payload with tmfs
+
+From: Felipe Franciosi <felipe@nutanix.com>
+
+commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream.
+
+The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of
+device-readable records and a single device-writable response entry:
+
+ struct virtio_scsi_ctrl_tmf
+ {
+ // Device-readable part
+ le32 type;
+ le32 subtype;
+ u8 lun[8];
+ le64 id;
+ // Device-writable part
+ u8 response;
+ }
+
+The above should be organised as two descriptor entries (or potentially
+more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64
+id" or after "u8 response".
+
+The Linux driver doesn't respect that, with virtscsi_abort() and
+virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf(). It
+results in the original scsi command payload (or writable buffers) added to
+the tmf.
+
+This fixes the problem by leaving cmd->sc zeroed out, which makes
+virtscsi_kick_cmd() add the tmf to the control vq without any payload.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
+Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/virtio_scsi.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/scsi/virtio_scsi.c
++++ b/drivers/scsi/virtio_scsi.c
+@@ -638,7 +638,6 @@ static int virtscsi_device_reset(struct
+ return FAILED;
+
+ memset(cmd, 0, sizeof(*cmd));
+- cmd->sc = sc;
+ cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
+ .type = VIRTIO_SCSI_T_TMF,
+ .subtype = cpu_to_virtio32(vscsi->vdev,
+@@ -697,7 +696,6 @@ static int virtscsi_abort(struct scsi_cm
+ return FAILED;
+
+ memset(cmd, 0, sizeof(*cmd));
+- cmd->sc = sc;
+ cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
+ .type = VIRTIO_SCSI_T_TMF,
+ .subtype = VIRTIO_SCSI_T_TMF_ABORT_TASK,
tracing-do-not-free-iter-trace-in-fail-path-of-tracing_open_pipe.patch
xen-fix-dom0-boot-on-huge-systems.patch
acpi-device_sysfs-avoid-of-modalias-creation-for-removed-device.patch
+mmc-sdhci-esdhc-imx-fix-hs400-timing-issue.patch
+spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch
+spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch
+regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch
+regulator-max77620-initialize-values-for-dt-properties.patch
+regulator-s2mpa01-fix-step-values-for-some-ldos.patch
+clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch
+clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch
+clocksource-drivers-arch_timer-workaround-for-allwinner-a64-timer-instability.patch
+s390-setup-fix-early-warning-messages.patch
+s390-virtio-handle-find-on-invalid-queue-gracefully.patch
+scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch
+scsi-aacraid-fix-performance-issue-on-logical-drives.patch
+scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch
+scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch
+fs-devpts-always-delete-dcache-dentry-s-in-dput.patch
+splice-don-t-merge-into-linked-buffers.patch
+m68k-add-ffreestanding-to-cflags.patch
+btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch
+btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch
+btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch
+crypto-pcbc-remove-bogus-memcpy-s-with-src-dest.patch
--- /dev/null
+From ef070b4e4aa25bb5f8632ad196644026c11903bf Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Tue, 19 Feb 2019 23:21:28 +0300
+Subject: spi: pxa2xx: Setup maximum supported DMA transfer length
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit ef070b4e4aa25bb5f8632ad196644026c11903bf upstream.
+
+When the commit b6ced294fb61
+
+ ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
+
+switches to SPI core provided DMA helpers, it missed to setup maximum
+supported DMA transfer length for the controller and thus users
+mistakenly try to send more data than supported with the following
+warning:
+
+ ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536
+
+Setup maximum supported DMA transfer length in order to make users know
+the limit.
+
+Fixes: b6ced294fb61 ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-pxa2xx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -1698,6 +1698,7 @@ static int pxa2xx_spi_probe(struct platf
+ platform_info->enable_dma = false;
+ } else {
+ master->can_dma = pxa2xx_spi_can_dma;
++ master->max_dma_len = MAX_DMA_LEN;
+ }
+ }
+
--- /dev/null
+From 673c865efbdc5fec3cc525c46d71844d42c60072 Mon Sep 17 00:00:00 2001
+From: Vignesh R <vigneshr@ti.com>
+Date: Tue, 29 Jan 2019 13:14:22 +0530
+Subject: spi: ti-qspi: Fix mmap read when more than one CS in use
+
+From: Vignesh R <vigneshr@ti.com>
+
+commit 673c865efbdc5fec3cc525c46d71844d42c60072 upstream.
+
+Commit 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") has
+has got order of parameter wrong when calling regmap_update_bits() to
+select CS for mmap access. Mask and value arguments are interchanged.
+Code will work on a system with single slave, but fails when more than
+one CS is in use. Fix this by correcting the order of parameters when
+calling regmap_update_bits().
+
+Fixes: 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vignesh R <vigneshr@ti.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-ti-qspi.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/spi/spi-ti-qspi.c
++++ b/drivers/spi/spi-ti-qspi.c
+@@ -490,8 +490,8 @@ static void ti_qspi_enable_memory_map(st
+ ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+ if (qspi->ctrl_base) {
+ regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
+- MEM_CS_EN(spi->chip_select),
+- MEM_CS_MASK);
++ MEM_CS_MASK,
++ MEM_CS_EN(spi->chip_select));
+ }
+ qspi->mmap_enabled = true;
+ }
+@@ -503,7 +503,7 @@ static void ti_qspi_disable_memory_map(s
+ ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
+ if (qspi->ctrl_base)
+ regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
+- 0, MEM_CS_MASK);
++ MEM_CS_MASK, 0);
+ qspi->mmap_enabled = false;
+ }
+
--- /dev/null
+From a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 23 Jan 2019 15:19:17 +0100
+Subject: splice: don't merge into linked buffers
+
+From: Jann Horn <jannh@google.com>
+
+commit a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 upstream.
+
+Before this patch, it was possible for two pipes to affect each other after
+data had been transferred between them with tee():
+
+============
+$ cat tee_test.c
+
+int main(void) {
+ int pipe_a[2];
+ if (pipe(pipe_a)) err(1, "pipe");
+ int pipe_b[2];
+ if (pipe(pipe_b)) err(1, "pipe");
+ if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write");
+ if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee");
+ if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");
+
+ char buf[5];
+ if (read(pipe_a[0], buf, 4) != 4) err(1, "read");
+ buf[4] = 0;
+ printf("got back: '%s'\n", buf);
+}
+$ gcc -o tee_test tee_test.c
+$ ./tee_test
+got back: 'abxx'
+$
+============
+
+As suggested by Al Viro, fix it by creating a separate type for
+non-mergeable pipe buffers, then changing the types of buffers in
+splice_pipe_to_pipe() and link_pipe().
+
+Cc: <stable@vger.kernel.org>
+Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing")
+Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()")
+Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/pipe.c | 14 ++++++++++++++
+ fs/splice.c | 4 ++++
+ include/linux/pipe_fs_i.h | 1 +
+ 3 files changed, 19 insertions(+)
+
+--- a/fs/pipe.c
++++ b/fs/pipe.c
+@@ -239,6 +239,14 @@ static const struct pipe_buf_operations
+ .get = generic_pipe_buf_get,
+ };
+
++static const struct pipe_buf_operations anon_pipe_buf_nomerge_ops = {
++ .can_merge = 0,
++ .confirm = generic_pipe_buf_confirm,
++ .release = anon_pipe_buf_release,
++ .steal = anon_pipe_buf_steal,
++ .get = generic_pipe_buf_get,
++};
++
+ static const struct pipe_buf_operations packet_pipe_buf_ops = {
+ .can_merge = 0,
+ .confirm = generic_pipe_buf_confirm,
+@@ -247,6 +255,12 @@ static const struct pipe_buf_operations
+ .get = generic_pipe_buf_get,
+ };
+
++void pipe_buf_mark_unmergeable(struct pipe_buffer *buf)
++{
++ if (buf->ops == &anon_pipe_buf_ops)
++ buf->ops = &anon_pipe_buf_nomerge_ops;
++}
++
+ static ssize_t
+ pipe_read(struct kiocb *iocb, struct iov_iter *to)
+ {
+--- a/fs/splice.c
++++ b/fs/splice.c
+@@ -1580,6 +1580,8 @@ retry:
+ */
+ obuf->flags &= ~PIPE_BUF_FLAG_GIFT;
+
++ pipe_buf_mark_unmergeable(obuf);
++
+ obuf->len = len;
+ opipe->nrbufs++;
+ ibuf->offset += obuf->len;
+@@ -1654,6 +1656,8 @@ static int link_pipe(struct pipe_inode_i
+ */
+ obuf->flags &= ~PIPE_BUF_FLAG_GIFT;
+
++ pipe_buf_mark_unmergeable(obuf);
++
+ if (obuf->len > len)
+ obuf->len = len;
+
+--- a/include/linux/pipe_fs_i.h
++++ b/include/linux/pipe_fs_i.h
+@@ -183,6 +183,7 @@ void generic_pipe_buf_get(struct pipe_in
+ int generic_pipe_buf_confirm(struct pipe_inode_info *, struct pipe_buffer *);
+ int generic_pipe_buf_steal(struct pipe_inode_info *, struct pipe_buffer *);
+ void generic_pipe_buf_release(struct pipe_inode_info *, struct pipe_buffer *);
++void pipe_buf_mark_unmergeable(struct pipe_buffer *buf);
+
+ extern const struct pipe_buf_operations nosteal_pipe_buf_ops;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
