--- /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
+@@ -673,7 +673,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;
+@@ -791,7 +791,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
+@@ -57,7 +57,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
+@@ -800,6 +800,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";
+ };
+
+@@ -811,6 +812,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";
+ };
+
+@@ -822,6 +824,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
+@@ -251,6 +251,7 @@ static inline void __flush_tlb_kernel_pg
+ dsb(ishst);
+ __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
+@@ -222,6 +222,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
+@@ -225,7 +225,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
+@@ -188,7 +188,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
+@@ -1142,7 +1142,8 @@ out_free_interp:
+ * (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 b5e86196b83fd68e065a7c811ab8925fb0dc3893 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Wed, 21 Aug 2019 14:17:00 +0100
+Subject: iommu/arm-smmu-v3: Disable detection of ATS and PRI
+
+From: Will Deacon <will@kernel.org>
+
+commit b5e86196b83fd68e065a7c811ab8925fb0dc3893 upstream.
+
+Detecting the ATS capability of the SMMU at probe time introduces a
+spinlock into the ->unmap() fast path, even when ATS is not actually
+in use. Furthermore, the ATC invalidation that exists is broken, as it
+occurs before invalidation of the main SMMU TLB which leaves a window
+where the ATC can be repopulated with stale entries.
+
+Given that ATS is both a new feature and a specialist sport, disable it
+for now whilst we fix it properly in subsequent patches. Since PRI
+requires ATS, disable that too.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 9ce27afc0830 ("iommu/arm-smmu-v3: Add support for PCI ATS")
+Acked-by: Robin Murphy <robin.murphy@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/arm-smmu-v3.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/iommu/arm-smmu-v3.c
++++ b/drivers/iommu/arm-smmu-v3.c
+@@ -2817,11 +2817,13 @@ static int arm_smmu_device_hw_probe(stru
+ }
+
+ /* Boolean feature flags */
++#if 0 /* ATS invalidation is slow and broken */
+ if (IS_ENABLED(CONFIG_PCI_PRI) && reg & IDR0_PRI)
+ smmu->features |= ARM_SMMU_FEAT_PRI;
+
+ if (IS_ENABLED(CONFIG_PCI_ATS) && reg & IDR0_ATS)
+ smmu->features |= ARM_SMMU_FEAT_ATS;
++#endif
+
+ if (reg & IDR0_SEV)
+ smmu->features |= ARM_SMMU_FEAT_SEV;
--- /dev/null
+From 2c70010867f164d1b30e787e360e05d10cc40046 Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@vmware.com>
+Date: Tue, 20 Aug 2019 01:53:17 -0700
+Subject: iommu/vt-d: Fix wrong analysis whether devices share the same bus
+
+From: Nadav Amit <namit@vmware.com>
+
+commit 2c70010867f164d1b30e787e360e05d10cc40046 upstream.
+
+set_msi_sid_cb() is used to determine whether device aliases share the
+same bus, but it can provide false indications that aliases use the same
+bus when in fact they do not. The reason is that set_msi_sid_cb()
+assumes that pdev is fixed, while actually pci_for_each_dma_alias() can
+call fn() when pdev is set to a subordinate device.
+
+As a result, running an VM on ESX with VT-d emulation enabled can
+results in the log warning such as:
+
+ DMAR: [INTR-REMAP] Request device [00:11.0] fault index 3b [fault reason 38] Blocked an interrupt request due to source-id verification failure
+
+This seems to cause additional ata errors such as:
+ ata3.00: qc timeout (cmd 0xa1)
+ ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
+
+These timeouts also cause boot to be much longer and other errors.
+
+Fix it by checking comparing the alias with the previous one instead.
+
+Fixes: 3f0c625c6ae71 ("iommu/vt-d: Allow interrupts from the entire bus for aliased devices")
+Cc: stable@vger.kernel.org
+Cc: Logan Gunthorpe <logang@deltatee.com>
+Cc: David Woodhouse <dwmw2@infradead.org>
+Cc: Joerg Roedel <joro@8bytes.org>
+Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
+Signed-off-by: Nadav Amit <namit@vmware.com>
+Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/intel_irq_remapping.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/iommu/intel_irq_remapping.c
++++ b/drivers/iommu/intel_irq_remapping.c
+@@ -376,13 +376,13 @@ static int set_msi_sid_cb(struct pci_dev
+ {
+ struct set_msi_sid_data *data = opaque;
+
++ if (data->count == 0 || PCI_BUS_NUM(alias) == PCI_BUS_NUM(data->alias))
++ data->busmatch_count++;
++
+ data->pdev = pdev;
+ data->alias = alias;
+ data->count++;
+
+- if (PCI_BUS_NUM(alias) == pdev->bus->number)
+- data->busmatch_count++;
+-
+ return 0;
+ }
+
--- /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
+@@ -152,6 +152,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.
+@@ -3026,7 +3029,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
+@@ -909,14 +909,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
+@@ -124,6 +124,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 6f51fdfd8229d5358c2d6e272cf73478866e8ddc Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Wed, 4 Sep 2019 06:04:07 -0300
+Subject: media: videobuf-core.c: poll_wait needs a non-NULL buf pointer
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 6f51fdfd8229d5358c2d6e272cf73478866e8ddc upstream.
+
+poll_wait uses &buf->done, but buf is NULL. Move the poll_wait to later
+in the function once buf is correctly set and only call it if it is
+non-NULL.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Fixes: bb436cbeb918 ("media: videobuf: fix epoll() by calling poll_wait first")
+Cc: <stable@vger.kernel.org> # for v5.1 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/v4l2-core/videobuf-core.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/v4l2-core/videobuf-core.c
++++ b/drivers/media/v4l2-core/videobuf-core.c
+@@ -1123,7 +1123,6 @@ __poll_t videobuf_poll_stream(struct fil
+ struct videobuf_buffer *buf = NULL;
+ __poll_t rc = 0;
+
+- poll_wait(file, &buf->done, wait);
+ videobuf_queue_lock(q);
+ if (q->streaming) {
+ if (!list_empty(&q->stream))
+@@ -1143,7 +1142,9 @@ __poll_t videobuf_poll_stream(struct fil
+ }
+ buf = q->read_buf;
+ }
+- if (!buf)
++ if (buf)
++ poll_wait(file, &buf->done, wait);
++ else
+ rc = EPOLLERR;
+
+ if (0 == rc) {
--- /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
+@@ -5486,7 +5486,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;
+@@ -5535,18 +5535,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
+@@ -5563,6 +5554,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));
+
+ return 0;
+ }
kvm-x86-manually-calculate-reserved-bits-when-loading-pdptrs.patch
kvm-x86-disable-posted-interrupts-for-non-standard-irqs-delivery-modes.patch
kvm-x86-mmu-use-fast-invalidate-mechanism-to-zap-mmio-sptes.patch
+media-videobuf-core.c-poll_wait-needs-a-non-null-buf-pointer.patch
+media-sn9c20x-add-msi-ms-1039-laptop-to-flip_dmi_table.patch
+media-don-t-drop-front-end-reference-count-for-detach.patch
+spi-ep93xx-repair-spi-cs-lookup-tables.patch
+spi-spi-fsl-dspi-exit-the-isr-with-irq_none-when-it-s-not-ours.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
+arm64-tlb-ensure-we-execute-an-isb-following-walk-cache-invalidation.patch
+arm64-dts-rockchip-limit-clock-rate-of-mmc-controllers-for-rk3328.patch
+iommu-arm-smmu-v3-disable-detection-of-ats-and-pri.patch
+alarmtimer-use-eopnotsupp-instead-of-enotsupp.patch
+iommu-vt-d-fix-wrong-analysis-whether-devices-share-the-same-bus.patch
+regulator-defer-init-completion-for-a-while-after-late_initcall.patch
--- /dev/null
+From 4fbc485324d2975c54201091dfad0a7dd4902324 Mon Sep 17 00:00:00 2001
+From: Alexander Sverdlin <alexander.sverdlin@gmail.com>
+Date: Sat, 31 Aug 2019 20:04:02 +0200
+Subject: spi: ep93xx: Repair SPI CS lookup tables
+
+From: Alexander Sverdlin <alexander.sverdlin@gmail.com>
+
+commit 4fbc485324d2975c54201091dfad0a7dd4902324 upstream.
+
+The actual device name of the SPI controller being registered on EP93xx is
+"spi0" (as seen by gpiod_find_lookup_table()). This patch fixes all
+relevant lookup tables and the following failure (seen on EDB9302):
+
+ep93xx-spi ep93xx-spi.0: failed to register SPI master
+ep93xx-spi: probe of ep93xx-spi.0 failed with error -22
+
+Fixes: 1dfbf334f1236 ("spi: ep93xx: Convert to use CS GPIO descriptors")
+Cc: stable@vger.kernel.org
+Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Reviewed-by: Lukasz Majewski <lukma@denx.de>
+Link: https://lore.kernel.org/r/20190831180402.10008-1-alexander.sverdlin@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-ep93xx/edb93xx.c | 2 +-
+ arch/arm/mach-ep93xx/simone.c | 2 +-
+ arch/arm/mach-ep93xx/ts72xx.c | 4 ++--
+ arch/arm/mach-ep93xx/vision_ep9307.c | 2 +-
+ 4 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/arch/arm/mach-ep93xx/edb93xx.c
++++ b/arch/arm/mach-ep93xx/edb93xx.c
+@@ -103,7 +103,7 @@ static struct spi_board_info edb93xx_spi
+ };
+
+ static struct gpiod_lookup_table edb93xx_spi_cs_gpio_table = {
+- .dev_id = "ep93xx-spi.0",
++ .dev_id = "spi0",
+ .table = {
+ GPIO_LOOKUP("A", 6, "cs", GPIO_ACTIVE_LOW),
+ { },
+--- a/arch/arm/mach-ep93xx/simone.c
++++ b/arch/arm/mach-ep93xx/simone.c
+@@ -73,7 +73,7 @@ static struct spi_board_info simone_spi_
+ * v1.3 parts will still work, since the signal on SFRMOUT is automatic.
+ */
+ static struct gpiod_lookup_table simone_spi_cs_gpio_table = {
+- .dev_id = "ep93xx-spi.0",
++ .dev_id = "spi0",
+ .table = {
+ GPIO_LOOKUP("A", 1, "cs", GPIO_ACTIVE_LOW),
+ { },
+--- a/arch/arm/mach-ep93xx/ts72xx.c
++++ b/arch/arm/mach-ep93xx/ts72xx.c
+@@ -267,7 +267,7 @@ static struct spi_board_info bk3_spi_boa
+ * goes through CPLD
+ */
+ static struct gpiod_lookup_table bk3_spi_cs_gpio_table = {
+- .dev_id = "ep93xx-spi.0",
++ .dev_id = "spi0",
+ .table = {
+ GPIO_LOOKUP("F", 3, "cs", GPIO_ACTIVE_LOW),
+ { },
+@@ -316,7 +316,7 @@ static struct spi_board_info ts72xx_spi_
+ };
+
+ static struct gpiod_lookup_table ts72xx_spi_cs_gpio_table = {
+- .dev_id = "ep93xx-spi.0",
++ .dev_id = "spi0",
+ .table = {
+ /* DIO_17 */
+ GPIO_LOOKUP("F", 2, "cs", GPIO_ACTIVE_LOW),
+--- a/arch/arm/mach-ep93xx/vision_ep9307.c
++++ b/arch/arm/mach-ep93xx/vision_ep9307.c
+@@ -242,7 +242,7 @@ static struct spi_board_info vision_spi_
+ };
+
+ static struct gpiod_lookup_table vision_spi_cs_gpio_table = {
+- .dev_id = "ep93xx-spi.0",
++ .dev_id = "spi0",
+ .table = {
+ GPIO_LOOKUP_IDX("A", 6, "cs", 0, GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP_IDX("A", 7, "cs", 1, GPIO_ACTIVE_LOW),
--- /dev/null
+From d41f36a6464a85c06ad920703d878e4491d2c023 Mon Sep 17 00:00:00 2001
+From: Vladimir Oltean <olteanv@gmail.com>
+Date: Fri, 23 Aug 2019 00:24:50 +0300
+Subject: spi: spi-fsl-dspi: Exit the ISR with IRQ_NONE when it's not ours
+
+From: Vladimir Oltean <olteanv@gmail.com>
+
+commit d41f36a6464a85c06ad920703d878e4491d2c023 upstream.
+
+The DSPI interrupt can be shared between two controllers at least on the
+LX2160A. In that case, the driver for one controller might misbehave and
+consume the other's interrupt. Fix this by actually checking if any of
+the bits in the status register have been asserted.
+
+Fixes: 13aed2392741 ("spi: spi-fsl-dspi: use IRQF_SHARED mode to request IRQ")
+Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
+Link: https://lore.kernel.org/r/20190822212450.21420-2-olteanv@gmail.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-fsl-dspi.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/spi/spi-fsl-dspi.c
++++ b/drivers/spi/spi-fsl-dspi.c
+@@ -886,9 +886,11 @@ static irqreturn_t dspi_interrupt(int ir
+ trans_mode);
+ }
+ }
++
++ return IRQ_HANDLED;
+ }
+
+- return IRQ_HANDLED;
++ return IRQ_NONE;
+ }
+
+ static const struct of_device_id fsl_dspi_dt_ids[] = {
--- /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 int 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;
++ }
+
+ de = (struct erofs_dirent *)kmap(dentry_page);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
