--- /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
+@@ -6287,10 +6287,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(root->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
+@@ -3106,11 +3106,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 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
+@@ -402,6 +402,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
+@@ -379,6 +379,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)
+ {
+@@ -411,8 +418,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
+@@ -421,16 +431,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
+@@ -52,7 +52,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);
+@@ -76,7 +76,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 {
+@@ -89,8 +89,6 @@ static int crypto_pcbc_encrypt_inplace(s
+ src += bsize;
+ } while ((nbytes -= bsize) >= bsize);
+
+- memcpy(walk->iv, iv, bsize);
+-
+ return nbytes;
+ }
+
+@@ -130,7 +128,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 {
+ fn(crypto_cipher_tfm(tfm), dst, src);
+@@ -142,8 +140,6 @@ static int crypto_pcbc_decrypt_segment(s
+ dst += bsize;
+ } while ((nbytes -= bsize) >= bsize);
+
+- memcpy(walk->iv, iv, bsize);
+-
+ return nbytes;
+ }
+
+@@ -156,7 +152,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];
+
+ do {
+@@ -169,8 +165,6 @@ static int crypto_pcbc_decrypt_inplace(s
+ src += bsize;
+ } while ((nbytes -= bsize) >= bsize);
+
+- memcpy(walk->iv, iv, bsize);
+-
+ return nbytes;
+ }
+
--- /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
+@@ -59,7 +59,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 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
+@@ -303,13 +303,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),
+@@ -320,11 +320,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
+@@ -372,7 +372,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),
+@@ -382,8 +382,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 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
+@@ -283,6 +283,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);
+ }
+@@ -423,7 +425,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 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
+@@ -4232,9 +4232,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
+@@ -692,7 +692,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,
+@@ -751,7 +750,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,
cifs-fix-read-after-write-for-files-with-read-caching.patch
tracing-do-not-free-iter-trace-in-fail-path-of-tracing_open_pipe.patch
acpi-device_sysfs-avoid-of-modalias-creation-for-removed-device.patch
+regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.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
+s390-virtio-handle-find-on-invalid-queue-gracefully.patch
+scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch
+scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch
+m68k-add-ffreestanding-to-cflags.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
projects / thirdparty / kernel / stable-queue.git / commitdiff
