--- /dev/null
+From 36ac51fd19a2980d09fa7bf872c47c3bbfa96c8e Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 30 Apr 2019 12:18:28 +0200
+Subject: ALSA: hda - Register irq handler after the chip initialization
+
+[ Upstream commit f495222e28275222ab6fd93813bd3d462e16d340 ]
+
+Currently the IRQ handler in HD-audio controller driver is registered
+before the chip initialization. That is, we have some window opened
+between the azx_acquire_irq() call and the CORB/RIRB setup. If an
+interrupt is triggered in this small window, the IRQ handler may
+access to the uninitialized RIRB buffer, which leads to a NULL
+dereference Oops.
+
+This is usually no big problem since most of Intel chips do register
+the IRQ via MSI, and we've already fixed the order of the IRQ
+enablement and the CORB/RIRB setup in the former commit b61749a89f82
+("sound: enable interrupt after dma buffer initialization"), hence the
+IRQ won't be triggered in that room. However, some platforms use a
+shared IRQ, and this may allow the IRQ trigger by another source.
+
+Another possibility is the kdump environment: a stale interrupt might
+be present in there, the IRQ handler can be falsely triggered as well.
+
+For covering this small race, let's move the azx_acquire_irq() call
+after hda_intel_init_chip() call. Although this is a bit radical
+change, it can cover more widely than checking the CORB/RIRB setup
+locally in the callee side.
+
+Reported-by: Liwei Song <liwei.song@windriver.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/pci/hda/hda_intel.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
+index 9bc8a7cb40ea..45bf89ed31de 100644
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -1883,9 +1883,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);
+
+@@ -2000,6 +1997,9 @@ static int azx_first_init(struct azx *chip)
+ return -ENODEV;
+ }
+
++ if (azx_acquire_irq(chip, 0) < 0)
++ return -EBUSY;
++
+ strcpy(card->driver, "HDA-Intel");
+ strlcpy(card->shortname, driver_short_names[chip->driver_type],
+ sizeof(card->shortname));
+--
+2.20.1
+
--- /dev/null
+From 84680168bc86ac3e20854bcdf42343148cf5c292 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 9 Apr 2019 17:35:22 +0200
+Subject: ALSA: seq: Protect in-kernel ioctl calls with mutex
+
+[ Upstream commit feb689025fbb6f0aa6297d3ddf97de945ea4ad32 ]
+
+ALSA OSS sequencer calls the ioctl function indirectly via
+snd_seq_kernel_client_ctl(). While we already applied the protection
+against races between the normal ioctls and writes via the client's
+ioctl_mutex, this code path was left untouched. And this seems to be
+the cause of still remaining some rare UAF as spontaneously triggered
+by syzkaller.
+
+For the sake of robustness, wrap the ioctl_mutex also for the call via
+snd_seq_kernel_client_ctl(), too.
+
+Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/core/seq/seq_clientmgr.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
+index b55cb96d1fed..40ae8f67efde 100644
+--- a/sound/core/seq/seq_clientmgr.c
++++ b/sound/core/seq/seq_clientmgr.c
+@@ -2343,14 +2343,19 @@ int snd_seq_kernel_client_ctl(int clientid, unsigned int cmd, void *arg)
+ {
+ const struct ioctl_handler *handler;
+ struct snd_seq_client *client;
++ int err;
+
+ client = clientptr(clientid);
+ if (client == NULL)
+ return -ENXIO;
+
+ for (handler = ioctl_handlers; handler->cmd > 0; ++handler) {
+- if (handler->cmd == cmd)
+- return handler->func(client, arg);
++ if (handler->cmd == cmd) {
++ mutex_lock(&client->ioctl_mutex);
++ err = handler->func(client, arg);
++ mutex_unlock(&client->ioctl_mutex);
++ return err;
++ }
+ }
+
+ pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",
+--
+2.20.1
+
--- /dev/null
+From 6fed5b28e9dc4ffbea609c6051e201abc155b3a4 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzk@kernel.org>
+Date: Thu, 14 Mar 2019 21:02:17 +0100
+Subject: ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8
+ regulators on Arndale Octa
+
+[ Upstream commit 5ab99cf7d5e96e3b727c30e7a8524c976bd3723d ]
+
+The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned
+off by Linux kernel as unused. However they supply critical parts of
+SoC so they should be always on:
+
+1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift,
+ RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt
+ lines, TTL/UARTR level shift, reset pins and SW-TACT1 button.
+ It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and
+ VDDQ_GPIO (gpm7, gpy7).
+ The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so
+ marking it "always-on" only reflects its real status.
+
+2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores,
+ memory and Mali (G3D).
+
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+index cdda614e417e..a370857beac0 100644
+--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
++++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+@@ -106,6 +106,7 @@
+ regulator-name = "PVDD_APIO_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
++ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+@@ -144,6 +145,7 @@
+ regulator-name = "PVDD_ABB_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
++ regulator-always-on;
+ };
+
+ ldo9_reg: LDO9 {
+--
+2.20.1
+
--- /dev/null
+From 8c942e5965e7de30b202724596e9bbb981e7b312 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:24 -0700
+Subject: ARM: dts: imx50: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
+
+[ Upstream commit b7b4fda2636296471e29b78c2aa9535d7bedb7a0 ]
+
+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 IMX5_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx50.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
+index 7fae2ffb76fe..ab522c2da6df 100644
+--- a/arch/arm/boot/dts/imx50.dtsi
++++ b/arch/arm/boot/dts/imx50.dtsi
+@@ -420,7 +420,7 @@
+ reg = <0x63fb0000 0x4000>;
+ interrupts = <6>;
+ clocks = <&clks IMX5_CLK_SDMA_GATE>,
+- <&clks IMX5_CLK_SDMA_GATE>;
++ <&clks IMX5_CLK_AHB>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+ fsl,sdma-ram-script-name = "imx/sdma/sdma-imx50.bin";
+--
+2.20.1
+
--- /dev/null
+From ba51f329a3b709b405bf7fb4c9b49ad200e862bb Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:23 -0700
+Subject: ARM: dts: imx51: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
+
+[ Upstream commit 918bbde8085ae147a43dcb491953e0dd8f3e9d6a ]
+
+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 IMX5_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx51.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
+index 5c4ba91e43ba..ef2abc097843 100644
+--- a/arch/arm/boot/dts/imx51.dtsi
++++ b/arch/arm/boot/dts/imx51.dtsi
+@@ -481,7 +481,7 @@
+ reg = <0x83fb0000 0x4000>;
+ interrupts = <6>;
+ clocks = <&clks IMX5_CLK_SDMA_GATE>,
+- <&clks IMX5_CLK_SDMA_GATE>;
++ <&clks IMX5_CLK_AHB>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+ fsl,sdma-ram-script-name = "imx/sdma/sdma-imx51.bin";
+--
+2.20.1
+
--- /dev/null
+From 100ab3d575481bfebeb60b8afff51795cfe72bde Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:22 -0700
+Subject: ARM: dts: imx53: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
+
+[ Upstream commit 28c168018e0902c67eb9c60d0fc4c8aa166c4efe ]
+
+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 IMX5_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx53.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
+index 6386185ae234..b6b0818343c4 100644
+--- a/arch/arm/boot/dts/imx53.dtsi
++++ b/arch/arm/boot/dts/imx53.dtsi
+@@ -701,7 +701,7 @@
+ reg = <0x63fb0000 0x4000>;
+ interrupts = <6>;
+ clocks = <&clks IMX5_CLK_SDMA_GATE>,
+- <&clks IMX5_CLK_SDMA_GATE>;
++ <&clks IMX5_CLK_AHB>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+ fsl,sdma-ram-script-name = "imx/sdma/sdma-imx53.bin";
+--
+2.20.1
+
--- /dev/null
+From 9ab0c828c495d6d625ce63acb151810ac4bd49a7 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:16 -0700
+Subject: ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA
+
+[ Upstream commit b14c872eebc501b9640b04f4a152df51d6eaf2fc ]
+
+Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
+clock to determine if it needs to configure the IP block as operating
+at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
+clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality(this at least
+breaks RAVE SP serdev driver on RDU2). Fix the code to specify
+IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect
+clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Tested-by: Adam Ford <aford173@gmail.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
+index 61d2d26afbf4..00d44a60972f 100644
+--- a/arch/arm/boot/dts/imx6qdl.dtsi
++++ b/arch/arm/boot/dts/imx6qdl.dtsi
+@@ -905,7 +905,7 @@
+ compatible = "fsl,imx6q-sdma", "fsl,imx35-sdma";
+ reg = <0x020ec000 0x4000>;
+ interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
+- clocks = <&clks IMX6QDL_CLK_SDMA>,
++ clocks = <&clks IMX6QDL_CLK_IPG>,
+ <&clks IMX6QDL_CLK_SDMA>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+--
+2.20.1
+
--- /dev/null
+From 5ab422cbddfb3fdb9145be2f7fcf850157e59003 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:20 -0700
+Subject: ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA
+
+[ Upstream commit c5ed5daa65d5f665e666b76c3dbfa503066defde ]
+
+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 IMX6SLL_CLK_SDMA result in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX6SLL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx6sll.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
+index 3e6ffaf5f104..7c7d5c47578e 100644
+--- a/arch/arm/boot/dts/imx6sll.dtsi
++++ b/arch/arm/boot/dts/imx6sll.dtsi
+@@ -591,7 +591,7 @@
+ compatible = "fsl,imx6sll-sdma", "fsl,imx35-sdma";
+ reg = <0x020ec000 0x4000>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+- clocks = <&clks IMX6SLL_CLK_SDMA>,
++ clocks = <&clks IMX6SLL_CLK_IPG>,
+ <&clks IMX6SLL_CLK_SDMA>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+--
+2.20.1
+
--- /dev/null
+From 64d7e5b8198904e51691c221d9a5c671dbb4b188 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:21 -0700
+Subject: ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA
+
+[ Upstream commit cc839d0f8c284fcb7591780b568f13415bbb737c ]
+
+Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
+clock to determine if it needs to configure the IP block as operating
+at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
+clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx6sl.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
+index 7a4f5dace902..2fa88c6f1882 100644
+--- a/arch/arm/boot/dts/imx6sl.dtsi
++++ b/arch/arm/boot/dts/imx6sl.dtsi
+@@ -739,7 +739,7 @@
+ reg = <0x020ec000 0x4000>;
+ interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SL_CLK_SDMA>,
+- <&clks IMX6SL_CLK_SDMA>;
++ <&clks IMX6SL_CLK_AHB>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+ /* imx6sl reuses imx6q sdma firmware */
+--
+2.20.1
+
--- /dev/null
+From 734f857bdeaba2ac58d21e92c0494d5c511127f4 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:17 -0700
+Subject: ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA
+
+[ Upstream commit 8979117765c19edc3b01cc0ef853537bf93eea4b ]
+
+Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
+clock to determine if it needs to configure the IP block as operating
+at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
+clocks as IMX6SX_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx6sx.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
+index 50083cecc6c9..7b62e6fb47eb 100644
+--- a/arch/arm/boot/dts/imx6sx.dtsi
++++ b/arch/arm/boot/dts/imx6sx.dtsi
+@@ -803,7 +803,7 @@
+ compatible = "fsl,imx6sx-sdma", "fsl,imx6q-sdma";
+ reg = <0x020ec000 0x4000>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+- clocks = <&clks IMX6SX_CLK_SDMA>,
++ clocks = <&clks IMX6SX_CLK_IPG>,
+ <&clks IMX6SX_CLK_SDMA>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+--
+2.20.1
+
--- /dev/null
+From 8988b21df8124166a7907a234a895b3c3d610289 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:19 -0700
+Subject: ARM: dts: imx6ul: Specify IMX6UL_CLK_IPG as "ipg" clock to SDMA
+
+[ Upstream commit 7b3132ecefdd1fcdf6b86e62021d0e55ea8034db ]
+
+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 IMX6UL_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX6UL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx6ul.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
+index 6dc0b569acdf..2366f093cc76 100644
+--- a/arch/arm/boot/dts/imx6ul.dtsi
++++ b/arch/arm/boot/dts/imx6ul.dtsi
+@@ -707,7 +707,7 @@
+ "fsl,imx35-sdma";
+ reg = <0x020ec000 0x4000>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+- clocks = <&clks IMX6UL_CLK_SDMA>,
++ clocks = <&clks IMX6UL_CLK_IPG>,
+ <&clks IMX6UL_CLK_SDMA>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+--
+2.20.1
+
--- /dev/null
+From 7930cdd19d60b78df445a153e0468c7baa256e09 Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Thu, 28 Mar 2019 23:49:18 -0700
+Subject: ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA
+
+[ Upstream commit 412b032a1dc72fc9d1c258800355efa6671b6315 ]
+
+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 IMX7D_CLK_SDMA results in driver incorrectly thinking that
+ratio is 1:1 which results in broken SDMA funtionality. Fix the code
+to specify IMX7D_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
+incorrect clock ratio.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Angus Ainslie (Purism) <angus@akkea.ca>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Fabio Estevam <fabio.estevam@nxp.com>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/imx7s.dtsi | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
+index a052198f6e96..a7f697b0290f 100644
+--- a/arch/arm/boot/dts/imx7s.dtsi
++++ b/arch/arm/boot/dts/imx7s.dtsi
+@@ -1050,8 +1050,8 @@
+ compatible = "fsl,imx7d-sdma", "fsl,imx35-sdma";
+ reg = <0x30bd0000 0x10000>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+- clocks = <&clks IMX7D_SDMA_CORE_CLK>,
+- <&clks IMX7D_AHB_CHANNEL_ROOT_CLK>;
++ clocks = <&clks IMX7D_IPG_ROOT_CLK>,
++ <&clks IMX7D_SDMA_CORE_CLK>;
+ clock-names = "ipg", "ahb";
+ #dma-cells = <3>;
+ fsl,sdma-ram-script-name = "imx/sdma/sdma-imx7d.bin";
+--
+2.20.1
+
--- /dev/null
+From ffde4cfbf3faf1466349ab2423189e25ffc16e4e Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+Date: Mon, 18 Feb 2019 15:34:12 +0100
+Subject: ARM: exynos: Fix undefined instruction during Exynos5422 resume
+
+[ Upstream commit 4d8e3e951a856777720272ce27f2c738a3eeef8c ]
+
+During early system resume on Exynos5422 with performance counters enabled
+the following kernel oops happens:
+
+ Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
+ Modules linked in:
+ CPU: 0 PID: 1433 Comm: bash Tainted: G W 5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480
+ Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
+ ...
+ Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
+ Control: 10c5387d Table: 4451006a DAC: 00000051
+ Process bash (pid: 1433, stack limit = 0xb7e0e22f)
+ ...
+ (reset_ctrl_regs) from [<c0112ad0>] (dbg_cpu_pm_notify+0x1c/0x24)
+ (dbg_cpu_pm_notify) from [<c014c840>] (notifier_call_chain+0x44/0x84)
+ (notifier_call_chain) from [<c014cbc0>] (__atomic_notifier_call_chain+0x7c/0x128)
+ (__atomic_notifier_call_chain) from [<c01ffaac>] (cpu_pm_notify+0x30/0x54)
+ (cpu_pm_notify) from [<c055116c>] (syscore_resume+0x98/0x3f4)
+ (syscore_resume) from [<c0189350>] (suspend_devices_and_enter+0x97c/0xe74)
+ (suspend_devices_and_enter) from [<c0189fb8>] (pm_suspend+0x770/0xc04)
+ (pm_suspend) from [<c0187740>] (state_store+0x6c/0xcc)
+ (state_store) from [<c09fa698>] (kobj_attr_store+0x14/0x20)
+ (kobj_attr_store) from [<c030159c>] (sysfs_kf_write+0x4c/0x50)
+ (sysfs_kf_write) from [<c0300620>] (kernfs_fop_write+0xfc/0x1e0)
+ (kernfs_fop_write) from [<c0282be8>] (__vfs_write+0x2c/0x160)
+ (__vfs_write) from [<c0282ea4>] (vfs_write+0xa4/0x16c)
+ (vfs_write) from [<c0283080>] (ksys_write+0x40/0x8c)
+ (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
+
+Undefined instruction is triggered during CP14 reset, because bits: #16
+(Secure privileged invasive debug disabled) and #17 (Secure privileged
+noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN
+and SPIDEN lines, which are provided by Secure JTAG hardware block. That
+block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422
+boots on cluster 1 (LITTLE/KFC).
+
+To fix this issue it is enough to turn on the power on the cluster 0 for
+a while. This lets the Secure JTAG block to propagate the needed signals
+to LITTLE/KFC cores and change their DSCR.
+
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mach-exynos/suspend.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
+index b1fe53e8b460..088c34e99b02 100644
+--- a/arch/arm/mach-exynos/suspend.c
++++ b/arch/arm/mach-exynos/suspend.c
+@@ -434,8 +434,27 @@ early_wakeup:
+
+ static void exynos5420_prepare_pm_resume(void)
+ {
++ unsigned int mpidr, cluster;
++
++ mpidr = read_cpuid_mpidr();
++ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
++
+ if (IS_ENABLED(CONFIG_EXYNOS5420_MCPM))
+ WARN_ON(mcpm_cpu_powered_up());
++
++ if (IS_ENABLED(CONFIG_HW_PERF_EVENTS) && cluster != 0) {
++ /*
++ * When system is resumed on the LITTLE/KFC core (cluster 1),
++ * the DSCR is not properly updated until the power is turned
++ * on also for the cluster 0. Enable it for a while to
++ * propagate the SPNIDEN and SPIDEN signals from Secure JTAG
++ * block and avoid undefined instruction issue on CP14 reset.
++ */
++ pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
++ EXYNOS_COMMON_CONFIGURATION(0));
++ pmu_raw_writel(0,
++ EXYNOS_COMMON_CONFIGURATION(0));
++ }
+ }
+
+ static void exynos5420_pm_resume(void)
+--
+2.20.1
+
--- /dev/null
+From fb4c9de4016dba651888db475fca03eff3423b73 Mon Sep 17 00:00:00 2001
+From: Kabir Sahane <x0153567@ti.com>
+Date: Tue, 9 Apr 2019 08:05:17 -0700
+Subject: ARM: OMAP2+: pm33xx-core: Do not Turn OFF CEFUSE as PPA may be using
+ it
+
+[ Upstream commit 72aff4ecf1cb85a3c6e6b42ccbda0bc631b090b3 ]
+
+This area is used to store keys by HSPPA in case of AM438x SOC. Leave it
+active.
+
+Signed-off-by: Kabir Sahane <x0153567@ti.com>
+Signed-off-by: Andrew F. Davis <afd@ti.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mach-omap2/pm33xx-core.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/arch/arm/mach-omap2/pm33xx-core.c b/arch/arm/mach-omap2/pm33xx-core.c
+index f4971e4a86b2..ca7026958d42 100644
+--- a/arch/arm/mach-omap2/pm33xx-core.c
++++ b/arch/arm/mach-omap2/pm33xx-core.c
+@@ -51,10 +51,12 @@ static int amx3_common_init(void)
+
+ /* CEFUSE domain can be turned off post bootup */
+ cefuse_pwrdm = pwrdm_lookup("cefuse_pwrdm");
+- if (cefuse_pwrdm)
+- omap_set_pwrdm_state(cefuse_pwrdm, PWRDM_POWER_OFF);
+- else
++ if (!cefuse_pwrdm)
+ pr_err("PM: Failed to get cefuse_pwrdm\n");
++ else if (omap_type() != OMAP2_DEVICE_TYPE_GP)
++ pr_info("PM: Leaving EFUSE power domain active\n");
++ else
++ omap_set_pwrdm_state(cefuse_pwrdm, PWRDM_POWER_OFF);
+
+ return 0;
+ }
+--
+2.20.1
+
--- /dev/null
+From 3d51b868c6a0d2acaaf2dc2eac9c38597e9d3aad Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Tue, 14 May 2019 15:41:48 -0700
+Subject: ARM: prevent tracing IPI_CPU_BACKTRACE
+
+[ Upstream commit be167862ae7dd85c56d385209a4890678e1b0488 ]
+
+Patch series "compiler: allow all arches to enable
+CONFIG_OPTIMIZE_INLINING", v3.
+
+This patch (of 11):
+
+When function tracing for IPIs is enabled, we get a warning for an
+overflow of the ipi_types array with the IPI_CPU_BACKTRACE type as
+triggered by raise_nmi():
+
+ arch/arm/kernel/smp.c: In function 'raise_nmi':
+ arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
+ trace_ipi_raise(target, ipi_types[ipinr]);
+
+This is a correct warning as we actually overflow the array here.
+
+This patch raise_nmi() to call __smp_cross_call() instead of
+smp_cross_call(), to avoid calling into ftrace. For clarification, I'm
+also adding a two new code comments describing how this one is special.
+
+The warning appears to have shown up after commit e7273ff49acf ("ARM:
+8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the
+number assignment from '15' to '8', but as far as I can tell has existed
+since the IPI tracepoints were first introduced. If we decide to
+backport this patch to stable kernels, we probably need to backport
+e7273ff49acf as well.
+
+[yamada.masahiro@socionext.com: rebase on v5.1-rc1]
+Link: http://lkml.kernel.org/r/20190423034959.13525-2-yamada.masahiro@socionext.com
+Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
+Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Christophe Leroy <christophe.leroy@c-s.fr>
+Cc: Mathieu Malaterre <malat@debian.org>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Cc: Paul Mackerras <paulus@samba.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Stefan Agner <stefan@agner.ch>
+Cc: Boris Brezillon <bbrezillon@kernel.org>
+Cc: Miquel Raynal <miquel.raynal@bootlin.com>
+Cc: Richard Weinberger <richard@nod.at>
+Cc: David Woodhouse <dwmw2@infradead.org>
+Cc: Brian Norris <computersforpeace@gmail.com>
+Cc: Marek Vasut <marek.vasut@gmail.com>
+Cc: Russell King <rmk+kernel@arm.linux.org.uk>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/include/asm/hardirq.h | 1 +
+ arch/arm/kernel/smp.c | 6 +++++-
+ 2 files changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
+index cba23eaa6072..7a88f160b1fb 100644
+--- a/arch/arm/include/asm/hardirq.h
++++ b/arch/arm/include/asm/hardirq.h
+@@ -6,6 +6,7 @@
+ #include <linux/threads.h>
+ #include <asm/irq.h>
+
++/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
+ #define NR_IPI 7
+
+ typedef struct {
+diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
+index a3ce7c5365fa..bada66ef4419 100644
+--- a/arch/arm/kernel/smp.c
++++ b/arch/arm/kernel/smp.c
+@@ -76,6 +76,10 @@ enum ipi_msg_type {
+ IPI_CPU_STOP,
+ IPI_IRQ_WORK,
+ IPI_COMPLETION,
++ /*
++ * CPU_BACKTRACE is special and not included in NR_IPI
++ * or tracable with trace_ipi_*
++ */
+ IPI_CPU_BACKTRACE,
+ /*
+ * SGI8-15 can be reserved by secure firmware, and thus may
+@@ -803,7 +807,7 @@ core_initcall(register_cpufreq_notifier);
+
+ static void raise_nmi(cpumask_t *mask)
+ {
+- smp_cross_call(mask, IPI_CPU_BACKTRACE);
++ __smp_cross_call(mask, IPI_CPU_BACKTRACE);
+ }
+
+ void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
+--
+2.20.1
+
--- /dev/null
+From 1586c239b0d7a3b9458e474b0fd7bd75fb84f996 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Tue, 30 Apr 2019 09:52:24 +0800
+Subject: blk-mq: move cancel of requeue_work into blk_mq_release
+
+[ Upstream commit fbc2a15e3433058582e5635aabe48a3011a644a8 ]
+
+With holding queue's kobject refcount, it is safe for driver
+to schedule requeue. However, blk_mq_kick_requeue_list() may
+be called after blk_sync_queue() is done because of concurrent
+requeue activities, then requeue work may not be completed when
+freeing queue, and kernel oops is triggered.
+
+So moving the cancel of requeue_work into blk_mq_release() for
+avoiding race between requeue and freeing queue.
+
+Cc: Dongli Zhang <dongli.zhang@oracle.com>
+Cc: James Smart <james.smart@broadcom.com>
+Cc: Bart Van Assche <bart.vanassche@wdc.com>
+Cc: linux-scsi@vger.kernel.org,
+Cc: Martin K . Petersen <martin.petersen@oracle.com>,
+Cc: Christoph Hellwig <hch@lst.de>,
+Cc: James E . J . Bottomley <jejb@linux.vnet.ibm.com>,
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Tested-by: James Smart <james.smart@broadcom.com>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-core.c | 1 -
+ block/blk-mq.c | 2 ++
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/block/blk-core.c b/block/blk-core.c
+index 33488b1426b7..6eed5d84c2ef 100644
+--- a/block/blk-core.c
++++ b/block/blk-core.c
+@@ -411,7 +411,6 @@ void blk_sync_queue(struct request_queue *q)
+ struct blk_mq_hw_ctx *hctx;
+ int i;
+
+- cancel_delayed_work_sync(&q->requeue_work);
+ queue_for_each_hw_ctx(q, hctx, i)
+ cancel_delayed_work_sync(&hctx->run_work);
+ } else {
+diff --git a/block/blk-mq.c b/block/blk-mq.c
+index 4e563ee462cb..70d839b9c3b0 100644
+--- a/block/blk-mq.c
++++ b/block/blk-mq.c
+@@ -2465,6 +2465,8 @@ void blk_mq_release(struct request_queue *q)
+ struct blk_mq_hw_ctx *hctx;
+ unsigned int i;
+
++ cancel_delayed_work_sync(&q->requeue_work);
++
+ /* hctx kobj stays in hctx */
+ queue_for_each_hw_ctx(q, hctx, i) {
+ if (!hctx)
+--
+2.20.1
+
--- /dev/null
+From b96ccad0ca65c47bfc56df7de2f8fbdf90fff3e7 Mon Sep 17 00:00:00 2001
+From: Paolo Valente <paolo.valente@linaro.org>
+Date: Tue, 12 Mar 2019 09:59:27 +0100
+Subject: block, bfq: increase idling for weight-raised queues
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 778c02a236a8728bb992de10ed1f12c0be5b7b0e ]
+
+If a sync bfq_queue has a higher weight than some other queue, and
+remains temporarily empty while in service, then, to preserve the
+bandwidth share of the queue, it is necessary to plug I/O dispatching
+until a new request arrives for the queue. In addition, a timeout
+needs to be set, to avoid waiting for ever if the process associated
+with the queue has actually finished its I/O.
+
+Even with the above timeout, the device is however not fed with new
+I/O for a while, if the process has finished its I/O. If this happens
+often, then throughput drops and latencies grow. For this reason, the
+timeout is kept rather low: 8 ms is the current default.
+
+Unfortunately, such a low value may cause, on the opposite end, a
+violation of bandwidth guarantees for a process that happens to issue
+new I/O too late. The higher the system load, the higher the
+probability that this happens to some process. This is a problem in
+scenarios where service guarantees matter more than throughput. One
+important case are weight-raised queues, which need to be granted a
+very high fraction of the bandwidth.
+
+To address this issue, this commit lower-bounds the plugging timeout
+for weight-raised queues to 20 ms. This simple change provides
+relevant benefits. For example, on a PLEXTOR PX-256M5S, with which
+gnome-terminal starts in 0.6 seconds if there is no other I/O in
+progress, the same applications starts in
+- 0.8 seconds, instead of 1.2 seconds, if ten files are being read
+ sequentially in parallel
+- 1 second, instead of 2 seconds, if, in parallel, five files are
+ being read sequentially, and five more files are being written
+ sequentially
+
+Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com>
+Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/bfq-iosched.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index 15e8c9955b79..6bb397995610 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -2509,6 +2509,8 @@ static void bfq_arm_slice_timer(struct bfq_data *bfqd)
+ if (BFQQ_SEEKY(bfqq) && bfqq->wr_coeff == 1 &&
+ bfq_symmetric_scenario(bfqd))
+ sl = min_t(u64, sl, BFQ_MIN_TT);
++ else if (bfqq->wr_coeff > 1)
++ sl = max_t(u32, sl, 20ULL * NSEC_PER_MSEC);
+
+ bfqd->last_idling_start = ktime_get();
+ hrtimer_start(&bfqd->idle_slice_timer, ns_to_ktime(sl),
+--
+2.20.1
+
--- /dev/null
+From 0f2c873122abd31fc364dd9aef452ae94c80d50b Mon Sep 17 00:00:00 2001
+From: Krzesimir Nowak <krzesimir@kinvolk.io>
+Date: Wed, 8 May 2019 18:08:58 +0200
+Subject: bpf: fix undefined behavior in narrow load handling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit e2f7fc0ac6957cabff4cecf6c721979b571af208 ]
+
+Commit 31fd85816dbe ("bpf: permits narrower load from bpf program
+context fields") made the verifier add AND instructions to clear the
+unwanted bits with a mask when doing a narrow load. The mask is
+computed with
+
+ (1 << size * 8) - 1
+
+where "size" is the size of the narrow load. When doing a 4 byte load
+of a an 8 byte field the verifier shifts the literal 1 by 32 places to
+the left. This results in an overflow of a signed integer, which is an
+undefined behavior. Typically, the computed mask was zero, so the
+result of the narrow load ended up being zero too.
+
+Cast the literal to long long to avoid overflows. Note that narrow
+load of the 4 byte fields does not have the undefined behavior,
+because the load size can only be either 1 or 2 bytes, so shifting 1
+by 8 or 16 places will not overflow it. And reading 4 bytes would not
+be a narrow load of a 4 bytes field.
+
+Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
+Reviewed-by: Alban Crequy <alban@kinvolk.io>
+Reviewed-by: Iago López Galeiras <iago@kinvolk.io>
+Signed-off-by: Krzesimir Nowak <krzesimir@kinvolk.io>
+Cc: Yonghong Song <yhs@fb.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/bpf/verifier.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
+index acc2305ad895..d3580a68dbef 100644
+--- a/kernel/bpf/verifier.c
++++ b/kernel/bpf/verifier.c
+@@ -5743,7 +5743,7 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
+ insn->dst_reg,
+ shift);
+ insn_buf[cnt++] = BPF_ALU64_IMM(BPF_AND, insn->dst_reg,
+- (1 << size * 8) - 1);
++ (1ULL << size * 8) - 1);
+ }
+ }
+
+--
+2.20.1
+
--- /dev/null
+From 37fb0a55032f46776cb2b53484a2e8c528377cc8 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Thu, 11 Apr 2019 16:21:53 -0700
+Subject: clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288
+
+[ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ]
+
+Experimentally it can be seen that going into deep sleep (specifically
+setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1)
+appears to fail unless "aclk_dmac1" is on. The failure is that the
+system never signals that it made it into suspend on the GLOBAL_PWROFF
+pin and it just hangs.
+
+NOTE that it's confirmed that it's the actual suspend that fails, not
+one of the earlier calls to read/write registers. Specifically if you
+comment out the "PMU_GLOBAL_INT_DISABLE" setting in
+rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in
+rockchip_lpmode_enter() then you can exercise the whole suspend path
+without any crashing.
+
+This is currently not a problem with suspend upstream because there is
+no current way to exercise the deep suspend code. However, anyone
+trying to make it work will run into this issue.
+
+This was not a problem on shipping rk3288-based Chromebooks because
+those devices all ran on an old kernel based on 3.14. On that kernel
+"aclk_dmac1" appears to be left on all the time.
+
+There are several ways to skin this problem.
+
+A) We could add "aclk_dmac1" to the list of critical clocks and that
+apperas to work, but presumably that wastes power.
+
+B) We could keep a list of "struct clk" objects to enable at suspend
+time in clk-rk3288.c and use the standard clock APIs.
+
+C) We could make the rk3288-pmu driver keep a list of clocks to enable
+at suspend time. Presumably this would require a dts and bindings
+change.
+
+D) We could just whack the clock on in the existing syscore suspend
+function where we whack a bunch of other clocks. This is particularly
+easy because we know for sure that the clock's only parent
+("aclk_cpu") is a critical clock so we don't need to do anything more
+than ungate it.
+
+In this case I have chosen D) because it seemed like the least work,
+but any of the other options would presumably also work fine.
+
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clk/rockchip/clk-rk3288.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
+index 64191694ff6e..9cfdbea493bb 100644
+--- a/drivers/clk/rockchip/clk-rk3288.c
++++ b/drivers/clk/rockchip/clk-rk3288.c
+@@ -835,6 +835,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)];
+@@ -850,6 +853,14 @@ static int rk3288_clk_suspend(void)
+ readl_relaxed(rk3288_cru_base + reg_id);
+ }
+
++ /*
++ * Going into deep sleep (specifically setting PMU_CLR_DMA in
++ * RK3288_PMU_PWRMODE_CON1) appears to fail unless
++ * "aclk_dmac1" is on.
++ */
++ writel_relaxed(1 << (12 + 16),
++ rk3288_cru_base + RK3288_CLKGATE_CON(10));
++
+ /*
+ * Switch PLLs other than DPLL (for SDRAM) to slow mode to
+ * avoid crashes on resume. The Mask ROM on the system will
+--
+2.20.1
+
--- /dev/null
+From 5a9168e8fe444a960f0085e350c50222f3ad0daa Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Sun, 5 May 2019 11:03:12 +0800
+Subject: configfs: fix possible use-after-free in configfs_register_group
+
+[ Upstream commit 35399f87e271f7cf3048eab00a421a6519ac8441 ]
+
+In configfs_register_group(), if create_default_group() failed, we
+forget to unlink the group. It will left a invalid item in the parent list,
+which may trigger the use-after-free issue seen below:
+
+BUG: KASAN: use-after-free in __list_add_valid+0xd4/0xe0 lib/list_debug.c:26
+Read of size 8 at addr ffff8881ef61ae20 by task syz-executor.0/5996
+
+CPU: 1 PID: 5996 Comm: syz-executor.0 Tainted: G C 5.0.0+ #5
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xa9/0x10e lib/dump_stack.c:113
+ print_address_description+0x65/0x270 mm/kasan/report.c:187
+ kasan_report+0x149/0x18d mm/kasan/report.c:317
+ __list_add_valid+0xd4/0xe0 lib/list_debug.c:26
+ __list_add include/linux/list.h:60 [inline]
+ list_add_tail include/linux/list.h:93 [inline]
+ link_obj+0xb0/0x190 fs/configfs/dir.c:759
+ link_group+0x1c/0x130 fs/configfs/dir.c:784
+ configfs_register_group+0x56/0x1e0 fs/configfs/dir.c:1751
+ configfs_register_default_group+0x72/0xc0 fs/configfs/dir.c:1834
+ ? 0xffffffffc1be0000
+ iio_sw_trigger_init+0x23/0x1000 [industrialio_sw_trigger]
+ do_one_initcall+0xbc/0x47d init/main.c:887
+ do_init_module+0x1b5/0x547 kernel/module.c:3456
+ load_module+0x6405/0x8c10 kernel/module.c:3804
+ __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
+ do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+RIP: 0033:0x462e99
+Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
+RSP: 002b:00007f494ecbcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
+RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
+RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
+RBP: 00007f494ecbcc70 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 00007f494ecbd6bc
+R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
+
+Allocated by task 5987:
+ set_track mm/kasan/common.c:87 [inline]
+ __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:497
+ kmalloc include/linux/slab.h:545 [inline]
+ kzalloc include/linux/slab.h:740 [inline]
+ configfs_register_default_group+0x4c/0xc0 fs/configfs/dir.c:1829
+ 0xffffffffc1bd0023
+ do_one_initcall+0xbc/0x47d init/main.c:887
+ do_init_module+0x1b5/0x547 kernel/module.c:3456
+ load_module+0x6405/0x8c10 kernel/module.c:3804
+ __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
+ do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Freed by task 5987:
+ set_track mm/kasan/common.c:87 [inline]
+ __kasan_slab_free+0x130/0x180 mm/kasan/common.c:459
+ slab_free_hook mm/slub.c:1429 [inline]
+ slab_free_freelist_hook mm/slub.c:1456 [inline]
+ slab_free mm/slub.c:3003 [inline]
+ kfree+0xe1/0x270 mm/slub.c:3955
+ configfs_register_default_group+0x9a/0xc0 fs/configfs/dir.c:1836
+ 0xffffffffc1bd0023
+ do_one_initcall+0xbc/0x47d init/main.c:887
+ do_init_module+0x1b5/0x547 kernel/module.c:3456
+ load_module+0x6405/0x8c10 kernel/module.c:3804
+ __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
+ do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+The buggy address belongs to the object at ffff8881ef61ae00
+ which belongs to the cache kmalloc-192 of size 192
+The buggy address is located 32 bytes inside of
+ 192-byte region [ffff8881ef61ae00, ffff8881ef61aec0)
+The buggy address belongs to the page:
+page:ffffea0007bd8680 count:1 mapcount:0 mapping:ffff8881f6c03000 index:0xffff8881ef61a700
+flags: 0x2fffc0000000200(slab)
+raw: 02fffc0000000200 ffffea0007ca4740 0000000500000005 ffff8881f6c03000
+raw: ffff8881ef61a700 000000008010000c 00000001ffffffff 0000000000000000
+page dumped because: kasan: bad access detected
+
+Memory state around the buggy address:
+ ffff8881ef61ad00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ ffff8881ef61ad80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
+>ffff8881ef61ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+ ^
+ ffff8881ef61ae80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
+ ffff8881ef61af00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+
+Fixes: 5cf6a51e6062 ("configfs: allow dynamic group creation")
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/configfs/dir.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
+index 39843fa7e11b..920d350df37b 100644
+--- a/fs/configfs/dir.c
++++ b/fs/configfs/dir.c
+@@ -1755,12 +1755,19 @@ int configfs_register_group(struct config_group *parent_group,
+
+ inode_lock_nested(d_inode(parent), I_MUTEX_PARENT);
+ ret = create_default_group(parent_group, group);
+- if (!ret) {
+- spin_lock(&configfs_dirent_lock);
+- configfs_dir_set_ready(group->cg_item.ci_dentry->d_fsdata);
+- spin_unlock(&configfs_dirent_lock);
+- }
++ if (ret)
++ goto err_out;
++
++ spin_lock(&configfs_dirent_lock);
++ configfs_dir_set_ready(group->cg_item.ci_dentry->d_fsdata);
++ spin_unlock(&configfs_dirent_lock);
++ inode_unlock(d_inode(parent));
++ return 0;
++err_out:
+ inode_unlock(d_inode(parent));
++ mutex_lock(&subsys->su_mutex);
++ unlink_group(group);
++ mutex_unlock(&subsys->su_mutex);
+ return ret;
+ }
+ EXPORT_SYMBOL(configfs_register_group);
+--
+2.20.1
+
--- /dev/null
+From 95b62ae2004cab12f3b0fdc71d58c66223b747b8 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Mon, 18 Mar 2019 18:39:30 +0300
+Subject: dmaengine: idma64: Use actual device for DMA transfers
+
+[ Upstream commit 5ba846b1ee0792f5a596b9b0b86d6e8cdebfab06 ]
+
+Intel IOMMU, when enabled, tries to find the domain of the device,
+assuming it's a PCI one, during DMA operations, such as mapping or
+unmapping. Since we are splitting the actual PCI device to couple of
+children via MFD framework (see drivers/mfd/intel-lpss.c for details),
+the DMA device appears to be a platform one, and thus not an actual one
+that performs DMA. In a such situation IOMMU can't find or allocate
+a proper domain for its operations. As a result, all DMA operations are
+failed.
+
+In order to fix this, supply parent of the platform device
+to the DMA engine framework and fix filter functions accordingly.
+
+We may rely on the fact that parent is a real PCI device, because no
+other configuration is present in the wild.
+
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Acked-by: Mark Brown <broonie@kernel.org>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts]
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/dma/idma64.c | 6 ++++--
+ drivers/dma/idma64.h | 2 ++
+ drivers/spi/spi-pxa2xx.c | 7 +------
+ drivers/tty/serial/8250/8250_dw.c | 4 ++--
+ 4 files changed, 9 insertions(+), 10 deletions(-)
+
+diff --git a/drivers/dma/idma64.c b/drivers/dma/idma64.c
+index 1fbf9cb9b742..89c5e5b46068 100644
+--- a/drivers/dma/idma64.c
++++ b/drivers/dma/idma64.c
+@@ -597,7 +597,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;
+
+ dma_set_max_seg_size(idma64->dma.dev, IDMA64C_CTLH_BLOCK_TS_MASK);
+
+@@ -637,6 +637,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;
+
+@@ -653,11 +654,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 6b816878e5e7..baa32e1425de 100644
+--- a/drivers/dma/idma64.h
++++ b/drivers/dma/idma64.h
+@@ -216,12 +216,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 729be74621e3..f41333817c50 100644
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -1416,12 +1416,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 d31b975dd3fd..284e8d052fc3 100644
+--- a/drivers/tty/serial/8250/8250_dw.c
++++ b/drivers/tty/serial/8250/8250_dw.c
+@@ -365,7 +365,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;
+ }
+
+ /*
+@@ -434,7 +434,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")) {
+ data->dma.rx_param = p->dev->parent;
+--
+2.20.1
+
--- /dev/null
+From 04c4c507a14999e1dba78cefe7255ea10e80e036 Mon Sep 17 00:00:00 2001
+From: Amit Kucheria <amit.kucheria@linaro.org>
+Date: Wed, 20 Mar 2019 18:47:52 +0530
+Subject: drivers: thermal: tsens: Don't print error message on -EPROBE_DEFER
+
+[ Upstream commit fc7d18cf6a923cde7f5e7ba2c1105bb106d3e29a ]
+
+We print a calibration failure message on -EPROBE_DEFER from
+nvmem/qfprom as follows:
+[ 3.003090] qcom-tsens 4a9000.thermal-sensor: version: 1.4
+[ 3.005376] qcom-tsens 4a9000.thermal-sensor: tsens calibration failed
+[ 3.113248] qcom-tsens 4a9000.thermal-sensor: version: 1.4
+
+This confuses people when, in fact, calibration succeeds later when
+nvmem/qfprom device is available. Don't print this message on a
+-EPROBE_DEFER.
+
+Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
+Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/thermal/qcom/tsens.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
+index a2c9bfae3d86..b139713289a4 100644
+--- a/drivers/thermal/qcom/tsens.c
++++ b/drivers/thermal/qcom/tsens.c
+@@ -171,7 +171,8 @@ static int tsens_probe(struct platform_device *pdev)
+ if (tmdev->ops->calibrate) {
+ ret = tmdev->ops->calibrate(tmdev);
+ if (ret < 0) {
+- dev_err(dev, "tsens calibration failed\n");
++ if (ret != -EPROBE_DEFER)
++ dev_err(dev, "tsens calibration failed\n");
+ return ret;
+ }
+ }
+--
+2.20.1
+
--- /dev/null
+From ee05823d6ced8878e7e91c5ca82c0f4eeb96aec6 Mon Sep 17 00:00:00 2001
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Date: Thu, 14 Mar 2019 13:46:44 -0400
+Subject: drm/amd/display: Use plane->color_space for dpp if specified
+
+[ Upstream commit a1e07ba89d49581471d64c48152dbe03b42bd025 ]
+
+[Why]
+The input color space for the plane was previously ignored even if it
+was set.
+
+If a limited range YUV format was given to DC then the
+wrong color transformation matrix was being used since DC assumed that
+it was full range instead.
+
+[How]
+Respect the given color_space format for the plane if it isn't
+COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM
+didn't specify.
+
+Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
+Acked-by: Aric Cyr <Aric.Cyr@amd.com>
+Acked-by: Leo Li <sunpeng.li@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c | 6 +++++-
+ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c
+index bf8b68f8db4f..bce5741f2952 100644
+--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c
+@@ -388,6 +388,10 @@ void dpp1_cnv_setup (
+ default:
+ break;
+ }
++
++ /* Set default color space based on format if none is given. */
++ color_space = input_color_space ? input_color_space : color_space;
++
+ REG_SET(CNVC_SURFACE_PIXEL_FORMAT, 0,
+ CNVC_SURFACE_PIXEL_FORMAT, pixel_format);
+ REG_UPDATE(FORMAT_CONTROL, FORMAT_CONTROL__ALPHA_EN, alpha_en);
+@@ -399,7 +403,7 @@ void dpp1_cnv_setup (
+ for (i = 0; i < 12; i++)
+ tbl_entry.regval[i] = input_csc_color_matrix.matrix[i];
+
+- tbl_entry.color_space = input_color_space;
++ tbl_entry.color_space = color_space;
+
+ if (color_space >= COLOR_SPACE_YCBCR601)
+ select = INPUT_CSC_SELECT_ICSC;
+diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+index a0355709abd1..7736ef123e9b 100644
+--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+@@ -1890,7 +1890,7 @@ static void update_dpp(struct dpp *dpp, struct dc_plane_state *plane_state)
+ plane_state->format,
+ EXPANSION_MODE_ZERO,
+ plane_state->input_csc_color_matrix,
+- COLOR_SPACE_YCBCR601_LIMITED);
++ plane_state->color_space);
+
+ //set scale and bias registers
+ build_prescale_params(&bns_params, plane_state);
+--
+2.20.1
+
--- /dev/null
+From b2b4d914f7b3b0eee7fd95a34a405811be8b2cd9 Mon Sep 17 00:00:00 2001
+From: Matt Redfearn <matt.redfearn@thinci.com>
+Date: Wed, 24 Apr 2019 13:22:27 +0000
+Subject: drm/bridge: adv7511: Fix low refresh rate selection
+
+[ Upstream commit 67793bd3b3948dc8c8384b6430e036a30a0ecb43 ]
+
+The driver currently sets register 0xfb (Low Refresh Rate) based on the
+value of mode->vrefresh. Firstly, this field is specified to be in Hz,
+but the magic numbers used by the code are Hz * 1000. This essentially
+leads to the low refresh rate always being set to 0x01, since the
+vrefresh value will always be less than 24000. Fix the magic numbers to
+be in Hz.
+Secondly, according to the comment in drm_modes.h, the field is not
+supposed to be used in a functional way anyway. Instead, use the helper
+function drm_mode_vrefresh().
+
+Fixes: 9c8af882bf12 ("drm: Add adv7511 encoder driver")
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Matt Redfearn <matt.redfearn@thinci.com>
+Signed-off-by: Sean Paul <seanpaul@chromium.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190424132210.26338-1-matt.redfearn@thinci.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+index 85c2d407a52e..e7ddd3e3db92 100644
+--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
++++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+@@ -747,11 +747,11 @@ static void adv7511_mode_set(struct adv7511 *adv7511,
+ vsync_polarity = 1;
+ }
+
+- if (mode->vrefresh <= 24000)
++ if (drm_mode_vrefresh(mode) <= 24)
+ low_refresh_rate = ADV7511_LOW_REFRESH_RATE_24HZ;
+- else if (mode->vrefresh <= 25000)
++ else if (drm_mode_vrefresh(mode) <= 25)
+ low_refresh_rate = ADV7511_LOW_REFRESH_RATE_25HZ;
+- else if (mode->vrefresh <= 30000)
++ else if (drm_mode_vrefresh(mode) <= 30)
+ low_refresh_rate = ADV7511_LOW_REFRESH_RATE_30HZ;
+ else
+ low_refresh_rate = ADV7511_LOW_REFRESH_RATE_NONE;
+--
+2.20.1
+
--- /dev/null
+From 091b7fee43d441e0daadcca0d25eca50956434b3 Mon Sep 17 00:00:00 2001
+From: Ben Skeggs <bskeggs@redhat.com>
+Date: Fri, 10 May 2019 11:57:04 +1000
+Subject: drm/nouveau/disp/dp: respect sink limits when selecting failsafe link
+ configuration
+
+[ Upstream commit 13d03e9daf70dab032c03dc172e75bb98ad899c4 ]
+
+Where possible, we want the failsafe link configuration (one which won't
+hang the OR during modeset because of not enough bandwidth for the mode)
+to also be supported by the sink.
+
+This prevents "link rate unsupported by sink" messages when link training
+fails.
+
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
+index 5f301e632599..818d21bd28d3 100644
+--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
++++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
+@@ -365,8 +365,15 @@ nvkm_dp_train(struct nvkm_dp *dp, u32 dataKBps)
+ * and it's better to have a failed modeset than that.
+ */
+ for (cfg = nvkm_dp_rates; cfg->rate; cfg++) {
+- if (cfg->nr <= outp_nr && cfg->nr <= outp_bw)
+- failsafe = cfg;
++ if (cfg->nr <= outp_nr && cfg->nr <= outp_bw) {
++ /* Try to respect sink limits too when selecting
++ * lowest link configuration.
++ */
++ if (!failsafe ||
++ (cfg->nr <= sink_nr && cfg->bw <= sink_bw))
++ failsafe = cfg;
++ }
++
+ if (failsafe && cfg[1].rate < dataKBps)
+ break;
+ }
+--
+2.20.1
+
--- /dev/null
+From b85e7940ce76fc47888bc63c5582c2cd05cb05f3 Mon Sep 17 00:00:00 2001
+From: Ben Skeggs <bskeggs@redhat.com>
+Date: Wed, 8 May 2019 14:54:34 +1000
+Subject: drm/nouveau/kms/gf119-gp10x: push HeadSetControlOutputResource() mthd
+ when encoders change
+
+[ Upstream commit a0b694d0af21c9993d1a39a75fd814bd48bf7eb4 ]
+
+HW has error checks in place which check that pixel depth is explicitly
+provided on DP, while HDMI has a "default" setting that we use.
+
+In multi-display configurations with identical modelines, but different
+protocols (HDMI + DP, in this case), it was possible for the DP head to
+get swapped to the head which previously drove the HDMI output, without
+updating HeadSetControlOutputResource(), triggering the error check and
+hanging the core update.
+
+Reported-by: Lyude Paul <lyude@redhat.com>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/nouveau/dispnv50/head.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c b/drivers/gpu/drm/nouveau/dispnv50/head.c
+index 4f57e5379796..d81a99bb2ac3 100644
+--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
++++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
+@@ -306,7 +306,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state)
+ asyh->set.or = head->func->or != NULL;
+ }
+
+- if (asyh->state.mode_changed)
++ if (asyh->state.mode_changed || asyh->state.connectors_changed)
+ nv50_head_atomic_check_mode(head, asyh);
+
+ if (asyh->state.color_mgmt_changed ||
+--
+2.20.1
+
--- /dev/null
+From da14d6c81685a58a9000790847f8a154f5f81313 Mon Sep 17 00:00:00 2001
+From: Ben Skeggs <bskeggs@redhat.com>
+Date: Fri, 3 May 2019 12:23:55 +1000
+Subject: drm/nouveau/kms/gv100-: fix spurious window immediate interlocks
+
+[ Upstream commit d2434e4d942c32cadcbdbcd32c58f35098f3b604 ]
+
+Cursor position updates were accidentally causing us to attempt to interlock
+window with window immediate, and without a matching window immediate update,
+NVDisplay could hang forever in some circumstances.
+
+Fixes suspend/resume on (at least) Quadro RTX4000 (TU104).
+
+Reported-by: Lyude Paul <lyude@redhat.com>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 +
+ drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 1 +
+ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
+ 3 files changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h b/drivers/gpu/drm/nouveau/dispnv50/disp.h
+index e48c5eb35b49..66c125a6b0b3 100644
+--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
++++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
+@@ -41,6 +41,7 @@ struct nv50_disp_interlock {
+ NV50_DISP_INTERLOCK__SIZE
+ } type;
+ u32 data;
++ u32 wimm;
+ };
+
+ void corec37d_ntfy_init(struct nouveau_bo *, u32);
+diff --git a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
+index 9103b8494279..f7dbd965e4e7 100644
+--- a/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
++++ b/drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c
+@@ -75,6 +75,7 @@ wimmc37b_init_(const struct nv50_wimm_func *func, struct nouveau_drm *drm,
+ return ret;
+ }
+
++ wndw->interlock.wimm = wndw->interlock.data;
+ wndw->immd = func;
+ return 0;
+ }
+diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+index 2187922e8dc2..b3db4553098d 100644
+--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
++++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+@@ -151,7 +151,7 @@ nv50_wndw_flush_set(struct nv50_wndw *wndw, u32 *interlock,
+ if (asyw->set.point) {
+ if (asyw->set.point = false, asyw->set.mask)
+ interlock[wndw->interlock.type] |= wndw->interlock.data;
+- interlock[NV50_DISP_INTERLOCK_WIMM] |= wndw->interlock.data;
++ interlock[NV50_DISP_INTERLOCK_WIMM] |= wndw->interlock.wimm;
+
+ wndw->immd->point(wndw, asyw);
+ wndw->immd->update(wndw, interlock);
+--
+2.20.1
+
--- /dev/null
+From ae5788f0fcdb418b4cfe2528954e50b783d3620b Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Mon, 13 May 2019 07:46:21 -0700
+Subject: drm/pl111: Initialize clock spinlock early
+
+[ Upstream commit 3e01ae2612bdd7975c74ec7123d7f8f5e6eed795 ]
+
+The following warning is seen on systems with broken clock divider.
+
+INFO: trying to register non-static key.
+the code is fine but needs lockdep annotation.
+turning off the locking correctness validator.
+CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-09698-g1fb3b52 #1
+Hardware name: ARM Integrator/CP (Device Tree)
+[<c0011be8>] (unwind_backtrace) from [<c000ebb8>] (show_stack+0x10/0x18)
+[<c000ebb8>] (show_stack) from [<c07d3fd0>] (dump_stack+0x18/0x24)
+[<c07d3fd0>] (dump_stack) from [<c0060d48>] (register_lock_class+0x674/0x6f8)
+[<c0060d48>] (register_lock_class) from [<c005de2c>]
+ (__lock_acquire+0x68/0x2128)
+[<c005de2c>] (__lock_acquire) from [<c0060408>] (lock_acquire+0x110/0x21c)
+[<c0060408>] (lock_acquire) from [<c07f755c>] (_raw_spin_lock+0x34/0x48)
+[<c07f755c>] (_raw_spin_lock) from [<c0536c8c>]
+ (pl111_display_enable+0xf8/0x5fc)
+[<c0536c8c>] (pl111_display_enable) from [<c0502f54>]
+ (drm_atomic_helper_commit_modeset_enables+0x1ec/0x244)
+
+Since commit eedd6033b4c8 ("drm/pl111: Support variants with broken clock
+divider"), the spinlock is not initialized if the clock divider is broken.
+Initialize it earlier to fix the problem.
+
+Fixes: eedd6033b4c8 ("drm/pl111: Support variants with broken clock divider")
+Cc: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/1557758781-23586-1-git-send-email-linux@roeck-us.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/pl111/pl111_display.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
+index 754f6b25f265..6d9f78612dee 100644
+--- a/drivers/gpu/drm/pl111/pl111_display.c
++++ b/drivers/gpu/drm/pl111/pl111_display.c
+@@ -531,14 +531,15 @@ pl111_init_clock_divider(struct drm_device *drm)
+ dev_err(drm->dev, "CLCD: unable to get clcdclk.\n");
+ return PTR_ERR(parent);
+ }
++
++ spin_lock_init(&priv->tim2_lock);
++
+ /* If the clock divider is broken, use the parent directly */
+ if (priv->variant->broken_clockdivider) {
+ priv->clk = parent;
+ return 0;
+ }
+ parent_name = __clk_get_name(parent);
+-
+- spin_lock_init(&priv->tim2_lock);
+ div->init = &init;
+
+ ret = devm_clk_hw_register(drm->dev, div);
+--
+2.20.1
+
--- /dev/null
+From 288bd0c129e4a875ec4dde56b694261f76ebf5c6 Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Fri, 3 May 2019 00:19:41 +1000
+Subject: EDAC/mpc85xx: Prevent building as a module
+
+[ Upstream commit 2b8358a951b1e2a534a54924cd8245e58a1c5fb8 ]
+
+The mpc85xx EDAC driver can be configured as a module but then fails to
+build because it uses two unexported symbols:
+
+ ERROR: ".pci_find_hose_for_OF_device" [drivers/edac/mpc85xx_edac_mod.ko] undefined!
+ ERROR: ".early_find_capability" [drivers/edac/mpc85xx_edac_mod.ko] undefined!
+
+We don't want to export those symbols just for this driver, so make the
+driver only configurable as a built-in.
+
+This seems to have been broken since at least
+
+ c92132f59806 ("edac/85xx: Add PCIe error interrupt edac support")
+
+(Nov 2013).
+
+ [ bp: make it depend on EDAC=y so that the EDAC core doesn't get built
+ as a module. ]
+
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Johannes Thumshirn <jth@kernel.org>
+Cc: James Morse <james.morse@arm.com>
+Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
+Cc: linux-edac <linux-edac@vger.kernel.org>
+Cc: linuxppc-dev@ozlabs.org
+Cc: morbidrsa@gmail.com
+Link: https://lkml.kernel.org/r/20190502141941.12927-1-mpe@ellerman.id.au
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/edac/Kconfig | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
+index 57304b2e989f..b00cc03ad6b6 100644
+--- a/drivers/edac/Kconfig
++++ b/drivers/edac/Kconfig
+@@ -250,8 +250,8 @@ config EDAC_PND2
+ micro-server but may appear on others in the future.
+
+ config EDAC_MPC85XX
+- tristate "Freescale MPC83xx / MPC85xx"
+- depends on FSL_SOC
++ bool "Freescale MPC83xx / MPC85xx"
++ depends on FSL_SOC && EDAC=y
+ help
+ Support for error detection and correction on the Freescale
+ MPC8349, MPC8560, MPC8540, MPC8548, T4240
+--
+2.20.1
+
--- /dev/null
+From 4cd3dcac8a5ed0de17b003d84a0d8d73adfc2f87 Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:28:30 +0800
+Subject: f2fs: fix to avoid panic in dec_valid_block_count()
+
+[ Upstream commit 5e159cd349bf3a31fb7e35c23a93308eb30f4f71 ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203209
+
+- Overview
+When mounting the attached crafted image and running program, I got this error.
+Additionally, it hangs on sync after the this script.
+
+The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
+
+- Reproduces
+cc poc_01.c
+./run.sh f2fs
+sync
+
+ kernel BUG at fs/f2fs/f2fs.h:1788!
+ RIP: 0010:f2fs_truncate_data_blocks_range+0x342/0x350
+ Call Trace:
+ f2fs_truncate_blocks+0x36d/0x3c0
+ f2fs_truncate+0x88/0x110
+ f2fs_setattr+0x3e1/0x460
+ notify_change+0x2da/0x400
+ do_truncate+0x6d/0xb0
+ do_sys_ftruncate+0xf1/0x160
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+The reason is dec_valid_block_count() will trigger kernel panic due to
+inconsistent count in between inode.i_blocks and actual block.
+
+To avoid panic, let's just print debug message and set SBI_NEED_FSCK to
+give a hint to fsck for latter repairing.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+[Jaegeuk Kim: fix build warning and add unlikely]
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/f2fs.h | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
+index a4b6eacf22ea..64f970cca1b4 100644
+--- a/fs/f2fs/f2fs.h
++++ b/fs/f2fs/f2fs.h
+@@ -1744,6 +1744,7 @@ enospc:
+ return -ENOSPC;
+ }
+
++void f2fs_msg(struct super_block *sb, const char *level, const char *fmt, ...);
+ static inline void dec_valid_block_count(struct f2fs_sb_info *sbi,
+ struct inode *inode,
+ block_t count)
+@@ -1752,13 +1753,21 @@ static inline void dec_valid_block_count(struct f2fs_sb_info *sbi,
+
+ spin_lock(&sbi->stat_lock);
+ f2fs_bug_on(sbi, sbi->total_valid_block_count < (block_t) count);
+- f2fs_bug_on(sbi, inode->i_blocks < sectors);
+ sbi->total_valid_block_count -= (block_t)count;
+ if (sbi->reserved_blocks &&
+ sbi->current_reserved_blocks < sbi->reserved_blocks)
+ sbi->current_reserved_blocks = min(sbi->reserved_blocks,
+ sbi->current_reserved_blocks + count);
+ spin_unlock(&sbi->stat_lock);
++ if (unlikely(inode->i_blocks < sectors)) {
++ f2fs_msg(sbi->sb, KERN_WARNING,
++ "Inconsistent i_blocks, ino:%lu, iblocks:%llu, sectors:%llu",
++ inode->i_ino,
++ (unsigned long long)inode->i_blocks,
++ (unsigned long long)sectors);
++ set_sbi_flag(sbi, SBI_NEED_FSCK);
++ return;
++ }
+ f2fs_i_blocks_write(inode, count, false, true);
+ }
+
+@@ -2727,7 +2736,6 @@ static inline void f2fs_update_iostat(struct f2fs_sb_info *sbi,
+
+ bool f2fs_is_valid_blkaddr(struct f2fs_sb_info *sbi,
+ block_t blkaddr, int type);
+-void f2fs_msg(struct super_block *sb, const char *level, const char *fmt, ...);
+ static inline void verify_blkaddr(struct f2fs_sb_info *sbi,
+ block_t blkaddr, int type)
+ {
+--
+2.20.1
+
--- /dev/null
+From 80c06ce87f12aad4a437fd0fbccc9521cb4b5592 Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:28:37 +0800
+Subject: f2fs: fix to avoid panic in do_recover_data()
+
+[ Upstream commit 22d61e286e2d9097dae36f75ed48801056b77cac ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203227
+
+- Overview
+When mounting the attached crafted image, following errors are reported.
+Additionally, it hangs on sync after trying to mount it.
+
+The image is intentionally fuzzed from a normal f2fs image for testing.
+Compile options for F2FS are as follows.
+CONFIG_F2FS_FS=y
+CONFIG_F2FS_STAT_FS=y
+CONFIG_F2FS_FS_XATTR=y
+CONFIG_F2FS_FS_POSIX_ACL=y
+CONFIG_F2FS_CHECK_FS=y
+
+- Reproduces
+mkdir test
+mount -t f2fs tmp.img test
+sync
+
+- Messages
+ kernel BUG at fs/f2fs/recovery.c:549!
+ RIP: 0010:recover_data+0x167a/0x1780
+ Call Trace:
+ f2fs_recover_fsync_data+0x613/0x710
+ f2fs_fill_super+0x1043/0x1aa0
+ mount_bdev+0x16d/0x1a0
+ mount_fs+0x4a/0x170
+ vfs_kern_mount+0x5d/0x100
+ do_mount+0x200/0xcf0
+ ksys_mount+0x79/0xc0
+ __x64_sys_mount+0x1c/0x20
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+During recovery, if ofs_of_node is inconsistent in between recovered
+node page and original checkpointed node page, let's just fail recovery
+instead of making kernel panic.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/recovery.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
+index ae0e5f2e67b4..bf5c5f4fa77e 100644
+--- a/fs/f2fs/recovery.c
++++ b/fs/f2fs/recovery.c
+@@ -485,7 +485,15 @@ retry_dn:
+ goto err;
+
+ f2fs_bug_on(sbi, ni.ino != ino_of_node(page));
+- f2fs_bug_on(sbi, ofs_of_node(dn.node_page) != ofs_of_node(page));
++
++ if (ofs_of_node(dn.node_page) != ofs_of_node(page)) {
++ f2fs_msg(sbi->sb, KERN_WARNING,
++ "Inconsistent ofs_of_node, ino:%lu, ofs:%u, %u",
++ inode->i_ino, ofs_of_node(dn.node_page),
++ ofs_of_node(page));
++ err = -EFAULT;
++ goto err;
++ }
+
+ for (; start < end; start++, dn.ofs_in_node++) {
+ block_t src, dest;
+--
+2.20.1
+
--- /dev/null
+From 93ab4f1ac925435b36cd9c3f653efca61e517da0 Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:30:52 +0800
+Subject: f2fs: fix to avoid panic in f2fs_inplace_write_data()
+
+[ Upstream commit 05573d6ccf702df549a7bdeabef31e4753df1a90 ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203239
+
+- 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_15.c
+./run.sh f2fs
+sync
+
+- Kernel messages
+ ------------[ cut here ]------------
+ kernel BUG at fs/f2fs/segment.c:3162!
+ RIP: 0010:f2fs_inplace_write_data+0x12d/0x160
+ Call Trace:
+ f2fs_do_write_data_page+0x3c1/0x820
+ __write_data_page+0x156/0x720
+ f2fs_write_cache_pages+0x20d/0x460
+ f2fs_write_data_pages+0x1b4/0x300
+ do_writepages+0x15/0x60
+ __filemap_fdatawrite_range+0x7c/0xb0
+ file_write_and_wait_range+0x2c/0x80
+ f2fs_do_sync_file+0x102/0x810
+ do_fsync+0x33/0x60
+ __x64_sys_fsync+0xb/0x10
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+The reason is f2fs_inplace_write_data() will trigger kernel panic due
+to data block locates in node type segment.
+
+To avoid panic, let's just return error code and set SBI_NEED_FSCK to
+give a hint to fsck for latter repairing.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/segment.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
+index 03fa2c4d3d79..8fc3edb6760c 100644
+--- a/fs/f2fs/segment.c
++++ b/fs/f2fs/segment.c
+@@ -3069,13 +3069,18 @@ int f2fs_inplace_write_data(struct f2fs_io_info *fio)
+ {
+ int err;
+ struct f2fs_sb_info *sbi = fio->sbi;
++ unsigned int segno;
+
+ fio->new_blkaddr = fio->old_blkaddr;
+ /* i/o temperature is needed for passing down write hints */
+ __get_segment_type(fio);
+
+- f2fs_bug_on(sbi, !IS_DATASEG(get_seg_entry(sbi,
+- GET_SEGNO(sbi, fio->new_blkaddr))->type));
++ segno = GET_SEGNO(sbi, fio->new_blkaddr);
++
++ if (!IS_DATASEG(get_seg_entry(sbi, segno)->type)) {
++ set_sbi_flag(sbi, SBI_NEED_FSCK);
++ return -EFAULT;
++ }
+
+ stat_inc_inplace_blocks(fio->sbi);
+
+--
+2.20.1
+
--- /dev/null
+From ffcd55ace4fbcadc6781160828c066432ead4156 Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:28:34 +0800
+Subject: f2fs: fix to avoid panic in f2fs_remove_inode_page()
+
+[ Upstream commit 8b6810f8acfe429fde7c7dad4714692cc5f75651 ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203219
+
+- Overview
+When mounting the attached crafted image and running program, I got this error.
+Additionally, it hangs on sync after running the program.
+
+The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
+
+- Reproduces
+cc poc_06.c
+mkdir test
+mount -t f2fs tmp.img test
+cp a.out test
+cd test
+sudo ./a.out
+sync
+
+- Messages
+ kernel BUG at fs/f2fs/node.c:1183!
+ RIP: 0010:f2fs_remove_inode_page+0x294/0x2d0
+ Call Trace:
+ f2fs_evict_inode+0x2a3/0x3a0
+ evict+0xba/0x180
+ __dentry_kill+0xbe/0x160
+ dentry_kill+0x46/0x180
+ dput+0xbb/0x100
+ do_renameat2+0x3c9/0x550
+ __x64_sys_rename+0x17/0x20
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+The reason is f2fs_remove_inode_page() will trigger kernel panic due to
+inconsistent i_blocks value of inode.
+
+To avoid panic, let's just print debug message and set SBI_NEED_FSCK to
+give a hint to fsck for latter repairing of potential image corruption.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+[Jaegeuk Kim: fix build warning and add unlikely]
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/node.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
+index 19a0d83aae65..807a77518a49 100644
+--- a/fs/f2fs/node.c
++++ b/fs/f2fs/node.c
+@@ -1180,8 +1180,14 @@ int f2fs_remove_inode_page(struct inode *inode)
+ f2fs_put_dnode(&dn);
+ return -EIO;
+ }
+- f2fs_bug_on(F2FS_I_SB(inode),
+- inode->i_blocks != 0 && inode->i_blocks != 8);
++
++ if (unlikely(inode->i_blocks != 0 && inode->i_blocks != 8)) {
++ f2fs_msg(F2FS_I_SB(inode)->sb, KERN_WARNING,
++ "Inconsistent i_blocks, ino:%lu, iblocks:%llu",
++ inode->i_ino,
++ (unsigned long long)inode->i_blocks);
++ set_sbi_flag(F2FS_I_SB(inode), SBI_NEED_FSCK);
++ }
+
+ /* will put inode & node pages */
+ err = truncate_node(&dn);
+--
+2.20.1
+
--- /dev/null
+From 407f50197c6ac5d5943d549ce439aef0ad5caac8 Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:28:33 +0800
+Subject: f2fs: fix to clear dirty inode in error path of f2fs_iget()
+
+[ Upstream commit 546d22f070d64a7b96f57c93333772085d3a5e6d ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203217
+
+- Overview
+When mounting the attached crafted image and running program, I got this error.
+Additionally, it hangs on sync after running the program.
+
+The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
+
+- Reproduces
+cc poc_test_05.c
+mkdir test
+mount -t f2fs tmp.img test
+sudo ./a.out
+sync
+
+- Messages
+ kernel BUG at fs/f2fs/inode.c:707!
+ RIP: 0010:f2fs_evict_inode+0x33f/0x3a0
+ Call Trace:
+ evict+0xba/0x180
+ f2fs_iget+0x598/0xdf0
+ f2fs_lookup+0x136/0x320
+ __lookup_slow+0x92/0x140
+ lookup_slow+0x30/0x50
+ walk_component+0x1c1/0x350
+ path_lookupat+0x62/0x200
+ filename_lookup+0xb3/0x1a0
+ do_readlinkat+0x56/0x110
+ __x64_sys_readlink+0x16/0x20
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+During inode loading, __recover_inline_status() can recovery inode status
+and set inode dirty, once we failed in following process, it will fail
+the check in f2fs_evict_inode, result in trigger BUG_ON().
+
+Let's clear dirty inode in error path of f2fs_iget() to avoid panic.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/inode.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
+index dd608b819a3c..fae9570e6860 100644
+--- a/fs/f2fs/inode.c
++++ b/fs/f2fs/inode.c
+@@ -476,6 +476,7 @@ make_now:
+ return inode;
+
+ bad_inode:
++ f2fs_inode_synced(inode);
+ iget_failed(inode);
+ trace_f2fs_iget_exit(inode, ret);
+ return ERR_PTR(ret);
+--
+2.20.1
+
--- /dev/null
+From eedd336d32ec9fda7f26d7883ade55484965b3cc Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:28:35 +0800
+Subject: f2fs: fix to do checksum even if inode page is uptodate
+
+[ Upstream commit b42b179bda9ff11075a6fc2bac4d9e400513679a ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203221
+
+- Overview
+When mounting the attached crafted image and running program, this error is reported.
+
+The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
+
+- Reproduces
+cc poc_07.c
+mkdir test
+mount -t f2fs tmp.img test
+cp a.out test
+cd test
+sudo ./a.out
+
+- Messages
+ kernel BUG at fs/f2fs/node.c:1279!
+ RIP: 0010:read_node_page+0xcf/0xf0
+ Call Trace:
+ __get_node_page+0x6b/0x2f0
+ f2fs_iget+0x8f/0xdf0
+ f2fs_lookup+0x136/0x320
+ __lookup_slow+0x92/0x140
+ lookup_slow+0x30/0x50
+ walk_component+0x1c1/0x350
+ path_lookupat+0x62/0x200
+ filename_lookup+0xb3/0x1a0
+ do_fchmodat+0x3e/0xa0
+ __x64_sys_chmod+0x12/0x20
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+On below paths, we can have opportunity to readahead inode page
+- gc_node_segment -> f2fs_ra_node_page
+- gc_data_segment -> f2fs_ra_node_page
+- f2fs_fill_dentries -> f2fs_ra_node_page
+
+Unlike synchronized read, on readahead path, we can set page uptodate
+before verifying page's checksum, then read_node_page() will trigger
+kernel panic once it encounters a uptodated page w/ incorrect checksum.
+
+So considering readahead scenario, we have to do checksum each time
+when loading inode page even if it is uptodated.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/inode.c | 4 ++--
+ fs/f2fs/node.c | 7 ++++---
+ 2 files changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
+index fae9570e6860..0f31df01e36c 100644
+--- a/fs/f2fs/inode.c
++++ b/fs/f2fs/inode.c
+@@ -179,8 +179,8 @@ bool f2fs_inode_chksum_verify(struct f2fs_sb_info *sbi, struct page *page)
+
+ if (provided != calculated)
+ f2fs_msg(sbi->sb, KERN_WARNING,
+- "checksum invalid, ino = %x, %x vs. %x",
+- ino_of_node(page), provided, calculated);
++ "checksum invalid, nid = %lu, ino_of_node = %x, %x vs. %x",
++ page->index, ino_of_node(page), provided, calculated);
+
+ return provided == calculated;
+ }
+diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
+index 34c3f732601c..e2d9edad758c 100644
+--- a/fs/f2fs/node.c
++++ b/fs/f2fs/node.c
+@@ -1282,9 +1282,10 @@ static int read_node_page(struct page *page, int op_flags)
+ int err;
+
+ if (PageUptodate(page)) {
+-#ifdef CONFIG_F2FS_CHECK_FS
+- f2fs_bug_on(sbi, !f2fs_inode_chksum_verify(sbi, page));
+-#endif
++ if (!f2fs_inode_chksum_verify(sbi, page)) {
++ ClearPageUptodate(page);
++ return -EBADMSG;
++ }
+ return LOCKED_PAGE;
+ }
+
+--
+2.20.1
+
--- /dev/null
+From bac313e6b450a98b85dfb9a276268cb996e482ce Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:28:36 +0800
+Subject: f2fs: fix to do sanity check on free nid
+
+[ Upstream commit 626bcf2b7ce87211dba565f2bfa7842ba5be5c1b ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203225
+
+- Overview
+When mounting the attached crafted image and unmounting it, following errors are reported.
+Additionally, it hangs on sync after unmounting.
+
+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
+touch test/t
+umount test
+sync
+
+- Messages
+ kernel BUG at fs/f2fs/node.c:3073!
+ RIP: 0010:f2fs_destroy_node_manager+0x2f0/0x300
+ Call Trace:
+ f2fs_put_super+0xf4/0x270
+ generic_shutdown_super+0x62/0x110
+ kill_block_super+0x1c/0x50
+ kill_f2fs_super+0xad/0xd0
+ deactivate_locked_super+0x35/0x60
+ cleanup_mnt+0x36/0x70
+ task_work_run+0x75/0x90
+ exit_to_usermode_loop+0x93/0xa0
+ do_syscall_64+0xba/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ RIP: 0010:f2fs_destroy_node_manager+0x2f0/0x300
+
+NAT table is corrupted, so reserved meta/node inode ids were added into
+free list incorrectly, during file creation, since reserved id has cached
+in inode hash, so it fails the creation and preallocated nid can not be
+released later, result in kernel panic.
+
+To fix this issue, let's do nid boundary check during free nid loading.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/node.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
+index 807a77518a49..34c3f732601c 100644
+--- a/fs/f2fs/node.c
++++ b/fs/f2fs/node.c
+@@ -2079,6 +2079,9 @@ static bool add_free_nid(struct f2fs_sb_info *sbi,
+ if (unlikely(nid == 0))
+ return false;
+
++ if (unlikely(f2fs_check_nid_range(sbi, nid)))
++ return false;
++
+ i = f2fs_kmem_cache_alloc(free_nid_slab, GFP_NOFS);
+ i->nid = nid;
+ i->state = FREE_NID;
+--
+2.20.1
+
--- /dev/null
+From 47bf6c85fe651f53bdd90d6b352b03e708c7c536 Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Mon, 15 Apr 2019 15:30:51 +0800
+Subject: f2fs: fix to do sanity check on valid block count of segment
+
+[ Upstream commit e95bcdb2fefa129f37bd9035af1d234ca92ee4ef ]
+
+As Jungyeon reported in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=203233
+
+- Overview
+When mounting the attached crafted image and running program, following errors are reported.
+Additionally, it hangs on sync after running program.
+
+The image is intentionally fuzzed from a normal f2fs image for testing.
+Compile options for F2FS are as follows.
+CONFIG_F2FS_FS=y
+CONFIG_F2FS_STAT_FS=y
+CONFIG_F2FS_FS_XATTR=y
+CONFIG_F2FS_FS_POSIX_ACL=y
+CONFIG_F2FS_CHECK_FS=y
+
+- Reproduces
+cc poc_13.c
+mkdir test
+mount -t f2fs tmp.img test
+cp a.out test
+cd test
+sudo ./a.out
+sync
+
+- Kernel messages
+ F2FS-fs (sdb): Bitmap was wrongly set, blk:4608
+ kernel BUG at fs/f2fs/segment.c:2102!
+ RIP: 0010:update_sit_entry+0x394/0x410
+ Call Trace:
+ f2fs_allocate_data_block+0x16f/0x660
+ do_write_page+0x62/0x170
+ f2fs_do_write_node_page+0x33/0xa0
+ __write_node_page+0x270/0x4e0
+ f2fs_sync_node_pages+0x5df/0x670
+ f2fs_write_checkpoint+0x372/0x1400
+ f2fs_sync_fs+0xa3/0x130
+ f2fs_do_sync_file+0x1a6/0x810
+ do_fsync+0x33/0x60
+ __x64_sys_fsync+0xb/0x10
+ do_syscall_64+0x43/0xf0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+sit.vblocks and sum valid block count in sit.valid_map may be
+inconsistent, segment w/ zero vblocks will be treated as free
+segment, while allocating in free segment, we may allocate a
+free block, if its bitmap is valid previously, it can cause
+kernel crash due to bitmap verification failure.
+
+Anyway, to avoid further serious metadata inconsistence and
+corruption, it is necessary and worth to detect SIT
+inconsistence. So let's enable check_block_count() to verify
+vblocks and valid_map all the time rather than do it only
+CONFIG_F2FS_CHECK_FS is enabled.
+
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/segment.h | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
+index b3d9e317ff0c..5079532cb176 100644
+--- a/fs/f2fs/segment.h
++++ b/fs/f2fs/segment.h
+@@ -660,7 +660,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;
+@@ -687,7 +686,7 @@ static inline int check_block_count(struct f2fs_sb_info *sbi,
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
+ return -EINVAL;
+ }
+-#endif
++
+ /* check segment usage, and check boundary of a given segment number */
+ if (unlikely(GET_SIT_VBLOCKS(raw_sit) > sbi->blocks_per_seg
+ || segno > TOTAL_SEGS(sbi) - 1)) {
+--
+2.20.1
+
--- /dev/null
+From a50b1f50e2a6d1223ea7e68af2c76c6da09c415f Mon Sep 17 00:00:00 2001
+From: Chao Yu <yuchao0@huawei.com>
+Date: Thu, 11 Apr 2019 11:48:10 +0800
+Subject: f2fs: fix to use inline space only if inline_xattr is enable
+
+[ Upstream commit 622927f3b8809206f6da54a6a7ed4df1a7770fce ]
+
+With below mkfs and mount option:
+
+MKFS_OPTIONS -- -O extra_attr -O project_quota -O inode_checksum -O flexible_inline_xattr -O inode_crtime -f
+MOUNT_OPTIONS -- -o noinline_xattr
+
+We may miss xattr data with below testcase:
+- mkdir dir
+- setfattr -n "user.name" -v 0 dir
+- for ((i = 0; i < 190; i++)) do touch dir/$i; done
+- umount
+- mount
+- getfattr -n "user.name" dir
+
+user.name: No such attribute
+
+The root cause is that we persist xattr data into reserved inline xattr
+space, even if inline_xattr is not enable in inline directory inode, after
+inline dentry conversion, reserved space no longer exists, so that xattr
+data missed.
+
+Let's use inline xattr space only if inline_xattr flag is set on inode
+to fix this iusse.
+
+Fixes: 6afc662e68b5 ("f2fs: support flexible inline xattr size")
+Signed-off-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/f2fs.h | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
+index 64f970cca1b4..44ea7ac69ef4 100644
+--- a/fs/f2fs/f2fs.h
++++ b/fs/f2fs/f2fs.h
+@@ -2497,7 +2497,9 @@ static inline void *inline_xattr_addr(struct inode *inode, struct page *page)
+
+ static inline int inline_xattr_size(struct inode *inode)
+ {
+- return get_inline_xattr_addrs(inode) * sizeof(__le32);
++ if (f2fs_has_inline_xattr(inode))
++ return get_inline_xattr_addrs(inode) * sizeof(__le32);
++ return 0;
+ }
+
+ static inline int f2fs_has_inline_data(struct inode *inode)
+--
+2.20.1
+
--- /dev/null
+From 78bbcc38db4efba1f64fbf8351bec5583c1132e1 Mon Sep 17 00:00:00 2001
+From: Hou Tao <houtao1@huawei.com>
+Date: Tue, 14 May 2019 15:44:32 -0700
+Subject: fs/fat/file.c: issue flush after the writeback of FAT
+
+[ Upstream commit bd8309de0d60838eef6fb575b0c4c7e95841cf73 ]
+
+fsync() needs to make sure the data & meta-data of file are persistent
+after the return of fsync(), even when a power-failure occurs later. In
+the case of fat-fs, the FAT belongs to the meta-data of file, so we need
+to issue a flush after the writeback of FAT instead before.
+
+Also bail out early when any stage of fsync fails.
+
+Link: http://lkml.kernel.org/r/20190409030158.136316-1-houtao1@huawei.com
+Signed-off-by: Hou Tao <houtao1@huawei.com>
+Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Jan Kara <jack@suse.cz>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/fat/file.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/fs/fat/file.c b/fs/fat/file.c
+index 4f3d72fb1e60..f86ea08bd6ce 100644
+--- a/fs/fat/file.c
++++ b/fs/fat/file.c
+@@ -193,12 +193,17 @@ static int fat_file_release(struct inode *inode, struct file *filp)
+ int fat_file_fsync(struct file *filp, loff_t start, loff_t end, int datasync)
+ {
+ struct inode *inode = filp->f_mapping->host;
+- int res, err;
++ int err;
++
++ err = __generic_file_fsync(filp, start, end, datasync);
++ if (err)
++ return err;
+
+- res = generic_file_fsync(filp, start, end, datasync);
+ err = sync_mapping_buffers(MSDOS_SB(inode->i_sb)->fat_inode->i_mapping);
++ if (err)
++ return err;
+
+- return res ? res : err;
++ return blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
+ }
+
+
+--
+2.20.1
+
--- /dev/null
+From ff654ec868b1d1933c45ddf69a513325d6a22137 Mon Sep 17 00:00:00 2001
+From: Kirill Smelkov <kirr@nexedi.com>
+Date: Wed, 27 Mar 2019 10:15:15 +0000
+Subject: fuse: require /dev/fuse reads to have enough buffer capacity
+
+[ Upstream commit d4b13963f217dd947da5c0cabd1569e914d21699 ]
+
+A FUSE filesystem server queues /dev/fuse sys_read calls to get
+filesystem requests to handle. It does not know in advance what would be
+that request as it can be anything that client issues - LOOKUP, READ,
+WRITE, ... Many requests are short and retrieve data from the
+filesystem. However WRITE and NOTIFY_REPLY write data into filesystem.
+
+Before getting into operation phase, FUSE filesystem server and kernel
+client negotiate what should be the maximum write size the client will
+ever issue. After negotiation the contract in between server/client is
+that the filesystem server then should queue /dev/fuse sys_read calls with
+enough buffer capacity to receive any client request - WRITE in
+particular, while FUSE client should not, in particular, send WRITE
+requests with > negotiated max_write payload. FUSE client in kernel and
+libfuse historically reserve 4K for request header. This way the
+contract is that filesystem server should queue sys_reads with
+4K+max_write buffer.
+
+If the filesystem server does not follow this contract, what can happen
+is that fuse_dev_do_read will see that request size is > buffer size,
+and then it will return EIO to client who issued the request but won't
+indicate in any way that there is a problem to filesystem server.
+This can be hard to diagnose because for some requests, e.g. for
+NOTIFY_REPLY which mimics WRITE, there is no client thread that is
+waiting for request completion and that EIO goes nowhere, while on
+filesystem server side things look like the kernel is not replying back
+after successful NOTIFY_RETRIEVE request made by the server.
+
+We can make the problem easy to diagnose if we indicate via error return to
+filesystem server when it is violating the contract. This should not
+practically cause problems because if a filesystem server is using shorter
+buffer, writes to it were already very likely to cause EIO, and if the
+filesystem is read-only it should be too following FUSE_MIN_READ_BUFFER
+minimum buffer size.
+
+Please see [1] for context where the problem of stuck filesystem was hit
+for real (because kernel client was incorrectly sending more than
+max_write data with NOTIFY_REPLY; see also previous patch), how the
+situation was traced and for more involving patch that did not make it
+into the tree.
+
+[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
+
+Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
+Cc: Han-Wen Nienhuys <hanwen@google.com>
+Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/fuse/dev.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
+index 249de20f752a..0ee64efc1980 100644
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -1250,6 +1250,16 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file,
+ struct fuse_in *in;
+ unsigned reqsize;
+
++ /*
++ * Require sane minimum read buffer - that has capacity for fixed part
++ * of any request header + negotated max_write room for data. If the
++ * requirement is not satisfied return EINVAL to the filesystem server
++ * to indicate that it is not following FUSE server/client contract.
++ * Don't dequeue / abort any request.
++ */
++ if (nbytes < max_t(size_t, FUSE_MIN_READ_BUFFER, 4096 + fc->max_write))
++ return -EINVAL;
++
+ restart:
+ spin_lock(&fiq->waitq.lock);
+ err = -EAGAIN;
+--
+2.20.1
+
--- /dev/null
+From b6c08a50275ea43daaea0ca1c977b768c3329484 Mon Sep 17 00:00:00 2001
+From: Kirill Smelkov <kirr@nexedi.com>
+Date: Wed, 27 Mar 2019 10:15:19 +0000
+Subject: fuse: retrieve: cap requested size to negotiated max_write
+
+[ Upstream commit 7640682e67b33cab8628729afec8ca92b851394f ]
+
+FUSE filesystem server and kernel client negotiate during initialization
+phase, what should be the maximum write size the client will ever issue.
+Correspondingly the filesystem server then queues sys_read calls to read
+requests with buffer capacity large enough to carry request header + that
+max_write bytes. A filesystem server is free to set its max_write in
+anywhere in the range between [1*page, fc->max_pages*page]. In particular
+go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages
+corresponds to 128K. Libfuse also allows users to configure max_write, but
+by default presets it to possible maximum.
+
+If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we
+allow to retrieve more than max_write bytes, corresponding prepared
+NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the
+filesystem server, in full correspondence with server/client contract, will
+be only queuing sys_read with ~max_write buffer capacity, and
+fuse_dev_do_read throws away requests that cannot fit into server request
+buffer. In turn the filesystem server could get stuck waiting indefinitely
+for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is
+understood by clients as that NOTIFY_REPLY was queued and will be sent
+back.
+
+Cap requested size to negotiate max_write to avoid the problem. This
+aligns with the way NOTIFY_RETRIEVE handler works, which already
+unconditionally caps requested retrieve size to fuse_conn->max_pages. This
+way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than
+was originally requested.
+
+Please see [1] for context where the problem of stuck filesystem was hit
+for real, how the situation was traced and for more involving patch that
+did not make it into the tree.
+
+[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
+[2] https://github.com/hanwen/go-fuse
+
+Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
+Cc: Han-Wen Nienhuys <hanwen@google.com>
+Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/fuse/dev.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
+index 0ee64efc1980..b75ccb76493c 100644
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -1691,7 +1691,7 @@ static int fuse_retrieve(struct fuse_conn *fc, struct inode *inode,
+ offset = outarg->offset & ~PAGE_MASK;
+ file_size = i_size_read(inode);
+
+- num = outarg->size;
++ num = min(outarg->size, fc->max_write);
+ if (outarg->offset > file_size)
+ num = 0;
+ else if (outarg->offset + num > file_size)
+--
+2.20.1
+
--- /dev/null
+From f2fe7acc3b8bc1ba4fa7d0586c454b3107adb1f0 Mon Sep 17 00:00:00 2001
+From: Tony Lindgren <tony@atomide.com>
+Date: Mon, 25 Mar 2019 15:43:18 -0700
+Subject: gpio: gpio-omap: add check for off wake capable gpios
+
+[ Upstream commit da38ef3ed10a09248e13ae16530c2c6d448dc47d ]
+
+We are currently assuming all GPIOs are non-wakeup capable GPIOs as we
+not configuring the bank->non_wakeup_gpios like we used to earlier with
+platform_data.
+
+Let's add omap_gpio_is_off_wakeup_capable() to make the handling clearer
+while considering that later patches may want to configure SoC specific
+bank->non_wakeup_gpios for the GPIOs in wakeup domain.
+
+Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
+Cc: Grygorii Strashko <grygorii.strashko@ti.com>
+Cc: Keerthy <j-keerthy@ti.com>
+Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Cc: Russell King <rmk+kernel@armlinux.org.uk>
+Cc: Tero Kristo <t-kristo@ti.com>
+Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpio/gpio-omap.c | 25 +++++++++++++++++--------
+ 1 file changed, 17 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
+index 6c1acf642c8e..6fa430d98517 100644
+--- a/drivers/gpio/gpio-omap.c
++++ b/drivers/gpio/gpio-omap.c
+@@ -343,6 +343,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)
+ {
+@@ -374,13 +390,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
+@@ -393,7 +403,6 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio,
+ bank->enabled_non_wakeup_gpios &= ~gpio_bit;
+ }
+
+-exit:
+ bank->level_mask =
+ readl_relaxed(bank->base + bank->regs->leveldetect0) |
+ readl_relaxed(bank->base + bank->regs->leveldetect1);
+--
+2.20.1
+
--- /dev/null
+From 65f6c29a4c5894ae2e3de6d28bb0845e74844fad Mon Sep 17 00:00:00 2001
+From: Andrey Smirnov <andrew.smirnov@gmail.com>
+Date: Sun, 10 Mar 2019 23:27:31 -0700
+Subject: gpio: vf610: Do not share irq_chip
+
+[ Upstream commit 338aa10750ba24d04beeaf5dc5efc032e5cf343f ]
+
+Fix the warning produced by gpiochip_set_irq_hooks() by allocating a
+dedicated IRQ chip per GPIO chip/port.
+
+Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
+Cc: Linus Walleij <linus.walleij@linaro.org>
+Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Cc: Chris Healy <cphealy@gmail.com>
+Cc: Andrew Lunn <andrew@lunn.ch>
+Cc: Heiner Kallweit <hkallweit1@gmail.com>
+Cc: Fabio Estevam <festevam@gmail.com>
+Cc: linux-gpio@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Cc: linux-imx@nxp.com
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpio/gpio-vf610.c | 26 ++++++++++++--------------
+ 1 file changed, 12 insertions(+), 14 deletions(-)
+
+diff --git a/drivers/gpio/gpio-vf610.c b/drivers/gpio/gpio-vf610.c
+index 7e09ce75ffb2..a9cb5571de54 100644
+--- a/drivers/gpio/gpio-vf610.c
++++ b/drivers/gpio/gpio-vf610.c
+@@ -37,6 +37,7 @@ struct fsl_gpio_soc_data {
+
+ struct vf610_gpio_port {
+ struct gpio_chip gc;
++ struct irq_chip ic;
+ void __iomem *base;
+ void __iomem *gpio_base;
+ const struct fsl_gpio_soc_data *sdata;
+@@ -66,8 +67,6 @@ struct vf610_gpio_port {
+ #define PORT_INT_EITHER_EDGE 0xb
+ #define PORT_INT_LOGIC_ONE 0xc
+
+-static struct irq_chip vf610_gpio_irq_chip;
+-
+ static const struct fsl_gpio_soc_data imx_data = {
+ .have_paddr = true,
+ };
+@@ -243,15 +242,6 @@ static int vf610_gpio_irq_set_wake(struct irq_data *d, u32 enable)
+ return 0;
+ }
+
+-static struct irq_chip vf610_gpio_irq_chip = {
+- .name = "gpio-vf610",
+- .irq_ack = vf610_gpio_irq_ack,
+- .irq_mask = vf610_gpio_irq_mask,
+- .irq_unmask = vf610_gpio_irq_unmask,
+- .irq_set_type = vf610_gpio_irq_set_type,
+- .irq_set_wake = vf610_gpio_irq_set_wake,
+-};
+-
+ static int vf610_gpio_probe(struct platform_device *pdev)
+ {
+ struct device *dev = &pdev->dev;
+@@ -259,6 +249,7 @@ static int vf610_gpio_probe(struct platform_device *pdev)
+ struct vf610_gpio_port *port;
+ struct resource *iores;
+ struct gpio_chip *gc;
++ struct irq_chip *ic;
+ int i;
+ int ret;
+
+@@ -295,6 +286,14 @@ static int vf610_gpio_probe(struct platform_device *pdev)
+ gc->direction_output = vf610_gpio_direction_output;
+ gc->set = vf610_gpio_set;
+
++ ic = &port->ic;
++ ic->name = "gpio-vf610";
++ ic->irq_ack = vf610_gpio_irq_ack;
++ ic->irq_mask = vf610_gpio_irq_mask;
++ ic->irq_unmask = vf610_gpio_irq_unmask;
++ ic->irq_set_type = vf610_gpio_irq_set_type;
++ ic->irq_set_wake = vf610_gpio_irq_set_wake;
++
+ ret = gpiochip_add_data(gc, port);
+ if (ret < 0)
+ return ret;
+@@ -306,14 +305,13 @@ static int vf610_gpio_probe(struct platform_device *pdev)
+ /* Clear the interrupt status register for all GPIO's */
+ vf610_gpio_writel(~0, port->base + PORT_ISFR);
+
+- ret = gpiochip_irqchip_add(gc, &vf610_gpio_irq_chip, 0,
+- handle_edge_irq, IRQ_TYPE_NONE);
++ ret = gpiochip_irqchip_add(gc, ic, 0, handle_edge_irq, IRQ_TYPE_NONE);
+ if (ret) {
+ dev_err(dev, "failed to add irqchip\n");
+ gpiochip_remove(gc);
+ return ret;
+ }
+- gpiochip_set_chained_irqchip(gc, &vf610_gpio_irq_chip, port->irq,
++ gpiochip_set_chained_irqchip(gc, ic, port->irq,
+ vf610_gpio_irq_handler);
+
+ return 0;
+--
+2.20.1
+
--- /dev/null
+From 2106462cb2dc5f2d487cf46958fafed8f716388b Mon Sep 17 00:00:00 2001
+From: Mike Kravetz <mike.kravetz@oracle.com>
+Date: Mon, 13 May 2019 17:19:38 -0700
+Subject: hugetlbfs: on restore reserve error path retain subpool reservation
+
+[ Upstream commit 0919e1b69ab459e06df45d3ba6658d281962db80 ]
+
+When a huge page is allocated, PagePrivate() is set if the allocation
+consumed a reservation. When freeing a huge page, PagePrivate is checked.
+If set, it indicates the reservation should be restored. PagePrivate
+being set at free huge page time mostly happens on error paths.
+
+When huge page reservations are created, a check is made to determine if
+the mapping is associated with an explicitly mounted filesystem. If so,
+pages are also reserved within the filesystem. The default action when
+freeing a huge page is to decrement the usage count in any associated
+explicitly mounted filesystem. However, if the reservation is to be
+restored the reservation/use count within the filesystem should not be
+decrementd. Otherwise, a subsequent page allocation and free for the same
+mapping location will cause the file filesystem usage to go 'negative'.
+
+Filesystem Size Used Avail Use% Mounted on
+nodev 4.0G -4.0M 4.1G - /opt/hugepool
+
+To fix, when freeing a huge page do not adjust filesystem usage if
+PagePrivate() is set to indicate the reservation should be restored.
+
+I did not cc stable as the problem has been around since reserves were
+added to hugetlbfs and nobody has noticed.
+
+Link: http://lkml.kernel.org/r/20190328234704.27083-2-mike.kravetz@oracle.com
+Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
+Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Cc: Davidlohr Bueso <dave@stgolabs.net>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/hugetlb.c | 21 ++++++++++++++++-----
+ 1 file changed, 16 insertions(+), 5 deletions(-)
+
+diff --git a/mm/hugetlb.c b/mm/hugetlb.c
+index 0bbb033d7d8c..65179513c2b2 100644
+--- a/mm/hugetlb.c
++++ b/mm/hugetlb.c
+@@ -1256,12 +1256,23 @@ void free_huge_page(struct page *page)
+ ClearPagePrivate(page);
+
+ /*
+- * A return code of zero implies that the subpool will be under its
+- * minimum size if the reservation is not restored after page is free.
+- * Therefore, force restore_reserve operation.
++ * If PagePrivate() was set on page, page allocation consumed a
++ * reservation. If the page was associated with a subpool, there
++ * would have been a page reserved in the subpool before allocation
++ * via hugepage_subpool_get_pages(). Since we are 'restoring' the
++ * reservtion, do not call hugepage_subpool_put_pages() as this will
++ * remove the reserved page from the subpool.
+ */
+- if (hugepage_subpool_put_pages(spool, 1) == 0)
+- restore_reserve = true;
++ if (!restore_reserve) {
++ /*
++ * A return code of zero implies that the subpool will be
++ * under its minimum size if the reservation is not restored
++ * after page is free. Therefore, force restore_reserve
++ * operation.
++ */
++ if (hugepage_subpool_put_pages(spool, 1) == 0)
++ restore_reserve = true;
++ }
+
+ spin_lock(&hugetlb_lock);
+ clear_page_huge_active(page);
+--
+2.20.1
+
--- /dev/null
+From 3d871afe2d0060f894d12712ee63c650f3c7b0ef Mon Sep 17 00:00:00 2001
+From: Adam Ludkiewicz <adam.ludkiewicz@intel.com>
+Date: Wed, 6 Feb 2019 15:08:15 -0800
+Subject: i40e: Queues are reserved despite "Invalid argument" error
+
+[ Upstream commit 3e957b377bf4262aec2dd424f28ece94e36814d4 ]
+
+Added a new local variable in the i40e_setup_tc function named
+old_queue_pairs so num_queue_pairs can be restored to the correct
+value in case configuring queue channels fails. Additionally, moved
+the exit label in the i40e_setup_tc function so the if (need_reset)
+block can be executed.
+Also, fixed data packing in the i40e_setup_tc function.
+
+Signed-off-by: Adam Ludkiewicz <adam.ludkiewicz@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
+index df8808cd7e11..4e04985fb430 100644
+--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
+@@ -6758,10 +6758,12 @@ static int i40e_setup_tc(struct net_device *netdev, void *type_data)
+ struct i40e_pf *pf = vsi->back;
+ u8 enabled_tc = 0, num_tc, hw;
+ bool need_reset = false;
++ int old_queue_pairs;
+ int ret = -EINVAL;
+ u16 mode;
+ int i;
+
++ old_queue_pairs = vsi->num_queue_pairs;
+ num_tc = mqprio_qopt->qopt.num_tc;
+ hw = mqprio_qopt->qopt.hw;
+ mode = mqprio_qopt->mode;
+@@ -6862,6 +6864,7 @@ config_tc:
+ }
+ ret = i40e_configure_queue_channels(vsi);
+ if (ret) {
++ vsi->num_queue_pairs = old_queue_pairs;
+ netdev_info(netdev,
+ "Failed configuring queue channels\n");
+ need_reset = true;
+--
+2.20.1
+
--- /dev/null
+From 01ccaf8b938028af50d02a117edc8d9b34b3928b Mon Sep 17 00:00:00 2001
+From: Brett Creeley <brett.creeley@intel.com>
+Date: Tue, 19 Feb 2019 15:04:06 -0800
+Subject: ice: Add missing case in print_link_msg for printing flow control
+
+[ Upstream commit 203a068ac9e2722e4d118116acaa3a5586f9468a ]
+
+Currently we aren't checking for the ICE_FC_NONE case for the current
+flow control mode. This is causing "Unknown" to be printed for the
+current flow control method if flow control is disabled. Fix this by
+adding the case for ICE_FC_NONE to print "None".
+
+Signed-off-by: Brett Creeley <brett.creeley@intel.com>
+Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ice/ice_main.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
+index db1543bca701..875f97aba6e0 100644
+--- a/drivers/net/ethernet/intel/ice/ice_main.c
++++ b/drivers/net/ethernet/intel/ice/ice_main.c
+@@ -652,6 +652,9 @@ void ice_print_link_msg(struct ice_vsi *vsi, bool isup)
+ case ICE_FC_RX_PAUSE:
+ fc = "RX";
+ break;
++ case ICE_FC_NONE:
++ fc = "None";
++ break;
+ default:
+ fc = "Unknown";
+ break;
+--
+2.20.1
+
--- /dev/null
+From 92fcf9ecaac922281743603a8a8c336927022bfd Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Mon, 13 May 2019 17:18:17 -0700
+Subject: initramfs: free initrd memory if opening /initrd.image fails
+
+[ Upstream commit 54c7a8916a887f357088f99e9c3a7720cd57d2c8 ]
+
+Patch series "initramfs tidyups".
+
+I've spent some time chasing down behavior in initramfs and found
+plenty of opportunity to improve the code. A first stab on that is
+contained in this series.
+
+This patch (of 7):
+
+We free the initrd memory for all successful or error cases except for the
+case where opening /initrd.image fails, which looks like an oversight.
+
+Steven said:
+
+: This also changes the behaviour when CONFIG_INITRAMFS_FORCE is enabled
+: - specifically it means that the initrd is freed (previously it was
+: ignored and never freed). But that seems like reasonable behaviour and
+: the previous behaviour looks like another oversight.
+
+Link: http://lkml.kernel.org/r/20190213174621.29297-3-hch@lst.de
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Steven Price <steven.price@arm.com>
+Acked-by: Mike Rapoport <rppt@linux.ibm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com> [arm64]
+Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: Russell King <linux@armlinux.org.uk>
+Cc: Will Deacon <will.deacon@arm.com>
+Cc: Guan Xuetao <gxt@pku.edu.cn>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ init/initramfs.c | 14 ++++++--------
+ 1 file changed, 6 insertions(+), 8 deletions(-)
+
+diff --git a/init/initramfs.c b/init/initramfs.c
+index f6f4a1e4cd54..cd5fb00fcb54 100644
+--- a/init/initramfs.c
++++ b/init/initramfs.c
+@@ -612,13 +612,12 @@ static int __init populate_rootfs(void)
+ printk(KERN_INFO "Trying to unpack rootfs image as initramfs...\n");
+ err = unpack_to_rootfs((char *)initrd_start,
+ initrd_end - initrd_start);
+- if (!err) {
+- free_initrd();
++ if (!err)
+ goto done;
+- } else {
+- clean_rootfs();
+- unpack_to_rootfs(__initramfs_start, __initramfs_size);
+- }
++
++ clean_rootfs();
++ unpack_to_rootfs(__initramfs_start, __initramfs_size);
++
+ printk(KERN_INFO "rootfs image is not initramfs (%s)"
+ "; looks like an initrd\n", err);
+ fd = ksys_open("/initrd.image",
+@@ -632,7 +631,6 @@ static int __init populate_rootfs(void)
+ written, initrd_end - initrd_start);
+
+ ksys_close(fd);
+- free_initrd();
+ }
+ done:
+ /* empty statement */;
+@@ -642,9 +640,9 @@ static int __init populate_rootfs(void)
+ initrd_end - initrd_start);
+ if (err)
+ printk(KERN_EMERG "Initramfs unpacking failed: %s\n", err);
+- free_initrd();
+ #endif
+ }
++ free_initrd();
+ flush_delayed_fput();
+ /*
+ * Try loading default modules from initramfs. This gives
+--
+2.20.1
+
--- /dev/null
+From abaa80c71ba926dfc788a37cfad7db31121304ac Mon Sep 17 00:00:00 2001
+From: Will Deacon <will.deacon@arm.com>
+Date: Tue, 23 Apr 2019 11:59:36 +0100
+Subject: iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel
+
+[ Upstream commit 3f54c447df34ff9efac7809a4a80fd3208efc619 ]
+
+Disabling the SMMU when probing from within a kdump kernel so that all
+incoming transactions are terminated can prevent the core of the crashed
+kernel from being transferred off the machine if all I/O devices are
+behind the SMMU.
+
+Instead, continue to probe the SMMU after it is disabled so that we can
+reinitialise it entirely and re-attach the DMA masters as they are reset.
+Since the kdump kernel may not have drivers for all of the active DMA
+masters, we suppress fault reporting to avoid spamming the console and
+swamping the IRQ threads.
+
+Reported-by: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
+Tested-by: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
+Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/arm-smmu-v3.c | 10 ++++------
+ 1 file changed, 4 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
+index 9ae3678844eb..40fbf20d69e5 100644
+--- a/drivers/iommu/arm-smmu-v3.c
++++ b/drivers/iommu/arm-smmu-v3.c
+@@ -2414,13 +2414,9 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)
+ /* Clear CR0 and sync (disables SMMU and queue processing) */
+ reg = readl_relaxed(smmu->base + ARM_SMMU_CR0);
+ if (reg & CR0_SMMUEN) {
+- if (is_kdump_kernel()) {
+- arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0);
+- arm_smmu_device_disable(smmu);
+- return -EBUSY;
+- }
+-
+ dev_warn(smmu->dev, "SMMU currently enabled! Resetting...\n");
++ WARN_ON(is_kdump_kernel() && !disable_bypass);
++ arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0);
+ }
+
+ ret = arm_smmu_device_disable(smmu);
+@@ -2513,6 +2509,8 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)
+ return ret;
+ }
+
++ if (is_kdump_kernel())
++ enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
+
+ /* Enable the SMMU interface, or ensure bypass */
+ if (!bypass || disable_bypass) {
+--
+2.20.1
+
--- /dev/null
+From 1109c938885f78e64d7b126dda716433283d3d1c Mon Sep 17 00:00:00 2001
+From: Lu Baolu <baolu.lu@linux.intel.com>
+Date: Thu, 2 May 2019 09:34:25 +0800
+Subject: iommu/vt-d: Set intel_iommu_gfx_mapped correctly
+
+[ Upstream commit cf1ec4539a50bdfe688caad4615ca47646884316 ]
+
+The intel_iommu_gfx_mapped flag is exported by the Intel
+IOMMU driver to indicate whether an IOMMU is used for the
+graphic device. In a virtualized IOMMU environment (e.g.
+QEMU), an include-all IOMMU is used for graphic device.
+This flag is found to be clear even the IOMMU is used.
+
+Cc: Ashok Raj <ashok.raj@intel.com>
+Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
+Cc: Kevin Tian <kevin.tian@intel.com>
+Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
+Fixes: c0771df8d5297 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.")
+Suggested-by: Kevin Tian <kevin.tian@intel.com>
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/intel-iommu.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
+index 603bf5233a99..c1439019dd12 100644
+--- a/drivers/iommu/intel-iommu.c
++++ b/drivers/iommu/intel-iommu.c
+@@ -4033,9 +4033,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)
+@@ -4831,6 +4829,9 @@ int __init intel_iommu_init(void)
+ goto out_free_reserved_range;
+ }
+
++ if (dmar_map_gfx)
++ intel_iommu_gfx_mapped = 1;
++
+ init_no_remapping_devices();
+
+ ret = init_dmars();
+--
+2.20.1
+
--- /dev/null
+From 4f9e5dcb777ee6eeca2445e2853c9e722e1f7b96 Mon Sep 17 00:00:00 2001
+From: Li Rongqing <lirongqing@baidu.com>
+Date: Tue, 14 May 2019 15:46:20 -0700
+Subject: ipc: prevent lockup on alloc_msg and free_msg
+
+[ Upstream commit d6a2946a88f524a47cc9b79279667137899db807 ]
+
+msgctl10 of ltp triggers the following lockup When CONFIG_KASAN is
+enabled on large memory SMP systems, the pages initialization can take a
+long time, if msgctl10 requests a huge block memory, and it will block
+rcu scheduler, so release cpu actively.
+
+After adding schedule() in free_msg, free_msg can not be called when
+holding spinlock, so adding msg to a tmp list, and free it out of
+spinlock
+
+ rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+ rcu: Tasks blocked on level-1 rcu_node (CPUs 16-31): P32505
+ rcu: Tasks blocked on level-1 rcu_node (CPUs 48-63): P34978
+ rcu: (detected by 11, t=35024 jiffies, g=44237529, q=16542267)
+ msgctl10 R running task 21608 32505 2794 0x00000082
+ Call Trace:
+ preempt_schedule_irq+0x4c/0xb0
+ retint_kernel+0x1b/0x2d
+ RIP: 0010:__is_insn_slot_addr+0xfb/0x250
+ Code: 82 1d 00 48 8b 9b 90 00 00 00 4c 89 f7 49 c1 ee 03 e8 59 83 1d 00 48 b8 00 00 00 00 00 fc ff df 4c 39 eb 48 89 9d 58 ff ff ff <41> c6 04 06 f8 74 66 4c 8d 75 98 4c 89 f1 48 c1 e9 03 48 01 c8 48
+ RSP: 0018:ffff88bce041f758 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
+ RAX: dffffc0000000000 RBX: ffffffff8471bc50 RCX: ffffffff828a2a57
+ RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff88bce041f780
+ RBP: ffff88bce041f828 R08: ffffed15f3f4c5b3 R09: ffffed15f3f4c5b3
+ R10: 0000000000000001 R11: ffffed15f3f4c5b2 R12: 000000318aee9b73
+ R13: ffffffff8471bc50 R14: 1ffff1179c083ef0 R15: 1ffff1179c083eec
+ kernel_text_address+0xc1/0x100
+ __kernel_text_address+0xe/0x30
+ unwind_get_return_address+0x2f/0x50
+ __save_stack_trace+0x92/0x100
+ create_object+0x380/0x650
+ __kmalloc+0x14c/0x2b0
+ load_msg+0x38/0x1a0
+ do_msgsnd+0x19e/0xcf0
+ do_syscall_64+0x117/0x400
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+ rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
+ rcu: Tasks blocked on level-1 rcu_node (CPUs 0-15): P32170
+ rcu: (detected by 14, t=35016 jiffies, g=44237525, q=12423063)
+ msgctl10 R running task 21608 32170 32155 0x00000082
+ Call Trace:
+ preempt_schedule_irq+0x4c/0xb0
+ retint_kernel+0x1b/0x2d
+ RIP: 0010:lock_acquire+0x4d/0x340
+ Code: 48 81 ec c0 00 00 00 45 89 c6 4d 89 cf 48 8d 6c 24 20 48 89 3c 24 48 8d bb e4 0c 00 00 89 74 24 0c 48 c7 44 24 20 b3 8a b5 41 <48> c1 ed 03 48 c7 44 24 28 b4 25 18 84 48 c7 44 24 30 d0 54 7a 82
+ RSP: 0018:ffff88af83417738 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
+ RAX: dffffc0000000000 RBX: ffff88bd335f3080 RCX: 0000000000000002
+ RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88bd335f3d64
+ RBP: ffff88af83417758 R08: 0000000000000000 R09: 0000000000000000
+ R10: 0000000000000001 R11: ffffed13f3f745b2 R12: 0000000000000000
+ R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000
+ is_bpf_text_address+0x32/0xe0
+ kernel_text_address+0xec/0x100
+ __kernel_text_address+0xe/0x30
+ unwind_get_return_address+0x2f/0x50
+ __save_stack_trace+0x92/0x100
+ save_stack+0x32/0xb0
+ __kasan_slab_free+0x130/0x180
+ kfree+0xfa/0x2d0
+ free_msg+0x24/0x50
+ do_msgrcv+0x508/0xe60
+ do_syscall_64+0x117/0x400
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Davidlohr said:
+ "So after releasing the lock, the msg rbtree/list is empty and new
+ calls will not see those in the newly populated tmp_msg list, and
+ therefore they cannot access the delayed msg freeing pointers, which
+ is good. Also the fact that the node_cache is now freed before the
+ actual messages seems to be harmless as this is wanted for
+ msg_insert() avoiding GFP_ATOMIC allocations, and after releasing the
+ info->lock the thing is freed anyway so it should not change things"
+
+Link: http://lkml.kernel.org/r/1552029161-4957-1-git-send-email-lirongqing@baidu.com
+Signed-off-by: Li RongQing <lirongqing@baidu.com>
+Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
+Reviewed-by: Davidlohr Bueso <dbueso@suse.de>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ ipc/mqueue.c | 10 ++++++++--
+ ipc/msgutil.c | 6 ++++++
+ 2 files changed, 14 insertions(+), 2 deletions(-)
+
+diff --git a/ipc/mqueue.c b/ipc/mqueue.c
+index c0d58f390c3b..bce7af1546d9 100644
+--- a/ipc/mqueue.c
++++ b/ipc/mqueue.c
+@@ -391,7 +391,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);
+
+@@ -402,10 +403,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 84598025a6ad..e65593742e2b 100644
+--- a/ipc/msgutil.c
++++ b/ipc/msgutil.c
+@@ -18,6 +18,7 @@
+ #include <linux/utsname.h>
+ #include <linux/proc_ns.h>
+ #include <linux/uaccess.h>
++#include <linux/sched.h>
+
+ #include "util.h"
+
+@@ -64,6 +65,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_ACCOUNT);
+ if (seg == NULL)
+@@ -176,6 +180,8 @@ void free_msg(struct msg_msg *msg)
+ kfree(msg);
+ while (seg != NULL) {
+ struct msg_msgseg *tmp = seg->next;
++
++ cond_resched();
+ kfree(seg);
+ seg = tmp;
+ }
+--
+2.20.1
+
--- /dev/null
+From 34f7587f0f17c0d2c4d6322d1c6dbae7868c8402 Mon Sep 17 00:00:00 2001
+From: Cyrill Gorcunov <gorcunov@gmail.com>
+Date: Mon, 13 May 2019 17:15:40 -0700
+Subject: kernel/sys.c: prctl: fix false positive in validate_prctl_map()
+
+[ Upstream commit a9e73998f9d705c94a8dca9687633adc0f24a19a ]
+
+While validating new map we require the @start_data to be strictly less
+than @end_data, which is fine for regular applications (this is why this
+nit didn't trigger for that long). These members are set from executable
+loaders such as elf handers, still it is pretty valid to have a loadable
+data section with zero size in file, in such case the start_data is equal
+to end_data once kernel loader finishes.
+
+As a result when we're trying to restore such programs the procedure fails
+and the kernel returns -EINVAL. From the image dump of a program:
+
+ | "mm_start_code": "0x400000",
+ | "mm_end_code": "0x8f5fb4",
+ | "mm_start_data": "0xf1bfb0",
+ | "mm_end_data": "0xf1bfb0",
+
+Thus we need to change validate_prctl_map from strictly less to less or
+equal operator use.
+
+Link: http://lkml.kernel.org/r/20190408143554.GY1421@uranus.lan
+Fixes: f606b77f1a9e3 ("prctl: PR_SET_MM -- introduce PR_SET_MM_MAP operation")
+Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
+Cc: Andrey Vagin <avagin@gmail.com>
+Cc: Dmitry Safonov <0x7f454c46@gmail.com>
+Cc: Pavel Emelyanov <xemul@virtuozzo.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sys.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/sys.c b/kernel/sys.c
+index 123bd73046ec..096932a45046 100644
+--- a/kernel/sys.c
++++ b/kernel/sys.c
+@@ -1919,7 +1919,7 @@ static int validate_prctl_map(struct prctl_mm_map *prctl_map)
+ ((unsigned long)prctl_map->__m1 __op \
+ (unsigned long)prctl_map->__m2) ? 0 : -EINVAL
+ error = __prctl_check_order(start_code, <, end_code);
+- error |= __prctl_check_order(start_data, <, end_data);
++ error |= __prctl_check_order(start_data,<=, end_data);
+ error |= __prctl_check_order(start_brk, <=, brk);
+ error |= __prctl_check_order(arg_start, <=, arg_end);
+ error |= __prctl_check_order(env_start, <=, env_end);
+--
+2.20.1
+
--- /dev/null
+From 3523cdbc64dcd41053bbf0ec1be1b431b81e0f34 Mon Sep 17 00:00:00 2001
+From: Fabien Dessenne <fabien.dessenne@st.com>
+Date: Wed, 24 Apr 2019 17:51:05 +0200
+Subject: mailbox: stm32-ipcc: check invalid irq
+
+[ Upstream commit 68a1c8485cf83734d4da9d81cd3b5d2ae7c0339b ]
+
+On failure of_irq_get() returns a negative value or zero, which is
+not handled as an error in the existing implementation.
+Instead of using this API, use platform_get_irq() that returns
+exclusively a negative value on failure.
+Also, do not output an error log in case of defer probe error.
+
+Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
+Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mailbox/stm32-ipcc.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c
+index 533b0da5235d..ca1f993c0de3 100644
+--- a/drivers/mailbox/stm32-ipcc.c
++++ b/drivers/mailbox/stm32-ipcc.c
+@@ -8,9 +8,9 @@
+ #include <linux/bitfield.h>
+ #include <linux/clk.h>
+ #include <linux/interrupt.h>
++#include <linux/io.h>
+ #include <linux/mailbox_controller.h>
+ #include <linux/module.h>
+-#include <linux/of_irq.h>
+ #include <linux/platform_device.h>
+ #include <linux/pm_wakeirq.h>
+
+@@ -240,9 +240,11 @@ static int stm32_ipcc_probe(struct platform_device *pdev)
+
+ /* irq */
+ for (i = 0; i < IPCC_IRQ_NUM; i++) {
+- ipcc->irqs[i] = of_irq_get_byname(dev->of_node, irq_name[i]);
++ ipcc->irqs[i] = platform_get_irq_byname(pdev, irq_name[i]);
+ if (ipcc->irqs[i] < 0) {
+- dev_err(dev, "no IRQ specified %s\n", irq_name[i]);
++ if (ipcc->irqs[i] != -EPROBE_DEFER)
++ dev_err(dev, "no IRQ specified %s\n",
++ irq_name[i]);
+ ret = ipcc->irqs[i];
+ goto err_clk;
+ }
+@@ -263,9 +265,10 @@ static int stm32_ipcc_probe(struct platform_device *pdev)
+
+ /* wakeup */
+ if (of_property_read_bool(np, "wakeup-source")) {
+- ipcc->wkp = of_irq_get_byname(dev->of_node, "wakeup");
++ ipcc->wkp = platform_get_irq_byname(pdev, "wakeup");
+ if (ipcc->wkp < 0) {
+- dev_err(dev, "could not get wakeup IRQ\n");
++ if (ipcc->wkp != -EPROBE_DEFER)
++ dev_err(dev, "could not get wakeup IRQ\n");
+ ret = ipcc->wkp;
+ goto err_clk;
+ }
+--
+2.20.1
+
--- /dev/null
+From 051db87772d9867fc2406338717675f5e12d25c8 Mon Sep 17 00:00:00 2001
+From: Linxu Fang <fanglinxu@huawei.com>
+Date: Mon, 13 May 2019 17:19:17 -0700
+Subject: mem-hotplug: fix node spanned pages when we have a node with only
+ ZONE_MOVABLE
+
+[ Upstream commit 299c83dce9ea3a79bb4b5511d2cb996b6b8e5111 ]
+
+342332e6a925 ("mm/page_alloc.c: introduce kernelcore=mirror option") and
+later patches rewrote the calculation of node spanned pages.
+
+e506b99696a2 ("mem-hotplug: fix node spanned pages when we have a movable
+node"), but the current code still has problems,
+
+When we have a node with only zone_movable and the node id is not zero,
+the size of node spanned pages is double added.
+
+That's because we have an empty normal zone, and zone_start_pfn or
+zone_end_pfn is not between arch_zone_lowest_possible_pfn and
+arch_zone_highest_possible_pfn, so we need to use clamp to constrain the
+range just like the commit <96e907d13602> (bootmem: Reimplement
+__absent_pages_in_range() using for_each_mem_pfn_range()).
+
+e.g.
+Zone ranges:
+ DMA [mem 0x0000000000001000-0x0000000000ffffff]
+ DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
+ Normal [mem 0x0000000100000000-0x000000023fffffff]
+Movable zone start for each node
+ Node 0: 0x0000000100000000
+ Node 1: 0x0000000140000000
+Early memory node ranges
+ node 0: [mem 0x0000000000001000-0x000000000009efff]
+ node 0: [mem 0x0000000000100000-0x00000000bffdffff]
+ node 0: [mem 0x0000000100000000-0x000000013fffffff]
+ node 1: [mem 0x0000000140000000-0x000000023fffffff]
+
+node 0 DMA spanned:0xfff present:0xf9e absent:0x61
+node 0 DMA32 spanned:0xff000 present:0xbefe0 absent:0x40020
+node 0 Normal spanned:0 present:0 absent:0
+node 0 Movable spanned:0x40000 present:0x40000 absent:0
+On node 0 totalpages(node_present_pages): 1048446
+node_spanned_pages:1310719
+node 1 DMA spanned:0 present:0 absent:0
+node 1 DMA32 spanned:0 present:0 absent:0
+node 1 Normal spanned:0x100000 present:0x100000 absent:0
+node 1 Movable spanned:0x100000 present:0x100000 absent:0
+On node 1 totalpages(node_present_pages): 2097152
+node_spanned_pages:2097152
+Memory: 6967796K/12582392K available (16388K kernel code, 3686K rwdata,
+4468K rodata, 2160K init, 10444K bss, 5614596K reserved, 0K
+cma-reserved)
+
+It shows that the current memory of node 1 is double added.
+After this patch, the problem is fixed.
+
+node 0 DMA spanned:0xfff present:0xf9e absent:0x61
+node 0 DMA32 spanned:0xff000 present:0xbefe0 absent:0x40020
+node 0 Normal spanned:0 present:0 absent:0
+node 0 Movable spanned:0x40000 present:0x40000 absent:0
+On node 0 totalpages(node_present_pages): 1048446
+node_spanned_pages:1310719
+node 1 DMA spanned:0 present:0 absent:0
+node 1 DMA32 spanned:0 present:0 absent:0
+node 1 Normal spanned:0 present:0 absent:0
+node 1 Movable spanned:0x100000 present:0x100000 absent:0
+On node 1 totalpages(node_present_pages): 1048576
+node_spanned_pages:1048576
+memory: 6967796K/8388088K available (16388K kernel code, 3686K rwdata,
+4468K rodata, 2160K init, 10444K bss, 1420292K reserved, 0K
+cma-reserved)
+
+Link: http://lkml.kernel.org/r/1554178276-10372-1-git-send-email-fanglinxu@huawei.com
+Signed-off-by: Linxu Fang <fanglinxu@huawei.com>
+Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
+Cc: Xishi Qiu <qiuxishi@huawei.com>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Pavel Tatashin <pavel.tatashin@microsoft.com>
+Cc: Oscar Salvador <osalvador@suse.de>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/page_alloc.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/mm/page_alloc.c b/mm/page_alloc.c
+index 8e6932a140b8..2d04bd2e1ced 100644
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -5937,13 +5937,15 @@ static unsigned long __meminit zone_spanned_pages_in_node(int nid,
+ unsigned long *zone_end_pfn,
+ unsigned long *ignored)
+ {
++ unsigned long zone_low = arch_zone_lowest_possible_pfn[zone_type];
++ unsigned long zone_high = arch_zone_highest_possible_pfn[zone_type];
+ /* When hotadd a new node from cpu_up(), the node should be empty */
+ if (!node_start_pfn && !node_end_pfn)
+ return 0;
+
+ /* Get the start and end of the zone */
+- *zone_start_pfn = arch_zone_lowest_possible_pfn[zone_type];
+- *zone_end_pfn = arch_zone_highest_possible_pfn[zone_type];
++ *zone_start_pfn = clamp(node_start_pfn, zone_low, zone_high);
++ *zone_end_pfn = clamp(node_end_pfn, zone_low, zone_high);
+ adjust_zone_range_for_zone_movable(nid, zone_type,
+ node_start_pfn, node_end_pfn,
+ zone_start_pfn, zone_end_pfn);
+--
+2.20.1
+
--- /dev/null
+From 000cb083dfd1d79f497b7384328517fb66b4eca9 Mon Sep 17 00:00:00 2001
+From: Binbin Wu <binbin.wu@intel.com>
+Date: Mon, 8 Apr 2019 16:09:10 +0800
+Subject: mfd: intel-lpss: Set the device in reset state when init
+
+[ Upstream commit dad06532292d77f37fbe831a02948a593500f682 ]
+
+In virtualized setup, when system reboots due to warm
+reset interrupt storm is seen.
+
+Call Trace:
+<IRQ>
+dump_stack+0x70/0xa5
+__report_bad_irq+0x2e/0xc0
+note_interrupt+0x248/0x290
+? add_interrupt_randomness+0x30/0x220
+handle_irq_event_percpu+0x54/0x80
+handle_irq_event+0x39/0x60
+handle_fasteoi_irq+0x91/0x150
+handle_irq+0x108/0x180
+do_IRQ+0x52/0xf0
+common_interrupt+0xf/0xf
+</IRQ>
+RIP: 0033:0x76fc2cfabc1d
+Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
+94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
+<48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
+24
+RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
+RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
+RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
+RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
+R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
+R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
+handlers:
+[<000000000d3fa913>] idma64_irq
+Disabling IRQ #27
+
+To avoid interrupt storm, set the device in reset state
+before bringing out the device from reset state.
+
+Changelog v2:
+- correct the subject line by adding "mfd: "
+
+Signed-off-by: Binbin Wu <binbin.wu@intel.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/intel-lpss.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
+index 50bffc3382d7..ff3fba16e735 100644
+--- a/drivers/mfd/intel-lpss.c
++++ b/drivers/mfd/intel-lpss.c
+@@ -273,6 +273,9 @@ static void intel_lpss_init_dev(const struct intel_lpss *lpss)
+ {
+ u32 value = LPSS_PRIV_SSP_REG_DIS_DMA_FIN;
+
++ /* Set the device in reset state */
++ writel(0, lpss->priv + LPSS_PRIV_RESETS);
++
+ intel_lpss_deassert_reset(lpss);
+
+ intel_lpss_set_remap_addr(lpss);
+--
+2.20.1
+
--- /dev/null
+From 981fb1a73013aac9fd0a8d871d5ca5933c86a7ef Mon Sep 17 00:00:00 2001
+From: Daniel Gomez <dagmcr@gmail.com>
+Date: Mon, 22 Apr 2019 21:09:50 +0200
+Subject: mfd: tps65912-spi: Add missing of table registration
+
+[ Upstream commit 9e364e87ad7f2c636276c773d718cda29d62b741 ]
+
+MODULE_DEVICE_TABLE(of, <of_match_table> should be called to complete DT
+OF mathing mechanism and register it.
+
+Before this patch:
+modinfo drivers/mfd/tps65912-spi.ko | grep alias
+alias: spi:tps65912
+
+After this patch:
+modinfo drivers/mfd/tps65912-spi.ko | grep alias
+alias: of:N*T*Cti,tps65912C*
+alias: of:N*T*Cti,tps65912
+alias: spi:tps65912
+
+Reported-by: Javier Martinez Canillas <javier@dowhile0.org>
+Signed-off-by: Daniel Gomez <dagmcr@gmail.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/tps65912-spi.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/mfd/tps65912-spi.c b/drivers/mfd/tps65912-spi.c
+index 3bd75061f777..f78be039e463 100644
+--- a/drivers/mfd/tps65912-spi.c
++++ b/drivers/mfd/tps65912-spi.c
+@@ -27,6 +27,7 @@ static const struct of_device_id tps65912_spi_of_match_table[] = {
+ { .compatible = "ti,tps65912", },
+ { /* sentinel */ }
+ };
++MODULE_DEVICE_TABLE(of, tps65912_spi_of_match_table);
+
+ static int tps65912_spi_probe(struct spi_device *spi)
+ {
+--
+2.20.1
+
--- /dev/null
+From f3b99329c00ef7bd821477400e306a0a6f8128e6 Mon Sep 17 00:00:00 2001
+From: Tony Lindgren <tony@atomide.com>
+Date: Thu, 14 Feb 2019 08:03:45 -0800
+Subject: mfd: twl6040: Fix device init errors for ACCCTL register
+
+[ Upstream commit 48171d0ea7caccf21c9ee3ae75eb370f2a756062 ]
+
+I noticed that we can get a -EREMOTEIO errors on at least omap4 duovero:
+
+twl6040 0-004b: Failed to write 2d = 19: -121
+
+And then any following register access will produce errors.
+
+There 2d offset above is register ACCCTL that gets written on twl6040
+powerup. With error checking added to the related regcache_sync() call,
+the -EREMOTEIO error is reproducable on twl6040 powerup at least
+duovero.
+
+To fix the error, we need to wait until twl6040 is accessible after the
+powerup. Based on tests on omap4 duovero, we need to wait over 8ms after
+powerup before register write will complete without failures. Let's also
+make sure we warn about possible errors too.
+
+Note that we have twl6040_patch[] reg_sequence with the ACCCTL register
+configuration and regcache_sync() will write the new value to ACCCTL.
+
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/twl6040.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
+index dd19f17a1b63..2b8c479dbfa6 100644
+--- a/drivers/mfd/twl6040.c
++++ b/drivers/mfd/twl6040.c
+@@ -322,8 +322,19 @@ int twl6040_power(struct twl6040 *twl6040, int on)
+ }
+ }
+
++ /*
++ * Register access can produce errors after power-up unless we
++ * wait at least 8ms based on measurements on duovero.
++ */
++ usleep_range(10000, 12000);
++
+ /* Sync with the HW */
+- regcache_sync(twl6040->regmap);
++ ret = regcache_sync(twl6040->regmap);
++ if (ret) {
++ dev_err(twl6040->dev, "Failed to sync with the HW: %i\n",
++ ret);
++ goto out;
++ }
+
+ /* Default PLL configuration after power up */
+ twl6040->pll = TWL6040_SYSCLK_SEL_LPPLL;
+--
+2.20.1
+
--- /dev/null
+From 8e6fcbe5380fd4cf83249c060bf0ef93f2a7ff05 Mon Sep 17 00:00:00 2001
+From: Serge Semin <fancer.lancer@gmail.com>
+Date: Fri, 3 May 2019 20:50:40 +0300
+Subject: mips: Make sure dt memory regions are valid
+
+[ Upstream commit 93fa5b280761a4dbb14c5330f260380385ab2b49 ]
+
+There are situations when memory regions coming from dts may be
+too big for the platform physical address space. This especially
+concerns XPA-capable systems. Bootloader may determine more than 4GB
+memory available and pass it to the kernel over dts memory node, while
+kernel is built without XPA/64BIT support. In this case the region
+may either simply be truncated by add_memory_region() method
+or by u64->phys_addr_t type casting. But in worst case the method
+can even drop the memory region if it exceeds PHYS_ADDR_MAX size.
+So lets make sure the retrieved from dts memory regions are valid,
+and if some of them aren't, just manually truncate them with a warning
+printed out.
+
+Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: James Hogan <jhogan@kernel.org>
+Cc: Mike Rapoport <rppt@linux.ibm.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Thomas Bogendoerfer <tbogendoerfer@suse.de>
+Cc: Huacai Chen <chenhc@lemote.com>
+Cc: Stefan Agner <stefan@agner.ch>
+Cc: Stephen Rothwell <sfr@canb.auug.org.au>
+Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Serge Semin <Sergey.Semin@t-platforms.ru>
+Cc: linux-mips@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kernel/prom.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
+index 89950b7bf536..bdaf3536241a 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);
+ }
+
+ int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
+--
+2.20.1
+
--- /dev/null
+From ec9de213cc99aa5698526d08666bd1256ba16124 Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+Date: Mon, 25 Mar 2019 15:09:47 +0530
+Subject: misc: pci_endpoint_test: Fix test_reg_bar to be updated in
+ pci_endpoint_test
+
+[ Upstream commit 8f220664570e755946db1282f48e07f26e1f2cb4 ]
+
+commit 834b90519925 ("misc: pci_endpoint_test: Add support for
+PCI_ENDPOINT_TEST regs to be mapped to any BAR") while adding
+test_reg_bar in order to map PCI_ENDPOINT_TEST regs to be mapped to any
+BAR failed to update test_reg_bar in pci_endpoint_test, resulting in
+test_reg_bar having invalid value when used outside probe.
+
+Fix it.
+
+Fixes: 834b90519925 ("misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR")
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/misc/pci_endpoint_test.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
+index 896e2df9400f..fd33a3b9c66f 100644
+--- a/drivers/misc/pci_endpoint_test.c
++++ b/drivers/misc/pci_endpoint_test.c
+@@ -662,6 +662,7 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
+ data = (struct pci_endpoint_test_data *)ent->driver_data;
+ if (data) {
+ test_reg_bar = data->test_reg_bar;
++ test->test_reg_bar = test_reg_bar;
+ test->alignment = data->alignment;
+ irq_type = data->irq_type;
+ }
+--
+2.20.1
+
--- /dev/null
+From 98920dbbf1e25afa93779056ed770ad512d1b6ac Mon Sep 17 00:00:00 2001
+From: Yue Hu <huyue2@yulong.com>
+Date: Mon, 13 May 2019 17:18:14 -0700
+Subject: mm/cma.c: fix crash on CMA allocation if bitmap allocation fails
+
+[ Upstream commit 1df3a339074e31db95c4790ea9236874b13ccd87 ]
+
+f022d8cb7ec7 ("mm: cma: Don't crash on allocation if CMA area can't be
+activated") fixes the crash issue when activation fails via setting
+cma->count as 0, same logic exists if bitmap allocation fails.
+
+Link: http://lkml.kernel.org/r/20190325081309.6004-1-zbestahu@gmail.com
+Signed-off-by: Yue Hu <huyue2@yulong.com>
+Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Laura Abbott <labbott@redhat.com>
+Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
+Cc: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/cma.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/mm/cma.c b/mm/cma.c
+index bfe9f5397165..6ce6e22f82d9 100644
+--- a/mm/cma.c
++++ b/mm/cma.c
+@@ -106,8 +106,10 @@ static int __init cma_activate_area(struct cma *cma)
+
+ cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+
+- if (!cma->bitmap)
++ if (!cma->bitmap) {
++ cma->count = 0;
+ return -ENOMEM;
++ }
+
+ WARN_ON_ONCE(!pfn_valid(pfn));
+ zone = page_zone(pfn_to_page(pfn));
+--
+2.20.1
+
--- /dev/null
+From 9da1b4ca02dcc2d7059c9f615dcd317d8fb28dd0 Mon Sep 17 00:00:00 2001
+From: Yue Hu <huyue2@yulong.com>
+Date: Mon, 13 May 2019 17:17:41 -0700
+Subject: mm/cma.c: fix the bitmap status to show failed allocation reason
+
+[ Upstream commit 2b59e01a3aa665f751d1410b99fae9336bd424e1 ]
+
+Currently one bit in cma bitmap represents number of pages rather than
+one page, cma->count means cma size in pages. So to find available pages
+via find_next_zero_bit()/find_next_bit() we should use cma size not in
+pages but in bits although current free pages number is correct due to
+zero value of order_per_bit. Once order_per_bit is changed the bitmap
+status will be incorrect.
+
+The size input in cma_debug_show_areas() is not correct. It will
+affect the available pages at some position to debug the failure issue.
+
+This is an example with order_per_bit = 1
+
+Before this change:
+[ 4.120060] cma: number of available pages: 1@93+4@108+7@121+7@137+7@153+7@169+7@185+7@201+3@213+3@221+3@229+3@237+3@245+3@253+3@261+3@269+3@277+3@285+3@293+3@301+3@309+3@317+3@325+19@333+15@369+512@512=> 638 free of 1024 total pages
+
+After this change:
+[ 4.143234] cma: number of available pages: 2@93+8@108+14@121+14@137+14@153+14@169+14@185+14@201+6@213+6@221+6@229+6@237+6@245+6@253+6@261+6@269+6@277+6@285+6@293+6@301+6@309+6@317+6@325+38@333+30@369=> 252 free of 1024 total pages
+
+Obviously the bitmap status before is incorrect.
+
+Link: http://lkml.kernel.org/r/20190320060829.9144-1-zbestahu@gmail.com
+Signed-off-by: Yue Hu <huyue2@yulong.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
+Cc: Randy Dunlap <rdunlap@infradead.org>
+Cc: Laura Abbott <labbott@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/cma.c | 19 +++++++++++--------
+ 1 file changed, 11 insertions(+), 8 deletions(-)
+
+diff --git a/mm/cma.c b/mm/cma.c
+index 6ce6e22f82d9..476dfe13a701 100644
+--- a/mm/cma.c
++++ b/mm/cma.c
+@@ -371,23 +371,26 @@ err:
+ #ifdef CONFIG_CMA_DEBUG
+ static void cma_debug_show_areas(struct cma *cma)
+ {
+- unsigned long next_zero_bit, next_set_bit;
++ unsigned long next_zero_bit, next_set_bit, nr_zero;
+ unsigned long start = 0;
+- unsigned int nr_zero, nr_total = 0;
++ unsigned long nr_part, nr_total = 0;
++ unsigned long nbits = cma_bitmap_maxno(cma);
+
+ mutex_lock(&cma->lock);
+ pr_info("number of available pages: ");
+ for (;;) {
+- next_zero_bit = find_next_zero_bit(cma->bitmap, cma->count, start);
+- if (next_zero_bit >= cma->count)
++ next_zero_bit = find_next_zero_bit(cma->bitmap, nbits, start);
++ if (next_zero_bit >= nbits)
+ break;
+- next_set_bit = find_next_bit(cma->bitmap, cma->count, next_zero_bit);
++ next_set_bit = find_next_bit(cma->bitmap, nbits, next_zero_bit);
+ nr_zero = next_set_bit - next_zero_bit;
+- pr_cont("%s%u@%lu", nr_total ? "+" : "", nr_zero, next_zero_bit);
+- nr_total += nr_zero;
++ nr_part = nr_zero << cma->order_per_bit;
++ pr_cont("%s%lu@%lu", nr_total ? "+" : "", nr_part,
++ next_zero_bit);
++ nr_total += nr_part;
+ start = next_zero_bit + nr_zero;
+ }
+- pr_cont("=> %u free of %lu total pages\n", nr_total, cma->count);
++ pr_cont("=> %lu free of %lu total pages\n", nr_total, cma->count);
+ mutex_unlock(&cma->lock);
+ }
+ #else
+--
+2.20.1
+
--- /dev/null
+From 6f8b1f3fc9c7097cf634336450e91f1a21a5444c Mon Sep 17 00:00:00 2001
+From: Yue Hu <huyue2@yulong.com>
+Date: Mon, 13 May 2019 17:16:37 -0700
+Subject: mm/cma_debug.c: fix the break condition in cma_maxchunk_get()
+
+[ Upstream commit f0fd50504a54f5548eb666dc16ddf8394e44e4b7 ]
+
+If not find zero bit in find_next_zero_bit(), it will return the size
+parameter passed in, so the start bit should be compared with bitmap_maxno
+rather than cma->count. Although getting maxchunk is working fine due to
+zero value of order_per_bit currently, the operation will be stuck if
+order_per_bit is set as non-zero.
+
+Link: http://lkml.kernel.org/r/20190319092734.276-1-zbestahu@gmail.com
+Signed-off-by: Yue Hu <huyue2@yulong.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Joe Perches <joe@perches.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Dmitry Safonov <d.safonov@partner.samsung.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/cma_debug.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mm/cma_debug.c b/mm/cma_debug.c
+index ad6723e9d110..3e0415076cc9 100644
+--- a/mm/cma_debug.c
++++ b/mm/cma_debug.c
+@@ -58,7 +58,7 @@ static int cma_maxchunk_get(void *data, u64 *val)
+ mutex_lock(&cma->lock);
+ for (;;) {
+ start = find_next_zero_bit(cma->bitmap, bitmap_maxno, end);
+- if (start >= cma->count)
++ if (start >= bitmap_maxno)
+ break;
+ end = find_next_bit(cma->bitmap, bitmap_maxno, start);
+ maxchunk = max(end - start, maxchunk);
+--
+2.20.1
+
--- /dev/null
+From 067e089cd56e95e803f0f7d03018fa8384232a01 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@redhat.com>
+Date: Mon, 13 May 2019 17:19:45 -0700
+Subject: mm/hmm: select mmu notifier when selecting HMM
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 734fb89968900b5c5f8edd5038bd4cdeab8c61d2 ]
+
+To avoid random config build issue, select mmu notifier when HMM is
+selected. In any cases when HMM get selected it will be by users that
+will also wants the mmu notifier.
+
+Link: http://lkml.kernel.org/r/20190403193318.16478-2-jglisse@redhat.com
+Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
+Acked-by: Balbir Singh <bsingharora@gmail.com>
+Cc: Ralph Campbell <rcampbell@nvidia.com>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: Ira Weiny <ira.weiny@intel.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Souptick Joarder <jrdr.linux@gmail.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mm/Kconfig b/mm/Kconfig
+index de64ea658716..b457e94ae618 100644
+--- a/mm/Kconfig
++++ b/mm/Kconfig
+@@ -700,12 +700,12 @@ config DEV_PAGEMAP_OPS
+
+ config HMM
+ bool
++ select MMU_NOTIFIER
+ select MIGRATE_VMA_HELPER
+
+ config HMM_MIRROR
+ bool "HMM mirror CPU page table into a device page table"
+ depends on ARCH_HAS_HMM
+- select MMU_NOTIFIER
+ select HMM
+ help
+ Select HMM_MIRROR if you want to mirror range of the CPU page table of a
+--
+2.20.1
+
--- /dev/null
+From 9e2ce7c907960946158565cc010c4f14bf9c60af Mon Sep 17 00:00:00 2001
+From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
+Date: Mon, 13 May 2019 17:19:11 -0700
+Subject: mm: page_mkclean vs MADV_DONTNEED race
+
+[ Upstream commit 024eee0e83f0df52317be607ca521e0fc572aa07 ]
+
+MADV_DONTNEED is handled with mmap_sem taken in read mode. We call
+page_mkclean without holding mmap_sem.
+
+MADV_DONTNEED implies that pages in the region are unmapped and subsequent
+access to the pages in that range is handled as a new page fault. This
+implies that if we don't have parallel access to the region when
+MADV_DONTNEED is run we expect those range to be unallocated.
+
+w.r.t page_mkclean() we need to make sure that we don't break the
+MADV_DONTNEED semantics. MADV_DONTNEED check for pmd_none without holding
+pmd_lock. This implies we skip the pmd if we temporarily mark pmd none.
+Avoid doing that while marking the page clean.
+
+Keep the sequence same for dax too even though we don't support
+MADV_DONTNEED for dax mapping
+
+The bug was noticed by code review and I didn't observe any failures w.r.t
+test run. This is similar to
+
+commit 58ceeb6bec86d9140f9d91d71a710e963523d063
+Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Date: Thu Apr 13 14:56:26 2017 -0700
+
+ thp: fix MADV_DONTNEED vs. MADV_FREE race
+
+commit ced108037c2aa542b3ed8b7afd1576064ad1362a
+Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Date: Thu Apr 13 14:56:20 2017 -0700
+
+ thp: fix MADV_DONTNEED vs. numa balancing race
+
+Link: http://lkml.kernel.org/r/20190321040610.14226-1-aneesh.kumar@linux.ibm.com
+Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc:"Kirill A . Shutemov" <kirill@shutemov.name>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/dax.c | 2 +-
+ mm/rmap.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/fs/dax.c b/fs/dax.c
+index 004c8ac1117c..75a289c31c7e 100644
+--- a/fs/dax.c
++++ b/fs/dax.c
+@@ -908,7 +908,7 @@ static void dax_mapping_entry_mkclean(struct address_space *mapping,
+ goto unlock_pmd;
+
+ flush_cache_page(vma, address, pfn);
+- pmd = pmdp_huge_clear_flush(vma, address, pmdp);
++ pmd = pmdp_invalidate(vma, address, pmdp);
+ pmd = pmd_wrprotect(pmd);
+ pmd = pmd_mkclean(pmd);
+ set_pmd_at(vma->vm_mm, address, pmdp, pmd);
+diff --git a/mm/rmap.c b/mm/rmap.c
+index 85b7f9423352..f048c2651954 100644
+--- a/mm/rmap.c
++++ b/mm/rmap.c
+@@ -926,7 +926,7 @@ static bool page_mkclean_one(struct page *page, struct vm_area_struct *vma,
+ continue;
+
+ flush_cache_page(vma, address, page_to_pfn(page));
+- entry = pmdp_huge_clear_flush(vma, address, pmd);
++ entry = pmdp_invalidate(vma, address, pmd);
+ entry = pmd_wrprotect(entry);
+ entry = pmd_mkclean(entry);
+ set_pmd_at(vma->vm_mm, address, pmd, entry);
+--
+2.20.1
+
--- /dev/null
+From e8607897171c93351cd22eee8acd479f49ea0d8a Mon Sep 17 00:00:00 2001
+From: Qian Cai <cai@lca.pw>
+Date: Mon, 13 May 2019 17:16:31 -0700
+Subject: mm/slab.c: fix an infinite loop in leaks_show()
+
+[ Upstream commit 745e10146c31b1c6ed3326286704ae251b17f663 ]
+
+"cat /proc/slab_allocators" could hang forever on SMP machines with
+kmemleak or object debugging enabled due to other CPUs running do_drain()
+will keep making kmemleak_object or debug_objects_cache dirty and unable
+to escape the first loop in leaks_show(),
+
+do {
+ set_store_user_clean(cachep);
+ drain_cpu_caches(cachep);
+ ...
+
+} while (!is_store_user_clean(cachep));
+
+For example,
+
+do_drain
+ slabs_destroy
+ slab_destroy
+ kmem_cache_free
+ __cache_free
+ ___cache_free
+ kmemleak_free_recursive
+ delete_object_full
+ __delete_object
+ put_object
+ free_object_rcu
+ kmem_cache_free
+ cache_free_debugcheck --> dirty kmemleak_object
+
+One approach is to check cachep->name and skip both kmemleak_object and
+debug_objects_cache in leaks_show(). The other is to set store_user_clean
+after drain_cpu_caches() which leaves a small window between
+drain_cpu_caches() and set_store_user_clean() where per-CPU caches could
+be dirty again lead to slightly wrong information has been stored but
+could also speed up things significantly which sounds like a good
+compromise. For example,
+
+ # cat /proc/slab_allocators
+ 0m42.778s # 1st approach
+ 0m0.737s # 2nd approach
+
+[akpm@linux-foundation.org: tweak comment]
+Link: http://lkml.kernel.org/r/20190411032635.10325-1-cai@lca.pw
+Fixes: d31676dfde25 ("mm/slab: alternative implementation for DEBUG_SLAB_LEAK")
+Signed-off-by: Qian Cai <cai@lca.pw>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: Pekka Enberg <penberg@kernel.org>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/slab.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/mm/slab.c b/mm/slab.c
+index 018d32496e8d..46f21e73db2f 100644
+--- a/mm/slab.c
++++ b/mm/slab.c
+@@ -4326,8 +4326,12 @@ static int leaks_show(struct seq_file *m, void *p)
+ * whole processing.
+ */
+ do {
+- set_store_user_clean(cachep);
+ drain_cpu_caches(cachep);
++ /*
++ * drain_cpu_caches() could make kmemleak_object and
++ * debug_objects_cache dirty, so reset afterwards.
++ */
++ set_store_user_clean(cachep);
+
+ x[1] = 0;
+
+--
+2.20.1
+
--- /dev/null
+From fa04a59ef7e1378f96e374774f381523d96c92a4 Mon Sep 17 00:00:00 2001
+From: Ludovic Barre <ludovic.barre@st.com>
+Date: Fri, 26 Apr 2019 09:46:35 +0200
+Subject: mmc: mmci: Prevent polling for busy detection in IRQ context
+
+[ Upstream commit 8520ce1e17799b220ff421d4f39438c9c572ade3 ]
+
+The IRQ handler, mmci_irq(), loops until all status bits have been cleared.
+However, the status bit signaling busy in variant->busy_detect_flag, may be
+set even if busy detection isn't monitored for the current request.
+
+This may be the case for the CMD11 when switching the I/O voltage, which
+leads to that mmci_irq() busy loops in IRQ context. Fix this problem, by
+clearing the status bit for busy, before continuing to validate the
+condition for the loop. This is safe, because the busy status detection has
+already been taken care of by mmci_cmd_irq().
+
+Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mmc/host/mmci.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
+index 1841d250e9e2..eb1a65cb878f 100644
+--- a/drivers/mmc/host/mmci.c
++++ b/drivers/mmc/host/mmci.c
+@@ -1295,9 +1295,10 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
+ }
+
+ /*
+- * Don't poll for busy completion in irq context.
++ * Busy detection has been handled by mmci_cmd_irq() above.
++ * Clear the status bit to prevent polling in IRQ context.
+ */
+- if (host->variant->busy_detect && host->busy_status)
++ if (host->variant->busy_detect_flag)
+ status &= ~host->variant->busy_detect_flag;
+
+ ret = 1;
+--
+2.20.1
+
--- /dev/null
+From 6e49ca3030add16af7c11ee334903db78da19120 Mon Sep 17 00:00:00 2001
+From: Peng Li <lipeng321@huawei.com>
+Date: Thu, 4 Apr 2019 16:17:51 +0800
+Subject: net: hns3: return 0 and print warning when hit duplicate MAC
+
+[ Upstream commit 72110b567479f0282489a9b3747e76d8c67d75f5 ]
+
+When set 2 same MAC to different function of one port, IMP
+will return error as the later one may modify the origin one.
+This will cause bond fail for 2 VFs of one port.
+
+Driver just print warning and return 0 with this patch, so
+if set same MAC address, it will return 0 but do not really
+configure HW.
+
+Signed-off-by: Peng Li <lipeng321@huawei.com>
+Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+index 340baf6a470c..4648c6a9d9e8 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+@@ -4300,8 +4300,11 @@ int hclge_add_uc_addr_common(struct hclge_vport *vport,
+ return hclge_add_mac_vlan_tbl(vport, &req, NULL);
+
+ /* check if we just hit the duplicate */
+- if (!ret)
+- ret = -EINVAL;
++ if (!ret) {
++ dev_warn(&hdev->pdev->dev, "VF %d mac(%pM) exists\n",
++ vport->vport_id, addr);
++ return 0;
++ }
+
+ dev_err(&hdev->pdev->dev,
+ "PF failed to add unicast entry(%pM) in the MAC table\n",
+--
+2.20.1
+
--- /dev/null
+From f913a49caad0524831661c272fe44b70a22e251b Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Fri, 28 Sep 2018 12:21:17 +0300
+Subject: net: thunderbolt: Unregister ThunderboltIP protocol handler when
+ suspending
+
+[ Upstream commit 9872760eb7b1d4f6066ad8b560714a5d0a728fdb ]
+
+The XDomain protocol messages may start as soon as Thunderbolt control
+channel is started. This means that if the other host starts sending
+ThunderboltIP packets early enough they will be passed to the network
+driver which then gets confused because its resume hook is not called
+yet.
+
+Fix this by unregistering the ThunderboltIP protocol handler when
+suspending and registering it back on resume.
+
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Acked-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/thunderbolt.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/thunderbolt.c b/drivers/net/thunderbolt.c
+index e0d6760f3219..4b5af2413970 100644
+--- a/drivers/net/thunderbolt.c
++++ b/drivers/net/thunderbolt.c
+@@ -1285,6 +1285,7 @@ static int __maybe_unused tbnet_suspend(struct device *dev)
+ tbnet_tear_down(net, true);
+ }
+
++ tb_unregister_protocol_handler(&net->handler);
+ return 0;
+ }
+
+@@ -1293,6 +1294,8 @@ static int __maybe_unused tbnet_resume(struct device *dev)
+ struct tb_service *svc = tb_to_service(dev);
+ struct tbnet *net = tb_service_get_drvdata(svc);
+
++ tb_register_protocol_handler(&net->handler);
++
+ netif_carrier_off(net->dev);
+ if (netif_running(net->dev)) {
+ netif_device_attach(net->dev);
+--
+2.20.1
+
--- /dev/null
+From 0c6d6813636c21d797a1c3b3b70bac78277ed535 Mon Sep 17 00:00:00 2001
+From: Jakub Jankowski <shasta@toxcorp.com>
+Date: Thu, 25 Apr 2019 23:46:50 +0200
+Subject: netfilter: nf_conntrack_h323: restore boundary check correctness
+
+[ Upstream commit f5e85ce8e733c2547827f6268136b70b802eabdb ]
+
+Since commit bc7d811ace4a ("netfilter: nf_ct_h323: Convert
+CHECK_BOUND macro to function"), NAT traversal for H.323
+doesn't work, failing to parse H323-UserInformation.
+nf_h323_error_boundary() compares contents of the bitstring,
+not the addresses, preventing valid H.323 packets from being
+conntrack'd.
+
+This looks like an oversight from when CHECK_BOUND macro was
+converted to a function.
+
+To fix it, stop dereferencing bs->cur and bs->end.
+
+Fixes: bc7d811ace4a ("netfilter: nf_ct_h323: Convert CHECK_BOUND macro to function")
+Signed-off-by: Jakub Jankowski <shasta@toxcorp.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_conntrack_h323_asn1.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/netfilter/nf_conntrack_h323_asn1.c b/net/netfilter/nf_conntrack_h323_asn1.c
+index 1601275efe2d..4c2ef42e189c 100644
+--- a/net/netfilter/nf_conntrack_h323_asn1.c
++++ b/net/netfilter/nf_conntrack_h323_asn1.c
+@@ -172,7 +172,7 @@ static int nf_h323_error_boundary(struct bitstr *bs, size_t bytes, size_t bits)
+ if (bits % BITS_PER_BYTE > 0)
+ bytes++;
+
+- if (*bs->cur + bytes > *bs->end)
++ if (bs->cur + bytes > bs->end)
+ return 1;
+
+ return 0;
+--
+2.20.1
+
--- /dev/null
+From 806de2ef475499053e70927728e7b0c6c24b99a2 Mon Sep 17 00:00:00 2001
+From: Taehee Yoo <ap420073@gmail.com>
+Date: Tue, 30 Apr 2019 01:55:54 +0900
+Subject: netfilter: nf_flow_table: check ttl value in flow offload data path
+
+[ Upstream commit 33cc3c0cfa64c86b6c4bbee86997aea638534931 ]
+
+nf_flow_offload_ip_hook() and nf_flow_offload_ipv6_hook() do not check
+ttl value. So, ttl value overflow may occur.
+
+Fixes: 97add9f0d66d ("netfilter: flow table support for IPv4")
+Fixes: 0995210753a2 ("netfilter: flow table support for IPv6")
+Signed-off-by: Taehee Yoo <ap420073@gmail.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_flow_table_ip.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
+index 15ed91309992..129e9ec99ec9 100644
+--- a/net/netfilter/nf_flow_table_ip.c
++++ b/net/netfilter/nf_flow_table_ip.c
+@@ -181,6 +181,9 @@ static int nf_flow_tuple_ip(struct sk_buff *skb, const struct net_device *dev,
+ iph->protocol != IPPROTO_UDP)
+ return -1;
+
++ if (iph->ttl <= 1)
++ return -1;
++
+ thoff = iph->ihl * 4;
+ if (!pskb_may_pull(skb, thoff + sizeof(*ports)))
+ return -1;
+@@ -412,6 +415,9 @@ static int nf_flow_tuple_ipv6(struct sk_buff *skb, const struct net_device *dev,
+ ip6h->nexthdr != IPPROTO_UDP)
+ return -1;
+
++ if (ip6h->hop_limit <= 1)
++ return -1;
++
+ thoff = sizeof(*ip6h);
+ if (!pskb_may_pull(skb, thoff + sizeof(*ports)))
+ return -1;
+--
+2.20.1
+
--- /dev/null
+From 07946f656e835c9f38d73883d7714af978979fc2 Mon Sep 17 00:00:00 2001
+From: Taehee Yoo <ap420073@gmail.com>
+Date: Fri, 3 May 2019 01:56:38 +0900
+Subject: netfilter: nf_flow_table: fix missing error check for
+ rhashtable_insert_fast
+
+[ Upstream commit 43c8f131184faf20c07221f3e09724611c6525d8 ]
+
+rhashtable_insert_fast() may return an error value when memory
+allocation fails, but flow_offload_add() does not check for errors.
+This patch just adds missing error checking.
+
+Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure")
+Signed-off-by: Taehee Yoo <ap420073@gmail.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_flow_table_core.c | 25 ++++++++++++++++++-------
+ 1 file changed, 18 insertions(+), 7 deletions(-)
+
+diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
+index e1537ace2b90..5df7486bb416 100644
+--- a/net/netfilter/nf_flow_table_core.c
++++ b/net/netfilter/nf_flow_table_core.c
+@@ -185,14 +185,25 @@ static const struct rhashtable_params nf_flow_offload_rhash_params = {
+
+ int flow_offload_add(struct nf_flowtable *flow_table, struct flow_offload *flow)
+ {
+- flow->timeout = (u32)jiffies;
++ int err;
+
+- rhashtable_insert_fast(&flow_table->rhashtable,
+- &flow->tuplehash[FLOW_OFFLOAD_DIR_ORIGINAL].node,
+- nf_flow_offload_rhash_params);
+- rhashtable_insert_fast(&flow_table->rhashtable,
+- &flow->tuplehash[FLOW_OFFLOAD_DIR_REPLY].node,
+- nf_flow_offload_rhash_params);
++ err = rhashtable_insert_fast(&flow_table->rhashtable,
++ &flow->tuplehash[0].node,
++ nf_flow_offload_rhash_params);
++ if (err < 0)
++ return err;
++
++ err = rhashtable_insert_fast(&flow_table->rhashtable,
++ &flow->tuplehash[1].node,
++ nf_flow_offload_rhash_params);
++ if (err < 0) {
++ rhashtable_remove_fast(&flow_table->rhashtable,
++ &flow->tuplehash[0].node,
++ nf_flow_offload_rhash_params);
++ return err;
++ }
++
++ flow->timeout = (u32)jiffies;
+ return 0;
+ }
+ EXPORT_SYMBOL_GPL(flow_offload_add);
+--
+2.20.1
+
--- /dev/null
+From df161e3286162b58d33a3614bc2a17f2165c62e2 Mon Sep 17 00:00:00 2001
+From: Taehee Yoo <ap420073@gmail.com>
+Date: Tue, 30 Apr 2019 01:55:29 +0900
+Subject: netfilter: nf_flow_table: fix netdev refcnt leak
+
+[ Upstream commit 26a302afbe328ecb7507cae2035d938e6635131b ]
+
+flow_offload_alloc() calls nf_route() to get a dst_entry. Internally,
+nf_route() calls ip_route_output_key() that allocates a dst_entry and
+holds it. So, a dst_entry should be released by dst_release() if
+nf_route() is successful.
+
+Otherwise, netns exit routine cannot be finished and the following
+message is printed:
+
+[ 257.490952] unregister_netdevice: waiting for lo to become free. Usage count = 1
+
+Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure")
+Signed-off-by: Taehee Yoo <ap420073@gmail.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nft_flow_offload.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/netfilter/nft_flow_offload.c b/net/netfilter/nft_flow_offload.c
+index 436cc14cfc59..7f85af4c40ff 100644
+--- a/net/netfilter/nft_flow_offload.c
++++ b/net/netfilter/nft_flow_offload.c
+@@ -113,6 +113,7 @@ static void nft_flow_offload_eval(const struct nft_expr *expr,
+ if (ret < 0)
+ goto err_flow_add;
+
++ dst_release(route.tuple[!dir].dst);
+ return;
+
+ err_flow_add:
+--
+2.20.1
+
--- /dev/null
+From 9f087a4c3ce788d8ed718fb8cbc2b169c944f30f Mon Sep 17 00:00:00 2001
+From: Florian Westphal <fw@strlen.de>
+Date: Tue, 30 Apr 2019 14:33:22 +0200
+Subject: netfilter: nf_tables: fix base chain stat rcu_dereference usage
+
+[ Upstream commit edbd82c5fba009f68d20b5db585be1e667c605f6 ]
+
+Following splat gets triggered when nfnetlink monitor is running while
+xtables-nft selftests are running:
+
+net/netfilter/nf_tables_api.c:1272 suspicious rcu_dereference_check() usage!
+other info that might help us debug this:
+
+1 lock held by xtables-nft-mul/27006:
+ #0: 00000000e0f85be9 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1a/0x50
+Call Trace:
+ nf_tables_fill_chain_info.isra.45+0x6cc/0x6e0
+ nf_tables_chain_notify+0xf8/0x1a0
+ nf_tables_commit+0x165c/0x1740
+
+nf_tables_fill_chain_info() can be called both from dumps (rcu read locked)
+or from the transaction path if a userspace process subscribed to nftables
+notifications.
+
+In the 'table dump' case, rcu_access_pointer() cannot be used: We do not
+hold transaction mutex so the pointer can be NULLed right after the check.
+Just unconditionally fetch the value, then have the helper return
+immediately if its NULL.
+
+In the notification case we don't hold the rcu read lock, but updates are
+prevented due to transaction mutex. Use rcu_dereference_check() to make lockdep
+aware of this.
+
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_tables_api.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
+index ebfcfe1dcbdb..29ff59dd99ac 100644
+--- a/net/netfilter/nf_tables_api.c
++++ b/net/netfilter/nf_tables_api.c
+@@ -1142,6 +1142,9 @@ static int nft_dump_stats(struct sk_buff *skb, struct nft_stats __percpu *stats)
+ u64 pkts, bytes;
+ int cpu;
+
++ if (!stats)
++ return 0;
++
+ memset(&total, 0, sizeof(total));
+ for_each_possible_cpu(cpu) {
+ cpu_stats = per_cpu_ptr(stats, cpu);
+@@ -1199,6 +1202,7 @@ static int nf_tables_fill_chain_info(struct sk_buff *skb, struct net *net,
+ if (nft_is_base_chain(chain)) {
+ const struct nft_base_chain *basechain = nft_base_chain(chain);
+ const struct nf_hook_ops *ops = &basechain->ops;
++ struct nft_stats __percpu *stats;
+ struct nlattr *nest;
+
+ nest = nla_nest_start(skb, NFTA_CHAIN_HOOK);
+@@ -1220,8 +1224,9 @@ static int nf_tables_fill_chain_info(struct sk_buff *skb, struct net *net,
+ if (nla_put_string(skb, NFTA_CHAIN_TYPE, basechain->type->name))
+ goto nla_put_failure;
+
+- if (rcu_access_pointer(basechain->stats) &&
+- nft_dump_stats(skb, rcu_dereference(basechain->stats)))
++ stats = rcu_dereference_check(basechain->stats,
++ lockdep_commit_lock_is_held(net));
++ if (nft_dump_stats(skb, stats))
+ goto nla_put_failure;
+ }
+
+--
+2.20.1
+
--- /dev/null
+From ce9fca48a0fa1140bc35a07fced42d8580b39d8b Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Fri, 12 Apr 2019 16:37:30 -0400
+Subject: nfsd: allow fh_want_write to be called twice
+
+[ Upstream commit 0b8f62625dc309651d0efcb6a6247c933acd8b45 ]
+
+A fuzzer recently triggered lockdep warnings about potential sb_writers
+deadlocks caused by fh_want_write().
+
+Looks like we aren't careful to pair each fh_want_write() with an
+fh_drop_write().
+
+It's not normally a problem since fh_put() will call fh_drop_write() for
+us. And was OK for NFSv3 where we'd do one operation that might call
+fh_want_write(), and then put the filehandle.
+
+But an NFSv4 protocol fuzzer can do weird things like call unlink twice
+in a compound, and then we get into trouble.
+
+I'm a little worried about this approach of just leaving everything to
+fh_put(). But I think there are probably a lot of
+fh_want_write()/fh_drop_write() imbalances so for now I think we need it
+to be more forgiving.
+
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/vfs.h | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
+index a7e107309f76..db351247892d 100644
+--- a/fs/nfsd/vfs.h
++++ b/fs/nfsd/vfs.h
+@@ -120,8 +120,11 @@ void nfsd_put_raparams(struct file *file, struct raparms *ra);
+
+ static inline int fh_want_write(struct svc_fh *fh)
+ {
+- int ret = mnt_want_write(fh->fh_export->ex_path.mnt);
++ int ret;
+
++ if (fh->fh_want_write)
++ return 0;
++ ret = mnt_want_write(fh->fh_export->ex_path.mnt);
+ if (!ret)
+ fh->fh_want_write = true;
+ return ret;
+--
+2.20.1
+
--- /dev/null
+From b43daa9f1d29e108520841d6dea0352e1d66a3d3 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 22 Mar 2019 15:07:11 +0100
+Subject: nfsd: avoid uninitialized variable warning
+
+[ Upstream commit 0ab88ca4bcf18ba21058d8f19220f60afe0d34d8 ]
+
+clang warns that 'contextlen' may be accessed without an initialization:
+
+fs/nfsd/nfs4xdr.c:2911:9: error: variable 'contextlen' is uninitialized when used here [-Werror,-Wuninitialized]
+ contextlen);
+ ^~~~~~~~~~
+fs/nfsd/nfs4xdr.c:2424:16: note: initialize the variable 'contextlen' to silence this warning
+ int contextlen;
+ ^
+ = 0
+
+Presumably this cannot happen, as FATTR4_WORD2_SECURITY_LABEL is
+set if CONFIG_NFSD_V4_SECURITY_LABEL is enabled.
+Adding another #ifdef like the other two in this function
+avoids the warning.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/nfs4xdr.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
+index 418fa9c78186..db0beefe65ec 100644
+--- a/fs/nfsd/nfs4xdr.c
++++ b/fs/nfsd/nfs4xdr.c
+@@ -2413,8 +2413,10 @@ nfsd4_encode_fattr(struct xdr_stream *xdr, struct svc_fh *fhp,
+ __be32 status;
+ int err;
+ struct nfs4_acl *acl = NULL;
++#ifdef CONFIG_NFSD_V4_SECURITY_LABEL
+ void *context = NULL;
+ int contextlen;
++#endif
+ bool contextsupport = false;
+ struct nfsd4_compoundres *resp = rqstp->rq_resp;
+ u32 minorversion = resp->cstate.minorversion;
+@@ -2899,12 +2901,14 @@ out_acl:
+ *p++ = cpu_to_be32(NFS4_CHANGE_TYPE_IS_TIME_METADATA);
+ }
+
++#ifdef CONFIG_NFSD_V4_SECURITY_LABEL
+ if (bmval2 & FATTR4_WORD2_SECURITY_LABEL) {
+ status = nfsd4_encode_security_label(xdr, rqstp, context,
+ contextlen);
+ if (status)
+ goto out;
+ }
++#endif
+
+ attrlen = htonl(xdr->buf->len - attrlen_offset - 4);
+ write_bytes_to_xdr_buf(xdr->buf, attrlen_offset, &attrlen, 4);
+--
+2.20.1
+
--- /dev/null
+From 739b40673dfcca13b1cb658c9ef12c1d5cc2f99a Mon Sep 17 00:00:00 2001
+From: Miroslav Lichvar <mlichvar@redhat.com>
+Date: Wed, 17 Apr 2019 10:48:33 +0200
+Subject: ntp: Allow TAI-UTC offset to be set to zero
+
+[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
+
+The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock.
+It is typically set by NTP/PTP implementations and it is automatically
+updated by the kernel on leap seconds. The initial value is zero (which
+applications may interpret as unknown), but this value cannot be set by
+adjtimex. This limitation seems to go back to the original "nanokernel"
+implementation by David Mills.
+
+Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in
+order to allow setting it back to the initial value.
+
+Fixes: 153b5d054ac2 ("ntp: support for TAI")
+Suggested-by: Ondrej Mosnacek <omosnace@redhat.com>
+Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Richard Cochran <richardcochran@gmail.com>
+Cc: Prarit Bhargava <prarit@redhat.com>
+Link: https://lkml.kernel.org/r/20190417084833.7401-1-mlichvar@redhat.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/time/ntp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
+index c5e0cba3b39c..6b23cd584295 100644
+--- a/kernel/time/ntp.c
++++ b/kernel/time/ntp.c
+@@ -698,7 +698,7 @@ static inline void process_adjtimex_modes(const struct timex *txc, s32 *time_tai
+ time_constant = max(time_constant, 0l);
+ }
+
+- if (txc->modes & ADJ_TAI && txc->constant > 0)
++ if (txc->modes & ADJ_TAI && txc->constant >= 0)
+ *time_tai = txc->constant;
+
+ if (txc->modes & ADJ_OFFSET)
+--
+2.20.1
+
--- /dev/null
+From 2de4c8bd09143c867e65bf594215719d30d2b02c Mon Sep 17 00:00:00 2001
+From: Keith Busch <keith.busch@intel.com>
+Date: Tue, 30 Apr 2019 09:33:40 -0600
+Subject: nvme-pci: shutdown on timeout during deletion
+
+[ Upstream commit 9dc1a38ef1925d23c2933c5867df816386d92ff8 ]
+
+We do not restart a controller in a deleting state for timeout errors.
+When in this state, unblock potential request dispatchers with failed
+completions by shutting down the controller on timeout detection.
+
+Reported-by: Yufen Yu <yuyufen@huawei.com>
+Signed-off-by: Keith Busch <keith.busch@intel.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/pci.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
+index 377f6fff420d..c8eeecc58115 100644
+--- a/drivers/nvme/host/pci.c
++++ b/drivers/nvme/host/pci.c
+@@ -1132,6 +1132,7 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)
+ struct nvme_dev *dev = nvmeq->dev;
+ struct request *abort_req;
+ struct nvme_command cmd;
++ bool shutdown = false;
+ u32 csts = readl(dev->bar + NVME_REG_CSTS);
+
+ /* If PCI error recovery process is happening, we cannot reset or
+@@ -1168,12 +1169,14 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)
+ * shutdown, so we return BLK_EH_DONE.
+ */
+ switch (dev->ctrl.state) {
++ case NVME_CTRL_DELETING:
++ shutdown = true;
+ case NVME_CTRL_CONNECTING:
+ case NVME_CTRL_RESETTING:
+ dev_warn_ratelimited(dev->ctrl.device,
+ "I/O %d QID %d timeout, disable controller\n",
+ req->tag, nvmeq->qid);
+- nvme_dev_disable(dev, false);
++ nvme_dev_disable(dev, shutdown);
+ nvme_req(req)->flags |= NVME_REQ_CANCELLED;
+ return BLK_EH_DONE;
+ default:
+--
+2.20.1
+
--- /dev/null
+From db04bb75fcd64d41d401ec56dd315c88679fa0e6 Mon Sep 17 00:00:00 2001
+From: Keith Busch <keith.busch@intel.com>
+Date: Tue, 30 Apr 2019 09:33:41 -0600
+Subject: nvme-pci: unquiesce admin queue on shutdown
+
+[ Upstream commit c8e9e9b7646ebe1c5066ddc420d7630876277eb4 ]
+
+Just like IO queues, the admin queue also will not be restarted after a
+controller shutdown. Unquiesce this queue so that we do not block
+request dispatch on a permanently disabled controller.
+
+Reported-by: Yufen Yu <yuyufen@huawei.com>
+Signed-off-by: Keith Busch <keith.busch@intel.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/pci.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
+index 7b9ef8e734e7..377f6fff420d 100644
+--- a/drivers/nvme/host/pci.c
++++ b/drivers/nvme/host/pci.c
+@@ -2187,8 +2187,11 @@ static void nvme_dev_disable(struct nvme_dev *dev, bool shutdown)
+ * must flush all entered requests to their failed completion to avoid
+ * deadlocking blk-mq hot-cpu notifier.
+ */
+- if (shutdown)
++ if (shutdown) {
+ nvme_start_queues(&dev->ctrl);
++ if (dev->ctrl.admin_q && !blk_queue_dying(dev->ctrl.admin_q))
++ blk_mq_unquiesce_queue(dev->ctrl.admin_q);
++ }
+ mutex_unlock(&dev->shutdown_lock);
+ }
+
+--
+2.20.1
+
--- /dev/null
+From 63cd180a3fe94293cec2872155c1910792b23a8b Mon Sep 17 00:00:00 2001
+From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+Date: Sat, 13 Apr 2019 11:32:58 +0100
+Subject: nvmem: core: fix read buffer in place
+
+[ Upstream commit 2fe518fecb3a4727393be286db9804cd82ee2d91 ]
+
+When the bit_offset in the cell is zero, the pointer to the msb will
+not be properly initialized (ie, will still be pointing to the first
+byte in the buffer).
+
+This being the case, if there are bits to clear in the msb, those will
+be left untouched while the mask will incorrectly clear bit positions
+on the first byte.
+
+This commit also makes sure that any byte unused in the cell is
+cleared.
+
+Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvmem/core.c | 15 ++++++++++-----
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
+index 7c530c88b3fb..99de51e87f7f 100644
+--- a/drivers/nvmem/core.c
++++ b/drivers/nvmem/core.c
+@@ -1028,7 +1028,7 @@ EXPORT_SYMBOL_GPL(nvmem_cell_put);
+ static 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) {
+@@ -1043,11 +1043,16 @@ static void nvmem_shift_read_buffer_in_place(struct nvmem_cell *cell, void *buf)
+ p = b;
+ *b++ >>= bit_offset;
+ }
+-
+- /* result fits in less bytes */
+- if (cell->bytes != DIV_ROUND_UP(cell->nbits, BITS_PER_BYTE))
+- *p-- = 0;
++ } else {
++ /* point to the msb */
++ p += cell->bytes - 1;
+ }
++
++ /* result fits in less bytes */
++ extra = cell->bytes - DIV_ROUND_UP(cell->nbits, BITS_PER_BYTE);
++ while (--extra >= 0)
++ *p-- = 0;
++
+ /* clear msb bits if any leftover in the last byte */
+ *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
+ }
+--
+2.20.1
+
--- /dev/null
+From c9030360f3a7c6279d47818a2683b44359ba316e Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wens@csie.org>
+Date: Sat, 13 Apr 2019 11:32:53 +0100
+Subject: nvmem: sunxi_sid: Support SID on A83T and H5
+
+[ Upstream commit da75b8909756160b8e785104ba421a20b756c975 ]
+
+The device tree binding already lists compatible strings for these two
+SoCs. They don't have the defect as seen on the H3, and the size and
+register layout is the same as the A64. Furthermore, the driver does
+not include nvmem cell definitions.
+
+Add support for these two compatible strings, re-using the config for
+the A64.
+
+Signed-off-by: Chen-Yu Tsai <wens@csie.org>
+Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvmem/sunxi_sid.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
+index d020f89248fd..69f8e972e29c 100644
+--- a/drivers/nvmem/sunxi_sid.c
++++ b/drivers/nvmem/sunxi_sid.c
+@@ -235,8 +235,10 @@ static const struct sunxi_sid_cfg sun50i_a64_cfg = {
+ static const struct of_device_id sunxi_sid_of_match[] = {
+ { .compatible = "allwinner,sun4i-a10-sid", .data = &sun4i_a10_cfg },
+ { .compatible = "allwinner,sun7i-a20-sid", .data = &sun7i_a20_cfg },
++ { .compatible = "allwinner,sun8i-a83t-sid", .data = &sun50i_a64_cfg },
+ { .compatible = "allwinner,sun8i-h3-sid", .data = &sun8i_h3_cfg },
+ { .compatible = "allwinner,sun50i-a64-sid", .data = &sun50i_a64_cfg },
++ { .compatible = "allwinner,sun50i-h5-sid", .data = &sun50i_a64_cfg },
+ {/* sentinel */},
+ };
+ MODULE_DEVICE_TABLE(of, sunxi_sid_of_match);
+--
+2.20.1
+
--- /dev/null
+From cb850a68625c520c7b724c6230bd6d7ea3f7bc2f Mon Sep 17 00:00:00 2001
+From: Josh Poimboeuf <jpoimboe@redhat.com>
+Date: Mon, 13 May 2019 12:01:31 -0500
+Subject: objtool: Don't use ignore flag for fake jumps
+
+[ Upstream commit e6da9567959e164f82bc81967e0d5b10dee870b4 ]
+
+The ignore flag is set on fake jumps in order to keep
+add_jump_destinations() from setting their jump_dest, since it already
+got set when the fake jump was created.
+
+But using the ignore flag is a bit of a hack. It's normally used to
+skip validation of an instruction, which doesn't really make sense for
+fake jumps.
+
+Also, after the next patch, using the ignore flag for fake jumps can
+trigger a false "why am I validating an ignored function?" warning.
+
+Instead just add an explicit check in add_jump_destinations() to skip
+fake jumps.
+
+Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/71abc072ff48b2feccc197723a9c52859476c068.1557766718.git.jpoimboe@redhat.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/objtool/check.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/tools/objtool/check.c b/tools/objtool/check.c
+index 46be34576620..02a47e365e52 100644
+--- a/tools/objtool/check.c
++++ b/tools/objtool/check.c
+@@ -28,6 +28,8 @@
+ #include <linux/hashtable.h>
+ #include <linux/kernel.h>
+
++#define FAKE_JUMP_OFFSET -1
++
+ struct alternative {
+ struct list_head list;
+ struct instruction *insn;
+@@ -501,7 +503,7 @@ static int add_jump_destinations(struct objtool_file *file)
+ insn->type != INSN_JUMP_UNCONDITIONAL)
+ continue;
+
+- if (insn->ignore)
++ if (insn->ignore || insn->offset == FAKE_JUMP_OFFSET)
+ continue;
+
+ rela = find_rela_by_dest_range(insn->sec, insn->offset,
+@@ -670,10 +672,10 @@ static int handle_group_alt(struct objtool_file *file,
+ clear_insn_state(&fake_jump->state);
+
+ fake_jump->sec = special_alt->new_sec;
+- fake_jump->offset = -1;
++ fake_jump->offset = FAKE_JUMP_OFFSET;
+ fake_jump->type = INSN_JUMP_UNCONDITIONAL;
+ fake_jump->jump_dest = list_next_entry(last_orig_insn, list);
+- fake_jump->ignore = true;
++ fake_jump->func = orig_insn->func;
+ }
+
+ if (!special_alt->new_len) {
+--
+2.20.1
+
--- /dev/null
+From 20778975512f338e21884e5174289ae1d265b8fe Mon Sep 17 00:00:00 2001
+From: Amir Goldstein <amir73il@gmail.com>
+Date: Wed, 24 Apr 2019 19:39:50 +0300
+Subject: ovl: do not generate duplicate fsnotify events for "fake" path
+
+[ Upstream commit d989903058a83e8536cc7aadf9256a47d5c173fe ]
+
+Overlayfs "fake" path is used for stacked file operations on underlying
+files. Operations on files with "fake" path must not generate fsnotify
+events with path data, because those events have already been generated at
+overlayfs layer and because the reported event->fd for fanotify marks on
+underlying inode/filesystem will have the wrong path (the overlayfs path).
+
+Link: https://lore.kernel.org/linux-fsdevel/20190423065024.12695-1-jencce.kernel@gmail.com/
+Reported-by: Murphy Zhou <jencce.kernel@gmail.com>
+Fixes: d1d04ef8572b ("ovl: stack file ops")
+Signed-off-by: Amir Goldstein <amir73il@gmail.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/overlayfs/file.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
+index 0c810f20f778..2c993937b784 100644
+--- a/fs/overlayfs/file.c
++++ b/fs/overlayfs/file.c
+@@ -29,10 +29,11 @@ static struct file *ovl_open_realfile(const struct file *file,
+ struct inode *inode = file_inode(file);
+ struct file *realfile;
+ const struct cred *old_cred;
++ int flags = file->f_flags | O_NOATIME | FMODE_NONOTIFY;
+
+ old_cred = ovl_override_creds(inode->i_sb);
+- realfile = open_with_fake_path(&file->f_path, file->f_flags | O_NOATIME,
+- realinode, current_cred());
++ realfile = open_with_fake_path(&file->f_path, flags, realinode,
++ current_cred());
+ revert_creds(old_cred);
+
+ pr_debug("open(%p[%pD2/%c], 0%o) -> (%p, 0%o)\n",
+@@ -50,7 +51,7 @@ static int ovl_change_flags(struct file *file, unsigned int flags)
+ int err;
+
+ /* No atime modificaton on underlying */
+- flags |= O_NOATIME;
++ flags |= O_NOATIME | FMODE_NONOTIFY;
+
+ /* If some flag changed that cannot be changed then something's amiss */
+ if (WARN_ON((file->f_flags ^ flags) & ~OVL_SETFL_MASK))
+--
+2.20.1
+
--- /dev/null
+From faf9b1cbbc6a7f67a102be827a55e6789deb7553 Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+Date: Mon, 25 Mar 2019 15:09:45 +0530
+Subject: PCI: designware-ep: Use aligned ATU window for raising MSI interrupts
+
+[ Upstream commit 6b7330303a8186fb211357e6d379237fe9d2ece1 ]
+
+Certain platforms like K2G reguires the outbound ATU window to be
+aligned. The alignment size is already present in mem->page_size.
+Use the alignment size present in mem->page_size to configure an
+aligned ATU window. In order to raise an interrupt, CPU has to write
+to address offset from the start of the window unlike before where
+writes were always to the beginning of the ATU window.
+
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/controller/dwc/pcie-designware-ep.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
+index de8635af4cde..739d97080d3b 100644
+--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
++++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
+@@ -385,6 +385,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
+ {
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct pci_epc *epc = ep->epc;
++ unsigned int aligned_offset;
+ u16 msg_ctrl, msg_data;
+ u32 msg_addr_lower, msg_addr_upper, reg;
+ u64 msg_addr;
+@@ -410,13 +411,15 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
+ reg = ep->msi_cap + PCI_MSI_DATA_32;
+ msg_data = dw_pcie_readw_dbi(pci, reg);
+ }
+- msg_addr = ((u64) msg_addr_upper) << 32 | msg_addr_lower;
++ aligned_offset = msg_addr_lower & (epc->mem->page_size - 1);
++ msg_addr = ((u64)msg_addr_upper) << 32 |
++ (msg_addr_lower & ~aligned_offset);
+ ret = dw_pcie_ep_map_addr(epc, func_no, ep->msi_mem_phys, msg_addr,
+ epc->mem->page_size);
+ if (ret)
+ return ret;
+
+- writel(msg_data | (interrupt_num - 1), ep->msi_mem);
++ writel(msg_data | (interrupt_num - 1), ep->msi_mem + aligned_offset);
+
+ dw_pcie_ep_unmap_addr(epc, func_no, ep->msi_mem_phys);
+
+--
+2.20.1
+
--- /dev/null
+From a418222f35367bb7ad3014e6ca1a93f2fe1cf369 Mon Sep 17 00:00:00 2001
+From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
+Date: Fri, 29 Mar 2019 11:57:54 +0000
+Subject: PCI: dwc: Free MSI in dw_pcie_host_init() error path
+
+[ Upstream commit 9e2b5de5604a6ff2626c51e77014d92c9299722c ]
+
+If we ever did MSI-related initializations, we need to call
+dw_pcie_free_msi() in the error code path.
+
+Remove the IS_ENABLED(CONFIG_PCI_MSI) check for MSI init because
+pci_msi_enabled() already has a stub for !CONFIG_PCI_MSI.
+
+Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/controller/dwc/pcie-designware-host.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
+index b56e22262a77..4eedb2c54ab3 100644
+--- a/drivers/pci/controller/dwc/pcie-designware-host.c
++++ b/drivers/pci/controller/dwc/pcie-designware-host.c
+@@ -439,7 +439,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
+ if (ret)
+ pci->num_viewport = 2;
+
+- if (IS_ENABLED(CONFIG_PCI_MSI) && pci_msi_enabled()) {
++ if (pci_msi_enabled()) {
+ /*
+ * If a specific SoC driver needs to change the
+ * default number of vectors, it needs to implement
+@@ -477,7 +477,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
+ if (pp->ops->host_init) {
+ ret = pp->ops->host_init(pp);
+ if (ret)
+- goto error;
++ goto err_free_msi;
+ }
+
+ pp->root_bus_nr = pp->busn->start;
+@@ -491,7 +491,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
+
+ ret = pci_scan_root_bus_bridge(bridge);
+ if (ret)
+- goto error;
++ goto err_free_msi;
+
+ bus = bridge->bus;
+
+@@ -507,6 +507,9 @@ int dw_pcie_host_init(struct pcie_port *pp)
+ pci_bus_add_devices(bus);
+ return 0;
+
++err_free_msi:
++ if (pci_msi_enabled() && !pp->ops->msi_host_init)
++ dw_pcie_free_msi(pp);
+ error:
+ pci_free_host_bridge(bridge);
+ return ret;
+--
+2.20.1
+
--- /dev/null
+From 3f224593a4f09e8250c9fdb38fa0f9442909792d Mon Sep 17 00:00:00 2001
+From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
+Date: Fri, 29 Mar 2019 11:57:17 +0000
+Subject: PCI: dwc: Free MSI IRQ page in dw_pcie_free_msi()
+
+[ Upstream commit dc69a3d567941784c3d00e1d0834582b42b0b3e7 ]
+
+To avoid a memory leak, free the page allocated for MSI IRQ in
+dw_pcie_free_msi().
+
+Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/controller/dwc/pcie-designware-host.c | 12 ++++++++----
+ drivers/pci/controller/dwc/pcie-designware.h | 1 +
+ 2 files changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
+index 4eedb2c54ab3..acd50920c2ff 100644
+--- a/drivers/pci/controller/dwc/pcie-designware-host.c
++++ b/drivers/pci/controller/dwc/pcie-designware-host.c
+@@ -303,20 +303,24 @@ void dw_pcie_free_msi(struct pcie_port *pp)
+
+ irq_domain_remove(pp->msi_domain);
+ irq_domain_remove(pp->irq_domain);
++
++ if (pp->msi_page)
++ __free_page(pp->msi_page);
+ }
+
+ void dw_pcie_msi_init(struct pcie_port *pp)
+ {
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct device *dev = pci->dev;
+- struct page *page;
+ u64 msi_target;
+
+- page = alloc_page(GFP_KERNEL);
+- pp->msi_data = dma_map_page(dev, page, 0, PAGE_SIZE, DMA_FROM_DEVICE);
++ pp->msi_page = alloc_page(GFP_KERNEL);
++ pp->msi_data = dma_map_page(dev, pp->msi_page, 0, PAGE_SIZE,
++ DMA_FROM_DEVICE);
+ if (dma_mapping_error(dev, pp->msi_data)) {
+ dev_err(dev, "Failed to map MSI data\n");
+- __free_page(page);
++ __free_page(pp->msi_page);
++ pp->msi_page = NULL;
+ return;
+ }
+ msi_target = (u64)pp->msi_data;
+diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
+index 9f1a5e399b70..14dcf6646699 100644
+--- a/drivers/pci/controller/dwc/pcie-designware.h
++++ b/drivers/pci/controller/dwc/pcie-designware.h
+@@ -164,6 +164,7 @@ struct pcie_port {
+ struct irq_domain *irq_domain;
+ struct irq_domain *msi_domain;
+ dma_addr_t msi_data;
++ struct page *msi_page;
+ u32 num_vectors;
+ u32 irq_status[MAX_MSI_CTRLS];
+ raw_spinlock_t lock;
+--
+2.20.1
+
--- /dev/null
+From bd5d4593c79cfd56af12d91c911bd3a6abae2e44 Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+Date: Mon, 25 Mar 2019 15:09:33 +0530
+Subject: PCI: keystone: Prevent ARM32 specific code to be compiled for ARM64
+
+[ Upstream commit f316a2b53cd7f37963ae20ec7072eb27a349a4ce ]
+
+hook_fault_code() is an ARM32 specific API for hooking into data abort.
+
+AM65X platforms (that integrate ARM v8 cores and select CONFIG_ARM64 as
+arch) rely on pci-keystone.c but on them the enumeration of a
+non-present BDF does not trigger a bus error, so the fixup exception
+provided by calling hook_fault_code() is not needed and can be guarded
+with CONFIG_ARM.
+
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+[lorenzo.pieralisi@arm.com: commit log]
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/controller/dwc/pci-keystone.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
+index e88bd221fffe..5e199e7d2d4f 100644
+--- a/drivers/pci/controller/dwc/pci-keystone.c
++++ b/drivers/pci/controller/dwc/pci-keystone.c
+@@ -237,6 +237,7 @@ static void ks_pcie_setup_interrupts(struct keystone_pcie *ks_pcie)
+ ks_dw_pcie_enable_error_irq(ks_pcie);
+ }
+
++#ifdef CONFIG_ARM
+ /*
+ * When a PCI device does not exist during config cycles, keystone host gets a
+ * bus error instead of returning 0xffffffff. This handler always returns 0
+@@ -256,6 +257,7 @@ static int keystone_pcie_fault(unsigned long addr, unsigned int fsr,
+
+ return 0;
+ }
++#endif
+
+ static int __init ks_pcie_host_init(struct pcie_port *pp)
+ {
+@@ -279,12 +281,14 @@ static int __init ks_pcie_host_init(struct pcie_port *pp)
+ val |= BIT(12);
+ writel(val, pci->dbi_base + PCIE_CAP_BASE + PCI_EXP_DEVCTL);
+
++#ifdef CONFIG_ARM
+ /*
+ * PCIe access errors that result into OCP errors are caught by ARM as
+ * "External aborts"
+ */
+ hook_fault_code(17, keystone_pcie_fault, SIGBUS, 0,
+ "Asynchronous external abort");
++#endif
+
+ return 0;
+ }
+--
+2.20.1
+
--- /dev/null
+From 0f414e631d02e3aa6cfb851e6cb9b2c3f32568d4 Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marek.vasut+renesas@gmail.com>
+Date: Mon, 25 Mar 2019 12:41:01 +0100
+Subject: PCI: rcar: Fix 64bit MSI message address handling
+
+[ Upstream commit 954b4b752a4c4e963b017ed8cef4c453c5ed308d ]
+
+The MSI message address in the RC address space can be 64 bit. The
+R-Car PCIe RC supports such a 64bit MSI message address as well.
+The code currently uses virt_to_phys(__get_free_pages()) to obtain
+a reserved page for the MSI message address, and the return value
+of which can be a 64 bit physical address on 64 bit system.
+
+However, the driver only programs PCIEMSIALR register with the bottom
+32 bits of the virt_to_phys(__get_free_pages()) return value and does
+not program the top 32 bits into PCIEMSIAUR, but rather programs the
+PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
+SoCs, however may fail on new 64 bit R-Car SoCs.
+
+Since from a PCIe controller perspective, an inbound MSI is a memory
+write to a special address (in case of this controller, defined by
+the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
+never hits the DRAM _and_ because allocation of an MSI by a PCIe card
+driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
+in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
+cause memory corruption or other issues.
+
+There is however the possibility that if virt_to_phys(__get_free_pages())
+returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
+to 0x0 _and_ if the system had physical RAM at the address matching the
+value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
+physical address matching the value of PCIEMSIALR and a remote write to
+such a buffer by a PCIe card would trigger a spurious MSI.
+
+Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
+Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Cc: Geert Uytterhoeven <geert+renesas@glider.be>
+Cc: Phil Edworthy <phil.edworthy@renesas.com>
+Cc: Simon Horman <horms+renesas@verge.net.au>
+Cc: Wolfram Sang <wsa@the-dreams.de>
+Cc: linux-renesas-soc@vger.kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/controller/pcie-rcar.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
+index 765c39911c0c..9b9c677ad3a0 100644
+--- a/drivers/pci/controller/pcie-rcar.c
++++ b/drivers/pci/controller/pcie-rcar.c
+@@ -892,7 +892,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
+ {
+ struct device *dev = pcie->dev;
+ struct rcar_msi *msi = &pcie->msi;
+- unsigned long base;
++ phys_addr_t base;
+ int err, i;
+
+ mutex_init(&msi->lock);
+@@ -937,8 +937,8 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
+ }
+ base = virt_to_phys((void *)msi->pages);
+
+- rcar_pci_write_reg(pcie, base | MSIFE, PCIEMSIALR);
+- rcar_pci_write_reg(pcie, 0, PCIEMSIAUR);
++ rcar_pci_write_reg(pcie, lower_32_bits(base) | MSIFE, PCIEMSIALR);
++ rcar_pci_write_reg(pcie, upper_32_bits(base), PCIEMSIAUR);
+
+ /* enable all MSI interrupts */
+ rcar_pci_write_reg(pcie, 0xffffffff, PCIEMSIIER);
+--
+2.20.1
+
--- /dev/null
+From 0b30f0610fb0023fa4c10449dd2462629e76ac18 Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Fri, 15 Mar 2019 02:29:43 -0500
+Subject: PCI: rcar: Fix a potential NULL pointer dereference
+
+[ Upstream commit f0d14edd2ba43b995bef4dd5da5ffe0ae19321a1 ]
+
+In case __get_free_pages() fails and returns NULL, fix the return
+value to -ENOMEM and release resources to avoid dereferencing a
+NULL pointer.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/controller/pcie-rcar.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
+index 6a4e435bd35f..765c39911c0c 100644
+--- a/drivers/pci/controller/pcie-rcar.c
++++ b/drivers/pci/controller/pcie-rcar.c
+@@ -931,6 +931,10 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
+
+ /* setup MSI data target */
+ msi->pages = __get_free_pages(GFP_KERNEL, 0);
++ if (!msi->pages) {
++ err = -ENOMEM;
++ goto err;
++ }
+ base = virt_to_phys((void *)msi->pages);
+
+ rcar_pci_write_reg(pcie, base | MSIFE, PCIEMSIALR);
+--
+2.20.1
+
--- /dev/null
+From df2cc856ab698479bc93f9e09da627f580be57d4 Mon Sep 17 00:00:00 2001
+From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
+Date: Fri, 22 Mar 2019 13:27:21 -0500
+Subject: PCI: rpadlpar: Fix leaked device_node references in add/remove paths
+
+[ Upstream commit fb26228bfc4ce3951544848555c0278e2832e618 ]
+
+The find_dlpar_node() helper returns a device node with its reference
+incremented. Both the add and remove paths use this helper for find the
+appropriate node, but fail to release the reference when done.
+
+Annotate the find_dlpar_node() helper with a comment about the incremented
+reference count and call of_node_put() on the obtained device_node in the
+add and remove paths. Also, fixup a reference leak in the find_vio_slot()
+helper where we fail to call of_node_put() on the vdevice node after we
+iterate over its children.
+
+Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/hotplug/rpadlpar_core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
+index e2356a9c7088..182f9e3443ee 100644
+--- a/drivers/pci/hotplug/rpadlpar_core.c
++++ b/drivers/pci/hotplug/rpadlpar_core.c
+@@ -51,6 +51,7 @@ static struct device_node *find_vio_slot_node(char *drc_name)
+ if (rc == 0)
+ break;
+ }
++ of_node_put(parent);
+
+ return dn;
+ }
+@@ -71,6 +72,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;
+@@ -306,6 +308,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:
+@@ -439,6 +442,7 @@ int dlpar_remove_slot(char *drc_name)
+ rc = dlpar_remove_pci_slot(drc_name, dn);
+ break;
+ }
++ of_node_put(dn);
+ vm_unmap_aliases();
+
+ printk(KERN_INFO "%s: slot %s removed\n", DLPAR_MODULE_NAME, drc_name);
+--
+2.20.1
+
--- /dev/null
+From 96ee8dcb8a1e2121f84d2e53d18a8eaf848b02bf Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Mon, 25 Mar 2019 17:19:09 -0500
+Subject: PCI: xilinx: Check for __get_free_pages() failure
+
+[ Upstream commit 699ca30162686bf305cdf94861be02eb0cf9bda2 ]
+
+If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer
+dereference.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Reviewed-by: Steven Price <steven.price@arm.com>
+Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/controller/pcie-xilinx.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/pci/controller/pcie-xilinx.c b/drivers/pci/controller/pcie-xilinx.c
+index 7b1389d8e2a5..ea48cba5480b 100644
+--- a/drivers/pci/controller/pcie-xilinx.c
++++ b/drivers/pci/controller/pcie-xilinx.c
+@@ -336,14 +336,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 */
+@@ -498,6 +503,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);
+@@ -526,7 +532,9 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
+ return -ENODEV;
+ }
+
+- xilinx_pcie_enable_msi(port);
++ ret = xilinx_pcie_enable_msi(port);
++ if (ret)
++ return ret;
+ }
+
+ return 0;
+--
+2.20.1
+
--- /dev/null
+From 98506788746933b7d1212684fc42e9798651d943 Mon Sep 17 00:00:00 2001
+From: Dennis Zhou <dennis@kernel.org>
+Date: Thu, 21 Feb 2019 15:54:11 -0800
+Subject: percpu: do not search past bitmap when allocating an area
+
+[ Upstream commit 8c43004af01635cc9fbb11031d070e5e0d327ef2 ]
+
+pcpu_find_block_fit() guarantees that a fit is found within
+PCPU_BITMAP_BLOCK_BITS. Iteration is used to determine the first fit as
+it compares against the block's contig_hint. This can lead to
+incorrectly scanning past the end of the bitmap. The behavior was okay
+given the check after for bit_off >= end and the correctness of the
+hints from pcpu_find_block_fit().
+
+This patch fixes this by bounding the end offset by the number of bits
+in a chunk.
+
+Signed-off-by: Dennis Zhou <dennis@kernel.org>
+Reviewed-by: Peng Fan <peng.fan@nxp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/percpu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/mm/percpu.c b/mm/percpu.c
+index c66149ce1fe6..ff76fa0b7528 100644
+--- a/mm/percpu.c
++++ b/mm/percpu.c
+@@ -988,7 +988,8 @@ static int pcpu_alloc_area(struct pcpu_chunk *chunk, int alloc_bits,
+ /*
+ * Search to find a fit.
+ */
+- end = start + alloc_bits + PCPU_BITMAP_BLOCK_BITS;
++ end = min_t(int, start + alloc_bits + PCPU_BITMAP_BLOCK_BITS,
++ pcpu_chunk_map_bits(chunk));
+ bit_off = bitmap_find_next_zero_area(chunk->alloc_map, end, start,
+ alloc_bits, align_mask);
+ if (bit_off >= end)
+--
+2.20.1
+
--- /dev/null
+From 9038678dd40f550a0b3e0b7dfe992630739ae8cc Mon Sep 17 00:00:00 2001
+From: John Sperbeck <jsperbeck@google.com>
+Date: Tue, 7 May 2019 18:43:20 -0700
+Subject: percpu: remove spurious lock dependency between percpu and sched
+
+[ Upstream commit 198790d9a3aeaef5792d33a560020861126edc22 ]
+
+In free_percpu() we sometimes call pcpu_schedule_balance_work() to
+queue a work item (which does a wakeup) while holding pcpu_lock.
+This creates an unnecessary lock dependency between pcpu_lock and
+the scheduler's pi_lock. There are other places where we call
+pcpu_schedule_balance_work() without hold pcpu_lock, and this case
+doesn't need to be different.
+
+Moving the call outside the lock prevents the following lockdep splat
+when running tools/testing/selftests/bpf/{test_maps,test_progs} in
+sequence with lockdep enabled:
+
+======================================================
+WARNING: possible circular locking dependency detected
+5.1.0-dbg-DEV #1 Not tainted
+------------------------------------------------------
+kworker/23:255/18872 is trying to acquire lock:
+000000000bc79290 (&(&pool->lock)->rlock){-.-.}, at: __queue_work+0xb2/0x520
+
+but task is already holding lock:
+00000000e3e7a6aa (pcpu_lock){..-.}, at: free_percpu+0x36/0x260
+
+which lock already depends on the new lock.
+
+the existing dependency chain (in reverse order) is:
+
+-> #4 (pcpu_lock){..-.}:
+ lock_acquire+0x9e/0x180
+ _raw_spin_lock_irqsave+0x3a/0x50
+ pcpu_alloc+0xfa/0x780
+ __alloc_percpu_gfp+0x12/0x20
+ alloc_htab_elem+0x184/0x2b0
+ __htab_percpu_map_update_elem+0x252/0x290
+ bpf_percpu_hash_update+0x7c/0x130
+ __do_sys_bpf+0x1912/0x1be0
+ __x64_sys_bpf+0x1a/0x20
+ do_syscall_64+0x59/0x400
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+-> #3 (&htab->buckets[i].lock){....}:
+ lock_acquire+0x9e/0x180
+ _raw_spin_lock_irqsave+0x3a/0x50
+ htab_map_update_elem+0x1af/0x3a0
+
+-> #2 (&rq->lock){-.-.}:
+ lock_acquire+0x9e/0x180
+ _raw_spin_lock+0x2f/0x40
+ task_fork_fair+0x37/0x160
+ sched_fork+0x211/0x310
+ copy_process.part.43+0x7b1/0x2160
+ _do_fork+0xda/0x6b0
+ kernel_thread+0x29/0x30
+ rest_init+0x22/0x260
+ arch_call_rest_init+0xe/0x10
+ start_kernel+0x4fd/0x520
+ x86_64_start_reservations+0x24/0x26
+ x86_64_start_kernel+0x6f/0x72
+ secondary_startup_64+0xa4/0xb0
+
+-> #1 (&p->pi_lock){-.-.}:
+ lock_acquire+0x9e/0x180
+ _raw_spin_lock_irqsave+0x3a/0x50
+ try_to_wake_up+0x41/0x600
+ wake_up_process+0x15/0x20
+ create_worker+0x16b/0x1e0
+ workqueue_init+0x279/0x2ee
+ kernel_init_freeable+0xf7/0x288
+ kernel_init+0xf/0x180
+ ret_from_fork+0x24/0x30
+
+-> #0 (&(&pool->lock)->rlock){-.-.}:
+ __lock_acquire+0x101f/0x12a0
+ lock_acquire+0x9e/0x180
+ _raw_spin_lock+0x2f/0x40
+ __queue_work+0xb2/0x520
+ queue_work_on+0x38/0x80
+ free_percpu+0x221/0x260
+ pcpu_freelist_destroy+0x11/0x20
+ stack_map_free+0x2a/0x40
+ bpf_map_free_deferred+0x3c/0x50
+ process_one_work+0x1f7/0x580
+ worker_thread+0x54/0x410
+ kthread+0x10f/0x150
+ ret_from_fork+0x24/0x30
+
+other info that might help us debug this:
+
+Chain exists of:
+ &(&pool->lock)->rlock --> &htab->buckets[i].lock --> pcpu_lock
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(pcpu_lock);
+ lock(&htab->buckets[i].lock);
+ lock(pcpu_lock);
+ lock(&(&pool->lock)->rlock);
+
+ *** DEADLOCK ***
+
+3 locks held by kworker/23:255/18872:
+ #0: 00000000b36a6e16 ((wq_completion)events){+.+.},
+ at: process_one_work+0x17a/0x580
+ #1: 00000000dfd966f0 ((work_completion)(&map->work)){+.+.},
+ at: process_one_work+0x17a/0x580
+ #2: 00000000e3e7a6aa (pcpu_lock){..-.},
+ at: free_percpu+0x36/0x260
+
+stack backtrace:
+CPU: 23 PID: 18872 Comm: kworker/23:255 Not tainted 5.1.0-dbg-DEV #1
+Hardware name: ...
+Workqueue: events bpf_map_free_deferred
+Call Trace:
+ dump_stack+0x67/0x95
+ print_circular_bug.isra.38+0x1c6/0x220
+ check_prev_add.constprop.50+0x9f6/0xd20
+ __lock_acquire+0x101f/0x12a0
+ lock_acquire+0x9e/0x180
+ _raw_spin_lock+0x2f/0x40
+ __queue_work+0xb2/0x520
+ queue_work_on+0x38/0x80
+ free_percpu+0x221/0x260
+ pcpu_freelist_destroy+0x11/0x20
+ stack_map_free+0x2a/0x40
+ bpf_map_free_deferred+0x3c/0x50
+ process_one_work+0x1f7/0x580
+ worker_thread+0x54/0x410
+ kthread+0x10f/0x150
+ ret_from_fork+0x24/0x30
+
+Signed-off-by: John Sperbeck <jsperbeck@google.com>
+Signed-off-by: Dennis Zhou <dennis@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/percpu.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/mm/percpu.c b/mm/percpu.c
+index 41e58f3d8fbf..c66149ce1fe6 100644
+--- a/mm/percpu.c
++++ b/mm/percpu.c
+@@ -1721,6 +1721,7 @@ void free_percpu(void __percpu *ptr)
+ struct pcpu_chunk *chunk;
+ unsigned long flags;
+ int off;
++ bool need_balance = false;
+
+ if (!ptr)
+ return;
+@@ -1742,7 +1743,7 @@ void free_percpu(void __percpu *ptr)
+
+ list_for_each_entry(pos, &pcpu_slot[pcpu_nr_slots - 1], list)
+ if (pos != chunk) {
+- pcpu_schedule_balance_work();
++ need_balance = true;
+ break;
+ }
+ }
+@@ -1750,6 +1751,9 @@ void free_percpu(void __percpu *ptr)
+ trace_percpu_free_percpu(chunk->base_addr, off, ptr);
+
+ spin_unlock_irqrestore(&pcpu_lock, flags);
++
++ if (need_balance)
++ pcpu_schedule_balance_work();
+ }
+ EXPORT_SYMBOL_GPL(free_percpu);
+
+--
+2.20.1
+
--- /dev/null
+From c35afa09949a596a06aba156d67afe720444cdd4 Mon Sep 17 00:00:00 2001
+From: Stephane Eranian <eranian@google.com>
+Date: Mon, 13 May 2019 17:34:00 -0700
+Subject: perf/x86/intel: Allow PEBS multi-entry in watermark mode
+
+[ Upstream commit c7a286577d7592720c2f179aadfb325a1ff48c95 ]
+
+This patch fixes a restriction/bug introduced by:
+
+ 583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS")
+
+The original patch prevented using multi-entry PEBS when wakeup_events != 0.
+However given that wakeup_events is part of a union with wakeup_watermark, it
+means that in watermark mode, PEBS multi-entry is also disabled which is not the
+intent. This patch fixes this by checking is watermark mode is enabled.
+
+Signed-off-by: Stephane Eranian <eranian@google.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: jolsa@redhat.com
+Cc: kan.liang@intel.com
+Cc: vincent.weaver@maine.edu
+Fixes: 583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS")
+Link: http://lkml.kernel.org/r/20190514003400.224340-1-eranian@google.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/events/intel/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
+index 09c53bcbd497..c8b0bf2b0d5e 100644
+--- a/arch/x86/events/intel/core.c
++++ b/arch/x86/events/intel/core.c
+@@ -3072,7 +3072,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_large_pebs_flags(event)))
+--
+2.20.1
+
--- /dev/null
+From 46cb12e7892f73be3038993da8cd9419c8284a6a Mon Sep 17 00:00:00 2001
+From: Enrico Granata <egranata@chromium.org>
+Date: Wed, 3 Apr 2019 15:40:36 -0700
+Subject: platform/chrome: cros_ec_proto: check for NULL transfer function
+
+[ Upstream commit 94d4e7af14a1170e34cf082d92e4c02de9e9fb88 ]
+
+As new transfer mechanisms are added to the EC codebase, they may
+not support v2 of the EC protocol.
+
+If the v3 initial handshake transfer fails, the kernel will try
+and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
+will be NULL, and the code will end up causing a kernel panic.
+
+Add a check for NULL before calling the transfer function, along
+with a helpful comment explaining how one might end up in this
+situation.
+
+Signed-off-by: Enrico Granata <egranata@chromium.org>
+Reviewed-by: Jett Rink <jettrink@chromium.org>
+Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/platform/chrome/cros_ec_proto.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
+index e5d5b1adb5a9..ac784ac66ac3 100644
+--- a/drivers/platform/chrome/cros_ec_proto.c
++++ b/drivers/platform/chrome/cros_ec_proto.c
+@@ -67,6 +67,17 @@ static int send_command(struct cros_ec_device *ec_dev,
+ else
+ xfer_fxn = ec_dev->cmd_xfer;
+
++ if (!xfer_fxn) {
++ /*
++ * This error can happen if a communication error happened and
++ * the EC is trying to use protocol v2, on an underlying
++ * communication mechanism that does not support v2.
++ */
++ dev_err_once(ec_dev->dev,
++ "missing EC transfer API, cannot send command\n");
++ return -EIO;
++ }
++
+ ret = (*xfer_fxn)(ec_dev, msg);
+ if (msg->result == EC_RES_IN_PROGRESS) {
+ int i;
+--
+2.20.1
+
--- /dev/null
+From 5bb45ab51e910732a857d41fc5eeba77f50eb769 Mon Sep 17 00:00:00 2001
+From: Junxiao Chang <junxiao.chang@intel.com>
+Date: Mon, 8 Apr 2019 17:40:22 +0800
+Subject: platform/x86: intel_pmc_ipc: adding error handling
+
+[ Upstream commit e61985d0550df8c2078310202aaad9b41049c36c ]
+
+If punit or telemetry device initialization fails, pmc driver should
+unregister and return failure.
+
+This change is to fix a kernel panic when removing kernel module
+intel_pmc_ipc.
+
+Fixes: 48c1917088ba ("platform:x86: Add Intel telemetry platform device")
+Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/platform/x86/intel_pmc_ipc.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/platform/x86/intel_pmc_ipc.c b/drivers/platform/x86/intel_pmc_ipc.c
+index e7edc8c63936..4ad9d127f2f5 100644
+--- a/drivers/platform/x86/intel_pmc_ipc.c
++++ b/drivers/platform/x86/intel_pmc_ipc.c
+@@ -776,13 +776,17 @@ static int ipc_create_pmc_devices(void)
+ if (ret) {
+ dev_err(ipcdev.dev, "Failed to add punit platform device\n");
+ platform_device_unregister(ipcdev.tco_dev);
++ return ret;
+ }
+
+ if (!ipcdev.telem_res_inval) {
+ ret = ipc_create_telemetry_device();
+- if (ret)
++ if (ret) {
+ dev_warn(ipcdev.dev,
+ "Failed to add telemetry platform device\n");
++ platform_device_unregister(ipcdev.punit_dev);
++ platform_device_unregister(ipcdev.tco_dev);
++ }
+ }
+
+ return ret;
+--
+2.20.1
+
--- /dev/null
+From 4a5cb29f2da115202f9a4415e1f46126cd96ba50 Mon Sep 17 00:00:00 2001
+From: Sven Van Asbroeck <thesven73@gmail.com>
+Date: Fri, 15 Feb 2019 16:43:02 -0500
+Subject: power: supply: max14656: fix potential use-before-alloc
+
+[ Upstream commit 0cd0e49711556d2331a06b1117b68dd786cb54d2 ]
+
+Call order on probe():
+- max14656_hw_init() enables interrupts on the chip
+- devm_request_irq() starts processing interrupts, isr
+ could be called immediately
+- isr: schedules delayed work (irq_work)
+- irq_work: calls power_supply_changed()
+- devm_power_supply_register() registers the power supply
+
+Depending on timing, it's possible that power_supply_changed()
+is called on an unregistered power supply structure.
+
+Fix by registering the power supply before requesting the irq.
+
+Cc: Alexander Kurz <akurz@blala.de>
+Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/power/supply/max14656_charger_detector.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/power/supply/max14656_charger_detector.c b/drivers/power/supply/max14656_charger_detector.c
+index b91b1d2999dc..d19307f791c6 100644
+--- a/drivers/power/supply/max14656_charger_detector.c
++++ b/drivers/power/supply/max14656_charger_detector.c
+@@ -280,6 +280,13 @@ static int max14656_probe(struct i2c_client *client,
+
+ INIT_DELAYED_WORK(&chip->irq_work, max14656_irq_worker);
+
++ chip->detect_psy = devm_power_supply_register(dev,
++ &chip->psy_desc, &psy_cfg);
++ if (IS_ERR(chip->detect_psy)) {
++ dev_err(dev, "power_supply_register failed\n");
++ return -EINVAL;
++ }
++
+ ret = devm_request_irq(dev, chip->irq, max14656_irq,
+ IRQF_TRIGGER_FALLING,
+ MAX14656_NAME, chip);
+@@ -289,13 +296,6 @@ static int max14656_probe(struct i2c_client *client,
+ }
+ enable_irq_wake(chip->irq);
+
+- chip->detect_psy = devm_power_supply_register(dev,
+- &chip->psy_desc, &psy_cfg);
+- if (IS_ERR(chip->detect_psy)) {
+- dev_err(dev, "power_supply_register failed\n");
+- return -EINVAL;
+- }
+-
+ schedule_delayed_work(&chip->irq_work, msecs_to_jiffies(2000));
+
+ return 0;
+--
+2.20.1
+
--- /dev/null
+From 692b6ebfa014c12f2778326d3613a70f388b9bf6 Mon Sep 17 00:00:00 2001
+From: Phong Hoang <phong.hoang.wz@renesas.com>
+Date: Tue, 19 Mar 2019 19:40:08 +0900
+Subject: pwm: Fix deadlock warning when removing PWM device
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 347ab9480313737c0f1aaa08e8f2e1a791235535 ]
+
+This patch fixes deadlock warning if removing PWM device
+when CONFIG_PROVE_LOCKING is enabled.
+
+This issue can be reproceduced by the following steps on
+the R-Car H3 Salvator-X board if the backlight is disabled:
+
+ # cd /sys/class/pwm/pwmchip0
+ # echo 0 > export
+ # ls
+ device export npwm power pwm0 subsystem uevent unexport
+ # cd device/driver
+ # ls
+ bind e6e31000.pwm uevent unbind
+ # echo e6e31000.pwm > unbind
+
+[ 87.659974] ======================================================
+[ 87.666149] WARNING: possible circular locking dependency detected
+[ 87.672327] 5.0.0 #7 Not tainted
+[ 87.675549] ------------------------------------------------------
+[ 87.681723] bash/2986 is trying to acquire lock:
+[ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
+[ 87.694528]
+[ 87.694528] but task is already holding lock:
+[ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
+[ 87.707405]
+[ 87.707405] which lock already depends on the new lock.
+[ 87.707405]
+[ 87.715574]
+[ 87.715574] the existing dependency chain (in reverse order) is:
+[ 87.723048]
+[ 87.723048] -> #1 (pwm_lock){+.+.}:
+[ 87.728017] __mutex_lock+0x70/0x7e4
+[ 87.732108] mutex_lock_nested+0x1c/0x24
+[ 87.736547] pwm_request_from_chip.part.6+0x34/0x74
+[ 87.741940] pwm_request_from_chip+0x20/0x40
+[ 87.746725] export_store+0x6c/0x1f4
+[ 87.750820] dev_attr_store+0x18/0x28
+[ 87.754998] sysfs_kf_write+0x54/0x64
+[ 87.759175] kernfs_fop_write+0xe4/0x1e8
+[ 87.763615] __vfs_write+0x40/0x184
+[ 87.767619] vfs_write+0xa8/0x19c
+[ 87.771448] ksys_write+0x58/0xbc
+[ 87.775278] __arm64_sys_write+0x18/0x20
+[ 87.779721] el0_svc_common+0xd0/0x124
+[ 87.783986] el0_svc_compat_handler+0x1c/0x24
+[ 87.788858] el0_svc_compat+0x8/0x18
+[ 87.792947]
+[ 87.792947] -> #0 (kn->count#58){++++}:
+[ 87.798260] lock_acquire+0xc4/0x22c
+[ 87.802353] __kernfs_remove+0x258/0x2c4
+[ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0
+[ 87.811836] remove_files.isra.1+0x38/0x78
+[ 87.816447] sysfs_remove_group+0x48/0x98
+[ 87.820971] sysfs_remove_groups+0x34/0x4c
+[ 87.825583] device_remove_attrs+0x6c/0x7c
+[ 87.830197] device_del+0x11c/0x33c
+[ 87.834201] device_unregister+0x14/0x2c
+[ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c
+[ 87.843509] pwmchip_remove+0xf4/0x13c
+[ 87.847773] rcar_pwm_remove+0x28/0x34
+[ 87.852039] platform_drv_remove+0x24/0x64
+[ 87.856651] device_release_driver_internal+0x18c/0x21c
+[ 87.862391] device_release_driver+0x14/0x1c
+[ 87.867175] unbind_store+0xe0/0x124
+[ 87.871265] drv_attr_store+0x20/0x30
+[ 87.875442] sysfs_kf_write+0x54/0x64
+[ 87.879618] kernfs_fop_write+0xe4/0x1e8
+[ 87.884055] __vfs_write+0x40/0x184
+[ 87.888057] vfs_write+0xa8/0x19c
+[ 87.891887] ksys_write+0x58/0xbc
+[ 87.895716] __arm64_sys_write+0x18/0x20
+[ 87.900154] el0_svc_common+0xd0/0x124
+[ 87.904417] el0_svc_compat_handler+0x1c/0x24
+[ 87.909289] el0_svc_compat+0x8/0x18
+[ 87.913378]
+[ 87.913378] other info that might help us debug this:
+[ 87.913378]
+[ 87.921374] Possible unsafe locking scenario:
+[ 87.921374]
+[ 87.927286] CPU0 CPU1
+[ 87.931808] ---- ----
+[ 87.936331] lock(pwm_lock);
+[ 87.939293] lock(kn->count#58);
+[ 87.945120] lock(pwm_lock);
+[ 87.950599] lock(kn->count#58);
+[ 87.953908]
+[ 87.953908] *** DEADLOCK ***
+[ 87.953908]
+[ 87.959821] 4 locks held by bash/2986:
+[ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
+[ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
+[ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
+[ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
+[ 87.995481]
+[ 87.995481] stack backtrace:
+[ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
+[ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
+[ 88.012791] Call trace:
+[ 88.015235] dump_backtrace+0x0/0x190
+[ 88.018891] show_stack+0x14/0x1c
+[ 88.022204] dump_stack+0xb0/0xec
+[ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0
+[ 88.030385] __lock_acquire+0x1318/0x1864
+[ 88.034388] lock_acquire+0xc4/0x22c
+[ 88.037958] __kernfs_remove+0x258/0x2c4
+[ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0
+[ 88.046398] remove_files.isra.1+0x38/0x78
+[ 88.050487] sysfs_remove_group+0x48/0x98
+[ 88.054490] sysfs_remove_groups+0x34/0x4c
+[ 88.058580] device_remove_attrs+0x6c/0x7c
+[ 88.062671] device_del+0x11c/0x33c
+[ 88.066154] device_unregister+0x14/0x2c
+[ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c
+[ 88.074421] pwmchip_remove+0xf4/0x13c
+[ 88.078163] rcar_pwm_remove+0x28/0x34
+[ 88.081906] platform_drv_remove+0x24/0x64
+[ 88.085996] device_release_driver_internal+0x18c/0x21c
+[ 88.091215] device_release_driver+0x14/0x1c
+[ 88.095478] unbind_store+0xe0/0x124
+[ 88.099048] drv_attr_store+0x20/0x30
+[ 88.102704] sysfs_kf_write+0x54/0x64
+[ 88.106359] kernfs_fop_write+0xe4/0x1e8
+[ 88.110275] __vfs_write+0x40/0x184
+[ 88.113757] vfs_write+0xa8/0x19c
+[ 88.117065] ksys_write+0x58/0xbc
+[ 88.120374] __arm64_sys_write+0x18/0x20
+[ 88.124291] el0_svc_common+0xd0/0x124
+[ 88.128034] el0_svc_compat_handler+0x1c/0x24
+[ 88.132384] el0_svc_compat+0x8/0x18
+
+The sysfs unexport in pwmchip_remove() is completely asymmetric
+to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9
+("pwm: Unexport children before chip removal") is a strong indication
+that this was wrong to begin with. We should just move
+pwmchip_sysfs_unexport() where it belongs, which is right after
+pwmchip_sysfs_unexport_children(). In that case, we do not need
+separate functions anymore either.
+
+We also really want to remove sysfs irrespective of whether or not
+the chip will be removed as a result of pwmchip_remove(). We can only
+assume that the driver will be gone after that, so we shouldn't leave
+any dangling sysfs files around.
+
+This warning disappears if we move pwmchip_sysfs_unexport() to
+the top of pwmchip_remove(), pwmchip_sysfs_unexport_children().
+That way it is also outside of the pwm_lock section, which indeed
+doesn't seem to be needed.
+
+Moving the pwmchip_sysfs_export() call outside of that section also
+seems fine and it'd be perfectly symmetric with pwmchip_remove() again.
+
+So, this patch fixes them.
+
+Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
+[shimoda: revise the commit log and code]
+Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
+Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal")
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Tested-by: Hoan Nguyen An <na-hoan@jinso.co.jp>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pwm/core.c | 10 +++++-----
+ drivers/pwm/sysfs.c | 14 +-------------
+ include/linux/pwm.h | 5 -----
+ 3 files changed, 6 insertions(+), 23 deletions(-)
+
+diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
+index 1581f6ab1b1f..c45e5719ba17 100644
+--- a/drivers/pwm/core.c
++++ b/drivers/pwm/core.c
+@@ -311,10 +311,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);
+@@ -348,7 +350,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);
+
+@@ -368,8 +370,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 7c71cdb8a9d8..1c64fd8e9234 100644
+--- a/drivers/pwm/sysfs.c
++++ b/drivers/pwm/sysfs.c
+@@ -399,19 +399,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;
+@@ -429,6 +416,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 56518adc31dd..bd7d611d63e9 100644
+--- a/include/linux/pwm.h
++++ b/include/linux/pwm.h
+@@ -639,7 +639,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)
+ {
+@@ -648,10 +647,6 @@ static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
+ static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
+ {
+ }
+-
+-static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+-{
+-}
+ #endif /* CONFIG_PWM_SYSFS */
+
+ #endif /* __LINUX_PWM_H */
+--
+2.20.1
+
--- /dev/null
+From aac4c49cf718182439225690a841d6a706aa8c1b Mon Sep 17 00:00:00 2001
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Date: Mon, 1 Apr 2019 19:57:48 +0200
+Subject: pwm: meson: Use the spin-lock only to protect register modifications
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit f173747fffdf037c791405ab4f1ec0eb392fc48e ]
+
+Holding the spin-lock for all of the code in meson_pwm_apply() can
+result in a "BUG: scheduling while atomic". This can happen because
+clk_get_rate() (which is called from meson_pwm_calc()) may sleep.
+Only hold the spin-lock when modifying registers to solve this.
+
+The reason why we need a spin-lock in the driver is because the
+REG_MISC_AB register is shared between the two channels provided by one
+PWM controller. The only functions where REG_MISC_AB is modified are
+meson_pwm_enable() and meson_pwm_disable() so the register reads/writes
+in there need to be protected by the spin-lock.
+
+The original code also used the spin-lock to protect the values in
+struct meson_pwm_channel. This could be necessary if two consumers can
+use the same PWM channel. However, PWM core doesn't allow this so we
+don't need to protect the values in struct meson_pwm_channel with a
+lock.
+
+Fixes: 211ed630753d2f ("pwm: Add support for Meson PWM Controller")
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pwm/pwm-meson.c | 25 +++++++++++++++++--------
+ 1 file changed, 17 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
+index c1ed641b3e26..f6e738ad7bd9 100644
+--- a/drivers/pwm/pwm-meson.c
++++ b/drivers/pwm/pwm-meson.c
+@@ -111,6 +111,10 @@ struct meson_pwm {
+ const struct meson_pwm_data *data;
+ void __iomem *base;
+ u8 inverter_mask;
++ /*
++ * Protects register (write) access to the REG_MISC_AB register
++ * that is shared between the two PWMs.
++ */
+ spinlock_t lock;
+ };
+
+@@ -235,6 +239,7 @@ static void meson_pwm_enable(struct meson_pwm *meson,
+ {
+ u32 value, clk_shift, clk_enable, enable;
+ unsigned int offset;
++ unsigned long flags;
+
+ switch (id) {
+ case 0:
+@@ -255,6 +260,8 @@ static void meson_pwm_enable(struct meson_pwm *meson,
+ return;
+ }
+
++ spin_lock_irqsave(&meson->lock, flags);
++
+ value = readl(meson->base + REG_MISC_AB);
+ value &= ~(MISC_CLK_DIV_MASK << clk_shift);
+ value |= channel->pre_div << clk_shift;
+@@ -267,11 +274,14 @@ static void meson_pwm_enable(struct meson_pwm *meson,
+ value = readl(meson->base + REG_MISC_AB);
+ value |= enable;
+ writel(value, meson->base + REG_MISC_AB);
++
++ spin_unlock_irqrestore(&meson->lock, flags);
+ }
+
+ static void meson_pwm_disable(struct meson_pwm *meson, unsigned int id)
+ {
+ u32 value, enable;
++ unsigned long flags;
+
+ switch (id) {
+ case 0:
+@@ -286,9 +296,13 @@ static void meson_pwm_disable(struct meson_pwm *meson, unsigned int id)
+ return;
+ }
+
++ spin_lock_irqsave(&meson->lock, flags);
++
+ value = readl(meson->base + REG_MISC_AB);
+ value &= ~enable;
+ writel(value, meson->base + REG_MISC_AB);
++
++ spin_unlock_irqrestore(&meson->lock, flags);
+ }
+
+ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+@@ -296,19 +310,16 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ {
+ struct meson_pwm_channel *channel = pwm_get_chip_data(pwm);
+ struct meson_pwm *meson = to_meson_pwm(chip);
+- unsigned long flags;
+ int err = 0;
+
+ if (!state)
+ return -EINVAL;
+
+- spin_lock_irqsave(&meson->lock, flags);
+-
+ if (!state->enabled) {
+ meson_pwm_disable(meson, pwm->hwpwm);
+ channel->state.enabled = false;
+
+- goto unlock;
++ return 0;
+ }
+
+ if (state->period != channel->state.period ||
+@@ -329,7 +340,7 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ err = meson_pwm_calc(meson, channel, pwm->hwpwm,
+ state->duty_cycle, state->period);
+ if (err < 0)
+- goto unlock;
++ return err;
+
+ channel->state.polarity = state->polarity;
+ channel->state.period = state->period;
+@@ -341,9 +352,7 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ channel->state.enabled = true;
+ }
+
+-unlock:
+- spin_unlock_irqrestore(&meson->lock, flags);
+- return err;
++ return 0;
+ }
+
+ static void meson_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+--
+2.20.1
+
--- /dev/null
+From 4b1d35dfc0f31ae08c76a767dcc3aeb2e2365f11 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christoph=20Vogtl=C3=A4nder?=
+ <c.vogtlaender@sigma-surface-science.com>
+Date: Tue, 12 Mar 2019 14:38:46 +0530
+Subject: pwm: tiehrpwm: Update shadow register for disabling PWMs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit b00ef53053191d3025c15e8041699f8c9d132daf ]
+
+It must be made sure that immediate mode is not already set, when
+modifying shadow register value in ehrpwm_pwm_disable(). Otherwise
+modifications to the action-qualifier continuous S/W force
+register(AQSFRC) will be done in the active register.
+This may happen when both channels are being disabled. In this case,
+only the first channel state will be recorded as disabled in the shadow
+register. Later, when enabling the first channel again, the second
+channel would be enabled as well. Setting RLDCSF to zero, first, ensures
+that the shadow register is updated as desired.
+
+Fixes: 38dabd91ff0b ("pwm: tiehrpwm: Fix disabling of output of PWMs")
+Signed-off-by: Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com>
+[vigneshr@ti.com: Improve commit message]
+Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pwm/pwm-tiehrpwm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
+index f7b8a86fa5c5..ad4a40c0f27c 100644
+--- a/drivers/pwm/pwm-tiehrpwm.c
++++ b/drivers/pwm/pwm-tiehrpwm.c
+@@ -382,6 +382,8 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+ }
+
+ /* Update shadow register first before modifying active register */
++ ehrpwm_modify(pc->mmio_base, AQSFRC, AQSFRC_RLDCSF_MASK,
++ AQSFRC_RLDCSF_ZRO);
+ ehrpwm_modify(pc->mmio_base, AQCSFRC, aqcsfrc_mask, aqcsfrc_val);
+ /*
+ * Changes to immediate action on Action Qualifier. This puts
+--
+2.20.1
+
--- /dev/null
+From f812d32c795606d8bb3db2d10f98b182ea08239f Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Tue, 14 May 2019 15:44:49 -0700
+Subject: rapidio: fix a NULL pointer dereference when create_workqueue() fails
+
+[ Upstream commit 23015b22e47c5409620b1726a677d69e5cd032ba ]
+
+In case create_workqueue fails, the fix releases resources and returns
+-ENOMEM to avoid NULL pointer dereference.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Acked-by: Alexandre Bounine <alex.bou9@gmail.com>
+Cc: Matt Porter <mporter@kernel.crashing.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/rapidio/rio_cm.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
+index bad0e0ea4f30..ef989a15aefc 100644
+--- a/drivers/rapidio/rio_cm.c
++++ b/drivers/rapidio/rio_cm.c
+@@ -2145,6 +2145,14 @@ static int riocm_add_mport(struct device *dev,
+ mutex_init(&cm->rx_lock);
+ riocm_rx_fill(cm, RIOCM_RX_RING_SIZE);
+ cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
++ if (!cm->rx_wq) {
++ riocm_error("failed to allocate IBMBOX_%d on %s",
++ cmbox, mport->name);
++ rio_release_outb_mbox(mport, cmbox);
++ kfree(cm);
++ return -ENOMEM;
++ }
++
+ INIT_WORK(&cm->rx_work, rio_ibmsg_handler);
+
+ cm->tx_slot = 0;
+--
+2.20.1
+
--- /dev/null
+From 11f22679c0220753d426a333182bb677b3376252 Mon Sep 17 00:00:00 2001
+From: Giridhar Malavali <gmalavali@marvell.com>
+Date: Tue, 2 Apr 2019 14:24:22 -0700
+Subject: scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags
+
+[ Upstream commit 0257eda08e806b82ee1fc90ef73583b6f022845c ]
+
+Driver maintains state machine for processing and completing switch
+commands. This patch resets FCF_ASYNC_{SENT|ACTIVE} flag to indicate if the
+previous command is active or sent, in order for next GPSC command to
+advance the state machine.
+
+[mkp: commit desc typo]
+
+Signed-off-by: Giridhar Malavali <gmalavali@marvell.com>
+Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/qla2xxx/qla_gs.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c
+index de3f2a097451..1f1a05a90d3d 100644
+--- a/drivers/scsi/qla2xxx/qla_gs.c
++++ b/drivers/scsi/qla2xxx/qla_gs.c
+@@ -3261,6 +3261,8 @@ static void qla24xx_async_gpsc_sp_done(void *s, int res)
+ "Async done-%s res %x, WWPN %8phC \n",
+ sp->name, res, fcport->port_name);
+
++ fcport->flags &= ~(FCF_ASYNC_SENT | FCF_ASYNC_ACTIVE);
++
+ if (res == QLA_FUNCTION_TIMEOUT)
+ return;
+
+@@ -4604,6 +4606,7 @@ int qla24xx_async_gnnid(scsi_qla_host_t *vha, fc_port_t *fcport)
+
+ done_free_sp:
+ sp->free(sp);
++ fcport->flags &= ~FCF_ASYNC_SENT;
+ done:
+ return rval;
+ }
+--
+2.20.1
+
--- /dev/null
+rapidio-fix-a-null-pointer-dereference-when-create_w.patch
+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
+drm-pl111-initialize-clock-spinlock-early.patch
+arm-prevent-tracing-ipi_cpu_backtrace.patch
+mm-hmm-select-mmu-notifier-when-selecting-hmm.patch
+hugetlbfs-on-restore-reserve-error-path-retain-subpo.patch
+mem-hotplug-fix-node-spanned-pages-when-we-have-a-no.patch
+mm-cma.c-fix-crash-on-cma-allocation-if-bitmap-alloc.patch
+initramfs-free-initrd-memory-if-opening-initrd.image.patch
+mm-cma.c-fix-the-bitmap-status-to-show-failed-alloca.patch
+mm-page_mkclean-vs-madv_dontneed-race.patch
+mm-cma_debug.c-fix-the-break-condition-in-cma_maxchu.patch
+mm-slab.c-fix-an-infinite-loop-in-leaks_show.patch
+kernel-sys.c-prctl-fix-false-positive-in-validate_pr.patch
+thermal-rcar_gen3_thermal-disable-interrupt-in-.remo.patch
+drivers-thermal-tsens-don-t-print-error-message-on-e.patch
+mfd-tps65912-spi-add-missing-of-table-registration.patch
+mfd-intel-lpss-set-the-device-in-reset-state-when-in.patch
+drm-nouveau-disp-dp-respect-sink-limits-when-selecti.patch
+mfd-twl6040-fix-device-init-errors-for-accctl-regist.patch
+perf-x86-intel-allow-pebs-multi-entry-in-watermark-m.patch
+drm-nouveau-kms-gf119-gp10x-push-headsetcontroloutpu.patch
+drm-bridge-adv7511-fix-low-refresh-rate-selection.patch
+objtool-don-t-use-ignore-flag-for-fake-jumps.patch
+drm-nouveau-kms-gv100-fix-spurious-window-immediate-.patch
+bpf-fix-undefined-behavior-in-narrow-load-handling.patch
+edac-mpc85xx-prevent-building-as-a-module.patch
+pwm-meson-use-the-spin-lock-only-to-protect-register.patch
+mailbox-stm32-ipcc-check-invalid-irq.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-avoid-panic-in-f2fs_inplace_write_data.patch
+f2fs-fix-to-avoid-panic-in-f2fs_remove_inode_page.patch
+f2fs-fix-to-do-sanity-check-on-free-nid.patch
+f2fs-fix-to-clear-dirty-inode-in-error-path-of-f2fs_.patch
+f2fs-fix-to-avoid-panic-in-dec_valid_block_count.patch
+f2fs-fix-to-use-inline-space-only-if-inline_xattr-is.patch
+f2fs-fix-to-do-sanity-check-on-valid-block-count-of-.patch
+f2fs-fix-to-do-checksum-even-if-inode-page-is-uptoda.patch
+percpu-remove-spurious-lock-dependency-between-percp.patch
+configfs-fix-possible-use-after-free-in-configfs_reg.patch
+uml-fix-a-boot-splat-wrt-use-of-cpu_all_mask.patch
+pci-dwc-free-msi-in-dw_pcie_host_init-error-path.patch
+pci-dwc-free-msi-irq-page-in-dw_pcie_free_msi.patch
+ovl-do-not-generate-duplicate-fsnotify-events-for-fa.patch
+mmc-mmci-prevent-polling-for-busy-detection-in-irq-c.patch
+netfilter-nf_flow_table-fix-missing-error-check-for-.patch
+netfilter-nf_conntrack_h323-restore-boundary-check-c.patch
+mips-make-sure-dt-memory-regions-are-valid.patch
+netfilter-nf_tables-fix-base-chain-stat-rcu_derefere.patch
+watchdog-use-depends-instead-of-select-for-pretimeou.patch
+watchdog-imx2_wdt-fix-set_timeout-for-big-timeout-va.patch
+watchdog-fix-compile-time-error-of-pretimeout-govern.patch
+blk-mq-move-cancel-of-requeue_work-into-blk_mq_relea.patch
+iommu-vt-d-set-intel_iommu_gfx_mapped-correctly.patch
+misc-pci_endpoint_test-fix-test_reg_bar-to-be-update.patch
+pci-designware-ep-use-aligned-atu-window-for-raising.patch
+nvme-pci-unquiesce-admin-queue-on-shutdown.patch
+nvme-pci-shutdown-on-timeout-during-deletion.patch
+netfilter-nf_flow_table-check-ttl-value-in-flow-offl.patch
+netfilter-nf_flow_table-fix-netdev-refcnt-leak.patch
+alsa-hda-register-irq-handler-after-the-chip-initial.patch
+nvmem-core-fix-read-buffer-in-place.patch
+nvmem-sunxi_sid-support-sid-on-a83t-and-h5.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
+nfsd-avoid-uninitialized-variable-warning.patch
+vfio-fix-warning-do-not-call-blocking-ops-when-task_.patch
+iommu-arm-smmu-v3-don-t-disable-smmu-in-kdump-kernel.patch
+switchtec-fix-unintended-mask-of-mrpc-event.patch
+net-thunderbolt-unregister-thunderboltip-protocol-ha.patch
+x86-pci-fix-pci-irq-routing-table-memory-leak.patch
+i40e-queues-are-reserved-despite-invalid-argument-er.patch
+platform-chrome-cros_ec_proto-check-for-null-transfe.patch
+pci-keystone-prevent-arm32-specific-code-to-be-compi.patch
+soc-mediatek-pwrap-zero-initialize-rdata-in-pwrap_in.patch
+clk-rockchip-turn-on-aclk_dmac1-for-suspend-on-rk328.patch
+soc-rockchip-set-the-proper-pwm-for-rk3288.patch
+arm-dts-imx51-specify-imx5_clk_ipg-as-ahb-clock-to-s.patch
+arm-dts-imx50-specify-imx5_clk_ipg-as-ahb-clock-to-s.patch
+arm-dts-imx53-specify-imx5_clk_ipg-as-ahb-clock-to-s.patch
+arm-dts-imx6sx-specify-imx6sx_clk_ipg-as-ahb-clock-t.patch
+arm-dts-imx6sll-specify-imx6sll_clk_ipg-as-ipg-clock.patch
+arm-dts-imx7d-specify-imx7d_clk_ipg-as-ipg-clock-to-.patch
+arm-dts-imx6ul-specify-imx6ul_clk_ipg-as-ipg-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
+drm-amd-display-use-plane-color_space-for-dpp-if-spe.patch
+alsa-seq-protect-in-kernel-ioctl-calls-with-mutex.patch
+arm-omap2-pm33xx-core-do-not-turn-off-cefuse-as-ppa-.patch
+platform-x86-intel_pmc_ipc-adding-error-handling.patch
+power-supply-max14656-fix-potential-use-before-alloc.patch
+net-hns3-return-0-and-print-warning-when-hit-duplica.patch
+pci-rcar-fix-a-potential-null-pointer-dereference.patch
+pci-rcar-fix-64bit-msi-message-address-handling.patch
+scsi-qla2xxx-reset-the-fcf_async_-sent-active-flags.patch
+video-hgafb-fix-potential-null-pointer-dereference.patch
+video-imsttfb-fix-potential-null-pointer-dereference.patch
+block-bfq-increase-idling-for-weight-raised-queues.patch
+pci-xilinx-check-for-__get_free_pages-failure.patch
+gpio-gpio-omap-add-check-for-off-wake-capable-gpios.patch
+ice-add-missing-case-in-print_link_msg-for-printing-.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
+usb-typec-fusb302-check-vconn-is-off-when-we-start-t.patch
+soc-renesas-identify-r-car-m3-w-es1.3.patch
+gpio-vf610-do-not-share-irq_chip.patch
+percpu-do-not-search-past-bitmap-when-allocating-an-.patch
--- /dev/null
+From d828984393790686602bd1d16e73a5a05772480f Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Thu, 7 Mar 2019 15:56:51 -0700
+Subject: soc: mediatek: pwrap: Zero initialize rdata in pwrap_init_cipher
+
+[ Upstream commit 89e28da82836530f1ac7a3a32fecc31f22d79b3e ]
+
+When building with -Wsometimes-uninitialized, Clang warns:
+
+drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is
+used uninitialized whenever '||' condition is true
+[-Werror,-Wsometimes-uninitialized]
+
+If pwrap_write returns non-zero, pwrap_read will not be called to
+initialize rdata, meaning that we will use some random uninitialized
+stack value in our print statement. Zero initialize rdata in case this
+happens.
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/401
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soc/mediatek/mtk-pmic-wrap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
+index 4e931fdf4d09..011a40b5fb49 100644
+--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
++++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
+@@ -1104,7 +1104,7 @@ static bool pwrap_is_pmic_cipher_ready(struct pmic_wrapper *wrp)
+ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
+ {
+ int ret;
+- u32 rdata;
++ u32 rdata = 0;
+
+ pwrap_writel(wrp, 0x1, PWRAP_CIPHER_SWRST);
+ pwrap_writel(wrp, 0x0, PWRAP_CIPHER_SWRST);
+--
+2.20.1
+
--- /dev/null
+From 131ceefa7bec6d10d29cf19194da0c655606b7be Mon Sep 17 00:00:00 2001
+From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
+Date: Thu, 28 Feb 2019 12:00:48 +0100
+Subject: soc: renesas: Identify R-Car M3-W ES1.3
+
+[ Upstream commit 15160f6de0bba712fcea078c5ac7571fe33fcd5d ]
+
+The Product Register of R-Car M3-W ES1.3 incorrectly identifies the SoC
+revision as ES2.1. Add a workaround to fix this.
+
+Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soc/renesas/renesas-soc.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
+index d44d0e687ab8..2a43d6e99962 100644
+--- a/drivers/soc/renesas/renesas-soc.c
++++ b/drivers/soc/renesas/renesas-soc.c
+@@ -285,6 +285,9 @@ static int __init renesas_soc_init(void)
+ /* R-Car M3-W ES1.1 incorrectly identifies as ES2.0 */
+ if ((product & 0x7fff) == 0x5210)
+ product ^= 0x11;
++ /* R-Car M3-W ES1.3 incorrectly identifies as ES2.1 */
++ if ((product & 0x7fff) == 0x5211)
++ product ^= 0x12;
+ if (soc->id && ((product >> 8) & 0xff) != soc->id) {
+ pr_warn("SoC mismatch (product = 0x%x)\n", product);
+ return -ENODEV;
+--
+2.20.1
+
--- /dev/null
+From 64cffee13379c02c1e0f90f30dda7a5b7d9c6606 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Tue, 9 Apr 2019 13:49:05 -0700
+Subject: soc: rockchip: Set the proper PWM for rk3288
+
+[ Upstream commit bbdc00a7de24cc90315b1775fb74841373fe12f7 ]
+
+The rk3288 SoC has two PWM implementations available, the "old"
+implementation and the "new" one. You can switch between the two of
+them by flipping a bit in the grf.
+
+The "old" implementation is the default at chip power up but isn't the
+one that's officially supposed to be used. ...and, in fact, the
+driver that gets selected in Linux using the rk3288 device tree only
+supports the "new" implementation.
+
+Long ago I tried to get a switch to the right IP block landed in the
+PWM driver (search for "rk3288: Switch to use the proper PWM IP") but
+that got rejected. In the mean time the grf has grown a full-fledged
+driver that already sets other random bits like this. That means we
+can now get the fix landed.
+
+For those wondering how things could have possibly worked for the last
+4.5 years, folks have mostly been relying on the bootloader to set
+this bit. ...but occasionally folks have pointed back to my old patch
+series [1] in downstream kernels.
+
+[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1391597.html
+
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soc/rockchip/grf.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
+index 96882ffde67e..3b81e1d75a97 100644
+--- a/drivers/soc/rockchip/grf.c
++++ b/drivers/soc/rockchip/grf.c
+@@ -66,9 +66,11 @@ static const struct rockchip_grf_info rk3228_grf __initconst = {
+ };
+
+ #define RK3288_GRF_SOC_CON0 0x244
++#define RK3288_GRF_SOC_CON2 0x24c
+
+ static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
+ { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12) },
++ { "pwm select", RK3288_GRF_SOC_CON2, HIWORD_UPDATE(1, 1, 0) },
+ };
+
+ static const struct rockchip_grf_info rk3288_grf __initconst = {
+--
+2.20.1
+
--- /dev/null
+From a570d8508f0185f83c40a03cdc23b2a12baecd97 Mon Sep 17 00:00:00 2001
+From: Wesley Sheng <wesley.sheng@microchip.com>
+Date: Mon, 15 Apr 2019 22:41:42 +0800
+Subject: switchtec: Fix unintended mask of MRPC event
+
+[ Upstream commit 083c1b5e50b701899dc32445efa8b153685260d5 ]
+
+When running application tool switchtec-user's `firmware update` and `event
+wait` commands concurrently, sometimes the firmware update speed reduced
+significantly.
+
+It is because when the MRPC event happened after MRPC event occurrence
+check but before the event mask loop reaches its header register in event
+ISR, the MRPC event would be masked unintentionally. Since there's no
+chance to enable it again except for a module reload, all the following
+MRPC execution completion checks time out.
+
+Fix this bug by skipping the mask operation for MRPC event in event ISR,
+same as what we already do for LINK event.
+
+Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
+Signed-off-by: Wesley Sheng <wesley.sheng@microchip.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/switch/switchtec.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
+index 37d0c15c9eeb..72db2e0ebced 100644
+--- a/drivers/pci/switch/switchtec.c
++++ b/drivers/pci/switch/switchtec.c
+@@ -1116,7 +1116,8 @@ static int mask_event(struct switchtec_dev *stdev, int eid, int idx)
+ if (!(hdr & SWITCHTEC_EVENT_OCCURRED && hdr & SWITCHTEC_EVENT_EN_IRQ))
+ return 0;
+
+- if (eid == SWITCHTEC_IOCTL_EVENT_LINK_STATE)
++ if (eid == SWITCHTEC_IOCTL_EVENT_LINK_STATE ||
++ eid == SWITCHTEC_IOCTL_EVENT_MRPC_COMP)
+ return 0;
+
+ dev_dbg(&stdev->dev, "%s: %d %d %x\n", __func__, eid, idx, hdr);
+--
+2.20.1
+
--- /dev/null
+From 0fc5c3a0471cd53747b2118c0652af40d03803a2 Mon Sep 17 00:00:00 2001
+From: Christian Brauner <christian@brauner.io>
+Date: Tue, 14 May 2019 15:44:55 -0700
+Subject: sysctl: return -EINVAL if val violates minmax
+
+[ Upstream commit e260ad01f0aa9e96b5386d5cd7184afd949dc457 ]
+
+Currently when userspace gives us a values that overflow e.g. file-max
+and other callers of __do_proc_doulongvec_minmax() we simply ignore the
+new value and leave the current value untouched.
+
+This can be problematic as it gives the illusion that the limit has
+indeed be bumped when in fact it failed. This commit makes sure to
+return EINVAL when an overflow is detected. Please note that this is a
+userspace facing change.
+
+Link: http://lkml.kernel.org/r/20190210203943.8227-4-christian@brauner.io
+Signed-off-by: Christian Brauner <christian@brauner.io>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Alexey Dobriyan <adobriyan@gmail.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Dominik Brodowski <linux@dominikbrodowski.net>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: Joe Lawrence <joe.lawrence@redhat.com>
+Cc: Waiman Long <longman@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sysctl.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/kernel/sysctl.c b/kernel/sysctl.c
+index 9a85c7ae7362..f8576509c7be 100644
+--- a/kernel/sysctl.c
++++ b/kernel/sysctl.c
+@@ -2791,8 +2791,10 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
+ if (neg)
+ continue;
+ val = convmul * val / convdiv;
+- if ((min && val < *min) || (max && val > *max))
+- continue;
++ if ((min && val < *min) || (max && val > *max)) {
++ err = -EINVAL;
++ break;
++ }
+ *i = val;
+ } else {
+ val = convdiv * (*i) / convmul;
+--
+2.20.1
+
--- /dev/null
+From acb10b0b025982c3c9283698a251d1c4414d9c3b Mon Sep 17 00:00:00 2001
+From: Jiada Wang <jiada_wang@mentor.com>
+Date: Wed, 24 Apr 2019 14:11:45 +0900
+Subject: thermal: rcar_gen3_thermal: disable interrupt in .remove
+
+[ Upstream commit 63f55fcea50c25ae5ad45af92d08dae3b84534c2 ]
+
+Currently IRQ remains enabled after .remove, later if device is probed,
+IRQ is requested before .thermal_init, this may cause IRQ function be
+called before device is initialized.
+
+this patch disables interrupt in .remove, to ensure irq function
+only be called after device is fully initialized.
+
+Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/thermal/rcar_gen3_thermal.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/thermal/rcar_gen3_thermal.c b/drivers/thermal/rcar_gen3_thermal.c
+index 7aed5337bdd3..704c8ad045bb 100644
+--- a/drivers/thermal/rcar_gen3_thermal.c
++++ b/drivers/thermal/rcar_gen3_thermal.c
+@@ -328,6 +328,9 @@ MODULE_DEVICE_TABLE(of, rcar_gen3_thermal_dt_ids);
+ static int rcar_gen3_thermal_remove(struct platform_device *pdev)
+ {
+ struct device *dev = &pdev->dev;
++ struct rcar_gen3_thermal_priv *priv = dev_get_drvdata(dev);
++
++ rcar_thermal_irq_set(priv, false);
+
+ pm_runtime_put(dev);
+ pm_runtime_disable(dev);
+--
+2.20.1
+
--- /dev/null
+From b13ad3c792ff791c3f557a1339475f6a30499b96 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Maciej=20=C5=BBenczykowski?= <maze@google.com>
+Date: Wed, 10 Apr 2019 11:11:23 -0700
+Subject: uml: fix a boot splat wrt use of cpu_all_mask
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 689a58605b63173acb0a8cf954af6a8f60440c93 ]
+
+Memory: 509108K/542612K available (3835K kernel code, 919K rwdata, 1028K rodata, 129K init, 211K bss, 33504K reserved, 0K cma-reserved)
+NR_IRQS: 15
+clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns
+------------[ cut here ]------------
+WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:458 clockevents_register_device+0x72/0x140
+posix-timer cpumask == cpu_all_mask, using cpu_possible_mask instead
+Modules linked in:
+CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-rc4-00048-ged79cc87302b #4
+Stack:
+ 604ebda0 603c5370 604ebe20 6046fd17
+ 00000000 6006fcbb 604ebdb0 603c53b5
+ 604ebe10 6003bfc4 604ebdd0 9000001ca
+Call Trace:
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<60083160>] ? clockevents_register_device+0x72/0x140
+ [<6001f16e>] show_stack+0x13b/0x155
+ [<603c5370>] ? dump_stack_print_info+0xe2/0xeb
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<603c53b5>] dump_stack+0x2a/0x2c
+ [<6003bfc4>] __warn+0x10e/0x13e
+ [<60070320>] ? vprintk_func+0xc8/0xcf
+ [<60030fd6>] ? block_signals+0x0/0x16
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<6003c08b>] warn_slowpath_fmt+0x97/0x99
+ [<600311a1>] ? set_signals+0x0/0x3f
+ [<6003bff4>] ? warn_slowpath_fmt+0x0/0x99
+ [<600842cb>] ? tick_oneshot_mode_active+0x44/0x4f
+ [<60030fd6>] ? block_signals+0x0/0x16
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<6007d2d5>] ? __clocksource_select+0x20/0x1b1
+ [<60030fd6>] ? block_signals+0x0/0x16
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<60083160>] clockevents_register_device+0x72/0x140
+ [<60031192>] ? get_signals+0x0/0xf
+ [<60030fd6>] ? block_signals+0x0/0x16
+ [<6006fcbb>] ? printk+0x0/0x94
+ [<60002eec>] um_timer_setup+0xc8/0xca
+ [<60001b59>] start_kernel+0x47f/0x57e
+ [<600035bc>] start_kernel_proc+0x49/0x4d
+ [<6006c483>] ? kmsg_dump_register+0x82/0x8a
+ [<6001de62>] new_thread_handler+0x81/0xb2
+ [<60003571>] ? kmsg_dumper_stdout_init+0x1a/0x1c
+ [<60020c75>] uml_finishsetup+0x54/0x59
+
+random: get_random_bytes called from init_oops_id+0x27/0x34 with crng_init=0
+---[ end trace 00173d0117a88acb ]---
+Calibrating delay loop... 6941.90 BogoMIPS (lpj=34709504)
+
+Signed-off-by: Maciej Żenczykowski <maze@google.com>
+Cc: Jeff Dike <jdike@addtoit.com>
+Cc: Richard Weinberger <richard@nod.at>
+Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
+Cc: linux-um@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/um/kernel/time.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
+index 052de4c8acb2..0c572a48158e 100644
+--- a/arch/um/kernel/time.c
++++ b/arch/um/kernel/time.c
+@@ -56,7 +56,7 @@ static int itimer_one_shot(struct clock_event_device *evt)
+ static struct clock_event_device timer_clockevent = {
+ .name = "posix-timer",
+ .rating = 250,
+- .cpumask = cpu_all_mask,
++ .cpumask = cpu_possible_mask,
+ .features = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+ .set_state_shutdown = itimer_shutdown,
+--
+2.20.1
+
--- /dev/null
+From 1d4129991375b6866ecb37a4d3ba3bff603ca5c3 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Mon, 11 Mar 2019 11:48:14 +0100
+Subject: usb: typec: fusb302: Check vconn is off when we start toggling
+
+[ Upstream commit 32a155b1a83d6659e2272e8e1eec199667b1897e ]
+
+The datasheet says the vconn MUST be off when we start toggling. The
+tcpm.c state-machine is responsible to make sure vconn is off, but lets
+add a WARN to catch any cases where vconn is not off for some reason.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/typec/fusb302/fusb302.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/usb/typec/fusb302/fusb302.c b/drivers/usb/typec/fusb302/fusb302.c
+index 82bed9810be6..62a0060d39d8 100644
+--- a/drivers/usb/typec/fusb302/fusb302.c
++++ b/drivers/usb/typec/fusb302/fusb302.c
+@@ -641,6 +641,8 @@ static int fusb302_set_toggling(struct fusb302_chip *chip,
+ return ret;
+ chip->intr_togdone = false;
+ } else {
++ /* Datasheet says vconn MUST be off when toggling */
++ WARN(chip->vconn_on, "Vconn is on during toggle start");
+ /* unmask TOGDONE interrupt */
+ ret = fusb302_i2c_clear_bits(chip, FUSB_REG_MASKA,
+ FUSB_REG_MASKA_TOGDONE);
+--
+2.20.1
+
--- /dev/null
+From fbfc05061c443e73e5ad8d08c6c5e7416f94ff04 Mon Sep 17 00:00:00 2001
+From: Farhan Ali <alifm@linux.ibm.com>
+Date: Wed, 3 Apr 2019 14:22:27 -0400
+Subject: vfio: Fix WARNING "do not call blocking ops when !TASK_RUNNING"
+
+[ Upstream commit 41be3e2618174fdf3361e49e64f2bf530f40c6b0 ]
+
+vfio_dev_present() which is the condition to
+wait_event_interruptible_timeout(), will call vfio_group_get_device
+and try to acquire the mutex group->device_lock.
+
+wait_event_interruptible_timeout() will set the state of the current
+task to TASK_INTERRUPTIBLE, before doing the condition check. This
+means that we will try to acquire the mutex while already in a
+sleeping state. The scheduler warns us by giving the following
+warning:
+
+[ 4050.264464] ------------[ cut here ]------------
+[ 4050.264508] do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000b33c00e2>] prepare_to_wait_event+0x14a/0x188
+[ 4050.264529] WARNING: CPU: 12 PID: 35924 at kernel/sched/core.c:6112 __might_sleep+0x76/0x90
+....
+
+ 4050.264756] Call Trace:
+[ 4050.264765] ([<000000000017bbaa>] __might_sleep+0x72/0x90)
+[ 4050.264774] [<0000000000b97edc>] __mutex_lock+0x44/0x8c0
+[ 4050.264782] [<0000000000b9878a>] mutex_lock_nested+0x32/0x40
+[ 4050.264793] [<000003ff800d7abe>] vfio_group_get_device+0x36/0xa8 [vfio]
+[ 4050.264803] [<000003ff800d87c0>] vfio_del_group_dev+0x238/0x378 [vfio]
+[ 4050.264813] [<000003ff8015f67c>] mdev_remove+0x3c/0x68 [mdev]
+[ 4050.264825] [<00000000008e01b0>] device_release_driver_internal+0x168/0x268
+[ 4050.264834] [<00000000008de692>] bus_remove_device+0x162/0x190
+[ 4050.264843] [<00000000008daf42>] device_del+0x1e2/0x368
+[ 4050.264851] [<00000000008db12c>] device_unregister+0x64/0x88
+[ 4050.264862] [<000003ff8015ed84>] mdev_device_remove+0xec/0x130 [mdev]
+[ 4050.264872] [<000003ff8015f074>] remove_store+0x6c/0xa8 [mdev]
+[ 4050.264881] [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8
+[ 4050.264890] [<00000000003c1530>] __vfs_write+0x38/0x1a8
+[ 4050.264899] [<00000000003c187c>] vfs_write+0xb4/0x198
+[ 4050.264908] [<00000000003c1af2>] ksys_write+0x5a/0xb0
+[ 4050.264916] [<0000000000b9e270>] system_call+0xdc/0x2d8
+[ 4050.264925] 4 locks held by sh/35924:
+[ 4050.264933] #0: 000000001ef90325 (sb_writers#4){.+.+}, at: vfs_write+0x9e/0x198
+[ 4050.264948] #1: 000000005c1ab0b3 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cc/0x1f8
+[ 4050.264963] #2: 0000000034831ab8 (kn->count#297){++++}, at: kernfs_remove_self+0x12e/0x150
+[ 4050.264979] #3: 00000000e152484f (&dev->mutex){....}, at: device_release_driver_internal+0x5c/0x268
+[ 4050.264993] Last Breaking-Event-Address:
+[ 4050.265002] [<000000000017bbaa>] __might_sleep+0x72/0x90
+[ 4050.265010] irq event stamp: 7039
+[ 4050.265020] hardirqs last enabled at (7047): [<00000000001cee7a>] console_unlock+0x6d2/0x740
+[ 4050.265029] hardirqs last disabled at (7054): [<00000000001ce87e>] console_unlock+0xd6/0x740
+[ 4050.265040] softirqs last enabled at (6416): [<0000000000b8fe26>] __udelay+0xb6/0x100
+[ 4050.265049] softirqs last disabled at (6415): [<0000000000b8fe06>] __udelay+0x96/0x100
+[ 4050.265057] ---[ end trace d04a07d39d99a9f9 ]---
+
+Let's fix this as described in the article
+https://lwn.net/Articles/628628/.
+
+Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
+[remove now redundant vfio_dev_present()]
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/vfio/vfio.c | 30 ++++++++++--------------------
+ 1 file changed, 10 insertions(+), 20 deletions(-)
+
+diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
+index 64833879f75d..7a386fb30bf1 100644
+--- a/drivers/vfio/vfio.c
++++ b/drivers/vfio/vfio.c
+@@ -34,6 +34,7 @@
+ #include <linux/uaccess.h>
+ #include <linux/vfio.h>
+ #include <linux/wait.h>
++#include <linux/sched/signal.h>
+
+ #define DRIVER_VERSION "0.3"
+ #define DRIVER_AUTHOR "Alex Williamson <alex.williamson@redhat.com>"
+@@ -904,30 +905,17 @@ void *vfio_device_data(struct vfio_device *device)
+ }
+ EXPORT_SYMBOL_GPL(vfio_device_data);
+
+-/* Given a referenced group, check if it contains the device */
+-static bool vfio_dev_present(struct vfio_group *group, struct device *dev)
+-{
+- struct vfio_device *device;
+-
+- device = vfio_group_get_device(group, dev);
+- if (!device)
+- return false;
+-
+- vfio_device_put(device);
+- return true;
+-}
+-
+ /*
+ * Decrement the device reference count and wait for the device to be
+ * removed. Open file descriptors for the device... */
+ void *vfio_del_group_dev(struct device *dev)
+ {
++ DEFINE_WAIT_FUNC(wait, woken_wake_function);
+ struct vfio_device *device = dev_get_drvdata(dev);
+ struct vfio_group *group = device->group;
+ void *device_data = device->device_data;
+ struct vfio_unbound_dev *unbound;
+ unsigned int i = 0;
+- long ret;
+ bool interrupted = false;
+
+ /*
+@@ -964,6 +952,8 @@ void *vfio_del_group_dev(struct device *dev)
+ * interval with counter to allow the driver to take escalating
+ * measures to release the device if it has the ability to do so.
+ */
++ add_wait_queue(&vfio.release_q, &wait);
++
+ do {
+ device = vfio_group_get_device(group, dev);
+ if (!device)
+@@ -975,12 +965,10 @@ void *vfio_del_group_dev(struct device *dev)
+ vfio_device_put(device);
+
+ if (interrupted) {
+- ret = wait_event_timeout(vfio.release_q,
+- !vfio_dev_present(group, dev), HZ * 10);
++ wait_woken(&wait, TASK_UNINTERRUPTIBLE, HZ * 10);
+ } else {
+- ret = wait_event_interruptible_timeout(vfio.release_q,
+- !vfio_dev_present(group, dev), HZ * 10);
+- if (ret == -ERESTARTSYS) {
++ wait_woken(&wait, TASK_INTERRUPTIBLE, HZ * 10);
++ if (signal_pending(current)) {
+ interrupted = true;
+ dev_warn(dev,
+ "Device is currently in use, task"
+@@ -989,8 +977,10 @@ void *vfio_del_group_dev(struct device *dev)
+ current->comm, task_pid_nr(current));
+ }
+ }
+- } while (ret <= 0);
+
++ } while (1);
++
++ remove_wait_queue(&vfio.release_q, &wait);
+ /*
+ * In order to support multiple devices per group, devices can be
+ * plucked from the group while other devices in the group are still
+--
+2.20.1
+
--- /dev/null
+From 60629e5300af6888a6a43b3bb20e830d416fcd6a Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Mon, 1 Apr 2019 17:46:58 +0200
+Subject: video: hgafb: fix potential NULL pointer dereference
+
+[ Upstream commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542 ]
+
+When ioremap fails, hga_vram should not be dereferenced. The fix
+check the failure to avoid NULL pointer dereference.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Cc: Aditya Pakki <pakki001@umn.edu>
+Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
+[b.zolnierkie: minor patch summary fixup]
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/hgafb.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
+index 463028543173..59e1cae57948 100644
+--- a/drivers/video/fbdev/hgafb.c
++++ b/drivers/video/fbdev/hgafb.c
+@@ -285,6 +285,8 @@ static int hga_card_detect(void)
+ hga_vram_len = 0x08000;
+
+ hga_vram = ioremap(0xb0000, hga_vram_len);
++ if (!hga_vram)
++ goto error;
+
+ if (request_region(0x3b0, 12, "hgafb"))
+ release_io_ports = 1;
+--
+2.20.1
+
--- /dev/null
+From 8aca29c9d6b18ab4123a2db35757e02e90a95ffa Mon Sep 17 00:00:00 2001
+From: Kangjie Lu <kjlu@umn.edu>
+Date: Mon, 1 Apr 2019 17:46:58 +0200
+Subject: video: imsttfb: fix potential NULL pointer dereferences
+
+[ Upstream commit 1d84353d205a953e2381044953b7fa31c8c9702d ]
+
+In case ioremap fails, the fix releases resources and returns
+-ENOMEM to avoid NULL pointer dereferences.
+
+Signed-off-by: Kangjie Lu <kjlu@umn.edu>
+Cc: Aditya Pakki <pakki001@umn.edu>
+Cc: Finn Thain <fthain@telegraphics.com.au>
+Cc: Rob Herring <robh@kernel.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+[b.zolnierkie: minor patch summary fixup]
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/imsttfb.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
+index ecdcf358ad5e..ffcf553719a3 100644
+--- a/drivers/video/fbdev/imsttfb.c
++++ b/drivers/video/fbdev/imsttfb.c
+@@ -1516,6 +1516,11 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+ info->fix.smem_start = addr;
+ info->screen_base = (__u8 *)ioremap(addr, par->ramdac == IBM ?
+ 0x400000 : 0x800000);
++ if (!info->screen_base) {
++ release_mem_region(addr, size);
++ framebuffer_release(info);
++ return -ENOMEM;
++ }
+ info->fix.mmio_start = addr + 0x800000;
+ par->dc_regs = ioremap(addr + 0x800000, 0x1000);
+ par->cmap_regs_phys = addr + 0x840000;
+--
+2.20.1
+
--- /dev/null
+From 1a6e3f68ccfc317d3290f3b2bb64ae2adf790748 Mon Sep 17 00:00:00 2001
+From: Vladimir Zapolskiy <vz@mleia.com>
+Date: Tue, 12 Mar 2019 01:54:25 +0200
+Subject: watchdog: fix compile time error of pretimeout governors
+
+[ Upstream commit a223770bfa7b6647f3a70983257bd89f9cafce46 ]
+
+CONFIG_WATCHDOG_PRETIMEOUT_GOV build symbol adds watchdog_pretimeout.o
+object to watchdog.o, the latter is compiled only if CONFIG_WATCHDOG_CORE
+is selected, so it rightfully makes sense to add it as a dependency.
+
+The change fixes the next compilation errors, if CONFIG_WATCHDOG_CORE=n
+and CONFIG_WATCHDOG_PRETIMEOUT_GOV=y are selected:
+
+ drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_register':
+ drivers/watchdog/pretimeout_noop.c:35: undefined reference to `watchdog_register_governor'
+ drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_unregister':
+ drivers/watchdog/pretimeout_noop.c:40: undefined reference to `watchdog_unregister_governor'
+
+ drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_register':
+ drivers/watchdog/pretimeout_panic.c:35: undefined reference to `watchdog_register_governor'
+ drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_unregister':
+ drivers/watchdog/pretimeout_panic.c:40: undefined reference to `watchdog_unregister_governor'
+
+Reported-by: Kuo, Hsuan-Chi <hckuo2@illinois.edu>
+Fixes: ff84136cb6a4 ("watchdog: add watchdog pretimeout governor framework")
+Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/watchdog/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
+index 8c9ea3cd9c60..b7914eb6a04b 100644
+--- a/drivers/watchdog/Kconfig
++++ b/drivers/watchdog/Kconfig
+@@ -1967,6 +1967,7 @@ comment "Watchdog Pretimeout Governors"
+
+ config WATCHDOG_PRETIMEOUT_GOV
+ bool "Enable watchdog pretimeout governors"
++ depends on WATCHDOG_CORE
+ help
+ The option allows to select watchdog pretimeout governors.
+
+--
+2.20.1
+
--- /dev/null
+From 5857edd5636dcad8394f9baf8fdbf3d07affdcff Mon Sep 17 00:00:00 2001
+From: Georg Hofmann <georg@hofmannsweb.com>
+Date: Mon, 8 Apr 2019 21:25:54 +0200
+Subject: watchdog: imx2_wdt: Fix set_timeout for big timeout values
+
+[ Upstream commit b07e228eee69601addba98b47b1a3850569e5013 ]
+
+The documentated behavior is: if max_hw_heartbeat_ms is implemented, the
+minimum of the set_timeout argument and max_hw_heartbeat_ms should be used.
+This patch implements this behavior.
+Previously only the first 7bits were used and the input argument was
+returned.
+
+Signed-off-by: Georg Hofmann <georg@hofmannsweb.com>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/watchdog/imx2_wdt.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
+index 2b52514eaa86..7e7bdcbbc741 100644
+--- a/drivers/watchdog/imx2_wdt.c
++++ b/drivers/watchdog/imx2_wdt.c
+@@ -178,8 +178,10 @@ static void __imx2_wdt_set_timeout(struct watchdog_device *wdog,
+ static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+ {
+- __imx2_wdt_set_timeout(wdog, new_timeout);
++ unsigned int actual;
+
++ actual = min(new_timeout, wdog->max_hw_heartbeat_ms * 1000);
++ __imx2_wdt_set_timeout(wdog, actual);
+ wdog->timeout = new_timeout;
+ return 0;
+ }
+--
+2.20.1
+
--- /dev/null
+From b65bd147a623ca816cda72630e049f95b03d233b Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Mon, 29 Apr 2019 12:28:27 -0700
+Subject: watchdog: Use depends instead of select for pretimeout governors
+
+[ Upstream commit f627ac0e12cd2736e60b9f5782ecec1d97251f77 ]
+
+Watchdog pretimeout governors were enabled from the default governor
+selection using "select". As a result, the default governor was always
+built into the kernel, even if no watchdog driver was loaded. By using
+"depends on" instead of "select", we are in better control, and the
+governors can all be built as modules. At the same time, set the default
+configuration option for pretimeout governors to match WATCHDOG_CORE
+(meaning all pretimeout governors are by default enabled if pretimeout
+support is enabled).
+
+The practical impact of this change is minimal. Previously, selecting
+a default governor automatically enabled that governor. Now, a default
+governor can only be selected if that governor has been enabled.
+Consequently, the order of governor selection is now reversed: The
+governor selection is now first, followed by default governor selection.
+
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/watchdog/Kconfig | 30 ++++++++++++++++--------------
+ 1 file changed, 16 insertions(+), 14 deletions(-)
+
+diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
+index 5ea8909a41f9..8c9ea3cd9c60 100644
+--- a/drivers/watchdog/Kconfig
++++ b/drivers/watchdog/Kconfig
+@@ -1972,6 +1972,20 @@ config WATCHDOG_PRETIMEOUT_GOV
+
+ if WATCHDOG_PRETIMEOUT_GOV
+
++config WATCHDOG_PRETIMEOUT_GOV_NOOP
++ tristate "Noop watchdog pretimeout governor"
++ default WATCHDOG_CORE
++ help
++ Noop watchdog pretimeout governor, only an informational
++ message is added to kernel log buffer.
++
++config WATCHDOG_PRETIMEOUT_GOV_PANIC
++ tristate "Panic watchdog pretimeout governor"
++ default WATCHDOG_CORE
++ help
++ Panic watchdog pretimeout governor, on watchdog pretimeout
++ event put the kernel into panic.
++
+ choice
+ prompt "Default Watchdog Pretimeout Governor"
+ default WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC
+@@ -1982,7 +1996,7 @@ choice
+
+ config WATCHDOG_PRETIMEOUT_DEFAULT_GOV_NOOP
+ bool "noop"
+- select WATCHDOG_PRETIMEOUT_GOV_NOOP
++ depends on WATCHDOG_PRETIMEOUT_GOV_NOOP
+ help
+ Use noop watchdog pretimeout governor by default. If noop
+ governor is selected by a user, write a short message to
+@@ -1990,7 +2004,7 @@ config WATCHDOG_PRETIMEOUT_DEFAULT_GOV_NOOP
+
+ config WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC
+ bool "panic"
+- select WATCHDOG_PRETIMEOUT_GOV_PANIC
++ depends on WATCHDOG_PRETIMEOUT_GOV_PANIC
+ help
+ Use panic watchdog pretimeout governor by default, if
+ a watchdog pretimeout event happens, consider that
+@@ -1998,18 +2012,6 @@ config WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC
+
+ endchoice
+
+-config WATCHDOG_PRETIMEOUT_GOV_NOOP
+- tristate "Noop watchdog pretimeout governor"
+- help
+- Noop watchdog pretimeout governor, only an informational
+- message is added to kernel log buffer.
+-
+-config WATCHDOG_PRETIMEOUT_GOV_PANIC
+- tristate "Panic watchdog pretimeout governor"
+- help
+- Panic watchdog pretimeout governor, on watchdog pretimeout
+- event put the kernel into panic.
+-
+ endif # WATCHDOG_PRETIMEOUT_GOV
+
+ endif # WATCHDOG
+--
+2.20.1
+
--- /dev/null
+From 7c051093ac4c39d2af975d47e7c8498d42722c06 Mon Sep 17 00:00:00 2001
+From: Wenwen Wang <wang6495@umn.edu>
+Date: Wed, 17 Apr 2019 09:18:50 -0500
+Subject: x86/PCI: Fix PCI IRQ routing table memory leak
+
+[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
+
+In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
+found through pirq_find_routing_table(). If the table is not found and
+CONFIG_PCI_BIOS is defined, the table is then allocated in
+pcibios_get_irq_routing_table() using kmalloc(). Later, if the I/O APIC is
+used, this table is actually not used. In that case, the allocated table
+is not freed, which is a memory leak.
+
+Free the allocated table if it is not used.
+
+Signed-off-by: Wenwen Wang <wang6495@umn.edu>
+[bhelgaas: added Ingo's reviewed-by, since the only change since v1 was to
+use the irq_routing_table local variable name he suggested]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Ingo Molnar <mingo@kernel.org>
+Acked-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/pci/irq.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
+index 52e55108404e..d3a73f9335e1 100644
+--- a/arch/x86/pci/irq.c
++++ b/arch/x86/pci/irq.c
+@@ -1119,6 +1119,8 @@ static const struct dmi_system_id pciirq_dmi_table[] __initconst = {
+
+ void __init pcibios_irq_init(void)
+ {
++ struct irq_routing_table *rtable = NULL;
++
+ DBG(KERN_DEBUG "PCI: IRQ init\n");
+
+ if (raw_pci_ops == NULL)
+@@ -1129,8 +1131,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();
+@@ -1145,8 +1149,10 @@ void __init pcibios_irq_init(void)
+ * If we're using the I/O APIC, avoid using the PCI IRQ
+ * routing table
+ */
+- if (io_apic_assign_pci_irqs)
++ if (io_apic_assign_pci_irqs) {
++ kfree(rtable);
+ pirq_table = NULL;
++ }
+ }
+
+ x86_init.pci.fixup_irqs();
+--
+2.20.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
