--- /dev/null
+From f18ddc13af981ce3c7b7f26925f099e7c6929aba Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+Date: Tue, 3 Sep 2019 14:18:02 -0300
+Subject: alarmtimer: Use EOPNOTSUPP instead of ENOTSUPP
+
+From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+
+commit f18ddc13af981ce3c7b7f26925f099e7c6929aba upstream.
+
+ENOTSUPP is not supposed to be returned to userspace. This was found on an
+OpenPower machine, where the RTC does not support set_alarm.
+
+On that system, a clock_nanosleep(CLOCK_REALTIME_ALARM, ...) results in
+"524 Unknown error 524"
+
+Replace it with EOPNOTSUPP which results in the expected "95 Operation not
+supported" error.
+
+Fixes: 1c6b39ad3f01 (alarmtimers: Return -ENOTSUPP if no RTC device is present)
+Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20190903171802.28314-1-cascardo@canonical.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/time/alarmtimer.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/kernel/time/alarmtimer.c
++++ b/kernel/time/alarmtimer.c
+@@ -676,7 +676,7 @@ static int alarm_timer_create(struct k_i
+ enum alarmtimer_type type;
+
+ if (!alarmtimer_get_rtcdev())
+- return -ENOTSUPP;
++ return -EOPNOTSUPP;
+
+ if (!capable(CAP_WAKE_ALARM))
+ return -EPERM;
+@@ -794,7 +794,7 @@ static int alarm_timer_nsleep(const cloc
+ int ret = 0;
+
+ if (!alarmtimer_get_rtcdev())
+- return -ENOTSUPP;
++ return -EOPNOTSUPP;
+
+ if (flags & ~TIMER_ABSTIME)
+ return -EINVAL;
--- /dev/null
+From 16986074035cc0205472882a00d404ed9d213313 Mon Sep 17 00:00:00 2001
+From: Lihua Yao <ylhuajnu@outlook.com>
+Date: Sat, 7 Sep 2019 03:30:01 +0000
+Subject: ARM: samsung: Fix system restart on S3C6410
+
+From: Lihua Yao <ylhuajnu@outlook.com>
+
+commit 16986074035cc0205472882a00d404ed9d213313 upstream.
+
+S3C6410 system restart is triggered by watchdog reset.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 9f55342cc2de ("ARM: dts: s3c64xx: Fix infinite interrupt in soft mode")
+Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/plat-samsung/watchdog-reset.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/plat-samsung/watchdog-reset.c
++++ b/arch/arm/plat-samsung/watchdog-reset.c
+@@ -62,6 +62,7 @@ void samsung_wdt_reset(void)
+ #ifdef CONFIG_OF
+ static const struct of_device_id s3c2410_wdt_match[] = {
+ { .compatible = "samsung,s3c2410-wdt" },
++ { .compatible = "samsung,s3c6410-wdt" },
+ {},
+ };
+
--- /dev/null
+From b7005d4ef4f3aa2dc24019ffba03a322557ac43d Mon Sep 17 00:00:00 2001
+From: Luis Araneda <luaraneda@gmail.com>
+Date: Thu, 8 Aug 2019 08:52:43 -0400
+Subject: ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
+
+From: Luis Araneda <luaraneda@gmail.com>
+
+commit b7005d4ef4f3aa2dc24019ffba03a322557ac43d upstream.
+
+This fixes a kernel panic on memcpy when
+FORTIFY_SOURCE is enabled.
+
+The initial smp implementation on commit aa7eb2bb4e4a
+("arm: zynq: Add smp support")
+used memcpy, which worked fine until commit ee333554fed5
+("ARM: 8749/1: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE")
+enabled overflow checks at runtime, producing a read
+overflow panic.
+
+The computed size of memcpy args are:
+- p_size (dst): 4294967295 = (size_t) -1
+- q_size (src): 1
+- size (len): 8
+
+Additionally, the memory is marked as __iomem, so one of
+the memcpy_* functions should be used for read/write.
+
+Fixes: aa7eb2bb4e4a ("arm: zynq: Add smp support")
+Signed-off-by: Luis Araneda <luaraneda@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Michal Simek <michal.simek@xilinx.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-zynq/platsmp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/mach-zynq/platsmp.c
++++ b/arch/arm/mach-zynq/platsmp.c
+@@ -65,7 +65,7 @@ int zynq_cpun_start(u32 address, int cpu
+ * 0x4: Jump by mov instruction
+ * 0x8: Jumping address
+ */
+- memcpy((__force void *)zero, &zynq_secondary_trampoline,
++ memcpy_toio(zero, &zynq_secondary_trampoline,
+ trampoline_size);
+ writel(address, zero + trampoline_size);
+
--- /dev/null
+From 03e61929c0d227ed3e1c322fc3804216ea298b7e Mon Sep 17 00:00:00 2001
+From: Shawn Lin <shawn.lin@rock-chips.com>
+Date: Fri, 30 Aug 2019 08:26:47 +0800
+Subject: arm64: dts: rockchip: limit clock rate of MMC controllers for RK3328
+
+From: Shawn Lin <shawn.lin@rock-chips.com>
+
+commit 03e61929c0d227ed3e1c322fc3804216ea298b7e upstream.
+
+150MHz is a fundamental limitation of RK3328 Soc, w/o this limitation,
+eMMC, for instance, will run into 200MHz clock rate in HS200 mode, which
+makes the RK3328 boards not always boot properly. By adding it in
+rk3328.dtsi would also obviate the worry of missing it when adding new
+boards.
+
+Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs")
+Cc: stable@vger.kernel.org
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: Liang Chen <cl@rock-chips.com>
+Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -708,6 +708,7 @@
+ <&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+ fifo-depth = <0x100>;
++ max-frequency = <150000000>;
+ status = "disabled";
+ };
+
+@@ -719,6 +720,7 @@
+ <&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+ fifo-depth = <0x100>;
++ max-frequency = <150000000>;
+ status = "disabled";
+ };
+
+@@ -730,6 +732,7 @@
+ <&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+ fifo-depth = <0x100>;
++ max-frequency = <150000000>;
+ status = "disabled";
+ };
+
--- /dev/null
+From 51696d346c49c6cf4f29e9b20d6e15832a2e3408 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Thu, 22 Aug 2019 15:03:45 +0100
+Subject: arm64: tlb: Ensure we execute an ISB following walk cache invalidation
+
+From: Will Deacon <will@kernel.org>
+
+commit 51696d346c49c6cf4f29e9b20d6e15832a2e3408 upstream.
+
+05f2d2f83b5a ("arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable")
+added a new TLB invalidation helper which is used when freeing
+intermediate levels of page table used for kernel mappings, but is
+missing the required ISB instruction after completion of the TLBI
+instruction.
+
+Add the missing barrier.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 05f2d2f83b5a ("arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable")
+Reviewed-by: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/tlbflush.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm64/include/asm/tlbflush.h
++++ b/arch/arm64/include/asm/tlbflush.h
+@@ -224,6 +224,7 @@ static inline void __flush_tlb_kernel_pg
+
+ __tlbi(vaae1is, addr);
+ dsb(ish);
++ isb();
+ }
+ #endif
+
--- /dev/null
+From 810f3b860850148788fc1ed8a6f5f807199fed65 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?=
+ <amadeuszx.slawinski@intel.com>
+Date: Tue, 27 Aug 2019 16:17:08 +0200
+Subject: ASoC: Intel: Fix use of potentially uninitialized variable
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
+
+commit 810f3b860850148788fc1ed8a6f5f807199fed65 upstream.
+
+If ipc->ops.reply_msg_match is NULL, we may end up using uninitialized
+mask value.
+
+reported by smatch:
+sound/soc/intel/common/sst-ipc.c:266 sst_ipc_reply_find_msg() error: uninitialized symbol 'mask'.
+
+Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
+Link: https://lore.kernel.org/r/20190827141712.21015-3-amadeuszx.slawinski@linux.intel.com
+Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@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>
+
+---
+ sound/soc/intel/common/sst-ipc.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/soc/intel/common/sst-ipc.c
++++ b/sound/soc/intel/common/sst-ipc.c
+@@ -231,6 +231,8 @@ struct ipc_message *sst_ipc_reply_find_m
+
+ if (ipc->ops.reply_msg_match != NULL)
+ header = ipc->ops.reply_msg_match(header, &mask);
++ else
++ mask = (u64)-1;
+
+ if (list_empty(&ipc->rx_list)) {
+ dev_err(ipc->dev, "error: rx list empty but received 0x%llx\n",
--- /dev/null
+From 855a06da37a773fd073d51023ac9d07988c87da8 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?=
+ <amadeuszx.slawinski@intel.com>
+Date: Tue, 27 Aug 2019 16:17:12 +0200
+Subject: ASoC: Intel: NHLT: Fix debug print format
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
+
+commit 855a06da37a773fd073d51023ac9d07988c87da8 upstream.
+
+oem_table_id is 8 chars long, so we need to limit it, otherwise it
+may print some unprintable characters into dmesg.
+
+Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
+Link: https://lore.kernel.org/r/20190827141712.21015-7-amadeuszx.slawinski@linux.intel.com
+Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@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>
+
+---
+ sound/soc/intel/skylake/skl-nhlt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/soc/intel/skylake/skl-nhlt.c
++++ b/sound/soc/intel/skylake/skl-nhlt.c
+@@ -231,7 +231,7 @@ int skl_nhlt_update_topology_bin(struct
+ struct hdac_bus *bus = skl_to_bus(skl);
+ struct device *dev = bus->dev;
+
+- dev_dbg(dev, "oem_id %.6s, oem_table_id %8s oem_revision %d\n",
++ dev_dbg(dev, "oem_id %.6s, oem_table_id %.8s oem_revision %d\n",
+ nhlt->header.oem_id, nhlt->header.oem_table_id,
+ nhlt->header.oem_revision);
+
--- /dev/null
+From 17d29ff98fd4b70e9ccdac5e95e18a087e2737ef Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?=
+ <amadeuszx.slawinski@intel.com>
+Date: Tue, 27 Aug 2019 16:17:07 +0200
+Subject: ASoC: Intel: Skylake: Use correct function to access iomem space
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
+
+commit 17d29ff98fd4b70e9ccdac5e95e18a087e2737ef upstream.
+
+For copying from __iomem, we should use __ioread32_copy.
+
+reported by sparse:
+sound/soc/intel/skylake/skl-debug.c:437:34: warning: incorrect type in argument 1 (different address spaces)
+sound/soc/intel/skylake/skl-debug.c:437:34: expected void [noderef] <asn:2> *to
+sound/soc/intel/skylake/skl-debug.c:437:34: got unsigned char *
+sound/soc/intel/skylake/skl-debug.c:437:51: warning: incorrect type in argument 2 (different address spaces)
+sound/soc/intel/skylake/skl-debug.c:437:51: expected void const *from
+sound/soc/intel/skylake/skl-debug.c:437:51: got void [noderef] <asn:2> *[assigned] fw_reg_addr
+
+Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@intel.com>
+Link: https://lore.kernel.org/r/20190827141712.21015-2-amadeuszx.slawinski@linux.intel.com
+Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@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>
+
+---
+ sound/soc/intel/skylake/skl-debug.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/soc/intel/skylake/skl-debug.c
++++ b/sound/soc/intel/skylake/skl-debug.c
+@@ -196,7 +196,7 @@ static ssize_t fw_softreg_read(struct fi
+ memset(d->fw_read_buff, 0, FW_REG_BUF);
+
+ if (w0_stat_sz > 0)
+- __iowrite32_copy(d->fw_read_buff, fw_reg_addr, w0_stat_sz >> 2);
++ __ioread32_copy(d->fw_read_buff, fw_reg_addr, w0_stat_sz >> 2);
+
+ for (offset = 0; offset < FW_REG_SIZE; offset += 16) {
+ ret += snprintf(tmp + ret, FW_REG_BUF - ret, "%#.4x: ", offset);
--- /dev/null
+From 7be3cb019db1cbd5fd5ffe6d64a23fefa4b6f229 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Thu, 26 Sep 2019 10:15:25 -0700
+Subject: binfmt_elf: Do not move brk for INTERP-less ET_EXEC
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 7be3cb019db1cbd5fd5ffe6d64a23fefa4b6f229 upstream.
+
+When brk was moved for binaries without an interpreter, it should have
+been limited to ET_DYN only. In other words, the special case was an
+ET_DYN that lacks an INTERP, not just an executable that lacks INTERP.
+The bug manifested for giant static executables, where the brk would end
+up in the middle of the text area on 32-bit architectures.
+
+Reported-and-tested-by: Richard Kojedzinszky <richard@kojedz.in>
+Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/binfmt_elf.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/binfmt_elf.c
++++ b/fs/binfmt_elf.c
+@@ -1144,7 +1144,8 @@ static int load_elf_binary(struct linux_
+ * (since it grows up, and may collide early with the stack
+ * growing down), and into the unused ELF_ET_DYN_BASE region.
+ */
+- if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) && !interpreter)
++ if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) &&
++ loc->elf_ex.e_type == ET_DYN && !interpreter)
+ current->mm->brk = current->mm->start_brk =
+ ELF_ET_DYN_BASE;
+
--- /dev/null
+From 14e3cdbb00a885eedc95c0cf8eda8fe28d26d6b4 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Wed, 19 Jun 2019 10:24:17 -0300
+Subject: media: don't drop front-end reference count for ->detach
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 14e3cdbb00a885eedc95c0cf8eda8fe28d26d6b4 upstream.
+
+A bugfix introduce a link failure in configurations without CONFIG_MODULES:
+
+In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:0:
+drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach':
+drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 'stb0899_attach' being applied to a already existing, static definition
+
+The problem is that the !IS_REACHABLE() declaration of stb0899_attach()
+is a 'static inline' definition that clashes with the weak definition.
+
+I further observed that the bugfix was only done for one of the five users
+of stb0899_attach(), the other four still have the problem. This reverts
+the bugfix and instead addresses the problem by not dropping the reference
+count when calling '->detach()', instead we call this function directly
+in dvb_frontend_put() before dropping the kref on the front-end.
+
+I first submitted this in early 2018, and after some discussion it
+was apparently discarded. While there is a long-term plan in place,
+that plan is obviously not nearing completion yet, and the current
+kernel is still broken unless this patch is applied.
+
+Link: https://patchwork.kernel.org/patch/10140175/
+Link: https://patchwork.linuxtv.org/patch/54831/
+
+Cc: Max Kellermann <max.kellermann@gmail.com>
+Cc: Wolfgang Rohdewald <wolfgang@rohdewald.de>
+Cc: stable@vger.kernel.org
+Fixes: f686c14364ad ("[media] stb0899: move code to "detach" callback")
+Fixes: 6cdeaed3b142 ("media: dvb_usb_pctv452e: module refcount changes were unbalanced")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/dvb-core/dvb_frontend.c | 4 +++-
+ drivers/media/usb/dvb-usb/pctv452e.c | 8 --------
+ 2 files changed, 3 insertions(+), 9 deletions(-)
+
+--- a/drivers/media/dvb-core/dvb_frontend.c
++++ b/drivers/media/dvb-core/dvb_frontend.c
+@@ -164,6 +164,9 @@ static void dvb_frontend_free(struct kre
+
+ static void dvb_frontend_put(struct dvb_frontend *fe)
+ {
++ /* call detach before dropping the reference count */
++ if (fe->ops.detach)
++ fe->ops.detach(fe);
+ /*
+ * Check if the frontend was registered, as otherwise
+ * kref was not initialized yet.
+@@ -3035,7 +3038,6 @@ void dvb_frontend_detach(struct dvb_fron
+ dvb_frontend_invoke_release(fe, fe->ops.release_sec);
+ dvb_frontend_invoke_release(fe, fe->ops.tuner_ops.release);
+ dvb_frontend_invoke_release(fe, fe->ops.analog_ops.release);
+- dvb_frontend_invoke_release(fe, fe->ops.detach);
+ dvb_frontend_put(fe);
+ }
+ EXPORT_SYMBOL(dvb_frontend_detach);
+--- a/drivers/media/usb/dvb-usb/pctv452e.c
++++ b/drivers/media/usb/dvb-usb/pctv452e.c
+@@ -913,14 +913,6 @@ static int pctv452e_frontend_attach(stru
+ &a->dev->i2c_adap);
+ if (!a->fe_adap[0].fe)
+ return -ENODEV;
+-
+- /*
+- * dvb_frontend will call dvb_detach for both stb0899_detach
+- * and stb0899_release but we only do dvb_attach(stb0899_attach).
+- * Increment the module refcount instead.
+- */
+- symbol_get(stb0899_attach);
+-
+ if ((dvb_attach(lnbp22_attach, a->fe_adap[0].fe,
+ &a->dev->i2c_adap)) == NULL)
+ err("Cannot attach lnbp22\n");
--- /dev/null
+From 7e0bb5828311f811309bed5749528ca04992af2f Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Sun, 18 Aug 2019 12:03:23 -0300
+Subject: media: sn9c20x: Add MSI MS-1039 laptop to flip_dmi_table
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 7e0bb5828311f811309bed5749528ca04992af2f upstream.
+
+Like a bunch of other MSI laptops the MS-1039 uses a 0c45:627b
+SN9C201 + OV7660 webcam which is mounted upside down.
+
+Add it to the sn9c20x flip_dmi_table to deal with this.
+
+Cc: stable@vger.kernel.org
+Reported-by: Rui Salvaterra <rsalvaterra@gmail.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/usb/gspca/sn9c20x.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/media/usb/gspca/sn9c20x.c
++++ b/drivers/media/usb/gspca/sn9c20x.c
+@@ -133,6 +133,13 @@ static const struct dmi_system_id flip_d
+ }
+ },
+ {
++ .ident = "MSI MS-1039",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "MICRO-STAR INT'L CO.,LTD."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "MS-1039"),
++ }
++ },
++ {
+ .ident = "MSI MS-1632",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "MSI"),
--- /dev/null
+From 55576cf1853798e86f620766e23b604c9224c19c Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@kernel.org>
+Date: Wed, 4 Sep 2019 13:42:50 +0100
+Subject: regulator: Defer init completion for a while after late_initcall
+
+From: Mark Brown <broonie@kernel.org>
+
+commit 55576cf1853798e86f620766e23b604c9224c19c upstream.
+
+The kernel has no way of knowing when we have finished instantiating
+drivers, between deferred probe and systems that build key drivers as
+modules we might be doing this long after userspace has booted. This has
+always been a bit of an issue with regulator_init_complete since it can
+power off hardware that's not had it's driver loaded which can result in
+user visible effects, the main case is powering off displays. Practically
+speaking it's not been an issue in real systems since most systems that
+use the regulator API are embedded and build in key drivers anyway but
+with Arm laptops coming on the market it's becoming more of an issue so
+let's do something about it.
+
+In the absence of any better idea just defer the powering off for 30s
+after late_initcall(), this is obviously a hack but it should mask the
+issue for now and it's no more arbitrary than late_initcall() itself.
+Ideally we'd have some heuristics to detect if we're on an affected
+system and tune or skip the delay appropriately, and there may be some
+need for a command line option to be added.
+
+Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Tested-by: Lee Jones <lee.jones@linaro.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/core.c | 42 +++++++++++++++++++++++++++++++-----------
+ 1 file changed, 31 insertions(+), 11 deletions(-)
+
+--- a/drivers/regulator/core.c
++++ b/drivers/regulator/core.c
+@@ -4789,7 +4789,7 @@ static int __init regulator_init(void)
+ /* init early to allow our consumers to complete system booting */
+ core_initcall(regulator_init);
+
+-static int __init regulator_late_cleanup(struct device *dev, void *data)
++static int regulator_late_cleanup(struct device *dev, void *data)
+ {
+ struct regulator_dev *rdev = dev_to_rdev(dev);
+ const struct regulator_ops *ops = rdev->desc->ops;
+@@ -4838,18 +4838,9 @@ unlock:
+ return 0;
+ }
+
+-static int __init regulator_init_complete(void)
++static void regulator_init_complete_work_function(struct work_struct *work)
+ {
+ /*
+- * Since DT doesn't provide an idiomatic mechanism for
+- * enabling full constraints and since it's much more natural
+- * with DT to provide them just assume that a DT enabled
+- * system has full constraints.
+- */
+- if (of_have_populated_dt())
+- has_full_constraints = true;
+-
+- /*
+ * Regulators may had failed to resolve their input supplies
+ * when were registered, either because the input supply was
+ * not registered yet or because its parent device was not
+@@ -4866,6 +4857,35 @@ static int __init regulator_init_complet
+ */
+ class_for_each_device(®ulator_class, NULL, NULL,
+ regulator_late_cleanup);
++}
++
++static DECLARE_DELAYED_WORK(regulator_init_complete_work,
++ regulator_init_complete_work_function);
++
++static int __init regulator_init_complete(void)
++{
++ /*
++ * Since DT doesn't provide an idiomatic mechanism for
++ * enabling full constraints and since it's much more natural
++ * with DT to provide them just assume that a DT enabled
++ * system has full constraints.
++ */
++ if (of_have_populated_dt())
++ has_full_constraints = true;
++
++ /*
++ * We punt completion for an arbitrary amount of time since
++ * systems like distros will load many drivers from userspace
++ * so consumers might not always be ready yet, this is
++ * particularly an issue with laptops where this might bounce
++ * the display off then on. Ideally we'd get a notification
++ * from userspace when this happens but we don't so just wait
++ * a bit and hope we waited long enough. It'd be better if
++ * we'd only do this on systems that need it, and a kernel
++ * command line option might be useful.
++ */
++ schedule_delayed_work(®ulator_init_complete_work,
++ msecs_to_jiffies(30000));
+
+ class_for_each_device(®ulator_class, NULL, NULL,
+ regulator_register_fill_coupling_array);
--- /dev/null
+From d0b7a302d58abe24ed0f32a0672dd4c356bb73db Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Thu, 22 Aug 2019 14:58:37 +0100
+Subject: Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}"
+
+From: Will Deacon <will@kernel.org>
+
+commit d0b7a302d58abe24ed0f32a0672dd4c356bb73db upstream.
+
+This reverts commit 24fe1b0efad4fcdd32ce46cffeab297f22581707.
+
+Commit 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from
+set_{pte,pmd,pud}") removed ISB instructions immediately following updates
+to the page table, on the grounds that they are not required by the
+architecture and a DSB alone is sufficient to ensure that subsequent data
+accesses use the new translation:
+
+ DDI0487E_a, B2-128:
+
+ | ... no instruction that appears in program order after the DSB
+ | instruction can alter any state of the system or perform any part of
+ | its functionality until the DSB completes other than:
+ |
+ | * Being fetched from memory and decoded
+ | * Reading the general-purpose, SIMD and floating-point,
+ | Special-purpose, or System registers that are directly or indirectly
+ | read without causing side-effects.
+
+However, the same document also states the following:
+
+ DDI0487E_a, B2-125:
+
+ | DMB and DSB instructions affect reads and writes to the memory system
+ | generated by Load/Store instructions and data or unified cache
+ | maintenance instructions being executed by the PE. Instruction fetches
+ | or accesses caused by a hardware translation table access are not
+ | explicit accesses.
+
+which appears to claim that the DSB alone is insufficient. Unfortunately,
+some CPU designers have followed the second clause above, whereas in Linux
+we've been relying on the first. This means that our mapping sequence:
+
+ MOV X0, <valid pte>
+ STR X0, [Xptep] // Store new PTE to page table
+ DSB ISHST
+ LDR X1, [X2] // Translates using the new PTE
+
+can actually raise a translation fault on the load instruction because the
+translation can be performed speculatively before the page table update and
+then marked as "faulting" by the CPU. For user PTEs, this is ok because we
+can handle the spurious fault, but for kernel PTEs and intermediate table
+entries this results in a panic().
+
+Revert the offending commit to reintroduce the missing barriers.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}")
+Reviewed-by: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/pgtable.h | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/include/asm/pgtable.h
++++ b/arch/arm64/include/asm/pgtable.h
+@@ -224,8 +224,10 @@ static inline void set_pte(pte_t *ptep,
+ * Only if the new pte is valid and kernel, otherwise TLB maintenance
+ * or update_mmu_cache() have the necessary barriers.
+ */
+- if (pte_valid_not_user(pte))
++ if (pte_valid_not_user(pte)) {
+ dsb(ishst);
++ isb();
++ }
+ }
+
+ extern void __sync_icache_dcache(pte_t pteval);
+@@ -432,6 +434,7 @@ static inline void set_pmd(pmd_t *pmdp,
+ {
+ WRITE_ONCE(*pmdp, pmd);
+ dsb(ishst);
++ isb();
+ }
+
+ static inline void pmd_clear(pmd_t *pmdp)
+@@ -483,6 +486,7 @@ static inline void set_pud(pud_t *pudp,
+ {
+ WRITE_ONCE(*pudp, pud);
+ dsb(ishst);
++ isb();
+ }
+
+ static inline void pud_clear(pud_t *pudp)
kvm-x86-always-stop-emulation-on-page-fault.patch
kvm-x86-set-ctxt-have_exception-in-x86_decode_insn.patch
kvm-x86-manually-calculate-reserved-bits-when-loading-pdptrs.patch
+media-sn9c20x-add-msi-ms-1039-laptop-to-flip_dmi_table.patch
+media-don-t-drop-front-end-reference-count-for-detach.patch
+binfmt_elf-do-not-move-brk-for-interp-less-et_exec.patch
+asoc-intel-nhlt-fix-debug-print-format.patch
+asoc-intel-skylake-use-correct-function-to-access-iomem-space.patch
+asoc-intel-fix-use-of-potentially-uninitialized-variable.patch
+staging-erofs-fix-an-error-handling-in-erofs_readdir.patch
+arm-samsung-fix-system-restart-on-s3c6410.patch
+arm-zynq-use-memcpy_toio-instead-of-memcpy-on-smp-bring-up.patch
+revert-arm64-remove-unnecessary-isbs-from-set_-pte-pmd-pud.patch
+arm64-tlb-ensure-we-execute-an-isb-following-walk-cache-invalidation.patch
+arm64-dts-rockchip-limit-clock-rate-of-mmc-controllers-for-rk3328.patch
+alarmtimer-use-eopnotsupp-instead-of-enotsupp.patch
+regulator-defer-init-completion-for-a-while-after-late_initcall.patch
--- /dev/null
+From acb383f1dcb4f1e79b66d4be3a0b6f519a957b0d Mon Sep 17 00:00:00 2001
+From: Gao Xiang <xiang@kernel.org>
+Date: Sun, 18 Aug 2019 20:54:57 +0800
+Subject: staging: erofs: fix an error handling in erofs_readdir()
+
+From: Gao Xiang <gaoxiang25@huawei.com>
+
+commit acb383f1dcb4f1e79b66d4be3a0b6f519a957b0d upstream.
+
+Richard observed a forever loop of erofs_read_raw_page() [1]
+which can be generated by forcely setting ->u.i_blkaddr
+to 0xdeadbeef (as my understanding block layer can
+handle access beyond end of device correctly).
+
+After digging into that, it seems the problem is highly
+related with directories and then I found the root cause
+is an improper error handling in erofs_readdir().
+
+Let's fix it now.
+
+[1] https://lore.kernel.org/r/1163995781.68824.1566084358245.JavaMail.zimbra@nod.at/
+
+Reported-by: Richard Weinberger <richard@nod.at>
+Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations")
+Cc: <stable@vger.kernel.org> # 4.19+
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
+Link: https://lore.kernel.org/r/20190818125457.25906-1-hsiangkao@aol.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/erofs/dir.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+--- a/drivers/staging/erofs/dir.c
++++ b/drivers/staging/erofs/dir.c
+@@ -100,8 +100,15 @@ static int erofs_readdir(struct file *f,
+ unsigned nameoff, maxsize;
+
+ dentry_page = read_mapping_page(mapping, i, NULL);
+- if (IS_ERR(dentry_page))
+- continue;
++ if (dentry_page == ERR_PTR(-ENOMEM)) {
++ err = -ENOMEM;
++ break;
++ } else if (IS_ERR(dentry_page)) {
++ errln("fail to readdir of logical block %u of nid %llu",
++ i, EROFS_V(dir)->nid);
++ err = -EFSCORRUPTED;
++ break;
++ }
+
+ lock_page(dentry_page);
+ de = (struct erofs_dirent *)kmap(dentry_page);
projects / thirdparty / kernel / stable-queue.git / commitdiff
