--- /dev/null
+From b7e320f31f2c6e97951ae4af91f75ab75c8f88f8 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 30 Apr 2019 12:18:28 +0200
+Subject: ALSA: hda - Register irq handler after the chip initialization
+
+[ Upstream commit f495222e28275222ab6fd93813bd3d462e16d340 ]
+
+Currently the IRQ handler in HD-audio controller driver is registered
+before the chip initialization. That is, we have some window opened
+between the azx_acquire_irq() call and the CORB/RIRB setup. If an
+interrupt is triggered in this small window, the IRQ handler may
+access to the uninitialized RIRB buffer, which leads to a NULL
+dereference Oops.
+
+This is usually no big problem since most of Intel chips do register
+the IRQ via MSI, and we've already fixed the order of the IRQ
+enablement and the CORB/RIRB setup in the former commit b61749a89f82
+("sound: enable interrupt after dma buffer initialization"), hence the
+IRQ won't be triggered in that room. However, some platforms use a
+shared IRQ, and this may allow the IRQ trigger by another source.
+
+Another possibility is the kdump environment: a stale interrupt might
+be present in there, the IRQ handler can be falsely triggered as well.
+
+For covering this small race, let's move the azx_acquire_irq() call
+after hda_intel_init_chip() call. Although this is a bit radical
+change, it can cover more widely than checking the CORB/RIRB setup
+locally in the callee side.
+
+Reported-by: Liwei Song <liwei.song@windriver.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/pci/hda/hda_intel.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
+index 74c9600876d6..ef8955abd918 100644
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -1707,9 +1707,6 @@ static int azx_first_init(struct azx *chip)
+ chip->msi = 0;
+ }
+
+- if (azx_acquire_irq(chip, 0) < 0)
+- return -EBUSY;
+-
+ pci_set_master(pci);
+ synchronize_irq(bus->irq);
+
+@@ -1820,6 +1817,9 @@ static int azx_first_init(struct azx *chip)
+ return -ENODEV;
+ }
+
++ if (azx_acquire_irq(chip, 0) < 0)
++ return -EBUSY;
++
+ strcpy(card->driver, "HDA-Intel");
+ strlcpy(card->shortname, driver_short_names[chip->driver_type],
+ sizeof(card->shortname));
+--
+2.20.1
+
--- /dev/null
+From 8219b9e032b0fe52418386d3807726fbad6dee5a Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzk@kernel.org>
+Date: Thu, 14 Mar 2019 21:02:17 +0100
+Subject: ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8
+ regulators on Arndale Octa
+
+[ Upstream commit 5ab99cf7d5e96e3b727c30e7a8524c976bd3723d ]
+
+The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned
+off by Linux kernel as unused. However they supply critical parts of
+SoC so they should be always on:
+
+1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift,
+ RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt
+ lines, TTL/UARTR level shift, reset pins and SW-TACT1 button.
+ It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and
+ VDDQ_GPIO (gpm7, gpy7).
+ The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so
+ marking it "always-on" only reflects its real status.
+
+2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores,
+ memory and Mali (G3D).
+
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+index 4ecef6981d5c..b54c0b8a5b34 100644
+--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
++++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+@@ -97,6 +97,7 @@
+ regulator-name = "PVDD_APIO_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
++ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+@@ -135,6 +136,7 @@
+ regulator-name = "PVDD_ABB_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
++ regulator-always-on;
+ };
+
+ ldo9_reg: LDO9 {
+--
+2.20.1
+
--- /dev/null
+From c566828a0b554e56fa8057351f77c70df7b868fc Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:16 -0700
+Subject: ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA
+
+[ Upstream commit b14c872eebc501b9640b04f4a152df51d6eaf2fc ]
+
+Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
+clock to determine if it needs to configure the IP block as operating
+at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
+clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality(this at least
+breaks RAVE SP serdev driver on RDU2). Fix the code to specify
+IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect
+clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Tested-by: Adam Ford <aford173@gmail.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
+index e6af41c4bbc1..3992b8ea1c48 100644
+--- a/arch/arm/boot/dts/imx6qdl.dtsi
++++ b/arch/arm/boot/dts/imx6qdl.dtsi
+@@ -853,7 +853,7 @@
+ compatible = "fsl,imx6q-sdma", "fsl,imx35-sdma";
+ reg = <0x020ec000 0x4000>;
+ interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
+- clocks = <&clks IMX6QDL_CLK_SDMA>,
++ clocks = <&clks IMX6QDL_CLK_IPG>,
+ <&clks IMX6QDL_CLK_SDMA>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+--
+2.20.1
+
--- /dev/null
+From fc9bc15c78b5c04f47ad517d52c8d35955526155 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:21 -0700
+Subject: ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA
+
+[ Upstream commit cc839d0f8c284fcb7591780b568f13415bbb737c ]
+
+Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
+clock to determine if it needs to configure the IP block as operating
+at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
+clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx6sl.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
+index d8ba99f1d87b..ac820dfef977 100644
+--- a/arch/arm/boot/dts/imx6sl.dtsi
++++ b/arch/arm/boot/dts/imx6sl.dtsi
+@@ -657,7 +657,7 @@
+ reg = <0x020ec000 0x4000>;
+ interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SL_CLK_SDMA>,
+- <&clks IMX6SL_CLK_SDMA>;
++ <&clks IMX6SL_CLK_AHB>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+ /* imx6sl reuses imx6q sdma firmware */
+--
+2.20.1
+
--- /dev/null
+From a3d2a6509fb86959c3d1639b759af49e6d102511 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:17 -0700
+Subject: ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA
+
+[ Upstream commit 8979117765c19edc3b01cc0ef853537bf93eea4b ]
+
+Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
+clock to determine if it needs to configure the IP block as operating
+at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
+clocks as IMX6SX_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx6sx.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
+index 6963dff815dc..5783eb8541ed 100644
+--- a/arch/arm/boot/dts/imx6sx.dtsi
++++ b/arch/arm/boot/dts/imx6sx.dtsi
+@@ -732,7 +732,7 @@
+ compatible = "fsl,imx6sx-sdma", "fsl,imx6q-sdma";
+ reg = <0x020ec000 0x4000>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+- clocks = <&clks IMX6SX_CLK_SDMA>,
++ clocks = <&clks IMX6SX_CLK_IPG>,
+ <&clks IMX6SX_CLK_SDMA>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+--
+2.20.1
+
--- /dev/null
+From 7469cd32f92035acd462ffa4f26a717cd04201a5 Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+Date: Mon, 18 Feb 2019 15:34:12 +0100
+Subject: ARM: exynos: Fix undefined instruction during Exynos5422 resume
+
+[ Upstream commit 4d8e3e951a856777720272ce27f2c738a3eeef8c ]
+
+During early system resume on Exynos5422 with performance counters enabled
+the following kernel oops happens:
+
+ Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
+ Modules linked in:
+ CPU: 0 PID: 1433 Comm: bash Tainted: G W 5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480
+ Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
+ ...
+ Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
+ Control: 10c5387d Table: 4451006a DAC: 00000051
+ Process bash (pid: 1433, stack limit = 0xb7e0e22f)
+ ...
+ (reset_ctrl_regs) from [<c0112ad0>] (dbg_cpu_pm_notify+0x1c/0x24)
+ (dbg_cpu_pm_notify) from [<c014c840>] (notifier_call_chain+0x44/0x84)
+ (notifier_call_chain) from [<c014cbc0>] (__atomic_notifier_call_chain+0x7c/0x128)
+ (__atomic_notifier_call_chain) from [<c01ffaac>] (cpu_pm_notify+0x30/0x54)
+ (cpu_pm_notify) from [<c055116c>] (syscore_resume+0x98/0x3f4)
+ (syscore_resume) from [<c0189350>] (suspend_devices_and_enter+0x97c/0xe74)
+ (suspend_devices_and_enter) from [<c0189fb8>] (pm_suspend+0x770/0xc04)
+ (pm_suspend) from [<c0187740>] (state_store+0x6c/0xcc)
+ (state_store) from [<c09fa698>] (kobj_attr_store+0x14/0x20)
+ (kobj_attr_store) from [<c030159c>] (sysfs_kf_write+0x4c/0x50)
+ (sysfs_kf_write) from [<c0300620>] (kernfs_fop_write+0xfc/0x1e0)
+ (kernfs_fop_write) from [<c0282be8>] (__vfs_write+0x2c/0x160)
+ (__vfs_write) from [<c0282ea4>] (vfs_write+0xa4/0x16c)
+ (vfs_write) from [<c0283080>] (ksys_write+0x40/0x8c)
+ (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
+
+Undefined instruction is triggered during CP14 reset, because bits: #16
+(Secure privileged invasive debug disabled) and #17 (Secure privileged
+noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN
+and SPIDEN lines, which are provided by Secure JTAG hardware block. That
+block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422
+boots on cluster 1 (LITTLE/KFC).
+
+To fix this issue it is enough to turn on the power on the cluster 0 for
+a while. This lets the Secure JTAG block to propagate the needed signals
+to LITTLE/KFC cores and change their DSCR.
+
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mach-exynos/suspend.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
+index a003833ac112..013f4d55ede8 100644
+--- a/arch/arm/mach-exynos/suspend.c
++++ b/arch/arm/mach-exynos/suspend.c
+@@ -508,8 +508,27 @@ early_wakeup:
+
+ static void exynos5420_prepare_pm_resume(void)
+ {
++ unsigned int mpidr, cluster;
++
++ mpidr = read_cpuid_mpidr();
++ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
++
+ if (IS_ENABLED(CONFIG_EXYNOS5420_MCPM))
+ WARN_ON(mcpm_cpu_powered_up());
++
++ if (IS_ENABLED(CONFIG_HW_PERF_EVENTS) && cluster != 0) {
++ /*
++ * When system is resumed on the LITTLE/KFC core (cluster 1),
++ * the DSCR is not properly updated until the power is turned
++ * on also for the cluster 0. Enable it for a while to
++ * propagate the SPNIDEN and SPIDEN signals from Secure JTAG
++ * block and avoid undefined instruction issue on CP14 reset.
++ */
++ pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
++ EXYNOS_COMMON_CONFIGURATION(0));
++ pmu_raw_writel(0,
++ EXYNOS_COMMON_CONFIGURATION(0));
++ }
+ }
+
+ static void exynos5420_pm_resume(void)
+--
+2.20.1
+
--- /dev/null
+From dfe300647458ac9af34de01e96793de0be99e4e2 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Thu, 11 Apr 2019 16:21:53 -0700
+Subject: clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288
+
+[ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ]
+
+Experimentally it can be seen that going into deep sleep (specifically
+setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1)
+appears to fail unless "aclk_dmac1" is on. The failure is that the
+system never signals that it made it into suspend on the GLOBAL_PWROFF
+pin and it just hangs.
+
+NOTE that it's confirmed that it's the actual suspend that fails, not
+one of the earlier calls to read/write registers. Specifically if you
+comment out the "PMU_GLOBAL_INT_DISABLE" setting in
+rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in
+rockchip_lpmode_enter() then you can exercise the whole suspend path
+without any crashing.
+
+This is currently not a problem with suspend upstream because there is
+no current way to exercise the deep suspend code. However, anyone
+trying to make it work will run into this issue.
+
+This was not a problem on shipping rk3288-based Chromebooks because
+those devices all ran on an old kernel based on 3.14. On that kernel
+"aclk_dmac1" appears to be left on all the time.
+
+There are several ways to skin this problem.
+
+A) We could add "aclk_dmac1" to the list of critical clocks and that
+apperas to work, but presumably that wastes power.
+
+B) We could keep a list of "struct clk" objects to enable at suspend
+time in clk-rk3288.c and use the standard clock APIs.
+
+C) We could make the rk3288-pmu driver keep a list of clocks to enable
+at suspend time. Presumably this would require a dts and bindings
+change.
+
+D) We could just whack the clock on in the existing syscore suspend
+function where we whack a bunch of other clocks. This is particularly
+easy because we know for sure that the clock's only parent
+("aclk_cpu") is a critical clock so we don't need to do anything more
+than ungate it.
+
+In this case I have chosen D) because it seemed like the least work,
+but any of the other options would presumably also work fine.
+
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clk/rockchip/clk-rk3288.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
+index 9040878e3e2b..a6cda84b67da 100644
+--- a/drivers/clk/rockchip/clk-rk3288.c
++++ b/drivers/clk/rockchip/clk-rk3288.c
+@@ -797,6 +797,9 @@ static const int rk3288_saved_cru_reg_ids[] = {
+ RK3288_CLKSEL_CON(10),
+ RK3288_CLKSEL_CON(33),
+ RK3288_CLKSEL_CON(37),
++
++ /* We turn aclk_dmac1 on for suspend; this will restore it */
++ RK3288_CLKGATE_CON(10),
+ };
+
+ static u32 rk3288_saved_cru_regs[ARRAY_SIZE(rk3288_saved_cru_reg_ids)];
+@@ -812,6 +815,14 @@ static int rk3288_clk_suspend(void)
+ readl_relaxed(rk3288_cru_base + reg_id);
+ }
+
++ /*
++ * Going into deep sleep (specifically setting PMU_CLR_DMA in
++ * RK3288_PMU_PWRMODE_CON1) appears to fail unless
++ * "aclk_dmac1" is on.
++ */
++ writel_relaxed(1 << (12 + 16),
++ rk3288_cru_base + RK3288_CLKGATE_CON(10));
++
+ /*
+ * Switch PLLs other than DPLL (for SDRAM) to slow mode to
+ * avoid crashes on resume. The Mask ROM on the system will
+--
+2.20.1
+
--- /dev/null
+From 5c183a635ac95585b9ac7c7ebae6ad961fb7eabd Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Mon, 18 Mar 2019 18:39:30 +0300
+Subject: dmaengine: idma64: Use actual device for DMA transfers
+
+[ Upstream commit 5ba846b1ee0792f5a596b9b0b86d6e8cdebfab06 ]
+
+Intel IOMMU, when enabled, tries to find the domain of the device,
+assuming it's a PCI one, during DMA operations, such as mapping or
+unmapping. Since we are splitting the actual PCI device to couple of
+children via MFD framework (see drivers/mfd/intel-lpss.c for details),
+the DMA device appears to be a platform one, and thus not an actual one
+that performs DMA. In a such situation IOMMU can't find or allocate
+a proper domain for its operations. As a result, all DMA operations are
+failed.
+
+In order to fix this, supply parent of the platform device
+to the DMA engine framework and fix filter functions accordingly.
+
+We may rely on the fact that parent is a real PCI device, because no
+other configuration is present in the wild.
+
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Acked-by: Mark Brown <broonie@kernel.org>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts]
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/dma/idma64.c | 6 ++++--
+ drivers/dma/idma64.h | 2 ++
+ drivers/spi/spi-pxa2xx.c | 7 +------
+ drivers/tty/serial/8250/8250_dw.c | 4 ++--
+ 4 files changed, 9 insertions(+), 10 deletions(-)
+
+diff --git a/drivers/dma/idma64.c b/drivers/dma/idma64.c
+index 7d56b47e4fcf..25e25b64bc89 100644
+--- a/drivers/dma/idma64.c
++++ b/drivers/dma/idma64.c
+@@ -594,7 +594,7 @@ static int idma64_probe(struct idma64_chip *chip)
+ idma64->dma.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ idma64->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+- idma64->dma.dev = chip->dev;
++ idma64->dma.dev = chip->sysdev;
+
+ ret = dma_async_device_register(&idma64->dma);
+ if (ret)
+@@ -632,6 +632,7 @@ static int idma64_platform_probe(struct platform_device *pdev)
+ {
+ struct idma64_chip *chip;
+ struct device *dev = &pdev->dev;
++ struct device *sysdev = dev->parent;
+ struct resource *mem;
+ int ret;
+
+@@ -648,11 +649,12 @@ static int idma64_platform_probe(struct platform_device *pdev)
+ if (IS_ERR(chip->regs))
+ return PTR_ERR(chip->regs);
+
+- ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
++ ret = dma_coerce_mask_and_coherent(sysdev, DMA_BIT_MASK(64));
+ if (ret)
+ return ret;
+
+ chip->dev = dev;
++ chip->sysdev = sysdev;
+
+ ret = idma64_probe(chip);
+ if (ret)
+diff --git a/drivers/dma/idma64.h b/drivers/dma/idma64.h
+index f6aeff0af8a5..e40c69bd1fb5 100644
+--- a/drivers/dma/idma64.h
++++ b/drivers/dma/idma64.h
+@@ -215,12 +215,14 @@ static inline void idma64_writel(struct idma64 *idma64, int offset, u32 value)
+ /**
+ * struct idma64_chip - representation of iDMA 64-bit controller hardware
+ * @dev: struct device of the DMA controller
++ * @sysdev: struct device of the physical device that does DMA
+ * @irq: irq line
+ * @regs: memory mapped I/O space
+ * @idma64: struct idma64 that is filed by idma64_probe()
+ */
+ struct idma64_chip {
+ struct device *dev;
++ struct device *sysdev;
+ int irq;
+ void __iomem *regs;
+ struct idma64 *idma64;
+diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
+index e87b6fc9f4c6..193aa3da5033 100644
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -1371,12 +1371,7 @@ static const struct pci_device_id pxa2xx_spi_pci_compound_match[] = {
+
+ static bool pxa2xx_spi_idma_filter(struct dma_chan *chan, void *param)
+ {
+- struct device *dev = param;
+-
+- if (dev != chan->device->dev->parent)
+- return false;
+-
+- return true;
++ return param == chan->device->dev;
+ }
+
+ static struct pxa2xx_spi_master *
+diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
+index a30d68c4b689..039837db65fc 100644
+--- a/drivers/tty/serial/8250/8250_dw.c
++++ b/drivers/tty/serial/8250/8250_dw.c
+@@ -258,7 +258,7 @@ static bool dw8250_fallback_dma_filter(struct dma_chan *chan, void *param)
+
+ static bool dw8250_idma_filter(struct dma_chan *chan, void *param)
+ {
+- return param == chan->device->dev->parent;
++ return param == chan->device->dev;
+ }
+
+ static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data)
+@@ -290,7 +290,7 @@ static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data)
+ data->uart_16550_compatible = true;
+ }
+
+- /* Platforms with iDMA */
++ /* Platforms with iDMA 64-bit */
+ if (platform_get_resource_byname(to_platform_device(p->dev),
+ IORESOURCE_MEM, "lpss_priv")) {
+ p->set_termios = dw8250_set_termios;
+--
+2.20.1
+
--- /dev/null
+From 92db9400a500abaa76ea2936984e18b4cbc9ce12 Mon Sep 17 00:00:00 2001
+From: Matt Redfearn <matt.redfearn@thinci.com>
+Date: Wed, 24 Apr 2019 13:22:27 +0000
+Subject: drm/bridge: adv7511: Fix low refresh rate selection
+
+[ Upstream commit 67793bd3b3948dc8c8384b6430e036a30a0ecb43 ]
+
+The driver currently sets register 0xfb (Low Refresh Rate) based on the
+value of mode->vrefresh. Firstly, this field is specified to be in Hz,
+but the magic numbers used by the code are Hz * 1000. This essentially
+leads to the low refresh rate always being set to 0x01, since the
+vrefresh value will always be less than 24000. Fix the magic numbers to
+be in Hz.
+Secondly, according to the comment in drm_modes.h, the field is not
+supposed to be used in a functional way anyway. Instead, use the helper
+function drm_mode_vrefresh().
+
+Fixes: 9c8af882bf12 ("drm: Add adv7511 encoder driver")
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Matt Redfearn <matt.redfearn@thinci.com>
+Signed-off-by: Sean Paul <seanpaul@chromium.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190424132210.26338-1-matt.redfearn@thinci.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/i2c/adv7511.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
+index c7c243e9b808..4300e27ed113 100644
+--- a/drivers/gpu/drm/i2c/adv7511.c
++++ b/drivers/gpu/drm/i2c/adv7511.c
+@@ -781,11 +781,11 @@ static void adv7511_encoder_mode_set(struct drm_encoder *encoder,
+ vsync_polarity = 1;
+ }
+
+- if (mode->vrefresh <= 24000)
++ if (drm_mode_vrefresh(mode) <= 24)
+ low_refresh_rate = ADV7511_LOW_REFRESH_RATE_24HZ;
+- else if (mode->vrefresh <= 25000)
++ else if (drm_mode_vrefresh(mode) <= 25)
+ low_refresh_rate = ADV7511_LOW_REFRESH_RATE_25HZ;
+- else if (mode->vrefresh <= 30000)
++ else if (drm_mode_vrefresh(mode) <= 30)
+ low_refresh_rate = ADV7511_LOW_REFRESH_RATE_30HZ;
+ else
+ low_refresh_rate = ADV7511_LOW_REFRESH_RATE_NONE;
+--
+2.20.1
+
--- /dev/null
+From c72b7d90b9c246380fb910e0162881d472138e77 Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:28:37 +0800
+Subject: f2fs: fix to avoid panic in do_recover_data()
+
+[ Upstream commit 22d61e286e2d9097dae36f75ed48801056b77cac ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203227
+
+- Overview
+When mounting the attached crafted image, following errors are reported.
+Additionally, it hangs on sync after trying to mount it.
+
+The image is intentionally fuzzed from a normal f2fs image for testing.
+Compile options for F2FS are as follows.
+CONFIG_F2FS_FS=y
+CONFIG_F2FS_STAT_FS=y
+CONFIG_F2FS_FS_XATTR=y
+CONFIG_F2FS_FS_POSIX_ACL=y
+CONFIG_F2FS_CHECK_FS=y
+
+- Reproduces
+mkdir test
+mount -t f2fs tmp.img test
+sync
+
+- Messages
+ kernel BUG at fs/f2fs/recovery.c:549!
+ RIP: 0010:recover_data+0x167a/0x1780
+ Call Trace:
+ f2fs_recover_fsync_data+0x613/0x710
+ f2fs_fill_super+0x1043/0x1aa0
+ mount_bdev+0x16d/0x1a0
+ mount_fs+0x4a/0x170
+ vfs_kern_mount+0x5d/0x100
+ do_mount+0x200/0xcf0
+ ksys_mount+0x79/0xc0
+ __x64_sys_mount+0x1c/0x20
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+During recovery, if ofs_of_node is inconsistent in between recovered
+node page and original checkpointed node page, let's just fail recovery
+instead of making kernel panic.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/recovery.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
+index 2878be3e448f..410354c334d7 100644
+--- a/fs/f2fs/recovery.c
++++ b/fs/f2fs/recovery.c
+@@ -413,7 +413,15 @@ static int do_recover_data(struct f2fs_sb_info *sbi, struct inode *inode,
+
+ get_node_info(sbi, dn.nid, &ni);
+ f2fs_bug_on(sbi, ni.ino != ino_of_node(page));
+- f2fs_bug_on(sbi, ofs_of_node(dn.node_page) != ofs_of_node(page));
++
++ if (ofs_of_node(dn.node_page) != ofs_of_node(page)) {
++ f2fs_msg(sbi->sb, KERN_WARNING,
++ "Inconsistent ofs_of_node, ino:%lu, ofs:%u, %u",
++ inode->i_ino, ofs_of_node(dn.node_page),
++ ofs_of_node(page));
++ err = -EFAULT;
++ goto err;
++ }
+
+ for (; start < end; start++, dn.ofs_in_node++) {
+ block_t src, dest;
+--
+2.20.1
+
--- /dev/null
+From 905a9429d3e2d916b6fb2cc119fa3d46283d8154 Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:30:51 +0800
+Subject: f2fs: fix to do sanity check on valid block count of segment
+
+[ Upstream commit e95bcdb2fefa129f37bd9035af1d234ca92ee4ef ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203233
+
+- Overview
+When mounting the attached crafted image and running program, following errors are reported.
+Additionally, it hangs on sync after running program.
+
+The image is intentionally fuzzed from a normal f2fs image for testing.
+Compile options for F2FS are as follows.
+CONFIG_F2FS_FS=y
+CONFIG_F2FS_STAT_FS=y
+CONFIG_F2FS_FS_XATTR=y
+CONFIG_F2FS_FS_POSIX_ACL=y
+CONFIG_F2FS_CHECK_FS=y
+
+- Reproduces
+cc poc_13.c
+mkdir test
+mount -t f2fs tmp.img test
+cp a.out test
+cd test
+sudo ./a.out
+sync
+
+- Kernel messages
+ F2FS-fs (sdb): Bitmap was wrongly set, blk:4608
+ kernel BUG at fs/f2fs/segment.c:2102!
+ RIP: 0010:update_sit_entry+0x394/0x410
+ Call Trace:
+ f2fs_allocate_data_block+0x16f/0x660
+ do_write_page+0x62/0x170
+ f2fs_do_write_node_page+0x33/0xa0
+ __write_node_page+0x270/0x4e0
+ f2fs_sync_node_pages+0x5df/0x670
+ f2fs_write_checkpoint+0x372/0x1400
+ f2fs_sync_fs+0xa3/0x130
+ f2fs_do_sync_file+0x1a6/0x810
+ do_fsync+0x33/0x60
+ __x64_sys_fsync+0xb/0x10
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+sit.vblocks and sum valid block count in sit.valid_map may be
+inconsistent, segment w/ zero vblocks will be treated as free
+segment, while allocating in free segment, we may allocate a
+free block, if its bitmap is valid previously, it can cause
+kernel crash due to bitmap verification failure.
+
+Anyway, to avoid further serious metadata inconsistence and
+corruption, it is necessary and worth to detect SIT
+inconsistence. So let's enable check_block_count() to verify
+vblocks and valid_map all the time rather than do it only
+CONFIG_F2FS_CHECK_FS is enabled.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/segment.h | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
+index 08b08ae6ba9d..f461fecf0e54 100644
+--- a/fs/f2fs/segment.h
++++ b/fs/f2fs/segment.h
+@@ -598,7 +598,6 @@ static inline void verify_block_addr(struct f2fs_io_info *fio, block_t blk_addr)
+ static inline int check_block_count(struct f2fs_sb_info *sbi,
+ int segno, struct f2fs_sit_entry *raw_sit)
+ {
+-#ifdef CONFIG_F2FS_CHECK_FS
+ bool is_valid = test_bit_le(0, raw_sit->valid_map) ? true : false;
+ int valid_blocks = 0;
+ int cur_pos = 0, next_pos;
+@@ -625,7 +624,7 @@ static inline int check_block_count(struct f2fs_sb_info *sbi,
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
+ return -EINVAL;
+ }
+-#endif
++
+ /* check segment usage, and check boundary of a given segment number */
+ if (unlikely(GET_SIT_VBLOCKS(raw_sit) > sbi->blocks_per_seg
+ || segno > TOTAL_SEGS(sbi) - 1)) {
+--
+2.20.1
+
--- /dev/null
+From c8b3acc2e4e466bd0dfb760d48e5e9bd24afda42 Mon Sep 17 00:00:00 2001
+From: Hou Tao <houtao1@huawei.com>
+Date: Tue, 14 May 2019 15:44:32 -0700
+Subject: fs/fat/file.c: issue flush after the writeback of FAT
+
+[ Upstream commit bd8309de0d60838eef6fb575b0c4c7e95841cf73 ]
+
+fsync() needs to make sure the data & meta-data of file are persistent
+after the return of fsync(), even when a power-failure occurs later. In
+the case of fat-fs, the FAT belongs to the meta-data of file, so we need
+to issue a flush after the writeback of FAT instead before.
+
+Also bail out early when any stage of fsync fails.
+
+Link: http://lkml.kernel.org/r/20190409030158.136316-1-houtao1@huawei.com
+Signed-off-by: Hou Tao <houtao1@huawei.com>
+Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Jan Kara <jack@suse.cz>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/fat/file.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/fs/fat/file.c b/fs/fat/file.c
+index a08f1039909a..d3f655ae020b 100644
+--- a/fs/fat/file.c
++++ b/fs/fat/file.c
+@@ -156,12 +156,17 @@ static int fat_file_release(struct inode *inode, struct file *filp)
+ int fat_file_fsync(struct file *filp, loff_t start, loff_t end, int datasync)
+ {
+ struct inode *inode = filp->f_mapping->host;
+- int res, err;
++ int err;
++
++ err = __generic_file_fsync(filp, start, end, datasync);
++ if (err)
++ return err;
+
+- res = generic_file_fsync(filp, start, end, datasync);
+ err = sync_mapping_buffers(MSDOS_SB(inode->i_sb)->fat_inode->i_mapping);
++ if (err)
++ return err;
+
+- return res ? res : err;
++ return blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
+ }
+
+
+--
+2.20.1
+
--- /dev/null
+From cab2e5096300bcb12ce3b04f8e5e7c0538fde023 Mon Sep 17 00:00:00 2001
+From: Kirill Smelkov <kirr@nexedi.com>
+Date: Wed, 27 Mar 2019 10:15:15 +0000
+Subject: fuse: require /dev/fuse reads to have enough buffer capacity
+
+[ Upstream commit d4b13963f217dd947da5c0cabd1569e914d21699 ]
+
+A FUSE filesystem server queues /dev/fuse sys_read calls to get
+filesystem requests to handle. It does not know in advance what would be
+that request as it can be anything that client issues - LOOKUP, READ,
+WRITE, ... Many requests are short and retrieve data from the
+filesystem. However WRITE and NOTIFY_REPLY write data into filesystem.
+
+Before getting into operation phase, FUSE filesystem server and kernel
+client negotiate what should be the maximum write size the client will
+ever issue. After negotiation the contract in between server/client is
+that the filesystem server then should queue /dev/fuse sys_read calls with
+enough buffer capacity to receive any client request - WRITE in
+particular, while FUSE client should not, in particular, send WRITE
+requests with > negotiated max_write payload. FUSE client in kernel and
+libfuse historically reserve 4K for request header. This way the
+contract is that filesystem server should queue sys_reads with
+4K+max_write buffer.
+
+If the filesystem server does not follow this contract, what can happen
+is that fuse_dev_do_read will see that request size is > buffer size,
+and then it will return EIO to client who issued the request but won't
+indicate in any way that there is a problem to filesystem server.
+This can be hard to diagnose because for some requests, e.g. for
+NOTIFY_REPLY which mimics WRITE, there is no client thread that is
+waiting for request completion and that EIO goes nowhere, while on
+filesystem server side things look like the kernel is not replying back
+after successful NOTIFY_RETRIEVE request made by the server.
+
+We can make the problem easy to diagnose if we indicate via error return to
+filesystem server when it is violating the contract. This should not
+practically cause problems because if a filesystem server is using shorter
+buffer, writes to it were already very likely to cause EIO, and if the
+filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER
+minimum buffer size.
+
+Please see [1] for context where the problem of stuck filesystem was hit
+for real (because kernel client was incorrectly sending more than
+max_write data with NOTIFY_REPLY; see also previous patch), how the
+situation was traced and for more involving patch that did not make it
+into the tree.
+
+[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
+
+Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
+Cc: Han-Wen Nienhuys <hanwen@google.com>
+Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/fuse/dev.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
+index 341196338e48..fbb978e75c6b 100644
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -1265,6 +1265,16 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file,
+ struct fuse_in *in;
+ unsigned reqsize;
+
++ /*
++ * Require sane minimum read buffer - that has capacity for fixed part
++ * of any request header + negotated max_write room for data. If the
++ * requirement is not satisfied return EINVAL to the filesystem server
++ * to indicate that it is not following FUSE server/client contract.
++ * Don't dequeue / abort any request.
++ */
++ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, 4096 + fc->max_write))
++ return -EINVAL;
++
+ restart:
+ spin_lock(&fiq->waitq.lock);
+ err = -EAGAIN;
+--
+2.20.1
+
--- /dev/null
+From 4fbe9532e5ad894e9e5b31af8c261c533eba2645 Mon Sep 17 00:00:00 2001
+From: Kirill Smelkov <kirr@nexedi.com>
+Date: Wed, 27 Mar 2019 10:15:19 +0000
+Subject: fuse: retrieve: cap requested size to negotiated max_write
+
+[ Upstream commit 7640682e67b33cab8628729afec8ca92b851394f ]
+
+FUSE filesystem server and kernel client negotiate during initialization
+phase, what should be the maximum write size the client will ever issue.
+Correspondingly the filesystem server then queues sys_read calls to read
+requests with buffer capacity large enough to carry request header + that
+max_write bytes. A filesystem server is free to set its max_write in
+anywhere in the range between [1*page, fc->max_pages*page]. In particular
+go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages
+corresponds to 128K. Libfuse also allows users to configure max_write, but
+by default presets it to possible maximum.
+
+If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we
+allow to retrieve more than max_write bytes, corresponding prepared
+NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the
+filesystem server, in full correspondence with server/client contract, will
+be only queuing sys_read with ~max_write buffer capacity, and
+fuse_dev_do_read throws away requests that cannot fit into server request
+buffer. In turn the filesystem server could get stuck waiting indefinitely
+for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is
+understood by clients as that NOTIFY_REPLY was queued and will be sent
+back.
+
+Cap requested size to negotiate max_write to avoid the problem. This
+aligns with the way NOTIFY_RETRIEVE handler works, which already
+unconditionally caps requested retrieve size to fuse_conn->max_pages. This
+way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than
+was originally requested.
+
+Please see [1] for context where the problem of stuck filesystem was hit
+for real, how the situation was traced and for more involving patch that
+did not make it into the tree.
+
+[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
+[2] https://github.com/hanwen/go-fuse
+
+Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
+Cc: Han-Wen Nienhuys <hanwen@google.com>
+Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/fuse/dev.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
+index fbb978e75c6b..217ceca3eb06 100644
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -1734,7 +1734,7 @@ static int fuse_retrieve(struct fuse_conn *fc, struct inode *inode,
+ offset = outarg->offset & ~PAGE_CACHE_MASK;
+ file_size = i_size_read(inode);
+
+- num = outarg->size;
++ num = min(outarg->size, fc->max_write);
+ if (outarg->offset > file_size)
+ num = 0;
+ else if (outarg->offset + num > file_size)
+--
+2.20.1
+
--- /dev/null
+From bceae35d08e8b1837dc4e45cc0c273d8838a43eb Mon Sep 17 00:00:00 2001
+From: Tony Lindgren <tony@atomide.com>
+Date: Mon, 25 Mar 2019 15:43:18 -0700
+Subject: gpio: gpio-omap: add check for off wake capable gpios
+
+[ Upstream commit da38ef3ed10a09248e13ae16530c2c6d448dc47d ]
+
+We are currently assuming all GPIOs are non-wakeup capable GPIOs as we
+not configuring the bank->non_wakeup_gpios like we used to earlier with
+platform_data.
+
+Let's add omap_gpio_is_off_wakeup_capable() to make the handling clearer
+while considering that later patches may want to configure SoC specific
+bank->non_wakeup_gpios for the GPIOs in wakeup domain.
+
+Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
+Cc: Grygorii Strashko <grygorii.strashko@ti.com>
+Cc: Keerthy <j-keerthy@ti.com>
+Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Cc: Russell King <rmk+kernel@armlinux.org.uk>
+Cc: Tero Kristo <t-kristo@ti.com>
+Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpio/gpio-omap.c | 25 +++++++++++++++++--------
+ 1 file changed, 17 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
+index 9943273ec981..c8c49b1d5f9f 100644
+--- a/drivers/gpio/gpio-omap.c
++++ b/drivers/gpio/gpio-omap.c
+@@ -292,6 +292,22 @@ static void omap_clear_gpio_debounce(struct gpio_bank *bank, unsigned offset)
+ }
+ }
+
++/*
++ * Off mode wake-up capable GPIOs in bank(s) that are in the wakeup domain.
++ * See TRM section for GPIO for "Wake-Up Generation" for the list of GPIOs
++ * in wakeup domain. If bank->non_wakeup_gpios is not configured, assume none
++ * are capable waking up the system from off mode.
++ */
++static bool omap_gpio_is_off_wakeup_capable(struct gpio_bank *bank, u32 gpio_mask)
++{
++ u32 no_wake = bank->non_wakeup_gpios;
++
++ if (no_wake)
++ return !!(~no_wake & gpio_mask);
++
++ return false;
++}
++
+ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio,
+ unsigned trigger)
+ {
+@@ -323,13 +339,7 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio,
+ }
+
+ /* This part needs to be executed always for OMAP{34xx, 44xx} */
+- if (!bank->regs->irqctrl) {
+- /* On omap24xx proceed only when valid GPIO bit is set */
+- if (bank->non_wakeup_gpios) {
+- if (!(bank->non_wakeup_gpios & gpio_bit))
+- goto exit;
+- }
+-
++ if (!bank->regs->irqctrl && !omap_gpio_is_off_wakeup_capable(bank, gpio)) {
+ /*
+ * Log the edge gpio and manually trigger the IRQ
+ * after resume if the input level changes
+@@ -342,7 +352,6 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio,
+ bank->enabled_non_wakeup_gpios &= ~gpio_bit;
+ }
+
+-exit:
+ bank->level_mask =
+ readl_relaxed(bank->base + bank->regs->leveldetect0) |
+ readl_relaxed(bank->base + bank->regs->leveldetect1);
+--
+2.20.1
+
--- /dev/null
+From 6a69977c7e149421924f088e53271f59e7e3e6e8 Mon Sep 17 00:00:00 2001
+From: Mike Kravetz <mike.kravetz@oracle.com>
+Date: Mon, 13 May 2019 17:19:38 -0700
+Subject: hugetlbfs: on restore reserve error path retain subpool reservation
+
+[ Upstream commit 0919e1b69ab459e06df45d3ba6658d281962db80 ]
+
+When a huge page is allocated, PagePrivate() is set if the allocation
+consumed a reservation. When freeing a huge page, PagePrivate is checked.
+If set, it indicates the reservation should be restored. PagePrivate
+being set at free huge page time mostly happens on error paths.
+
+When huge page reservations are created, a check is made to determine if
+the mapping is associated with an explicitly mounted filesystem. If so,
+pages are also reserved within the filesystem. The default action when
+freeing a huge page is to decrement the usage count in any associated
+explicitly mounted filesystem. However, if the reservation is to be
+restored the reservation/use count within the filesystem should not be
+decrementd. Otherwise, a subsequent page allocation and free for the same
+mapping location will cause the file filesystem usage to go 'negative'.
+
+Filesystem Size Used Avail Use% Mounted on
+nodev 4.0G -4.0M 4.1G - /opt/hugepool
+
+To fix, when freeing a huge page do not adjust filesystem usage if
+PagePrivate() is set to indicate the reservation should be restored.
+
+I did not cc stable as the problem has been around since reserves were
+added to hugetlbfs and nobody has noticed.
+
+Link: http://lkml.kernel.org/r/20190328234704.27083-2-mike.kravetz@oracle.com
+Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
+Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Cc: Davidlohr Bueso <dave@stgolabs.net>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/hugetlb.c | 21 ++++++++++++++++-----
+ 1 file changed, 16 insertions(+), 5 deletions(-)
+
+diff --git a/mm/hugetlb.c b/mm/hugetlb.c
+index d7f65a8c629b..fd932e7a25dd 100644
+--- a/mm/hugetlb.c
++++ b/mm/hugetlb.c
+@@ -1221,12 +1221,23 @@ void free_huge_page(struct page *page)
+ ClearPagePrivate(page);
+
+ /*
+- * A return code of zero implies that the subpool will be under its
+- * minimum size if the reservation is not restored after page is free.
+- * Therefore, force restore_reserve operation.
++ * If PagePrivate() was set on page, page allocation consumed a
++ * reservation. If the page was associated with a subpool, there
++ * would have been a page reserved in the subpool before allocation
++ * via hugepage_subpool_get_pages(). Since we are 'restoring' the
++ * reservtion, do not call hugepage_subpool_put_pages() as this will
++ * remove the reserved page from the subpool.
+ */
+- if (hugepage_subpool_put_pages(spool, 1) == 0)
+- restore_reserve = true;
++ if (!restore_reserve) {
++ /*
++ * A return code of zero implies that the subpool will be
++ * under its minimum size if the reservation is not restored
++ * after page is free. Therefore, force restore_reserve
++ * operation.
++ */
++ if (hugepage_subpool_put_pages(spool, 1) == 0)
++ restore_reserve = true;
++ }
+
+ spin_lock(&hugetlb_lock);
+ clear_page_huge_active(page);
+--
+2.20.1
+
--- /dev/null
+From 56b35336153b3d464378fa327278691bff0fa583 Mon Sep 17 00:00:00 2001
+From: Lu Baolu <baolu.lu@linux.intel.com>
+Date: Thu, 2 May 2019 09:34:25 +0800
+Subject: iommu/vt-d: Set intel_iommu_gfx_mapped correctly
+
+[ Upstream commit cf1ec4539a50bdfe688caad4615ca47646884316 ]
+
+The intel_iommu_gfx_mapped flag is exported by the Intel
+IOMMU driver to indicate whether an IOMMU is used for the
+graphic device. In a virtualized IOMMU environment (e.g.
+QEMU), an include-all IOMMU is used for graphic device.
+This flag is found to be clear even the IOMMU is used.
+
+Cc: Ashok Raj <ashok.raj@intel.com>
+Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
+Cc: Kevin Tian <kevin.tian@intel.com>
+Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
+Fixes: c0771df8d5297 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.")
+Suggested-by: Kevin Tian <kevin.tian@intel.com>
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/intel-iommu.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
+index 3e97c4b2ebed..b965561a4162 100644
+--- a/drivers/iommu/intel-iommu.c
++++ b/drivers/iommu/intel-iommu.c
+@@ -3983,9 +3983,7 @@ static void __init init_no_remapping_devices(void)
+
+ /* This IOMMU has *only* gfx devices. Either bypass it or
+ set the gfx_mapped flag, as appropriate */
+- if (dmar_map_gfx) {
+- intel_iommu_gfx_mapped = 1;
+- } else {
++ if (!dmar_map_gfx) {
+ drhd->ignored = 1;
+ for_each_active_dev_scope(drhd->devices,
+ drhd->devices_cnt, i, dev)
+@@ -4694,6 +4692,9 @@ int __init intel_iommu_init(void)
+ goto out_free_reserved_range;
+ }
+
++ if (dmar_map_gfx)
++ intel_iommu_gfx_mapped = 1;
++
+ init_no_remapping_devices();
+
+ ret = init_dmars();
+--
+2.20.1
+
--- /dev/null
+From 6bc3c95119240baef5efa4de21cd493d433e85b9 Mon Sep 17 00:00:00 2001
+From: Li Rongqing <lirongqing@baidu.com>
+Date: Tue, 14 May 2019 15:46:20 -0700
+Subject: ipc: prevent lockup on alloc_msg and free_msg
+
+[ Upstream commit d6a2946a88f524a47cc9b79279667137899db807 ]
+
+msgctl10 of ltp triggers the following lockup When CONFIG_KASAN is
+enabled on large memory SMP systems, the pages initialization can take a
+long time, if msgctl10 requests a huge block memory, and it will block
+rcu scheduler, so release cpu actively.
+
+After adding schedule() in free_msg, free_msg can not be called when
+holding spinlock, so adding msg to a tmp list, and free it out of
+spinlock
+
+ rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+ rcu: Tasks blocked on level-1 rcu_node (CPUs 16-31): P32505
+ rcu: Tasks blocked on level-1 rcu_node (CPUs 48-63): P34978
+ rcu: (detected by 11, t=35024 jiffies, g=44237529, q=16542267)
+ msgctl10 R running task 21608 32505 2794 0x00000082
+ Call Trace:
+ preempt_schedule_irq+0x4c/0xb0
+ retint_kernel+0x1b/0x2d
+ RIP: 0010:__is_insn_slot_addr+0xfb/0x250
+ Code: 82 1d 00 48 8b 9b 90 00 00 00 4c 89 f7 49 c1 ee 03 e8 59 83 1d 00 48 b8 00 00 00 00 00 fc ff df 4c 39 eb 48 89 9d 58 ff ff ff <41> c6 04 06 f8 74 66 4c 8d 75 98 4c 89 f1 48 c1 e9 03 48 01 c8 48
+ RSP: 0018:ffff88bce041f758 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
+ RAX: dffffc0000000000 RBX: ffffffff8471bc50 RCX: ffffffff828a2a57
+ RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff88bce041f780
+ RBP: ffff88bce041f828 R08: ffffed15f3f4c5b3 R09: ffffed15f3f4c5b3
+ R10: 0000000000000001 R11: ffffed15f3f4c5b2 R12: 000000318aee9b73
+ R13: ffffffff8471bc50 R14: 1ffff1179c083ef0 R15: 1ffff1179c083eec
+ kernel_text_address+0xc1/0x100
+ __kernel_text_address+0xe/0x30
+ unwind_get_return_address+0x2f/0x50
+ __save_stack_trace+0x92/0x100
+ create_object+0x380/0x650
+ __kmalloc+0x14c/0x2b0
+ load_msg+0x38/0x1a0
+ do_msgsnd+0x19e/0xcf0
+ do_syscall_64+0x117/0x400
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+ rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+ rcu: Tasks blocked on level-1 rcu_node (CPUs 0-15): P32170
+ rcu: (detected by 14, t=35016 jiffies, g=44237525, q=12423063)
+ msgctl10 R running task 21608 32170 32155 0x00000082
+ Call Trace:
+ preempt_schedule_irq+0x4c/0xb0
+ retint_kernel+0x1b/0x2d
+ RIP: 0010:lock_acquire+0x4d/0x340
+ Code: 48 81 ec c0 00 00 00 45 89 c6 4d 89 cf 48 8d 6c 24 20 48 89 3c 24 48 8d bb e4 0c 00 00 89 74 24 0c 48 c7 44 24 20 b3 8a b5 41 <48> c1 ed 03 48 c7 44 24 28 b4 25 18 84 48 c7 44 24 30 d0 54 7a 82
+ RSP: 0018:ffff88af83417738 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
+ RAX: dffffc0000000000 RBX: ffff88bd335f3080 RCX: 0000000000000002
+ RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88bd335f3d64
+ RBP: ffff88af83417758 R08: 0000000000000000 R09: 0000000000000000
+ R10: 0000000000000001 R11: ffffed13f3f745b2 R12: 0000000000000000
+ R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000
+ is_bpf_text_address+0x32/0xe0
+ kernel_text_address+0xec/0x100
+ __kernel_text_address+0xe/0x30
+ unwind_get_return_address+0x2f/0x50
+ __save_stack_trace+0x92/0x100
+ save_stack+0x32/0xb0
+ __kasan_slab_free+0x130/0x180
+ kfree+0xfa/0x2d0
+ free_msg+0x24/0x50
+ do_msgrcv+0x508/0xe60
+ do_syscall_64+0x117/0x400
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Davidlohr said:
+ "So after releasing the lock, the msg rbtree/list is empty and new
+ calls will not see those in the newly populated tmp_msg list, and
+ therefore they cannot access the delayed msg freeing pointers, which
+ is good. Also the fact that the node_cache is now freed before the
+ actual messages seems to be harmless as this is wanted for
+ msg_insert() avoiding GFP_ATOMIC allocations, and after releasing the
+ info->lock the thing is freed anyway so it should not change things"
+
+Link: http://lkml.kernel.org/r/1552029161-4957-1-git-send-email-lirongqing@baidu.com
+Signed-off-by: Li RongQing <lirongqing@baidu.com>
+Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
+Reviewed-by: Davidlohr Bueso <dbueso@suse.de>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ ipc/mqueue.c | 10 ++++++++--
+ ipc/msgutil.c | 6 ++++++
+ 2 files changed, 14 insertions(+), 2 deletions(-)
+
+diff --git a/ipc/mqueue.c b/ipc/mqueue.c
+index 5e24eb0ab5dd..6ed74825ab54 100644
+--- a/ipc/mqueue.c
++++ b/ipc/mqueue.c
+@@ -373,7 +373,8 @@ static void mqueue_evict_inode(struct inode *inode)
+ struct user_struct *user;
+ unsigned long mq_bytes, mq_treesize;
+ struct ipc_namespace *ipc_ns;
+- struct msg_msg *msg;
++ struct msg_msg *msg, *nmsg;
++ LIST_HEAD(tmp_msg);
+
+ clear_inode(inode);
+
+@@ -384,10 +385,15 @@ static void mqueue_evict_inode(struct inode *inode)
+ info = MQUEUE_I(inode);
+ spin_lock(&info->lock);
+ while ((msg = msg_get(info)) != NULL)
+- free_msg(msg);
++ list_add_tail(&msg->m_list, &tmp_msg);
+ kfree(info->node_cache);
+ spin_unlock(&info->lock);
+
++ list_for_each_entry_safe(msg, nmsg, &tmp_msg, m_list) {
++ list_del(&msg->m_list);
++ free_msg(msg);
++ }
++
+ /* Total amount of bytes accounted for the mqueue */
+ mq_treesize = info->attr.mq_maxmsg * sizeof(struct msg_msg) +
+ min_t(unsigned int, info->attr.mq_maxmsg, MQ_PRIO_MAX) *
+diff --git a/ipc/msgutil.c b/ipc/msgutil.c
+index ed81aafd2392..9467307487f7 100644
+--- a/ipc/msgutil.c
++++ b/ipc/msgutil.c
+@@ -18,6 +18,7 @@
+ #include <linux/utsname.h>
+ #include <linux/proc_ns.h>
+ #include <linux/uaccess.h>
++#include <linux/sched.h>
+
+ #include "util.h"
+
+@@ -66,6 +67,9 @@ static struct msg_msg *alloc_msg(size_t len)
+ pseg = &msg->next;
+ while (len > 0) {
+ struct msg_msgseg *seg;
++
++ cond_resched();
++
+ alen = min(len, DATALEN_SEG);
+ seg = kmalloc(sizeof(*seg) + alen, GFP_KERNEL);
+ if (seg == NULL)
+@@ -178,6 +182,8 @@ void free_msg(struct msg_msg *msg)
+ kfree(msg);
+ while (seg != NULL) {
+ struct msg_msgseg *tmp = seg->next;
++
++ cond_resched();
+ kfree(seg);
+ seg = tmp;
+ }
+--
+2.20.1
+
--- /dev/null
+From 17dde14f3f15e1c23336af513b230c8bff901fda Mon Sep 17 00:00:00 2001
+From: Cyrill Gorcunov <gorcunov@gmail.com>
+Date: Mon, 13 May 2019 17:15:40 -0700
+Subject: kernel/sys.c: prctl: fix false positive in validate_prctl_map()
+
+[ Upstream commit a9e73998f9d705c94a8dca9687633adc0f24a19a ]
+
+While validating new map we require the @start_data to be strictly less
+than @end_data, which is fine for regular applications (this is why this
+nit didn't trigger for that long). These members are set from executable
+loaders such as elf handers, still it is pretty valid to have a loadable
+data section with zero size in file, in such case the start_data is equal
+to end_data once kernel loader finishes.
+
+As a result when we're trying to restore such programs the procedure fails
+and the kernel returns -EINVAL. From the image dump of a program:
+
+ | "mm_start_code": "0x400000",
+ | "mm_end_code": "0x8f5fb4",
+ | "mm_start_data": "0xf1bfb0",
+ | "mm_end_data": "0xf1bfb0",
+
+Thus we need to change validate_prctl_map from strictly less to less or
+equal operator use.
+
+Link: http://lkml.kernel.org/r/20190408143554.GY1421@uranus.lan
+Fixes: f606b77f1a9e3 ("prctl: PR_SET_MM -- introduce PR_SET_MM_MAP operation")
+Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
+Cc: Andrey Vagin <avagin@gmail.com>
+Cc: Dmitry Safonov <0x7f454c46@gmail.com>
+Cc: Pavel Emelyanov <xemul@virtuozzo.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sys.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/sys.c b/kernel/sys.c
+index e2446ade79ba..1855f1bf113e 100644
+--- a/kernel/sys.c
++++ b/kernel/sys.c
+@@ -1762,7 +1762,7 @@ static int validate_prctl_map(struct prctl_mm_map *prctl_map)
+ ((unsigned long)prctl_map->__m1 __op \
+ (unsigned long)prctl_map->__m2) ? 0 : -EINVAL
+ error = __prctl_check_order(start_code, <, end_code);
+- error |= __prctl_check_order(start_data, <, end_data);
++ error |= __prctl_check_order(start_data,<=, end_data);
+ error |= __prctl_check_order(start_brk, <=, brk);
+ error |= __prctl_check_order(arg_start, <=, arg_end);
+ error |= __prctl_check_order(env_start, <=, env_end);
+--
+2.20.1
+
--- /dev/null
+From 0a4f00b614550ce53cf1ce0ae9857987592a0d3c Mon Sep 17 00:00:00 2001
+From: Binbin Wu <binbin.wu@intel.com>
+Date: Mon, 8 Apr 2019 16:09:10 +0800
+Subject: mfd: intel-lpss: Set the device in reset state when init
+
+[ Upstream commit dad06532292d77f37fbe831a02948a593500f682 ]
+
+In virtualized setup, when system reboots due to warm
+reset interrupt storm is seen.
+
+Call Trace:
+<IRQ>
+dump_stack+0x70/0xa5
+__report_bad_irq+0x2e/0xc0
+note_interrupt+0x248/0x290
+? add_interrupt_randomness+0x30/0x220
+handle_irq_event_percpu+0x54/0x80
+handle_irq_event+0x39/0x60
+handle_fasteoi_irq+0x91/0x150
+handle_irq+0x108/0x180
+do_IRQ+0x52/0xf0
+common_interrupt+0xf/0xf
+</IRQ>
+RIP: 0033:0x76fc2cfabc1d
+Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
+94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
+<48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
+24
+RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
+RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
+RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
+RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
+R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
+R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
+handlers:
+[<000000000d3fa913>] idma64_irq
+Disabling IRQ #27
+
+To avoid interrupt storm, set the device in reset state
+before bringing out the device from reset state.
+
+Changelog v2:
+- correct the subject line by adding "mfd: "
+
+Signed-off-by: Binbin Wu <binbin.wu@intel.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/intel-lpss.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
+index ac867489b5a9..498875193386 100644
+--- a/drivers/mfd/intel-lpss.c
++++ b/drivers/mfd/intel-lpss.c
+@@ -267,6 +267,9 @@ static void intel_lpss_init_dev(const struct intel_lpss *lpss)
+ {
+ u32 value = LPSS_PRIV_SSP_REG_DIS_DMA_FIN;
+
++ /* Set the device in reset state */
++ writel(0, lpss->priv + LPSS_PRIV_RESETS);
++
+ intel_lpss_deassert_reset(lpss);
+
+ intel_lpss_set_remap_addr(lpss);
+--
+2.20.1
+
--- /dev/null
+From 91f2d31a311fa0f5a43a3ef007612585da041412 Mon Sep 17 00:00:00 2001
+From: Tony Lindgren <tony@atomide.com>
+Date: Thu, 14 Feb 2019 08:03:45 -0800
+Subject: mfd: twl6040: Fix device init errors for ACCCTL register
+
+[ Upstream commit 48171d0ea7caccf21c9ee3ae75eb370f2a756062 ]
+
+I noticed that we can get a -EREMOTEIO errors on at least omap4 duovero:
+
+twl6040 0-004b: Failed to write 2d = 19: -121
+
+And then any following register access will produce errors.
+
+There 2d offset above is register ACCCTL that gets written on twl6040
+powerup. With error checking added to the related regcache_sync() call,
+the -EREMOTEIO error is reproducable on twl6040 powerup at least
+duovero.
+
+To fix the error, we need to wait until twl6040 is accessible after the
+powerup. Based on tests on omap4 duovero, we need to wait over 8ms after
+powerup before register write will complete without failures. Let's also
+make sure we warn about possible errors too.
+
+Note that we have twl6040_patch[] reg_sequence with the ACCCTL register
+configuration and regcache_sync() will write the new value to ACCCTL.
+
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/twl6040.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
+index 72aab60ae846..db8684430f02 100644
+--- a/drivers/mfd/twl6040.c
++++ b/drivers/mfd/twl6040.c
+@@ -316,8 +316,19 @@ int twl6040_power(struct twl6040 *twl6040, int on)
+ }
+ }
+
++ /*
++ * Register access can produce errors after power-up unless we
++ * wait at least 8ms based on measurements on duovero.
++ */
++ usleep_range(10000, 12000);
++
+ /* Sync with the HW */
+- regcache_sync(twl6040->regmap);
++ ret = regcache_sync(twl6040->regmap);
++ if (ret) {
++ dev_err(twl6040->dev, "Failed to sync with the HW: %i\n",
++ ret);
++ goto out;
++ }
+
+ /* Default PLL configuration after power up */
+ twl6040->pll = TWL6040_SYSCLK_SEL_LPPLL;
+--
+2.20.1
+
--- /dev/null
+From d7a01b245fdc005813d77cd8b418df7236644b50 Mon Sep 17 00:00:00 2001
+From: Serge Semin <fancer.lancer@gmail.com>
+Date: Fri, 3 May 2019 20:50:40 +0300
+Subject: mips: Make sure dt memory regions are valid
+
+[ Upstream commit 93fa5b280761a4dbb14c5330f260380385ab2b49 ]
+
+There are situations when memory regions coming from dts may be
+too big for the platform physical address space. This especially
+concerns XPA-capable systems. Bootloader may determine more than 4GB
+memory available and pass it to the kernel over dts memory node, while
+kernel is built without XPA/64BIT support. In this case the region
+may either simply be truncated by add_memory_region() method
+or by u64->phys_addr_t type casting. But in worst case the method
+can even drop the memory region if it exceeds PHYS_ADDR_MAX size.
+So lets make sure the retrieved from dts memory regions are valid,
+and if some of them aren't, just manually truncate them with a warning
+printed out.
+
+Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: James Hogan <jhogan@kernel.org>
+Cc: Mike Rapoport <rppt@linux.ibm.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Thomas Bogendoerfer <tbogendoerfer@suse.de>
+Cc: Huacai Chen <chenhc@lemote.com>
+Cc: Stefan Agner <stefan@agner.ch>
+Cc: Stephen Rothwell <sfr@canb.auug.org.au>
+Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Serge Semin <Sergey.Semin@t-platforms.ru>
+Cc: linux-mips@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kernel/prom.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
+index 5fcec3032f38..6131807799b4 100644
+--- a/arch/mips/kernel/prom.c
++++ b/arch/mips/kernel/prom.c
+@@ -41,7 +41,19 @@ char *mips_get_machine_name(void)
+ #ifdef CONFIG_USE_OF
+ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+ {
+- return add_memory_region(base, size, BOOT_MEM_RAM);
++ if (base >= PHYS_ADDR_MAX) {
++ pr_warn("Trying to add an invalid memory region, skipped\n");
++ return;
++ }
++
++ /* Truncate the passed memory region instead of type casting */
++ if (base + size - 1 >= PHYS_ADDR_MAX || base + size < base) {
++ pr_warn("Truncate memory region %llx @ %llx to size %llx\n",
++ size, base, PHYS_ADDR_MAX - base);
++ size = PHYS_ADDR_MAX - base;
++ }
++
++ add_memory_region(base, size, BOOT_MEM_RAM);
+ }
+
+ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
+--
+2.20.1
+
--- /dev/null
+From 4d2dc308433590e5e82e4583e1b56031351ae5b0 Mon Sep 17 00:00:00 2001
+From: Yue Hu <huyue2@yulong.com>
+Date: Mon, 13 May 2019 17:18:14 -0700
+Subject: mm/cma.c: fix crash on CMA allocation if bitmap allocation fails
+
+[ Upstream commit 1df3a339074e31db95c4790ea9236874b13ccd87 ]
+
+f022d8cb7ec7 ("mm: cma: Don't crash on allocation if CMA area can't be
+activated") fixes the crash issue when activation fails via setting
+cma->count as 0, same logic exists if bitmap allocation fails.
+
+Link: http://lkml.kernel.org/r/20190325081309.6004-1-zbestahu@gmail.com
+Signed-off-by: Yue Hu <huyue2@yulong.com>
+Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Laura Abbott <labbott@redhat.com>
+Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
+Cc: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/cma.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/mm/cma.c b/mm/cma.c
+index f0d91aca5a4c..5ae4452656cd 100644
+--- a/mm/cma.c
++++ b/mm/cma.c
+@@ -100,8 +100,10 @@ static int __init cma_activate_area(struct cma *cma)
+
+ cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+
+- if (!cma->bitmap)
++ if (!cma->bitmap) {
++ cma->count = 0;
+ return -ENOMEM;
++ }
+
+ WARN_ON_ONCE(!pfn_valid(pfn));
+ zone = page_zone(pfn_to_page(pfn));
+--
+2.20.1
+
--- /dev/null
+From 6f96370ea6b4bbdb599969cedd19ccda6bba865a Mon Sep 17 00:00:00 2001
+From: Yue Hu <huyue2@yulong.com>
+Date: Mon, 13 May 2019 17:16:37 -0700
+Subject: mm/cma_debug.c: fix the break condition in cma_maxchunk_get()
+
+[ Upstream commit f0fd50504a54f5548eb666dc16ddf8394e44e4b7 ]
+
+If not find zero bit in find_next_zero_bit(), it will return the size
+parameter passed in, so the start bit should be compared with bitmap_maxno
+rather than cma->count. Although getting maxchunk is working fine due to
+zero value of order_per_bit currently, the operation will be stuck if
+order_per_bit is set as non-zero.
+
+Link: http://lkml.kernel.org/r/20190319092734.276-1-zbestahu@gmail.com
+Signed-off-by: Yue Hu <huyue2@yulong.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Joe Perches <joe@perches.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Dmitry Safonov <d.safonov@partner.samsung.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/cma_debug.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mm/cma_debug.c b/mm/cma_debug.c
+index f8e4b60db167..da50dab56b70 100644
+--- a/mm/cma_debug.c
++++ b/mm/cma_debug.c
+@@ -57,7 +57,7 @@ static int cma_maxchunk_get(void *data, u64 *val)
+ mutex_lock(&cma->lock);
+ for (;;) {
+ start = find_next_zero_bit(cma->bitmap, bitmap_maxno, end);
+- if (start >= cma->count)
++ if (start >= bitmap_maxno)
+ break;
+ end = find_next_bit(cma->bitmap, bitmap_maxno, start);
+ maxchunk = max(end - start, maxchunk);
+--
+2.20.1
+
--- /dev/null
+From e9d71f0e30c4151c0b77d4750c9287a5ecd4ebfb Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Fri, 12 Apr 2019 16:37:30 -0400
+Subject: nfsd: allow fh_want_write to be called twice
+
+[ Upstream commit 0b8f62625dc309651d0efcb6a6247c933acd8b45 ]
+
+A fuzzer recently triggered lockdep warnings about potential sb_writers
+deadlocks caused by fh_want_write().
+
+Looks like we aren't careful to pair each fh_want_write() with an
+fh_drop_write().
+
+It's not normally a problem since fh_put() will call fh_drop_write() for
+us. And was OK for NFSv3 where we'd do one operation that might call
+fh_want_write(), and then put the filehandle.
+
+But an NFSv4 protocol fuzzer can do weird things like call unlink twice
+in a compound, and then we get into trouble.
+
+I'm a little worried about this approach of just leaving everything to
+fh_put(). But I think there are probably a lot of
+fh_want_write()/fh_drop_write() imbalances so for now I think we need it
+to be more forgiving.
+
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/vfs.h | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
+index fcfc48cbe136..128d6e216fd7 100644
+--- a/fs/nfsd/vfs.h
++++ b/fs/nfsd/vfs.h
+@@ -109,8 +109,11 @@ void nfsd_put_raparams(struct file *file, struct raparms *ra);
+
+ static inline int fh_want_write(struct svc_fh *fh)
+ {
+- int ret = mnt_want_write(fh->fh_export->ex_path.mnt);
++ int ret;
+
++ if (fh->fh_want_write)
++ return 0;
++ ret = mnt_want_write(fh->fh_export->ex_path.mnt);
+ if (!ret)
+ fh->fh_want_write = true;
+ return ret;
+--
+2.20.1
+
--- /dev/null
+From b1d88de7f28c6840e83c2c5c7de972a5ac296136 Mon Sep 17 00:00:00 2001
+From: Miroslav Lichvar <mlichvar@redhat.com>
+Date: Wed, 17 Apr 2019 10:48:33 +0200
+Subject: ntp: Allow TAI-UTC offset to be set to zero
+
+[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
+
+The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
+It is typically set by NTP/PTP implementations and it is automatically
+updated by the kernel on leap seconds. The initial value is zero (which
+applications may interpret as unknown), but this value cannot be set by
+adjtimex. This limitation seems to go back to the original "nanokernel"
+implementation by David Mills.
+
+Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in
+order to allow setting it back to the initial value.
+
+Fixes: 153b5d054ac2 ("ntp: support for TAI")
+Suggested-by: Ondrej Mosnacek <omosnace@redhat.com>
+Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Richard Cochran <richardcochran@gmail.com>
+Cc: Prarit Bhargava <prarit@redhat.com>
+Link: https://lkml.kernel.org/r/20190417084833.7401-1-mlichvar@redhat.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/time/ntp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
+index ab861771e37f..0e0dc5d89911 100644
+--- a/kernel/time/ntp.c
++++ b/kernel/time/ntp.c
+@@ -633,7 +633,7 @@ static inline void process_adjtimex_modes(struct timex *txc,
+ time_constant = max(time_constant, 0l);
+ }
+
+- if (txc->modes & ADJ_TAI && txc->constant > 0)
++ if (txc->modes & ADJ_TAI && txc->constant >= 0)
+ *time_tai = txc->constant;
+
+ if (txc->modes & ADJ_OFFSET)
+--
+2.20.1
+
--- /dev/null
+From 38ef89cf92c2b1cf2aacb011fcf155a04e5e37eb Mon Sep 17 00:00:00 2001
+From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+Date: Sat, 13 Apr 2019 11:32:58 +0100
+Subject: nvmem: core: fix read buffer in place
+
+[ Upstream commit 2fe518fecb3a4727393be286db9804cd82ee2d91 ]
+
+When the bit_offset in the cell is zero, the pointer to the msb will
+not be properly initialized (ie, will still be pointing to the first
+byte in the buffer).
+
+This being the case, if there are bits to clear in the msb, those will
+be left untouched while the mask will incorrectly clear bit positions
+on the first byte.
+
+This commit also makes sure that any byte unused in the cell is
+cleared.
+
+Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvmem/core.c | 15 ++++++++++-----
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
+index 6fd4e5a5ef4a..931cc33e46f0 100644
+--- a/drivers/nvmem/core.c
++++ b/drivers/nvmem/core.c
+@@ -789,7 +789,7 @@ static inline void nvmem_shift_read_buffer_in_place(struct nvmem_cell *cell,
+ void *buf)
+ {
+ u8 *p, *b;
+- int i, bit_offset = cell->bit_offset;
++ int i, extra, bit_offset = cell->bit_offset;
+
+ p = b = buf;
+ if (bit_offset) {
+@@ -804,11 +804,16 @@ static inline void nvmem_shift_read_buffer_in_place(struct nvmem_cell *cell,
+ p = b;
+ *b++ >>= bit_offset;
+ }
+-
+- /* result fits in less bytes */
+- if (cell->bytes != DIV_ROUND_UP(cell->nbits, BITS_PER_BYTE))
+- *p-- = 0;
++ } else {
++ /* point to the msb */
++ p += cell->bytes - 1;
+ }
++
++ /* result fits in less bytes */
++ extra = cell->bytes - DIV_ROUND_UP(cell->nbits, BITS_PER_BYTE);
++ while (--extra >= 0)
++ *p-- = 0;
++
+ /* clear msb bits if any leftover in the last byte */
+ *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
+ }
+--
+2.20.1
+
--- /dev/null
+From a71520327e749c703d4e873e5abb48f4ccea6da4 Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Fri, 15 Mar 2019 02:29:43 -0500
+Subject: PCI: rcar: Fix a potential NULL pointer dereference
+
+[ Upstream commit f0d14edd2ba43b995bef4dd5da5ffe0ae19321a1 ]
+
+In case __get_free_pages() fails and returns NULL, fix the return
+value to -ENOMEM and release resources to avoid dereferencing a
+NULL pointer.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/host/pcie-rcar.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
+index 414c33686621..b18cf12731ee 100644
+--- a/drivers/pci/host/pcie-rcar.c
++++ b/drivers/pci/host/pcie-rcar.c
+@@ -737,6 +737,10 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
+
+ /* setup MSI data target */
+ msi->pages = __get_free_pages(GFP_KERNEL, 0);
++ if (!msi->pages) {
++ err = -ENOMEM;
++ goto err;
++ }
+ base = virt_to_phys((void *)msi->pages);
+
+ rcar_pci_write_reg(pcie, base | MSIFE, PCIEMSIALR);
+--
+2.20.1
+
--- /dev/null
+From a1d50cc0cf82c76e9be9d1aad951d743bcd9f367 Mon Sep 17 00:00:00 2001
+From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
+Date: Fri, 22 Mar 2019 13:27:21 -0500
+Subject: PCI: rpadlpar: Fix leaked device_node references in add/remove paths
+
+[ Upstream commit fb26228bfc4ce3951544848555c0278e2832e618 ]
+
+The find_dlpar_node() helper returns a device node with its reference
+incremented. Both the add and remove paths use this helper for find the
+appropriate node, but fail to release the reference when done.
+
+Annotate the find_dlpar_node() helper with a comment about the incremented
+reference count and call of_node_put() on the obtained device_node in the
+add and remove paths. Also, fixup a reference leak in the find_vio_slot()
+helper where we fail to call of_node_put() on the vdevice node after we
+iterate over its children.
+
+Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/hotplug/rpadlpar_core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
+index f2fcbe944d94..aae295708ea7 100644
+--- a/drivers/pci/hotplug/rpadlpar_core.c
++++ b/drivers/pci/hotplug/rpadlpar_core.c
+@@ -55,6 +55,7 @@ static struct device_node *find_vio_slot_node(char *drc_name)
+ if ((rc == 0) && (!strcmp(drc_name, name)))
+ break;
+ }
++ of_node_put(parent);
+
+ return dn;
+ }
+@@ -78,6 +79,7 @@ static struct device_node *find_php_slot_pci_node(char *drc_name,
+ return np;
+ }
+
++/* Returns a device_node with its reference count incremented */
+ static struct device_node *find_dlpar_node(char *drc_name, int *node_type)
+ {
+ struct device_node *dn;
+@@ -314,6 +316,7 @@ int dlpar_add_slot(char *drc_name)
+ rc = dlpar_add_phb(drc_name, dn);
+ break;
+ }
++ of_node_put(dn);
+
+ printk(KERN_INFO "%s: slot %s added\n", DLPAR_MODULE_NAME, drc_name);
+ exit:
+@@ -447,6 +450,7 @@ int dlpar_remove_slot(char *drc_name)
+ rc = dlpar_remove_pci_slot(drc_name, dn);
+ break;
+ }
++ of_node_put(dn);
+ vm_unmap_aliases();
+
+ printk(KERN_INFO "%s: slot %s removed\n", DLPAR_MODULE_NAME, drc_name);
+--
+2.20.1
+
--- /dev/null
+From 55ffde78a6abd040b7080868c92c506599ad2199 Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Mon, 25 Mar 2019 17:19:09 -0500
+Subject: PCI: xilinx: Check for __get_free_pages() failure
+
+[ Upstream commit 699ca30162686bf305cdf94861be02eb0cf9bda2 ]
+
+If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer
+dereference.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Reviewed-by: Steven Price <steven.price@arm.com>
+Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/host/pcie-xilinx.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
+index 4cfa46360d12..6a2499f4d610 100644
+--- a/drivers/pci/host/pcie-xilinx.c
++++ b/drivers/pci/host/pcie-xilinx.c
+@@ -349,14 +349,19 @@ static const struct irq_domain_ops msi_domain_ops = {
+ * xilinx_pcie_enable_msi - Enable MSI support
+ * @port: PCIe port information
+ */
+-static void xilinx_pcie_enable_msi(struct xilinx_pcie_port *port)
++static int xilinx_pcie_enable_msi(struct xilinx_pcie_port *port)
+ {
+ phys_addr_t msg_addr;
+
+ port->msi_pages = __get_free_pages(GFP_KERNEL, 0);
++ if (!port->msi_pages)
++ return -ENOMEM;
++
+ msg_addr = virt_to_phys((void *)port->msi_pages);
+ pcie_write(port, 0x0, XILINX_PCIE_REG_MSIBASE1);
+ pcie_write(port, msg_addr, XILINX_PCIE_REG_MSIBASE2);
++
++ return 0;
+ }
+
+ /* INTx Functions */
+@@ -555,6 +560,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
+ struct device *dev = port->dev;
+ struct device_node *node = dev->of_node;
+ struct device_node *pcie_intc_node;
++ int ret;
+
+ /* Setup INTx */
+ pcie_intc_node = of_get_next_child(node, NULL);
+@@ -582,7 +588,9 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
+ return PTR_ERR(port->irq_domain);
+ }
+
+- xilinx_pcie_enable_msi(port);
++ ret = xilinx_pcie_enable_msi(port);
++ if (ret)
++ return ret;
+ }
+
+ return 0;
+--
+2.20.1
+
--- /dev/null
+From 5d72525356b2370f8a79b9d39bc8e5aa8748376d Mon Sep 17 00:00:00 2001
+From: Stephane Eranian <eranian@google.com>
+Date: Mon, 13 May 2019 17:34:00 -0700
+Subject: perf/x86/intel: Allow PEBS multi-entry in watermark mode
+
+[ Upstream commit c7a286577d7592720c2f179aadfb325a1ff48c95 ]
+
+This patch fixes a restriction/bug introduced by:
+
+ 583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS")
+
+The original patch prevented using multi-entry PEBS when wakeup_events != 0.
+However given that wakeup_events is part of a union with wakeup_watermark, it
+means that in watermark mode, PEBS multi-entry is also disabled which is not the
+intent. This patch fixes this by checking is watermark mode is enabled.
+
+Signed-off-by: Stephane Eranian <eranian@google.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: jolsa@redhat.com
+Cc: kan.liang@intel.com
+Cc: vincent.weaver@maine.edu
+Fixes: 583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS")
+Link: http://lkml.kernel.org/r/20190514003400.224340-1-eranian@google.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
+index 325ed90511cf..3572434a73cb 100644
+--- a/arch/x86/kernel/cpu/perf_event_intel.c
++++ b/arch/x86/kernel/cpu/perf_event_intel.c
+@@ -2513,7 +2513,7 @@ static int intel_pmu_hw_config(struct perf_event *event)
+ return ret;
+
+ if (event->attr.precise_ip) {
+- if (!(event->attr.freq || event->attr.wakeup_events)) {
++ if (!(event->attr.freq || (event->attr.wakeup_events && !event->attr.watermark))) {
+ event->hw.flags |= PERF_X86_EVENT_AUTO_RELOAD;
+ if (!(event->attr.sample_type &
+ ~intel_pmu_free_running_flags(event)))
+--
+2.20.1
+
--- /dev/null
+From 46d0633a1de591d48fa97b183dc6eaa0278e80d5 Mon Sep 17 00:00:00 2001
+From: Enrico Granata <egranata@chromium.org>
+Date: Wed, 3 Apr 2019 15:40:36 -0700
+Subject: platform/chrome: cros_ec_proto: check for NULL transfer function
+
+[ Upstream commit 94d4e7af14a1170e34cf082d92e4c02de9e9fb88 ]
+
+As new transfer mechanisms are added to the EC codebase, they may
+not support v2 of the EC protocol.
+
+If the v3 initial handshake transfer fails, the kernel will try
+and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
+will be NULL, and the code will end up causing a kernel panic.
+
+Add a check for NULL before calling the transfer function, along
+with a helpful comment explaining how one might end up in this
+situation.
+
+Signed-off-by: Enrico Granata <egranata@chromium.org>
+Reviewed-by: Jett Rink <jettrink@chromium.org>
+Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/platform/chrome/cros_ec_proto.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
+index a0b8c8a8c323..5c285f2b3a65 100644
+--- a/drivers/platform/chrome/cros_ec_proto.c
++++ b/drivers/platform/chrome/cros_ec_proto.c
+@@ -66,6 +66,17 @@ static int send_command(struct cros_ec_device *ec_dev,
+ else
+ xfer_fxn = ec_dev->cmd_xfer;
+
++ if (!xfer_fxn) {
++ /*
++ * This error can happen if a communication error happened and
++ * the EC is trying to use protocol v2, on an underlying
++ * communication mechanism that does not support v2.
++ */
++ dev_err_once(ec_dev->dev,
++ "missing EC transfer API, cannot send command\n");
++ return -EIO;
++ }
++
+ ret = (*xfer_fxn)(ec_dev, msg);
+ if (msg->result == EC_RES_IN_PROGRESS) {
+ int i;
+--
+2.20.1
+
--- /dev/null
+From 116fd01059b57e0a499b2d7fb92d37259efca9c3 Mon Sep 17 00:00:00 2001
+From: Phong Hoang <phong.hoang.wz@renesas.com>
+Date: Tue, 19 Mar 2019 19:40:08 +0900
+Subject: pwm: Fix deadlock warning when removing PWM device
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 347ab9480313737c0f1aaa08e8f2e1a791235535 ]
+
+This patch fixes deadlock warning if removing PWM device
+when CONFIG_PROVE_LOCKING is enabled.
+
+This issue can be reproceduced by the following steps on
+the R-Car H3 Salvator-X board if the backlight is disabled:
+
+ # cd /sys/class/pwm/pwmchip0
+ # echo 0 > export
+ # ls
+ device export npwm power pwm0 subsystem uevent unexport
+ # cd device/driver
+ # ls
+ bind e6e31000.pwm uevent unbind
+ # echo e6e31000.pwm > unbind
+
+[ 87.659974] ======================================================
+[ 87.666149] WARNING: possible circular locking dependency detected
+[ 87.672327] 5.0.0 #7 Not tainted
+[ 87.675549] ------------------------------------------------------
+[ 87.681723] bash/2986 is trying to acquire lock:
+[ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
+[ 87.694528]
+[ 87.694528] but task is already holding lock:
+[ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
+[ 87.707405]
+[ 87.707405] which lock already depends on the new lock.
+[ 87.707405]
+[ 87.715574]
+[ 87.715574] the existing dependency chain (in reverse order) is:
+[ 87.723048]
+[ 87.723048] -> #1 (pwm_lock){+.+.}:
+[ 87.728017] __mutex_lock+0x70/0x7e4
+[ 87.732108] mutex_lock_nested+0x1c/0x24
+[ 87.736547] pwm_request_from_chip.part.6+0x34/0x74
+[ 87.741940] pwm_request_from_chip+0x20/0x40
+[ 87.746725] export_store+0x6c/0x1f4
+[ 87.750820] dev_attr_store+0x18/0x28
+[ 87.754998] sysfs_kf_write+0x54/0x64
+[ 87.759175] kernfs_fop_write+0xe4/0x1e8
+[ 87.763615] __vfs_write+0x40/0x184
+[ 87.767619] vfs_write+0xa8/0x19c
+[ 87.771448] ksys_write+0x58/0xbc
+[ 87.775278] __arm64_sys_write+0x18/0x20
+[ 87.779721] el0_svc_common+0xd0/0x124
+[ 87.783986] el0_svc_compat_handler+0x1c/0x24
+[ 87.788858] el0_svc_compat+0x8/0x18
+[ 87.792947]
+[ 87.792947] -> #0 (kn->count#58){++++}:
+[ 87.798260] lock_acquire+0xc4/0x22c
+[ 87.802353] __kernfs_remove+0x258/0x2c4
+[ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0
+[ 87.811836] remove_files.isra.1+0x38/0x78
+[ 87.816447] sysfs_remove_group+0x48/0x98
+[ 87.820971] sysfs_remove_groups+0x34/0x4c
+[ 87.825583] device_remove_attrs+0x6c/0x7c
+[ 87.830197] device_del+0x11c/0x33c
+[ 87.834201] device_unregister+0x14/0x2c
+[ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c
+[ 87.843509] pwmchip_remove+0xf4/0x13c
+[ 87.847773] rcar_pwm_remove+0x28/0x34
+[ 87.852039] platform_drv_remove+0x24/0x64
+[ 87.856651] device_release_driver_internal+0x18c/0x21c
+[ 87.862391] device_release_driver+0x14/0x1c
+[ 87.867175] unbind_store+0xe0/0x124
+[ 87.871265] drv_attr_store+0x20/0x30
+[ 87.875442] sysfs_kf_write+0x54/0x64
+[ 87.879618] kernfs_fop_write+0xe4/0x1e8
+[ 87.884055] __vfs_write+0x40/0x184
+[ 87.888057] vfs_write+0xa8/0x19c
+[ 87.891887] ksys_write+0x58/0xbc
+[ 87.895716] __arm64_sys_write+0x18/0x20
+[ 87.900154] el0_svc_common+0xd0/0x124
+[ 87.904417] el0_svc_compat_handler+0x1c/0x24
+[ 87.909289] el0_svc_compat+0x8/0x18
+[ 87.913378]
+[ 87.913378] other info that might help us debug this:
+[ 87.913378]
+[ 87.921374] Possible unsafe locking scenario:
+[ 87.921374]
+[ 87.927286] CPU0 CPU1
+[ 87.931808] ---- ----
+[ 87.936331] lock(pwm_lock);
+[ 87.939293] lock(kn->count#58);
+[ 87.945120] lock(pwm_lock);
+[ 87.950599] lock(kn->count#58);
+[ 87.953908]
+[ 87.953908] *** DEADLOCK ***
+[ 87.953908]
+[ 87.959821] 4 locks held by bash/2986:
+[ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
+[ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
+[ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
+[ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
+[ 87.995481]
+[ 87.995481] stack backtrace:
+[ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
+[ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
+[ 88.012791] Call trace:
+[ 88.015235] dump_backtrace+0x0/0x190
+[ 88.018891] show_stack+0x14/0x1c
+[ 88.022204] dump_stack+0xb0/0xec
+[ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0
+[ 88.030385] __lock_acquire+0x1318/0x1864
+[ 88.034388] lock_acquire+0xc4/0x22c
+[ 88.037958] __kernfs_remove+0x258/0x2c4
+[ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0
+[ 88.046398] remove_files.isra.1+0x38/0x78
+[ 88.050487] sysfs_remove_group+0x48/0x98
+[ 88.054490] sysfs_remove_groups+0x34/0x4c
+[ 88.058580] device_remove_attrs+0x6c/0x7c
+[ 88.062671] device_del+0x11c/0x33c
+[ 88.066154] device_unregister+0x14/0x2c
+[ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c
+[ 88.074421] pwmchip_remove+0xf4/0x13c
+[ 88.078163] rcar_pwm_remove+0x28/0x34
+[ 88.081906] platform_drv_remove+0x24/0x64
+[ 88.085996] device_release_driver_internal+0x18c/0x21c
+[ 88.091215] device_release_driver+0x14/0x1c
+[ 88.095478] unbind_store+0xe0/0x124
+[ 88.099048] drv_attr_store+0x20/0x30
+[ 88.102704] sysfs_kf_write+0x54/0x64
+[ 88.106359] kernfs_fop_write+0xe4/0x1e8
+[ 88.110275] __vfs_write+0x40/0x184
+[ 88.113757] vfs_write+0xa8/0x19c
+[ 88.117065] ksys_write+0x58/0xbc
+[ 88.120374] __arm64_sys_write+0x18/0x20
+[ 88.124291] el0_svc_common+0xd0/0x124
+[ 88.128034] el0_svc_compat_handler+0x1c/0x24
+[ 88.132384] el0_svc_compat+0x8/0x18
+
+The sysfs unexport in pwmchip_remove() is completely asymmetric
+to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9
+("pwm: Unexport children before chip removal") is a strong indication
+that this was wrong to begin with. We should just move
+pwmchip_sysfs_unexport() where it belongs, which is right after
+pwmchip_sysfs_unexport_children(). In that case, we do not need
+separate functions anymore either.
+
+We also really want to remove sysfs irrespective of whether or not
+the chip will be removed as a result of pwmchip_remove(). We can only
+assume that the driver will be gone after that, so we shouldn't leave
+any dangling sysfs files around.
+
+This warning disappears if we move pwmchip_sysfs_unexport() to
+the top of pwmchip_remove(), pwmchip_sysfs_unexport_children().
+That way it is also outside of the pwm_lock section, which indeed
+doesn't seem to be needed.
+
+Moving the pwmchip_sysfs_export() call outside of that section also
+seems fine and it'd be perfectly symmetric with pwmchip_remove() again.
+
+So, this patch fixes them.
+
+Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
+[shimoda: revise the commit log and code]
+Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
+Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal")
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Tested-by: Hoan Nguyen An <na-hoan@jinso.co.jp>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pwm/core.c | 10 +++++-----
+ drivers/pwm/sysfs.c | 14 +-------------
+ include/linux/pwm.h | 5 -----
+ 3 files changed, 6 insertions(+), 23 deletions(-)
+
+diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
+index ec84ff8ad1b4..6911f9662300 100644
+--- a/drivers/pwm/core.c
++++ b/drivers/pwm/core.c
+@@ -284,10 +284,12 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
+ if (IS_ENABLED(CONFIG_OF))
+ of_pwmchip_add(chip);
+
+- pwmchip_sysfs_export(chip);
+-
+ out:
+ mutex_unlock(&pwm_lock);
++
++ if (!ret)
++ pwmchip_sysfs_export(chip);
++
+ return ret;
+ }
+ EXPORT_SYMBOL_GPL(pwmchip_add_with_polarity);
+@@ -321,7 +323,7 @@ int pwmchip_remove(struct pwm_chip *chip)
+ unsigned int i;
+ int ret = 0;
+
+- pwmchip_sysfs_unexport_children(chip);
++ pwmchip_sysfs_unexport(chip);
+
+ mutex_lock(&pwm_lock);
+
+@@ -341,8 +343,6 @@ int pwmchip_remove(struct pwm_chip *chip)
+
+ free_pwms(chip);
+
+- pwmchip_sysfs_unexport(chip);
+-
+ out:
+ mutex_unlock(&pwm_lock);
+ return ret;
+diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
+index 375008e2be20..199370e41da9 100644
+--- a/drivers/pwm/sysfs.c
++++ b/drivers/pwm/sysfs.c
+@@ -338,19 +338,6 @@ void pwmchip_sysfs_export(struct pwm_chip *chip)
+ }
+
+ void pwmchip_sysfs_unexport(struct pwm_chip *chip)
+-{
+- struct device *parent;
+-
+- parent = class_find_device(&pwm_class, NULL, chip,
+- pwmchip_sysfs_match);
+- if (parent) {
+- /* for class_find_device() */
+- put_device(parent);
+- device_unregister(parent);
+- }
+-}
+-
+-void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+ {
+ struct device *parent;
+ unsigned int i;
+@@ -368,6 +355,7 @@ void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+ }
+
+ put_device(parent);
++ device_unregister(parent);
+ }
+
+ static int __init pwm_sysfs_init(void)
+diff --git a/include/linux/pwm.h b/include/linux/pwm.h
+index aa8736d5b2f3..cfc3ed46cad2 100644
+--- a/include/linux/pwm.h
++++ b/include/linux/pwm.h
+@@ -331,7 +331,6 @@ static inline void pwm_remove_table(struct pwm_lookup *table, size_t num)
+ #ifdef CONFIG_PWM_SYSFS
+ void pwmchip_sysfs_export(struct pwm_chip *chip);
+ void pwmchip_sysfs_unexport(struct pwm_chip *chip);
+-void pwmchip_sysfs_unexport_children(struct pwm_chip *chip);
+ #else
+ static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
+ {
+@@ -340,10 +339,6 @@ static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
+ static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
+ {
+ }
+-
+-static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+-{
+-}
+ #endif /* CONFIG_PWM_SYSFS */
+
+ #endif /* __LINUX_PWM_H */
+--
+2.20.1
+
--- /dev/null
+From b6517e9b996fa23703e2bc5d5f964ecc98c17688 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christoph=20Vogtl=C3=A4nder?=
+ <c.vogtlaender@sigma-surface-science.com>
+Date: Tue, 12 Mar 2019 14:38:46 +0530
+Subject: pwm: tiehrpwm: Update shadow register for disabling PWMs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit b00ef53053191d3025c15e8041699f8c9d132daf ]
+
+It must be made sure that immediate mode is not already set, when
+modifying shadow register value in ehrpwm_pwm_disable(). Otherwise
+modifications to the action-qualifier continuous S/W force
+register(AQSFRC) will be done in the active register.
+This may happen when both channels are being disabled. In this case,
+only the first channel state will be recorded as disabled in the shadow
+register. Later, when enabling the first channel again, the second
+channel would be enabled as well. Setting RLDCSF to zero, first, ensures
+that the shadow register is updated as desired.
+
+Fixes: 38dabd91ff0b ("pwm: tiehrpwm: Fix disabling of output of PWMs")
+Signed-off-by: Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com>
+[vigneshr@ti.com: Improve commit message]
+Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pwm/pwm-tiehrpwm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
+index 062dff1c902d..ede17f89d57f 100644
+--- a/drivers/pwm/pwm-tiehrpwm.c
++++ b/drivers/pwm/pwm-tiehrpwm.c
+@@ -385,6 +385,8 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+ }
+
+ /* Update shadow register first before modifying active register */
++ ehrpwm_modify(pc->mmio_base, AQSFRC, AQSFRC_RLDCSF_MASK,
++ AQSFRC_RLDCSF_ZRO);
+ ehrpwm_modify(pc->mmio_base, AQCSFRC, aqcsfrc_mask, aqcsfrc_val);
+ /*
+ * Changes to immediate action on Action Qualifier. This puts
+--
+2.20.1
+
--- /dev/null
+fs-fat-file.c-issue-flush-after-the-writeback-of-fat.patch
+sysctl-return-einval-if-val-violates-minmax.patch
+ipc-prevent-lockup-on-alloc_msg-and-free_msg.patch
+hugetlbfs-on-restore-reserve-error-path-retain-subpo.patch
+mm-cma.c-fix-crash-on-cma-allocation-if-bitmap-alloc.patch
+mm-cma_debug.c-fix-the-break-condition-in-cma_maxchu.patch
+kernel-sys.c-prctl-fix-false-positive-in-validate_pr.patch
+mfd-intel-lpss-set-the-device-in-reset-state-when-in.patch
+mfd-twl6040-fix-device-init-errors-for-accctl-regist.patch
+perf-x86-intel-allow-pebs-multi-entry-in-watermark-m.patch
+drm-bridge-adv7511-fix-low-refresh-rate-selection.patch
+ntp-allow-tai-utc-offset-to-be-set-to-zero.patch
+f2fs-fix-to-avoid-panic-in-do_recover_data.patch
+f2fs-fix-to-do-sanity-check-on-valid-block-count-of-.patch
+uml-fix-a-boot-splat-wrt-use-of-cpu_all_mask.patch
+mips-make-sure-dt-memory-regions-are-valid.patch
+iommu-vt-d-set-intel_iommu_gfx_mapped-correctly.patch
+alsa-hda-register-irq-handler-after-the-chip-initial.patch
+nvmem-core-fix-read-buffer-in-place.patch
+fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch
+fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch
+nfsd-allow-fh_want_write-to-be-called-twice.patch
+x86-pci-fix-pci-irq-routing-table-memory-leak.patch
+platform-chrome-cros_ec_proto-check-for-null-transfe.patch
+soc-mediatek-pwrap-zero-initialize-rdata-in-pwrap_in.patch
+clk-rockchip-turn-on-aclk_dmac1-for-suspend-on-rk328.patch
+arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ahb-clock-t.patch
+arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ipg-clock-t.patch
+arm-dts-imx6qdl-specify-imx6qdl_clk_ipg-as-ipg-clock.patch
+pci-rpadlpar-fix-leaked-device_node-references-in-ad.patch
+pci-rcar-fix-a-potential-null-pointer-dereference.patch
+video-hgafb-fix-potential-null-pointer-dereference.patch
+video-imsttfb-fix-potential-null-pointer-dereference.patch
+pci-xilinx-check-for-__get_free_pages-failure.patch
+gpio-gpio-omap-add-check-for-off-wake-capable-gpios.patch
+dmaengine-idma64-use-actual-device-for-dma-transfers.patch
+pwm-tiehrpwm-update-shadow-register-for-disabling-pw.patch
+arm-dts-exynos-always-enable-necessary-apio_1v8-and-.patch
+pwm-fix-deadlock-warning-when-removing-pwm-device.patch
+arm-exynos-fix-undefined-instruction-during-exynos54.patch
--- /dev/null
+From 56d26c53b046ef131a4fbd591c7c53c21d884b5b Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Thu, 7 Mar 2019 15:56:51 -0700
+Subject: soc: mediatek: pwrap: Zero initialize rdata in pwrap_init_cipher
+
+[ Upstream commit 89e28da82836530f1ac7a3a32fecc31f22d79b3e ]
+
+When building with -Wsometimes-uninitialized, Clang warns:
+
+drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is
+used uninitialized whenever '||' condition is true
+[-Werror,-Wsometimes-uninitialized]
+
+If pwrap_write returns non-zero, pwrap_read will not be called to
+initialize rdata, meaning that we will use some random uninitialized
+stack value in our print statement. Zero initialize rdata in case this
+happens.
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/401
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soc/mediatek/mtk-pmic-wrap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
+index 105597a885cb..33b10dd7d87e 100644
+--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
++++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
+@@ -591,7 +591,7 @@ static bool pwrap_is_pmic_cipher_ready(struct pmic_wrapper *wrp)
+ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
+ {
+ int ret;
+- u32 rdata;
++ u32 rdata = 0;
+
+ pwrap_writel(wrp, 0x1, PWRAP_CIPHER_SWRST);
+ pwrap_writel(wrp, 0x0, PWRAP_CIPHER_SWRST);
+--
+2.20.1
+
--- /dev/null
+From 5e5570c4ae0a12ae1deea4615f8669a5ceb0330d Mon Sep 17 00:00:00 2001
+From: Christian Brauner <christian@brauner.io>
+Date: Tue, 14 May 2019 15:44:55 -0700
+Subject: sysctl: return -EINVAL if val violates minmax
+
+[ Upstream commit e260ad01f0aa9e96b5386d5cd7184afd949dc457 ]
+
+Currently when userspace gives us a values that overflow e.g. file-max
+and other callers of __do_proc_doulongvec_minmax() we simply ignore the
+new value and leave the current value untouched.
+
+This can be problematic as it gives the illusion that the limit has
+indeed be bumped when in fact it failed. This commit makes sure to
+return EINVAL when an overflow is detected. Please note that this is a
+userspace facing change.
+
+Link: http://lkml.kernel.org/r/20190210203943.8227-4-christian@brauner.io
+Signed-off-by: Christian Brauner <christian@brauner.io>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Alexey Dobriyan <adobriyan@gmail.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Dominik Brodowski <linux@dominikbrodowski.net>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: Joe Lawrence <joe.lawrence@redhat.com>
+Cc: Waiman Long <longman@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sysctl.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/kernel/sysctl.c b/kernel/sysctl.c
+index c140659db669..24c7fe8608d0 100644
+--- a/kernel/sysctl.c
++++ b/kernel/sysctl.c
+@@ -2461,8 +2461,10 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
+ if (neg)
+ continue;
+ val = convmul * val / convdiv;
+- if ((min && val < *min) || (max && val > *max))
+- continue;
++ if ((min && val < *min) || (max && val > *max)) {
++ err = -EINVAL;
++ break;
++ }
+ *i = val;
+ } else {
+ val = convdiv * (*i) / convmul;
+--
+2.20.1
+
--- /dev/null
+From 6d5f60012c11dbb218c0f4aed31525df59a2c31f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Maciej=20=C5=BBenczykowski?= <maze@google.com>
+Date: Wed, 10 Apr 2019 11:11:23 -0700
+Subject: uml: fix a boot splat wrt use of cpu_all_mask
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 689a58605b63173acb0a8cf954af6a8f60440c93 ]
+
+Memory: 509108K/542612K available (3835K kernel code, 919K rwdata, 1028K rodata, 129K init, 211K bss, 33504K reserved, 0K cma-reserved)
+NR_IRQS: 15
+clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns
+------------[ cut here ]------------
+WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:458 clockevents_register_device+0x72/0x140
+posix-timer cpumask == cpu_all_mask, using cpu_possible_mask instead
+Modules linked in:
+CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-rc4-00048-ged79cc87302b #4
+Stack:
+ 604ebda0 603c5370 604ebe20 6046fd17
+ 00000000 6006fcbb 604ebdb0 603c53b5
+ 604ebe10 6003bfc4 604ebdd0 9000001ca
+Call Trace:
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<60083160>] ? clockevents_register_device+0x72/0x140
+ [<6001f16e>] show_stack+0x13b/0x155
+ [<603c5370>] ? dump_stack_print_info+0xe2/0xeb
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<603c53b5>] dump_stack+0x2a/0x2c
+ [<6003bfc4>] __warn+0x10e/0x13e
+ [<60070320>] ? vprintk_func+0xc8/0xcf
+ [<60030fd6>] ? block_signals+0x0/0x16
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<6003c08b>] warn_slowpath_fmt+0x97/0x99
+ [<600311a1>] ? set_signals+0x0/0x3f
+ [<6003bff4>] ? warn_slowpath_fmt+0x0/0x99
+ [<600842cb>] ? tick_oneshot_mode_active+0x44/0x4f
+ [<60030fd6>] ? block_signals+0x0/0x16
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<6007d2d5>] ? __clocksource_select+0x20/0x1b1
+ [<60030fd6>] ? block_signals+0x0/0x16
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<60083160>] clockevents_register_device+0x72/0x140
+ [<60031192>] ? get_signals+0x0/0xf
+ [<60030fd6>] ? block_signals+0x0/0x16
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<60002eec>] um_timer_setup+0xc8/0xca
+ [<60001b59>] start_kernel+0x47f/0x57e
+ [<600035bc>] start_kernel_proc+0x49/0x4d
+ [<6006c483>] ? kmsg_dump_register+0x82/0x8a
+ [<6001de62>] new_thread_handler+0x81/0xb2
+ [<60003571>] ? kmsg_dumper_stdout_init+0x1a/0x1c
+ [<60020c75>] uml_finishsetup+0x54/0x59
+
+random: get_random_bytes called from init_oops_id+0x27/0x34 with crng_init=0
+---[ end trace 00173d0117a88acb ]---
+Calibrating delay loop... 6941.90 BogoMIPS (lpj=34709504)
+
+Signed-off-by: Maciej Żenczykowski <maze@google.com>
+Cc: Jeff Dike <jdike@addtoit.com>
+Cc: Richard Weinberger <richard@nod.at>
+Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
+Cc: linux-um@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/um/kernel/time.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
+index 25c23666d592..040e3efdc9a6 100644
+--- a/arch/um/kernel/time.c
++++ b/arch/um/kernel/time.c
+@@ -56,7 +56,7 @@ static int itimer_one_shot(struct clock_event_device *evt)
+ static struct clock_event_device timer_clockevent = {
+ .name = "posix-timer",
+ .rating = 250,
+- .cpumask = cpu_all_mask,
++ .cpumask = cpu_possible_mask,
+ .features = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+ .set_state_shutdown = itimer_shutdown,
+--
+2.20.1
+
--- /dev/null
+From 249d4b6f0c21546c06e831b822de5861b0d43807 Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Mon, 1 Apr 2019 17:46:58 +0200
+Subject: video: hgafb: fix potential NULL pointer dereference
+
+[ Upstream commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542 ]
+
+When ioremap fails, hga_vram should not be dereferenced. The fix
+check the failure to avoid NULL pointer dereference.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Cc: Aditya Pakki <pakki001@umn.edu>
+Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
+[b.zolnierkie: minor patch summary fixup]
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/hgafb.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
+index 15d3ccff2965..4a397c7c1b56 100644
+--- a/drivers/video/fbdev/hgafb.c
++++ b/drivers/video/fbdev/hgafb.c
+@@ -285,6 +285,8 @@ static int hga_card_detect(void)
+ hga_vram_len = 0x08000;
+
+ hga_vram = ioremap(0xb0000, hga_vram_len);
++ if (!hga_vram)
++ goto error;
+
+ if (request_region(0x3b0, 12, "hgafb"))
+ release_io_ports = 1;
+--
+2.20.1
+
--- /dev/null
+From f93beb4279d3c08c704fbeddde1ec39ecaa7bc08 Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Mon, 1 Apr 2019 17:46:58 +0200
+Subject: video: imsttfb: fix potential NULL pointer dereferences
+
+[ Upstream commit 1d84353d205a953e2381044953b7fa31c8c9702d ]
+
+In case ioremap fails, the fix releases resources and returns
+-ENOMEM to avoid NULL pointer dereferences.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Cc: Aditya Pakki <pakki001@umn.edu>
+Cc: Finn Thain <fthain@telegraphics.com.au>
+Cc: Rob Herring <robh@kernel.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+[b.zolnierkie: minor patch summary fixup]
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/imsttfb.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
+index 9b167f7ef6c6..4994a540f680 100644
+--- a/drivers/video/fbdev/imsttfb.c
++++ b/drivers/video/fbdev/imsttfb.c
+@@ -1517,6 +1517,11 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+ info->fix.smem_start = addr;
+ info->screen_base = (__u8 *)ioremap(addr, par->ramdac == IBM ?
+ 0x400000 : 0x800000);
++ if (!info->screen_base) {
++ release_mem_region(addr, size);
++ framebuffer_release(info);
++ return -ENOMEM;
++ }
+ info->fix.mmio_start = addr + 0x800000;
+ par->dc_regs = ioremap(addr + 0x800000, 0x1000);
+ par->cmap_regs_phys = addr + 0x840000;
+--
+2.20.1
+
--- /dev/null
+From d311506602ed27dcbb721e86e743afbc86ae9ca7 Mon Sep 17 00:00:00 2001
+From: Wenwen Wang <wang6495@umn.edu>
+Date: Wed, 17 Apr 2019 09:18:50 -0500
+Subject: x86/PCI: Fix PCI IRQ routing table memory leak
+
+[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
+
+In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
+found through pirq_find_routing_table(). If the table is not found and
+CONFIG_PCI_BIOS is defined, the table is then allocated in
+pcibios_get_irq_routing_table() using kmalloc(). Later, if the I/O APIC is
+used, this table is actually not used. In that case, the allocated table
+is not freed, which is a memory leak.
+
+Free the allocated table if it is not used.
+
+Signed-off-by: Wenwen Wang <wang6495@umn.edu>
+[bhelgaas: added Ingo's reviewed-by, since the only change since v1 was to
+use the irq_routing_table local variable name he suggested]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Ingo Molnar <mingo@kernel.org>
+Acked-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/pci/irq.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
+index 9bd115484745..5f0e596b0519 100644
+--- a/arch/x86/pci/irq.c
++++ b/arch/x86/pci/irq.c
+@@ -1117,6 +1117,8 @@ static struct dmi_system_id __initdata pciirq_dmi_table[] = {
+
+ void __init pcibios_irq_init(void)
+ {
++ struct irq_routing_table *rtable = NULL;
++
+ DBG(KERN_DEBUG "PCI: IRQ init\n");
+
+ if (raw_pci_ops == NULL)
+@@ -1127,8 +1129,10 @@ void __init pcibios_irq_init(void)
+ pirq_table = pirq_find_routing_table();
+
+ #ifdef CONFIG_PCI_BIOS
+- if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN))
++ if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) {
+ pirq_table = pcibios_get_irq_routing_table();
++ rtable = pirq_table;
++ }
+ #endif
+ if (pirq_table) {
+ pirq_peer_trick();
+@@ -1143,8 +1147,10 @@ void __init pcibios_irq_init(void)
+ * If we're using the I/O APIC, avoid using the PCI IRQ
+ * routing table
+ */
+- if (io_apic_assign_pci_irqs)
++ if (io_apic_assign_pci_irqs) {
++ kfree(rtable);
+ pirq_table = NULL;
++ }
+ }
+
+ x86_init.pci.fixup_irqs();
+--
+2.20.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
