From: Sasha Levin Date: Tue, 11 Jun 2019 17:35:56 +0000 (-0400) Subject: fixes for 4.4 X-Git-Tag: v5.1.10~18 X-Git-Url: http://git.ipfire.org/?p=thirdparty%2Fkernel%2Fstable-queue.git;a=commitdiff_plain;h=cd033818a79dd318c32eb1fa653f75b6fb8eb72a fixes for 4.4 Signed-off-by: Sasha Levin --- diff --git a/queue-4.4/alsa-hda-register-irq-handler-after-the-chip-initial.patch b/queue-4.4/alsa-hda-register-irq-handler-after-the-chip-initial.patch new file mode 100644 index 0000000000..2a979ecffe --- /dev/null +++ b/queue-4.4/alsa-hda-register-irq-handler-after-the-chip-initial.patch @@ -0,0 +1,63 @@ +From b7e320f31f2c6e97951ae4af91f75ab75c8f88f8 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +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 +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/arm-dts-exynos-always-enable-necessary-apio_1v8-and-.patch b/queue-4.4/arm-dts-exynos-always-enable-necessary-apio_1v8-and-.patch new file mode 100644 index 0000000000..504dcac724 --- /dev/null +++ b/queue-4.4/arm-dts-exynos-always-enable-necessary-apio_1v8-and-.patch @@ -0,0 +1,52 @@ +From 8219b9e032b0fe52418386d3807726fbad6dee5a Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/arm-dts-imx6qdl-specify-imx6qdl_clk_ipg-as-ipg-clock.patch b/queue-4.4/arm-dts-imx6qdl-specify-imx6qdl_clk_ipg-as-ipg-clock.patch new file mode 100644 index 0000000000..8ded8cb74a --- /dev/null +++ b/queue-4.4/arm-dts-imx6qdl-specify-imx6qdl_clk_ipg-as-ipg-clock.patch @@ -0,0 +1,48 @@ +From c566828a0b554e56fa8057351f77c70df7b868fc Mon Sep 17 00:00:00 2001 +From: Andrey Smirnov +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 +Reviewed-by: Lucas Stach +Cc: Angus Ainslie (Purism) +Cc: Chris Healy +Cc: Lucas Stach +Cc: Fabio Estevam +Cc: Shawn Guo +Cc: linux-arm-kernel@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Tested-by: Adam Ford +Signed-off-by: Shawn Guo +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ahb-clock-t.patch b/queue-4.4/arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ahb-clock-t.patch new file mode 100644 index 0000000000..5dcfaafb42 --- /dev/null +++ b/queue-4.4/arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ahb-clock-t.patch @@ -0,0 +1,45 @@ +From fc9bc15c78b5c04f47ad517d52c8d35955526155 Mon Sep 17 00:00:00 2001 +From: Andrey Smirnov +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 +Cc: Angus Ainslie (Purism) +Cc: Chris Healy +Cc: Lucas Stach +Cc: Fabio Estevam +Cc: Shawn Guo +Cc: linux-arm-kernel@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Shawn Guo +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ipg-clock-t.patch b/queue-4.4/arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ipg-clock-t.patch new file mode 100644 index 0000000000..4fb24aaa63 --- /dev/null +++ b/queue-4.4/arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ipg-clock-t.patch @@ -0,0 +1,45 @@ +From a3d2a6509fb86959c3d1639b759af49e6d102511 Mon Sep 17 00:00:00 2001 +From: Andrey Smirnov +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 +Cc: Angus Ainslie (Purism) +Cc: Chris Healy +Cc: Lucas Stach +Cc: Fabio Estevam +Cc: Shawn Guo +Cc: linux-arm-kernel@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Shawn Guo +Signed-off-by: Sasha Levin +--- + 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 = ; +- clocks = <&clks IMX6SX_CLK_SDMA>, ++ clocks = <&clks IMX6SX_CLK_IPG>, + <&clks IMX6SX_CLK_SDMA>; + clock-names = "ipg", "ahb"; + #dma-cells = <3>; +-- +2.20.1 + diff --git a/queue-4.4/arm-exynos-fix-undefined-instruction-during-exynos54.patch b/queue-4.4/arm-exynos-fix-undefined-instruction-during-exynos54.patch new file mode 100644 index 0000000000..312aaa6bfd --- /dev/null +++ b/queue-4.4/arm-exynos-fix-undefined-instruction-during-exynos54.patch @@ -0,0 +1,88 @@ +From 7469cd32f92035acd462ffa4f26a717cd04201a5 Mon Sep 17 00:00:00 2001 +From: Marek Szyprowski +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 [] (dbg_cpu_pm_notify+0x1c/0x24) + (dbg_cpu_pm_notify) from [] (notifier_call_chain+0x44/0x84) + (notifier_call_chain) from [] (__atomic_notifier_call_chain+0x7c/0x128) + (__atomic_notifier_call_chain) from [] (cpu_pm_notify+0x30/0x54) + (cpu_pm_notify) from [] (syscore_resume+0x98/0x3f4) + (syscore_resume) from [] (suspend_devices_and_enter+0x97c/0xe74) + (suspend_devices_and_enter) from [] (pm_suspend+0x770/0xc04) + (pm_suspend) from [] (state_store+0x6c/0xcc) + (state_store) from [] (kobj_attr_store+0x14/0x20) + (kobj_attr_store) from [] (sysfs_kf_write+0x4c/0x50) + (sysfs_kf_write) from [] (kernfs_fop_write+0xfc/0x1e0) + (kernfs_fop_write) from [] (__vfs_write+0x2c/0x160) + (__vfs_write) from [] (vfs_write+0xa4/0x16c) + (vfs_write) from [] (ksys_write+0x40/0x8c) + (ksys_write) from [] (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 +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/clk-rockchip-turn-on-aclk_dmac1-for-suspend-on-rk328.patch b/queue-4.4/clk-rockchip-turn-on-aclk_dmac1-for-suspend-on-rk328.patch new file mode 100644 index 0000000000..7f80292490 --- /dev/null +++ b/queue-4.4/clk-rockchip-turn-on-aclk_dmac1-for-suspend-on-rk328.patch @@ -0,0 +1,89 @@ +From dfe300647458ac9af34de01e96793de0be99e4e2 Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +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 +Reviewed-by: Elaine Zhang +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/dmaengine-idma64-use-actual-device-for-dma-transfers.patch b/queue-4.4/dmaengine-idma64-use-actual-device-for-dma-transfers.patch new file mode 100644 index 0000000000..f9263ff89d --- /dev/null +++ b/queue-4.4/dmaengine-idma64-use-actual-device-for-dma-transfers.patch @@ -0,0 +1,131 @@ +From 5c183a635ac95585b9ac7c7ebae6ad961fb7eabd Mon Sep 17 00:00:00 2001 +From: Andy Shevchenko +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 +Acked-by: Mark Brown +Acked-by: Greg Kroah-Hartman [for tty parts] +Signed-off-by: Vinod Koul +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/drm-bridge-adv7511-fix-low-refresh-rate-selection.patch b/queue-4.4/drm-bridge-adv7511-fix-low-refresh-rate-selection.patch new file mode 100644 index 0000000000..6bce1e95a9 --- /dev/null +++ b/queue-4.4/drm-bridge-adv7511-fix-low-refresh-rate-selection.patch @@ -0,0 +1,49 @@ +From 92db9400a500abaa76ea2936984e18b4cbc9ce12 Mon Sep 17 00:00:00 2001 +From: Matt Redfearn +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 +Signed-off-by: Matt Redfearn +Signed-off-by: Sean Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20190424132210.26338-1-matt.redfearn@thinci.com +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/f2fs-fix-to-avoid-panic-in-do_recover_data.patch b/queue-4.4/f2fs-fix-to-avoid-panic-in-do_recover_data.patch new file mode 100644 index 0000000000..6829ee14ba --- /dev/null +++ b/queue-4.4/f2fs-fix-to-avoid-panic-in-do_recover_data.patch @@ -0,0 +1,78 @@ +From c72b7d90b9c246380fb910e0162881d472138e77 Mon Sep 17 00:00:00 2001 +From: Chao Yu +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 +Signed-off-by: Jaegeuk Kim +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/f2fs-fix-to-do-sanity-check-on-valid-block-count-of-.patch b/queue-4.4/f2fs-fix-to-do-sanity-check-on-valid-block-count-of-.patch new file mode 100644 index 0000000000..1a4ae119bf --- /dev/null +++ b/queue-4.4/f2fs-fix-to-do-sanity-check-on-valid-block-count-of-.patch @@ -0,0 +1,93 @@ +From 905a9429d3e2d916b6fb2cc119fa3d46283d8154 Mon Sep 17 00:00:00 2001 +From: Chao Yu +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 +Signed-off-by: Jaegeuk Kim +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/fs-fat-file.c-issue-flush-after-the-writeback-of-fat.patch b/queue-4.4/fs-fat-file.c-issue-flush-after-the-writeback-of-fat.patch new file mode 100644 index 0000000000..43c296163e --- /dev/null +++ b/queue-4.4/fs-fat-file.c-issue-flush-after-the-writeback-of-fat.patch @@ -0,0 +1,54 @@ +From c8b3acc2e4e466bd0dfb760d48e5e9bd24afda42 Mon Sep 17 00:00:00 2001 +From: Hou Tao +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 +Acked-by: OGAWA Hirofumi +Cc: Al Viro +Cc: Jan Kara +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch b/queue-4.4/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch new file mode 100644 index 0000000000..b3439702eb --- /dev/null +++ b/queue-4.4/fuse-require-dev-fuse-reads-to-have-enough-buffer-ca.patch @@ -0,0 +1,82 @@ +From cab2e5096300bcb12ce3b04f8e5e7c0538fde023 Mon Sep 17 00:00:00 2001 +From: Kirill Smelkov +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 +Cc: Han-Wen Nienhuys +Cc: Jakob Unterwurzacher +Signed-off-by: Miklos Szeredi +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch b/queue-4.4/fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch new file mode 100644 index 0000000000..28c2eee61a --- /dev/null +++ b/queue-4.4/fuse-retrieve-cap-requested-size-to-negotiated-max_w.patch @@ -0,0 +1,66 @@ +From 4fbe9532e5ad894e9e5b31af8c261c533eba2645 Mon Sep 17 00:00:00 2001 +From: Kirill Smelkov +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 +Cc: Han-Wen Nienhuys +Cc: Jakob Unterwurzacher +Signed-off-by: Miklos Szeredi +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/gpio-gpio-omap-add-check-for-off-wake-capable-gpios.patch b/queue-4.4/gpio-gpio-omap-add-check-for-off-wake-capable-gpios.patch new file mode 100644 index 0000000000..e1e510e7be --- /dev/null +++ b/queue-4.4/gpio-gpio-omap-add-check-for-off-wake-capable-gpios.patch @@ -0,0 +1,82 @@ +From bceae35d08e8b1837dc4e45cc0c273d8838a43eb Mon Sep 17 00:00:00 2001 +From: Tony Lindgren +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 +Cc: Grygorii Strashko +Cc: Keerthy +Cc: Peter Ujfalusi +Cc: Russell King +Cc: Tero Kristo +Reported-by: Grygorii Strashko +Signed-off-by: Tony Lindgren +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/hugetlbfs-on-restore-reserve-error-path-retain-subpo.patch b/queue-4.4/hugetlbfs-on-restore-reserve-error-path-retain-subpo.patch new file mode 100644 index 0000000000..5e639067cf --- /dev/null +++ b/queue-4.4/hugetlbfs-on-restore-reserve-error-path-retain-subpo.patch @@ -0,0 +1,80 @@ +From 6a69977c7e149421924f088e53271f59e7e3e6e8 Mon Sep 17 00:00:00 2001 +From: Mike Kravetz +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 +Reviewed-by: Naoya Horiguchi +Cc: Davidlohr Bueso +Cc: Joonsoo Kim +Cc: Michal Hocko +Cc: "Kirill A . Shutemov" +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/iommu-vt-d-set-intel_iommu_gfx_mapped-correctly.patch b/queue-4.4/iommu-vt-d-set-intel_iommu_gfx_mapped-correctly.patch new file mode 100644 index 0000000000..2f833d705e --- /dev/null +++ b/queue-4.4/iommu-vt-d-set-intel_iommu_gfx_mapped-correctly.patch @@ -0,0 +1,54 @@ +From 56b35336153b3d464378fa327278691bff0fa583 Mon Sep 17 00:00:00 2001 +From: Lu Baolu +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 +Cc: Jacob Pan +Cc: Kevin Tian +Reported-by: Zhenyu Wang +Fixes: c0771df8d5297 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.") +Suggested-by: Kevin Tian +Signed-off-by: Lu Baolu +Signed-off-by: Joerg Roedel +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/ipc-prevent-lockup-on-alloc_msg-and-free_msg.patch b/queue-4.4/ipc-prevent-lockup-on-alloc_msg-and-free_msg.patch new file mode 100644 index 0000000000..ecd257c0fd --- /dev/null +++ b/queue-4.4/ipc-prevent-lockup-on-alloc_msg-and-free_msg.patch @@ -0,0 +1,159 @@ +From 6bc3c95119240baef5efa4de21cd493d433e85b9 Mon Sep 17 00:00:00 2001 +From: Li Rongqing +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 +Signed-off-by: Zhang Yu +Reviewed-by: Davidlohr Bueso +Cc: Manfred Spraul +Cc: Arnd Bergmann +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + #include + #include ++#include + + #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 + diff --git a/queue-4.4/kernel-sys.c-prctl-fix-false-positive-in-validate_pr.patch b/queue-4.4/kernel-sys.c-prctl-fix-false-positive-in-validate_pr.patch new file mode 100644 index 0000000000..0164016371 --- /dev/null +++ b/queue-4.4/kernel-sys.c-prctl-fix-false-positive-in-validate_pr.patch @@ -0,0 +1,54 @@ +From 17dde14f3f15e1c23336af513b230c8bff901fda Mon Sep 17 00:00:00 2001 +From: Cyrill Gorcunov +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 +Cc: Andrey Vagin +Cc: Dmitry Safonov <0x7f454c46@gmail.com> +Cc: Pavel Emelyanov +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/mfd-intel-lpss-set-the-device-in-reset-state-when-in.patch b/queue-4.4/mfd-intel-lpss-set-the-device-in-reset-state-when-in.patch new file mode 100644 index 0000000000..1b7e9b5d3d --- /dev/null +++ b/queue-4.4/mfd-intel-lpss-set-the-device-in-reset-state-when-in.patch @@ -0,0 +1,70 @@ +From 0a4f00b614550ce53cf1ce0ae9857987592a0d3c Mon Sep 17 00:00:00 2001 +From: Binbin Wu +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: + +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 + +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 +Acked-by: Mika Westerberg +Reviewed-by: Andy Shevchenko +Signed-off-by: Lee Jones +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/mfd-twl6040-fix-device-init-errors-for-accctl-regist.patch b/queue-4.4/mfd-twl6040-fix-device-init-errors-for-accctl-regist.patch new file mode 100644 index 0000000000..2f4280566d --- /dev/null +++ b/queue-4.4/mfd-twl6040-fix-device-init-errors-for-accctl-regist.patch @@ -0,0 +1,62 @@ +From 91f2d31a311fa0f5a43a3ef007612585da041412 Mon Sep 17 00:00:00 2001 +From: Tony Lindgren +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 +Acked-by: Peter Ujfalusi +Signed-off-by: Lee Jones +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/mips-make-sure-dt-memory-regions-are-valid.patch b/queue-4.4/mips-make-sure-dt-memory-regions-are-valid.patch new file mode 100644 index 0000000000..adf9ca6f87 --- /dev/null +++ b/queue-4.4/mips-make-sure-dt-memory-regions-are-valid.patch @@ -0,0 +1,69 @@ +From d7a01b245fdc005813d77cd8b418df7236644b50 Mon Sep 17 00:00:00 2001 +From: Serge Semin +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 +Signed-off-by: Paul Burton +Cc: Ralf Baechle +Cc: James Hogan +Cc: Mike Rapoport +Cc: Andrew Morton +Cc: Michal Hocko +Cc: Greg Kroah-Hartman +Cc: Thomas Bogendoerfer +Cc: Huacai Chen +Cc: Stefan Agner +Cc: Stephen Rothwell +Cc: Alexandre Belloni +Cc: Juergen Gross +Cc: Serge Semin +Cc: linux-mips@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/mm-cma.c-fix-crash-on-cma-allocation-if-bitmap-alloc.patch b/queue-4.4/mm-cma.c-fix-crash-on-cma-allocation-if-bitmap-alloc.patch new file mode 100644 index 0000000000..ebc90c8616 --- /dev/null +++ b/queue-4.4/mm-cma.c-fix-crash-on-cma-allocation-if-bitmap-alloc.patch @@ -0,0 +1,44 @@ +From 4d2dc308433590e5e82e4583e1b56031351ae5b0 Mon Sep 17 00:00:00 2001 +From: Yue Hu +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 +Reviewed-by: Anshuman Khandual +Cc: Joonsoo Kim +Cc: Laura Abbott +Cc: Mike Rapoport +Cc: Randy Dunlap +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/mm-cma_debug.c-fix-the-break-condition-in-cma_maxchu.patch b/queue-4.4/mm-cma_debug.c-fix-the-break-condition-in-cma_maxchu.patch new file mode 100644 index 0000000000..dc6d79ad4e --- /dev/null +++ b/queue-4.4/mm-cma_debug.c-fix-the-break-condition-in-cma_maxchu.patch @@ -0,0 +1,44 @@ +From 6f96370ea6b4bbdb599969cedd19ccda6bba865a Mon Sep 17 00:00:00 2001 +From: Yue Hu +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 +Reviewed-by: Andrew Morton +Cc: Michal Hocko +Cc: Joe Perches +Cc: David Rientjes +Cc: Dmitry Safonov +Cc: Joonsoo Kim +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/nfsd-allow-fh_want_write-to-be-called-twice.patch b/queue-4.4/nfsd-allow-fh_want_write-to-be-called-twice.patch new file mode 100644 index 0000000000..94ba168a80 --- /dev/null +++ b/queue-4.4/nfsd-allow-fh_want_write-to-be-called-twice.patch @@ -0,0 +1,51 @@ +From e9d71f0e30c4151c0b77d4750c9287a5ecd4ebfb Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/ntp-allow-tai-utc-offset-to-be-set-to-zero.patch b/queue-4.4/ntp-allow-tai-utc-offset-to-be-set-to-zero.patch new file mode 100644 index 0000000000..5b4224d38a --- /dev/null +++ b/queue-4.4/ntp-allow-tai-utc-offset-to-be-set-to-zero.patch @@ -0,0 +1,46 @@ +From b1d88de7f28c6840e83c2c5c7de972a5ac296136 Mon Sep 17 00:00:00 2001 +From: Miroslav Lichvar +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 +Signed-off-by: Miroslav Lichvar +Signed-off-by: Thomas Gleixner +Cc: John Stultz +Cc: Richard Cochran +Cc: Prarit Bhargava +Link: https://lkml.kernel.org/r/20190417084833.7401-1-mlichvar@redhat.com +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/nvmem-core-fix-read-buffer-in-place.patch b/queue-4.4/nvmem-core-fix-read-buffer-in-place.patch new file mode 100644 index 0000000000..b54425580d --- /dev/null +++ b/queue-4.4/nvmem-core-fix-read-buffer-in-place.patch @@ -0,0 +1,63 @@ +From 38ef89cf92c2b1cf2aacb011fcf155a04e5e37eb Mon Sep 17 00:00:00 2001 +From: Jorge Ramirez-Ortiz +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 +Signed-off-by: Srinivas Kandagatla +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/pci-rcar-fix-a-potential-null-pointer-dereference.patch b/queue-4.4/pci-rcar-fix-a-potential-null-pointer-dereference.patch new file mode 100644 index 0000000000..fddba55831 --- /dev/null +++ b/queue-4.4/pci-rcar-fix-a-potential-null-pointer-dereference.patch @@ -0,0 +1,39 @@ +From a71520327e749c703d4e873e5abb48f4ccea6da4 Mon Sep 17 00:00:00 2001 +From: Kangjie Lu +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 +Signed-off-by: Lorenzo Pieralisi +Reviewed-by: Ulrich Hecht +Reviewed-by: Geert Uytterhoeven +Reviewed-by: Simon Horman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/pci-rpadlpar-fix-leaked-device_node-references-in-ad.patch b/queue-4.4/pci-rpadlpar-fix-leaked-device_node-references-in-ad.patch new file mode 100644 index 0000000000..f807edb170 --- /dev/null +++ b/queue-4.4/pci-rpadlpar-fix-leaked-device_node-references-in-ad.patch @@ -0,0 +1,63 @@ +From a1d50cc0cf82c76e9be9d1aad951d743bcd9f367 Mon Sep 17 00:00:00 2001 +From: Tyrel Datwyler +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 +Signed-off-by: Bjorn Helgaas +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/pci-xilinx-check-for-__get_free_pages-failure.patch b/queue-4.4/pci-xilinx-check-for-__get_free_pages-failure.patch new file mode 100644 index 0000000000..189d814334 --- /dev/null +++ b/queue-4.4/pci-xilinx-check-for-__get_free_pages-failure.patch @@ -0,0 +1,66 @@ +From 55ffde78a6abd040b7080868c92c506599ad2199 Mon Sep 17 00:00:00 2001 +From: Kangjie Lu +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 +Signed-off-by: Lorenzo Pieralisi +Reviewed-by: Steven Price +Reviewed-by: Mukesh Ojha +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/perf-x86-intel-allow-pebs-multi-entry-in-watermark-m.patch b/queue-4.4/perf-x86-intel-allow-pebs-multi-entry-in-watermark-m.patch new file mode 100644 index 0000000000..d2ec8f5668 --- /dev/null +++ b/queue-4.4/perf-x86-intel-allow-pebs-multi-entry-in-watermark-m.patch @@ -0,0 +1,47 @@ +From 5d72525356b2370f8a79b9d39bc8e5aa8748376d Mon Sep 17 00:00:00 2001 +From: Stephane Eranian +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 +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/platform-chrome-cros_ec_proto-check-for-null-transfe.patch b/queue-4.4/platform-chrome-cros_ec_proto-check-for-null-transfe.patch new file mode 100644 index 0000000000..645b48bb81 --- /dev/null +++ b/queue-4.4/platform-chrome-cros_ec_proto-check-for-null-transfe.patch @@ -0,0 +1,51 @@ +From 46d0633a1de591d48fa97b183dc6eaa0278e80d5 Mon Sep 17 00:00:00 2001 +From: Enrico Granata +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 +Reviewed-by: Jett Rink +Signed-off-by: Enric Balletbo i Serra +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/pwm-fix-deadlock-warning-when-removing-pwm-device.patch b/queue-4.4/pwm-fix-deadlock-warning-when-removing-pwm-device.patch new file mode 100644 index 0000000000..d4b1b73469 --- /dev/null +++ b/queue-4.4/pwm-fix-deadlock-warning-when-removing-pwm-device.patch @@ -0,0 +1,275 @@ +From 116fd01059b57e0a499b2d7fb92d37259efca9c3 Mon Sep 17 00:00:00 2001 +From: Phong Hoang +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 +[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 +Tested-by: Hoan Nguyen An +Reviewed-by: Geert Uytterhoeven +Reviewed-by: Simon Horman +Reviewed-by: Uwe Kleine-König +Signed-off-by: Thierry Reding +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/pwm-tiehrpwm-update-shadow-register-for-disabling-pw.patch b/queue-4.4/pwm-tiehrpwm-update-shadow-register-for-disabling-pw.patch new file mode 100644 index 0000000000..a4f66dc594 --- /dev/null +++ b/queue-4.4/pwm-tiehrpwm-update-shadow-register-for-disabling-pw.patch @@ -0,0 +1,47 @@ +From b6517e9b996fa23703e2bc5d5f964ecc98c17688 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christoph=20Vogtl=C3=A4nder?= + +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 +[vigneshr@ti.com: Improve commit message] +Signed-off-by: Vignesh Raghavendra +Signed-off-by: Thierry Reding +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/series b/queue-4.4/series new file mode 100644 index 0000000000..5ba3dd8d01 --- /dev/null +++ b/queue-4.4/series @@ -0,0 +1,40 @@ +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 diff --git a/queue-4.4/soc-mediatek-pwrap-zero-initialize-rdata-in-pwrap_in.patch b/queue-4.4/soc-mediatek-pwrap-zero-initialize-rdata-in-pwrap_in.patch new file mode 100644 index 0000000000..0659a98d12 --- /dev/null +++ b/queue-4.4/soc-mediatek-pwrap-zero-initialize-rdata-in-pwrap_in.patch @@ -0,0 +1,44 @@ +From 56d26c53b046ef131a4fbd591c7c53c21d884b5b Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +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 +Reviewed-by: Nick Desaulniers +Reviewed-by: Arnd Bergmann +Signed-off-by: Matthias Brugger +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/sysctl-return-einval-if-val-violates-minmax.patch b/queue-4.4/sysctl-return-einval-if-val-violates-minmax.patch new file mode 100644 index 0000000000..05caa62685 --- /dev/null +++ b/queue-4.4/sysctl-return-einval-if-val-violates-minmax.patch @@ -0,0 +1,53 @@ +From 5e5570c4ae0a12ae1deea4615f8669a5ceb0330d Mon Sep 17 00:00:00 2001 +From: Christian Brauner +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 +Acked-by: Luis Chamberlain +Cc: Kees Cook +Cc: Alexey Dobriyan +Cc: Al Viro +Cc: Dominik Brodowski +Cc: "Eric W. Biederman" +Cc: Joe Lawrence +Cc: Waiman Long +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/uml-fix-a-boot-splat-wrt-use-of-cpu_all_mask.patch b/queue-4.4/uml-fix-a-boot-splat-wrt-use-of-cpu_all_mask.patch new file mode 100644 index 0000000000..9bef2d62fa --- /dev/null +++ b/queue-4.4/uml-fix-a-boot-splat-wrt-use-of-cpu_all_mask.patch @@ -0,0 +1,87 @@ +From 6d5f60012c11dbb218c0f4aed31525df59a2c31f Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Maciej=20=C5=BBenczykowski?= +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 +Cc: Jeff Dike +Cc: Richard Weinberger +Cc: Anton Ivanov +Cc: linux-um@lists.infradead.org +Cc: linux-kernel@vger.kernel.org + +Signed-off-by: Richard Weinberger +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/video-hgafb-fix-potential-null-pointer-dereference.patch b/queue-4.4/video-hgafb-fix-potential-null-pointer-dereference.patch new file mode 100644 index 0000000000..7a94163c37 --- /dev/null +++ b/queue-4.4/video-hgafb-fix-potential-null-pointer-dereference.patch @@ -0,0 +1,36 @@ +From 249d4b6f0c21546c06e831b822de5861b0d43807 Mon Sep 17 00:00:00 2001 +From: Kangjie Lu +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 +Cc: Aditya Pakki +Cc: Ferenc Bakonyi +[b.zolnierkie: minor patch summary fixup] +Signed-off-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/video-imsttfb-fix-potential-null-pointer-dereference.patch b/queue-4.4/video-imsttfb-fix-potential-null-pointer-dereference.patch new file mode 100644 index 0000000000..a8f718d5bc --- /dev/null +++ b/queue-4.4/video-imsttfb-fix-potential-null-pointer-dereference.patch @@ -0,0 +1,41 @@ +From f93beb4279d3c08c704fbeddde1ec39ecaa7bc08 Mon Sep 17 00:00:00 2001 +From: Kangjie Lu +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 +Cc: Aditya Pakki +Cc: Finn Thain +Cc: Rob Herring +Cc: Greg Kroah-Hartman +[b.zolnierkie: minor patch summary fixup] +Signed-off-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-4.4/x86-pci-fix-pci-irq-routing-table-memory-leak.patch b/queue-4.4/x86-pci-fix-pci-irq-routing-table-memory-leak.patch new file mode 100644 index 0000000000..3e67a65635 --- /dev/null +++ b/queue-4.4/x86-pci-fix-pci-irq-routing-table-memory-leak.patch @@ -0,0 +1,67 @@ +From d311506602ed27dcbb721e86e743afbc86ae9ca7 Mon Sep 17 00:00:00 2001 +From: Wenwen Wang +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 +[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 +Reviewed-by: Ingo Molnar +Acked-by: Thomas Gleixner +Signed-off-by: Sasha Levin +--- + 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 +