--- /dev/null
+From 705bf11ea926d08132f2ea9b1101f398ab319d65 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 26 Oct 2022 15:41:04 +0300
+Subject: ARM: at91: pm: avoid soft resetting AC DLL
+
+From: Claudiu Beznea <claudiu.beznea@microchip.com>
+
+[ Upstream commit cef8cdc0d0e7c701fe4dcfba4ed3fd25d28a6020 ]
+
+Do not soft reset AC DLL as controller is buggy and this operation my
+introduce glitches in the controller leading to undefined behavior.
+
+Fixes: f0bbf17958e8 ("ARM: at91: pm: add self-refresh support for sama7g5")
+Depends-on: a02875c4cbd6 ("ARM: at91: pm: fix self-refresh for sama7g5")
+Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
+Link: https://lore.kernel.org/r/20221026124114.985876-2-claudiu.beznea@microchip.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mach-at91/pm_suspend.S | 7 ++++++-
+ include/soc/at91/sama7-ddr.h | 5 ++++-
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
+index 65cfcc19a936..2f0a370a1309 100644
+--- a/arch/arm/mach-at91/pm_suspend.S
++++ b/arch/arm/mach-at91/pm_suspend.S
+@@ -169,10 +169,15 @@ sr_ena_2:
+ cmp tmp1, #UDDRC_STAT_SELFREF_TYPE_SW
+ bne sr_ena_2
+
+- /* Put DDR PHY's DLL in bypass mode for non-backup modes. */
++ /* Disable DX DLLs for non-backup modes. */
+ cmp r7, #AT91_PM_BACKUP
+ beq sr_ena_3
+
++ /* Do not soft reset the AC DLL. */
++ ldr tmp1, [r3, DDR3PHY_ACDLLCR]
++ bic tmp1, tmp1, DDR3PHY_ACDLLCR_DLLSRST
++ str tmp1, [r3, DDR3PHY_ACDLLCR]
++
+ /* Disable DX DLLs. */
+ ldr tmp1, [r3, #DDR3PHY_DX0DLLCR]
+ orr tmp1, tmp1, #DDR3PHY_DXDLLCR_DLLDIS
+diff --git a/include/soc/at91/sama7-ddr.h b/include/soc/at91/sama7-ddr.h
+index f203f34dba12..cac3f9cd25f9 100644
+--- a/include/soc/at91/sama7-ddr.h
++++ b/include/soc/at91/sama7-ddr.h
+@@ -26,7 +26,10 @@
+ #define DDR3PHY_PGSR (0x0C) /* DDR3PHY PHY General Status Register */
+ #define DDR3PHY_PGSR_IDONE (1 << 0) /* Initialization Done */
+
+-#define DDR3PHY_ACIOCR (0x24) /* DDR3PHY AC I/O Configuration Register */
++#define DDR3PHY_ACDLLCR (0x14) /* DDR3PHY AC DLL Control Register */
++#define DDR3PHY_ACDLLCR_DLLSRST (1 << 30) /* DLL Soft Reset */
++
++#define DDR3PHY_ACIOCR (0x24) /* DDR3PHY AC I/O Configuration Register */
+ #define DDR3PHY_ACIOCR_CSPDD_CS0 (1 << 18) /* CS#[0] Power Down Driver */
+ #define DDR3PHY_ACIOCR_CKPDD_CK0 (1 << 8) /* CK[0] Power Down Driver */
+ #define DDR3PHY_ACIORC_ACPDD (1 << 3) /* AC Power Down Driver */
+--
+2.35.1
+
--- /dev/null
+From cebcb25723da87c7c18b81fb3a811579f52413a0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 17 Oct 2022 11:31:19 +0300
+Subject: ARM: dts: at91: sama7g5: fix signal name of pin PB2
+
+From: Mihai Sain <mihai.sain@microchip.com>
+
+[ Upstream commit 2b4337c8409b4e9e5aed15c597e4031dd567bdd8 ]
+
+The signal name of pin PB2 with function F is FLEXCOM11_IO1
+as it is defined in the datasheet.
+
+Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek")
+Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
+Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
+Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
+Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
+Link: https://lore.kernel.org/r/20221017083119.1643-1-mihai.sain@microchip.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/sama7g5-pinfunc.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/sama7g5-pinfunc.h b/arch/arm/boot/dts/sama7g5-pinfunc.h
+index 4eb30445d205..6e87f0d4b8fc 100644
+--- a/arch/arm/boot/dts/sama7g5-pinfunc.h
++++ b/arch/arm/boot/dts/sama7g5-pinfunc.h
+@@ -261,7 +261,7 @@
+ #define PIN_PB2__FLEXCOM6_IO0 PINMUX_PIN(PIN_PB2, 2, 1)
+ #define PIN_PB2__ADTRG PINMUX_PIN(PIN_PB2, 3, 1)
+ #define PIN_PB2__A20 PINMUX_PIN(PIN_PB2, 4, 1)
+-#define PIN_PB2__FLEXCOM11_IO0 PINMUX_PIN(PIN_PB2, 6, 3)
++#define PIN_PB2__FLEXCOM11_IO1 PINMUX_PIN(PIN_PB2, 6, 3)
+ #define PIN_PB3 35
+ #define PIN_PB3__GPIO PINMUX_PIN(PIN_PB3, 0, 0)
+ #define PIN_PB3__RF1 PINMUX_PIN(PIN_PB3, 1, 1)
+--
+2.35.1
+
--- /dev/null
+From 200b1ea251b0ae27163946845940627b7c2c6d5b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 20:19:45 +0100
+Subject: ARM: dts: imx7: Fix NAND controller size-cells
+
+From: Marek Vasut <marex@denx.de>
+
+[ Upstream commit 753395ea1e45c724150070b5785900b6a44bd5fb ]
+
+The NAND controller size-cells should be 0 per DT bindings.
+Fix the following warning produces by DT bindings check:
+"
+nand-controller@33002000: #size-cells:0:0: 0 was expected
+nand-controller@33002000: Unevaluated properties are not allowed ('#address-cells', '#size-cells' were unexpected)
+"
+Fix the missing space in node name too.
+
+Fixes: e7495a45a76de ("ARM: dts: imx7: add GPMI NAND and APBH DMA")
+Signed-off-by: Marek Vasut <marex@denx.de>
+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 95f22513a7c0..c8206c636a01 100644
+--- a/arch/arm/boot/dts/imx7s.dtsi
++++ b/arch/arm/boot/dts/imx7s.dtsi
+@@ -1252,10 +1252,10 @@ dma_apbh: dma-apbh@33000000 {
+ clocks = <&clks IMX7D_NAND_USDHC_BUS_RAWNAND_CLK>;
+ };
+
+- gpmi: nand-controller@33002000{
++ gpmi: nand-controller@33002000 {
+ compatible = "fsl,imx7d-gpmi-nand";
+ #address-cells = <1>;
+- #size-cells = <1>;
++ #size-cells = <0>;
+ reg = <0x33002000 0x2000>, <0x33004000 0x4000>;
+ reg-names = "gpmi-nand", "bch";
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+--
+2.35.1
+
--- /dev/null
+From 92a41074cfd4e772ce61b4a9e84159c268ffdf81 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 20:19:46 +0100
+Subject: arm64: dts: imx8mm: Fix NAND controller size-cells
+
+From: Marek Vasut <marex@denx.de>
+
+[ Upstream commit 1610233bc2c2cae2dff9e101e6ea5ef69cceb0e9 ]
+
+The NAND controller size-cells should be 0 per DT bindings.
+Fix the following warning produces by DT bindings check:
+"
+nand-controller@33002000: #size-cells:0:0: 0 was expected
+nand-controller@33002000: Unevaluated properties are not allowed ('#address-cells', '#size-cells' were unexpected)
+"
+Fix the missing space in node name too.
+
+Fixes: a05ea40eb384e ("arm64: dts: imx: Add i.mx8mm dtsi support")
+Signed-off-by: Marek Vasut <marex@denx.de>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/freescale/imx8mm.dtsi | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+index 2f632e8ca388..67e91fdfaf52 100644
+--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
++++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+@@ -1014,10 +1014,10 @@ dma_apbh: dma-controller@33000000 {
+ clocks = <&clk IMX8MM_CLK_NAND_USDHC_BUS_RAWNAND_CLK>;
+ };
+
+- gpmi: nand-controller@33002000{
++ gpmi: nand-controller@33002000 {
+ compatible = "fsl,imx8mm-gpmi-nand", "fsl,imx7d-gpmi-nand";
+ #address-cells = <1>;
+- #size-cells = <1>;
++ #size-cells = <0>;
+ reg = <0x33002000 0x2000>, <0x33004000 0x4000>;
+ reg-names = "gpmi-nand", "bch";
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+--
+2.35.1
+
--- /dev/null
+From 2b57a356e55ffebe26ee40a519d95e6297b525e5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 20:19:47 +0100
+Subject: arm64: dts: imx8mn: Fix NAND controller size-cells
+
+From: Marek Vasut <marex@denx.de>
+
+[ Upstream commit 5468e93b5b1083eaa729f98e59da18c85d9c4126 ]
+
+The NAND controller size-cells should be 0 per DT bindings.
+Fix the following warning produces by DT bindings check:
+"
+nand-controller@33002000: #size-cells:0:0: 0 was expected
+nand-controller@33002000: Unevaluated properties are not allowed ('#address-cells', '#size-cells' were unexpected)
+"
+
+Fixes: 6c3debcbae47a ("arm64: dts: freescale: Add i.MX8MN dtsi support")
+Signed-off-by: Marek Vasut <marex@denx.de>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+index 6d6cbd4c83b8..6dcead5bae62 100644
+--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
++++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+@@ -998,7 +998,7 @@ dma_apbh: dma-controller@33000000 {
+ gpmi: nand-controller@33002000 {
+ compatible = "fsl,imx8mn-gpmi-nand", "fsl,imx7d-gpmi-nand";
+ #address-cells = <1>;
+- #size-cells = <1>;
++ #size-cells = <0>;
+ reg = <0x33002000 0x2000>, <0x33004000 0x4000>;
+ reg-names = "gpmi-nand", "bch";
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+--
+2.35.1
+
--- /dev/null
+From 97852a12cb8e5867fdb9c29eabd4e5ad343cd6dc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 29 Aug 2022 09:49:47 -0700
+Subject: arm64: dts: qcom: sa8155p-adp: Specify which LDO modes are allowed
+
+From: Douglas Anderson <dianders@chromium.org>
+
+[ Upstream commit bd9f3dcf42d943b53190f99bcdbcfe98a56ac4cd ]
+
+This board uses RPMH, specifies "regulator-allow-set-load" for LDOs,
+but doesn't specify any modes with "regulator-allowed-modes".
+
+Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
+get_optimum_mode(), not set_load()") the above meant that we were able
+to set either LPM or HPM mode. After that commit (and fixes [1]) we'll
+be stuck at the initial mode. Discussion of this has resulted in the
+decision that the old dts files were wrong and should be fixed to
+fully restore old functionality.
+
+Let's re-enable the old functionality by fixing the dts.
+
+NOTE: while here, let's also remove the nonsensical
+"regulator-allow-set-load" on the fixed regulator "vreg_s4a_1p8".
+
+[1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid
+
+Fixes: 5b85e8f2225c ("arm64: dts: qcom: sa8155p-adp: Add base dts file")
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Link: https://lore.kernel.org/r/20220829094903.v2.1.Id59c32b560c4662d8b3697de2bd494d08d654806@changeid
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/qcom/sa8155p-adp.dts | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
+index 5ae2ddc65f7e..56a789a5789e 100644
+--- a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
++++ b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
+@@ -43,7 +43,6 @@ vreg_s4a_1p8: smps4 {
+
+ regulator-always-on;
+ regulator-boot-on;
+- regulator-allow-set-load;
+
+ vin-supply = <&vreg_3p3>;
+ };
+@@ -114,6 +113,9 @@ vreg_l5a_0p88: ldo5 {
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7a_1p8: ldo7 {
+@@ -129,6 +131,9 @@ vreg_l10a_2p96: ldo10 {
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11a_0p8: ldo11 {
+@@ -235,6 +240,9 @@ vreg_l5c_1p2: ldo5 {
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c_1p8: ldo7 {
+@@ -250,6 +258,9 @@ vreg_l8c_1p2: ldo8 {
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l10c_3p3: ldo10 {
+--
+2.35.1
+
--- /dev/null
+From 184e62f06a0ce7f5cdeaad7103a29a1822cab316 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 29 Aug 2022 09:49:50 -0700
+Subject: arm64: dts: qcom: sm8150-xperia-kumano: Specify which LDO modes are
+ allowed
+
+From: Douglas Anderson <dianders@chromium.org>
+
+[ Upstream commit aa30e786202e4ed1df980442d305658441f65859 ]
+
+This board uses RPMH, specifies "regulator-allow-set-load" for LDOs,
+but doesn't specify any modes with "regulator-allowed-modes".
+
+Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
+get_optimum_mode(), not set_load()") the above meant that we were able
+to set either LPM or HPM mode. After that commit (and fixes [1]) we'll
+be stuck at the initial mode. Discussion of this has resulted in the
+decision that the old dts files were wrong and should be fixed to
+fully restore old functionality.
+
+Let's re-enable the old functionality by fixing the dts.
+
+[1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid
+
+Fixes: d0a6ce59ea4e ("arm64: dts: qcom: sm8150: Add support for SONY Xperia 1 / 5 (Kumano platform)")
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Link: https://lore.kernel.org/r/20220829094903.v2.4.I51d60414a42ba9e3008e208d60a04c9ffc425fa7@changeid
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi b/arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi
+index 014fe3a31548..fb6e5a140c9f 100644
+--- a/arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano.dtsi
+@@ -348,6 +348,9 @@ vreg_l6c_2p9: ldo6 {
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c_3p0: ldo7 {
+@@ -367,6 +370,9 @@ vreg_l9c_2p9: ldo9 {
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l10c_3p3: ldo10 {
+--
+2.35.1
+
--- /dev/null
+From d76431e364719e2ac08c76e6ae9631e1620fb880 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 29 Aug 2022 09:49:51 -0700
+Subject: arm64: dts: qcom: sm8250-xperia-edo: Specify which LDO modes are
+ allowed
+
+From: Douglas Anderson <dianders@chromium.org>
+
+[ Upstream commit b7870d460c05ce31e2311036d91de1e2e0b32cea ]
+
+This board uses RPMH, specifies "regulator-allow-set-load" for LDOs,
+but doesn't specify any modes with "regulator-allowed-modes".
+
+Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
+get_optimum_mode(), not set_load()") the above meant that we were able
+to set either LPM or HPM mode. After that commit (and fixes [1]) we'll
+be stuck at the initial mode. Discussion of this has resulted in the
+decision that the old dts files were wrong and should be fixed to
+fully restore old functionality.
+
+Let's re-enable the old functionality by fixing the dts.
+
+[1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid
+
+Fixes: 69cdb97ef652 ("arm64: dts: qcom: sm8250: Add support for SONY Xperia 1 II / 5 II (Edo platform)")
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Link: https://lore.kernel.org/r/20220829094903.v2.5.Ie446d5183d8b1e9ec4e32228ca300e604e3315eb@changeid
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi b/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
+index d63f7a9bc4e9..b15d085db05a 100644
+--- a/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
++++ b/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
+@@ -317,6 +317,9 @@ vreg_l6c_2p9: ldo6 {
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c_2p85: ldo7 {
+@@ -339,6 +342,9 @@ vreg_l9c_2p9: ldo9 {
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l10c_3p3: ldo10 {
+--
+2.35.1
+
--- /dev/null
+From 462acae365f6b2edb8aa044eed8bb917f77b0a9d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 29 Aug 2022 09:49:52 -0700
+Subject: arm64: dts: qcom: sm8350-hdk: Specify which LDO modes are allowed
+
+From: Douglas Anderson <dianders@chromium.org>
+
+[ Upstream commit 1ce8aaf6abdc35cde555924418b3d4516b4ec871 ]
+
+This board uses RPMH, specifies "regulator-allow-set-load" for LDOs,
+but doesn't specify any modes with "regulator-allowed-modes".
+
+Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement
+get_optimum_mode(), not set_load()") the above meant that we were able
+to set either LPM or HPM mode. After that commit (and fixes [1]) we'll
+be stuck at the initial mode. Discussion of this has resulted in the
+decision that the old dts files were wrong and should be fixed to
+fully restore old functionality.
+
+Let's re-enable the old functionality by fixing the dts.
+
+[1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid
+
+Fixes: 9208c19f2124 ("arm64: dts: qcom: Introduce SM8350 HDK")
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
+Reviewed-by: Vinod Koul <vkoul@kernel.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Link: https://lore.kernel.org/r/20220829094903.v2.6.I6799be85cf36d3b494f803cba767a569080624f5@changeid
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+index 56093e260ddf..9ea0d7233add 100644
+--- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
++++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+@@ -108,6 +108,9 @@ vreg_l5b_0p88: ldo5 {
+ regulator-max-microvolt = <888000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6b_1p2: ldo6 {
+@@ -116,6 +119,9 @@ vreg_l6b_1p2: ldo6 {
+ regulator-max-microvolt = <1208000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_2p96: ldo7 {
+@@ -124,6 +130,9 @@ vreg_l7b_2p96: ldo7 {
+ regulator-max-microvolt = <2504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_1p2: ldo9 {
+@@ -132,6 +141,9 @@ vreg_l9b_1p2: ldo9 {
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
++ regulator-allowed-modes =
++ <RPMH_REGULATOR_MODE_LPM
++ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+--
+2.35.1
+
--- /dev/null
+From c4b50f6fa4c7625fc8d20d37dee29a479ec7cdb9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 09:01:06 -0700
+Subject: arm64: Fix bit-shifting UB in the MIDR_CPU_MODEL() macro
+
+From: D Scott Phillips <scott@os.amperecomputing.com>
+
+[ Upstream commit 8ec8490a1950efeccb00967698cf7cb2fcd25ca7 ]
+
+CONFIG_UBSAN_SHIFT with gcc-5 complains that the shifting of
+ARM_CPU_IMP_AMPERE (0xC0) into bits [31:24] by MIDR_CPU_MODEL() is
+undefined behavior. Well, sort of, it actually spells the error as:
+
+ arch/arm64/kernel/proton-pack.c: In function 'spectre_bhb_loop_affected':
+ arch/arm64/include/asm/cputype.h:44:2: error: initializer element is not constant
+ (((imp) << MIDR_IMPLEMENTOR_SHIFT) | \
+ ^
+
+This isn't an issue for other Implementor codes, as all the other codes
+have zero in the top bit and so are representable as a signed int.
+
+Cast the implementor code to unsigned in MIDR_CPU_MODEL to remove the
+undefined behavior.
+
+Fixes: 0e5d5ae837c8 ("arm64: Add AMPERE1 to the Spectre-BHB affected list")
+Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com>
+Link: https://lore.kernel.org/r/20221102160106.1096948-1-scott@os.amperecomputing.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/include/asm/cputype.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
+index 457b6bb276bb..9cf5d9551e99 100644
+--- a/arch/arm64/include/asm/cputype.h
++++ b/arch/arm64/include/asm/cputype.h
+@@ -41,7 +41,7 @@
+ (((midr) & MIDR_IMPLEMENTOR_MASK) >> MIDR_IMPLEMENTOR_SHIFT)
+
+ #define MIDR_CPU_MODEL(imp, partnum) \
+- (((imp) << MIDR_IMPLEMENTOR_SHIFT) | \
++ ((_AT(u32, imp) << MIDR_IMPLEMENTOR_SHIFT) | \
+ (0xf << MIDR_ARCHITECTURE_SHIFT) | \
+ ((partnum) << MIDR_PARTNUM_SHIFT))
+
+--
+2.35.1
+
--- /dev/null
+From edaf22356350adec46e69d3710739010ad304891 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Oct 2022 11:16:03 +0800
+Subject: ASoC: core: Fix use-after-free in snd_soc_exit()
+
+From: Chen Zhongjin <chenzhongjin@huawei.com>
+
+[ Upstream commit 6ec27c53886c8963729885bcf2dd996eba2767a7 ]
+
+KASAN reports a use-after-free:
+
+BUG: KASAN: use-after-free in device_del+0xb5b/0xc60
+Read of size 8 at addr ffff888008655050 by task rmmod/387
+CPU: 2 PID: 387 Comm: rmmod
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
+Call Trace:
+<TASK>
+dump_stack_lvl+0x79/0x9a
+print_report+0x17f/0x47b
+kasan_report+0xbb/0xf0
+device_del+0xb5b/0xc60
+platform_device_del.part.0+0x24/0x200
+platform_device_unregister+0x2e/0x40
+snd_soc_exit+0xa/0x22 [snd_soc_core]
+__do_sys_delete_module.constprop.0+0x34f/0x5b0
+do_syscall_64+0x3a/0x90
+entry_SYSCALL_64_after_hwframe+0x63/0xcd
+...
+</TASK>
+
+It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,
+but its ret is ignored, which makes soc_dummy_dev unregistered twice.
+
+snd_soc_init()
+ snd_soc_util_init()
+ platform_device_register_simple(soc_dummy_dev)
+ platform_driver_register() # fail
+ platform_device_unregister(soc_dummy_dev)
+ platform_driver_register() # success
+...
+snd_soc_exit()
+ snd_soc_util_exit()
+ # soc_dummy_dev will be unregistered for second time
+
+To fix it, handle error and stop snd_soc_init() when util_init() fail.
+Also clean debugfs when util_init() or driver_register() fail.
+
+Fixes: fb257897bf20 ("ASoC: Work around allmodconfig failure")
+Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
+Link: https://lore.kernel.org/r/20221028031603.59416-1-chenzhongjin@huawei.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/soc-core.c | 17 +++++++++++++++--
+ 1 file changed, 15 insertions(+), 2 deletions(-)
+
+diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
+index 5da762807824..1b1749b920f4 100644
+--- a/sound/soc/soc-core.c
++++ b/sound/soc/soc-core.c
+@@ -3366,10 +3366,23 @@ EXPORT_SYMBOL_GPL(snd_soc_of_get_dai_link_codecs);
+
+ static int __init snd_soc_init(void)
+ {
++ int ret;
++
+ snd_soc_debugfs_init();
+- snd_soc_util_init();
++ ret = snd_soc_util_init();
++ if (ret)
++ goto err_util_init;
+
+- return platform_driver_register(&soc_driver);
++ ret = platform_driver_register(&soc_driver);
++ if (ret)
++ goto err_register;
++ return 0;
++
++err_register:
++ snd_soc_util_exit();
++err_util_init:
++ snd_soc_debugfs_exit();
++ return ret;
+ }
+ module_init(snd_soc_init);
+
+--
+2.35.1
+
--- /dev/null
+From 5df3b375bb8f408e9fa759de9dc547812d10e6f6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 21:40:31 +0800
+Subject: ASoC: soc-utils: Remove __exit for snd_soc_util_exit()
+
+From: Chen Zhongjin <chenzhongjin@huawei.com>
+
+[ Upstream commit 314d34fe7f0a5836cb0472950c1f17744b4efde8 ]
+
+snd_soc_util_exit() is called in __init snd_soc_init() for cleanup.
+Remove the __exit annotation for it to fix the build warning:
+
+WARNING: modpost: sound/soc/snd-soc-core.o: section mismatch in reference: init_module (section: .init.text) -> snd_soc_util_exit (section: .exit.text)
+
+Fixes: 6ec27c53886c ("ASoC: core: Fix use-after-free in snd_soc_exit()")
+Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
+Link: https://lore.kernel.org/r/20221031134031.256511-1-chenzhongjin@huawei.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/soc-utils.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sound/soc/soc-utils.c b/sound/soc/soc-utils.c
+index 299b5d6ebfd1..f2c9d97c19c7 100644
+--- a/sound/soc/soc-utils.c
++++ b/sound/soc/soc-utils.c
+@@ -206,7 +206,7 @@ int __init snd_soc_util_init(void)
+ return ret;
+ }
+
+-void __exit snd_soc_util_exit(void)
++void snd_soc_util_exit(void)
+ {
+ platform_driver_unregister(&soc_dummy_driver);
+ platform_device_unregister(soc_dummy_dev);
+--
+2.35.1
+
--- /dev/null
+From f9fb9f38f407ba8838cc676a204021b2262977d9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Oct 2022 11:57:59 +0200
+Subject: ASoC: tas2764: Fix set_tdm_slot in case of single slot
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Martin Povišer <povik+lin@cutebit.org>
+
+[ Upstream commit faac764ea1ea6898d93e46c403271fb105c0906e ]
+
+There's a special branch in the set_tdm_slot op for the case of nslots
+being 1, but:
+
+ (1) That branch can never work (there's a check for tx_mask being
+ non-zero, later there's another check for it *being* zero; one or
+ the other always throws -EINVAL).
+
+ (2) The intention of the branch seems to be what the general other
+ branch reduces to in case of nslots being 1.
+
+For those reasons remove the 'nslots being 1' special case.
+
+Fixes: 827ed8a0fa50 ("ASoC: tas2764: Add the driver for the TAS2764")
+Suggested-by: Jos Dehaes <jos.dehaes@gmail.com>
+Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
+Link: https://lore.kernel.org/r/20221027095800.16094-2-povik+lin@cutebit.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/codecs/tas2764.c | 19 ++++++-------------
+ 1 file changed, 6 insertions(+), 13 deletions(-)
+
+diff --git a/sound/soc/codecs/tas2764.c b/sound/soc/codecs/tas2764.c
+index afb4c0d7e714..1951bae95b31 100644
+--- a/sound/soc/codecs/tas2764.c
++++ b/sound/soc/codecs/tas2764.c
+@@ -386,20 +386,13 @@ static int tas2764_set_dai_tdm_slot(struct snd_soc_dai *dai,
+ if (tx_mask == 0 || rx_mask != 0)
+ return -EINVAL;
+
+- if (slots == 1) {
+- if (tx_mask != 1)
+- return -EINVAL;
+- left_slot = 0;
+- right_slot = 0;
++ left_slot = __ffs(tx_mask);
++ tx_mask &= ~(1 << left_slot);
++ if (tx_mask == 0) {
++ right_slot = left_slot;
+ } else {
+- left_slot = __ffs(tx_mask);
+- tx_mask &= ~(1 << left_slot);
+- if (tx_mask == 0) {
+- right_slot = left_slot;
+- } else {
+- right_slot = __ffs(tx_mask);
+- tx_mask &= ~(1 << right_slot);
+- }
++ right_slot = __ffs(tx_mask);
++ tx_mask &= ~(1 << right_slot);
+ }
+
+ if (tx_mask != 0 || left_slot >= slots || right_slot >= slots)
+--
+2.35.1
+
--- /dev/null
+From 5d627176078fa6766c058e85aee237703c92eb6b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Oct 2022 11:57:58 +0200
+Subject: ASoC: tas2770: Fix set_tdm_slot in case of single slot
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Martin Povišer <povik+lin@cutebit.org>
+
+[ Upstream commit e59bf547a7dd366f93bfebb7487959580ca6c0ec ]
+
+There's a special branch in the set_tdm_slot op for the case of nslots
+being 1, but:
+
+ (1) That branch can never work (there's a check for tx_mask being
+ non-zero, later there's another check for it *being* zero; one or
+ the other always throws -EINVAL).
+
+ (2) The intention of the branch seems to be what the general other
+ branch reduces to in case of nslots being 1.
+
+For those reasons remove the 'nslots being 1' special case.
+
+Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
+Suggested-by: Jos Dehaes <jos.dehaes@gmail.com>
+Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
+Link: https://lore.kernel.org/r/20221027095800.16094-1-povik+lin@cutebit.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/codecs/tas2770.c | 20 ++++++--------------
+ 1 file changed, 6 insertions(+), 14 deletions(-)
+
+diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c
+index a13b086a072b..ec0df3b1ef61 100644
+--- a/sound/soc/codecs/tas2770.c
++++ b/sound/soc/codecs/tas2770.c
+@@ -395,21 +395,13 @@ static int tas2770_set_dai_tdm_slot(struct snd_soc_dai *dai,
+ if (tx_mask == 0 || rx_mask != 0)
+ return -EINVAL;
+
+- if (slots == 1) {
+- if (tx_mask != 1)
+- return -EINVAL;
+-
+- left_slot = 0;
+- right_slot = 0;
++ left_slot = __ffs(tx_mask);
++ tx_mask &= ~(1 << left_slot);
++ if (tx_mask == 0) {
++ right_slot = left_slot;
+ } else {
+- left_slot = __ffs(tx_mask);
+- tx_mask &= ~(1 << left_slot);
+- if (tx_mask == 0) {
+- right_slot = left_slot;
+- } else {
+- right_slot = __ffs(tx_mask);
+- tx_mask &= ~(1 << right_slot);
+- }
++ right_slot = __ffs(tx_mask);
++ tx_mask &= ~(1 << right_slot);
+ }
+
+ if (tx_mask != 0 || left_slot >= slots || right_slot >= slots)
+--
+2.35.1
+
--- /dev/null
+From d40afcb6312043bedb0248ff87f4091032e958d5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Nov 2022 21:40:01 +0800
+Subject: ata: libata-transport: fix double ata_host_put() in ata_tport_add()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 8c76310740807ade5ecdab5888f70ecb6d35732e ]
+
+In the error path in ata_tport_add(), when calling put_device(),
+ata_tport_release() is called, it will put the refcount of 'ap->host'.
+
+And then ata_host_put() is called again, the refcount is decreased
+to 0, ata_host_release() is called, all ports are freed and set to
+null.
+
+When unbinding the device after failure, ata_host_stop() is called
+to release the resources, it leads a null-ptr-deref(), because all
+the ports all freed and null.
+
+Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
+CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8
+pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : ata_host_stop+0x3c/0x84 [libata]
+lr : release_nodes+0x64/0xd0
+Call trace:
+ ata_host_stop+0x3c/0x84 [libata]
+ release_nodes+0x64/0xd0
+ devres_release_all+0xbc/0x1b0
+ device_unbind_cleanup+0x20/0x70
+ really_probe+0x158/0x320
+ __driver_probe_device+0x84/0x120
+ driver_probe_device+0x44/0x120
+ __driver_attach+0xb4/0x220
+ bus_for_each_dev+0x78/0xdc
+ driver_attach+0x2c/0x40
+ bus_add_driver+0x184/0x240
+ driver_register+0x80/0x13c
+ __pci_register_driver+0x4c/0x60
+ ahci_pci_driver_init+0x30/0x1000 [ahci]
+
+Fix this by removing redundant ata_host_put() in the error path.
+
+Fixes: 2623c7a5f279 ("libata: add refcounting to ata_host")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/libata-transport.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/ata/libata-transport.c b/drivers/ata/libata-transport.c
+index 93d6920cd86c..2b1e3403570c 100644
+--- a/drivers/ata/libata-transport.c
++++ b/drivers/ata/libata-transport.c
+@@ -317,7 +317,6 @@ int ata_tport_add(struct device *parent,
+ tport_err:
+ transport_destroy_device(dev);
+ put_device(dev);
+- ata_host_put(ap->host);
+ return error;
+ }
+
+--
+2.35.1
+
--- /dev/null
+From b8b51764629b5dbf337faa380a942a86a0be975c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Nov 2022 21:40:04 +0800
+Subject: ata: libata-transport: fix error handling in ata_tdev_add()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 1ff36351309e3eadcff297480baf4785e726de9b ]
+
+In ata_tdev_add(), the return value of transport_add_device() is
+not checked. As a result, it causes null-ptr-deref while removing
+the module, because transport_remove_device() is called to remove
+the device that was not added.
+
+Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
+CPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #36
+pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : device_del+0x48/0x3a0
+lr : device_del+0x44/0x3a0
+Call trace:
+ device_del+0x48/0x3a0
+ attribute_container_class_device_del+0x28/0x40
+ transport_remove_classdev+0x60/0x7c
+ attribute_container_device_trigger+0x118/0x120
+ transport_remove_device+0x20/0x30
+ ata_tdev_delete+0x24/0x50 [libata]
+ ata_tlink_delete+0x40/0xa0 [libata]
+ ata_tport_delete+0x2c/0x60 [libata]
+ ata_port_detach+0x148/0x1b0 [libata]
+ ata_pci_remove_one+0x50/0x80 [libata]
+ ahci_remove_one+0x4c/0x8c [ahci]
+
+Fix this by checking and handling return value of transport_add_device()
+in ata_tdev_add(). In the error path, device_del() is called to delete
+the device which was added earlier in this function, and ata_tdev_free()
+is called to free ata_dev.
+
+Fixes: d9027470b886 ("[libata] Add ATA transport class")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/libata-transport.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/ata/libata-transport.c b/drivers/ata/libata-transport.c
+index 5ee46521198d..60f22e1a4943 100644
+--- a/drivers/ata/libata-transport.c
++++ b/drivers/ata/libata-transport.c
+@@ -683,7 +683,13 @@ static int ata_tdev_add(struct ata_device *ata_dev)
+ return error;
+ }
+
+- transport_add_device(dev);
++ error = transport_add_device(dev);
++ if (error) {
++ device_del(dev);
++ ata_tdev_free(ata_dev);
++ return error;
++ }
++
+ transport_configure_device(dev);
+ return 0;
+ }
+--
+2.35.1
+
--- /dev/null
+From f50128004496455aee2e200cea9e9a3df74fd8d8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Nov 2022 21:40:03 +0800
+Subject: ata: libata-transport: fix error handling in ata_tlink_add()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit cf0816f6322c5c37ee52655f928e91ecf32da103 ]
+
+In ata_tlink_add(), the return value of transport_add_device() is
+not checked. As a result, it causes null-ptr-deref while removing
+the module, because transport_remove_device() is called to remove
+the device that was not added.
+
+Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
+CPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #12
+pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : device_del+0x48/0x39c
+lr : device_del+0x44/0x39c
+Call trace:
+ device_del+0x48/0x39c
+ attribute_container_class_device_del+0x28/0x40
+ transport_remove_classdev+0x60/0x7c
+ attribute_container_device_trigger+0x118/0x120
+ transport_remove_device+0x20/0x30
+ ata_tlink_delete+0x88/0xb0 [libata]
+ ata_tport_delete+0x2c/0x60 [libata]
+ ata_port_detach+0x148/0x1b0 [libata]
+ ata_pci_remove_one+0x50/0x80 [libata]
+ ahci_remove_one+0x4c/0x8c [ahci]
+
+Fix this by checking and handling return value of transport_add_device()
+in ata_tlink_add().
+
+Fixes: d9027470b886 ("[libata] Add ATA transport class")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/libata-transport.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/ata/libata-transport.c b/drivers/ata/libata-transport.c
+index 3dd3b2543086..5ee46521198d 100644
+--- a/drivers/ata/libata-transport.c
++++ b/drivers/ata/libata-transport.c
+@@ -428,7 +428,9 @@ int ata_tlink_add(struct ata_link *link)
+ goto tlink_err;
+ }
+
+- transport_add_device(dev);
++ error = transport_add_device(dev);
++ if (error)
++ goto tlink_transport_err;
+ transport_configure_device(dev);
+
+ ata_for_each_dev(ata_dev, link, ALL) {
+@@ -443,6 +445,7 @@ int ata_tlink_add(struct ata_link *link)
+ ata_tdev_delete(ata_dev);
+ }
+ transport_remove_device(dev);
++ tlink_transport_err:
+ device_del(dev);
+ tlink_err:
+ transport_destroy_device(dev);
+--
+2.35.1
+
--- /dev/null
+From 555b27e578ca3b74762e1f6f582da91155d468d7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Nov 2022 21:40:02 +0800
+Subject: ata: libata-transport: fix error handling in ata_tport_add()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 3613dbe3909dcc637fe6be00e4dc43b4aa0470ee ]
+
+In ata_tport_add(), the return value of transport_add_device() is
+not checked. As a result, it causes null-ptr-deref while removing
+the module, because transport_remove_device() is called to remove
+the device that was not added.
+
+Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
+CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8
+pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : device_del+0x48/0x39c
+lr : device_del+0x44/0x39c
+Call trace:
+ device_del+0x48/0x39c
+ attribute_container_class_device_del+0x28/0x40
+ transport_remove_classdev+0x60/0x7c
+ attribute_container_device_trigger+0x118/0x120
+ transport_remove_device+0x20/0x30
+ ata_tport_delete+0x34/0x60 [libata]
+ ata_port_detach+0x148/0x1b0 [libata]
+ ata_pci_remove_one+0x50/0x80 [libata]
+ ahci_remove_one+0x4c/0x8c [ahci]
+
+Fix this by checking and handling return value of transport_add_device()
+in ata_tport_add().
+
+Fixes: d9027470b886 ("[libata] Add ATA transport class")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/libata-transport.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/ata/libata-transport.c b/drivers/ata/libata-transport.c
+index 2b1e3403570c..3dd3b2543086 100644
+--- a/drivers/ata/libata-transport.c
++++ b/drivers/ata/libata-transport.c
+@@ -301,7 +301,9 @@ int ata_tport_add(struct device *parent,
+ pm_runtime_enable(dev);
+ pm_runtime_forbid(dev);
+
+- transport_add_device(dev);
++ error = transport_add_device(dev);
++ if (error)
++ goto tport_transport_add_err;
+ transport_configure_device(dev);
+
+ error = ata_tlink_add(&ap->link);
+@@ -312,6 +314,7 @@ int ata_tport_add(struct device *parent,
+
+ tport_link_err:
+ transport_remove_device(dev);
++ tport_transport_add_err:
+ device_del(dev);
+
+ tport_err:
+--
+2.35.1
+
--- /dev/null
+From 18f3e1dc357520de7bbe05319fe88e9b119db8a4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Nov 2022 23:39:44 +0300
+Subject: block: sed-opal: kmalloc the cmd/resp buffers
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+[ Upstream commit f829230dd51974c1f4478900ed30bb77ba530b40 ]
+
+In accordance with [1] the DMA-able memory buffers must be
+cacheline-aligned otherwise the cache writing-back and invalidation
+performed during the mapping may cause the adjacent data being lost. It's
+specifically required for the DMA-noncoherent platforms [2]. Seeing the
+opal_dev.{cmd,resp} buffers are implicitly used for DMAs in the NVME and
+SCSI/SD drivers in framework of the nvme_sec_submit() and sd_sec_submit()
+methods respectively they must be cacheline-aligned to prevent the denoted
+problem. One of the option to guarantee that is to kmalloc the buffers
+[2]. Let's explicitly allocate them then instead of embedding into the
+opal_dev structure instance.
+
+Note this fix was inspired by the commit c94b7f9bab22 ("nvme-hwmon:
+kmalloc the NVME SMART log buffer").
+
+[1] Documentation/core-api/dma-api.rst
+[2] Documentation/core-api/dma-api-howto.rst
+
+Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20221107203944.31686-1-Sergey.Semin@baikalelectronics.ru
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/sed-opal.c | 32 ++++++++++++++++++++++++++++----
+ 1 file changed, 28 insertions(+), 4 deletions(-)
+
+diff --git a/block/sed-opal.c b/block/sed-opal.c
+index daafadbb88ca..0ac5a4f3f226 100644
+--- a/block/sed-opal.c
++++ b/block/sed-opal.c
+@@ -88,8 +88,8 @@ struct opal_dev {
+ u64 lowest_lba;
+
+ size_t pos;
+- u8 cmd[IO_BUFFER_LENGTH];
+- u8 resp[IO_BUFFER_LENGTH];
++ u8 *cmd;
++ u8 *resp;
+
+ struct parsed_resp parsed;
+ size_t prev_d_len;
+@@ -2134,6 +2134,8 @@ void free_opal_dev(struct opal_dev *dev)
+ return;
+
+ clean_opal_dev(dev);
++ kfree(dev->resp);
++ kfree(dev->cmd);
+ kfree(dev);
+ }
+ EXPORT_SYMBOL(free_opal_dev);
+@@ -2146,17 +2148,39 @@ struct opal_dev *init_opal_dev(void *data, sec_send_recv *send_recv)
+ if (!dev)
+ return NULL;
+
++ /*
++ * Presumably DMA-able buffers must be cache-aligned. Kmalloc makes
++ * sure the allocated buffer is DMA-safe in that regard.
++ */
++ dev->cmd = kmalloc(IO_BUFFER_LENGTH, GFP_KERNEL);
++ if (!dev->cmd)
++ goto err_free_dev;
++
++ dev->resp = kmalloc(IO_BUFFER_LENGTH, GFP_KERNEL);
++ if (!dev->resp)
++ goto err_free_cmd;
++
+ INIT_LIST_HEAD(&dev->unlk_lst);
+ mutex_init(&dev->dev_lock);
+ dev->data = data;
+ dev->send_recv = send_recv;
+ if (check_opal_support(dev) != 0) {
+ pr_debug("Opal is not supported on this device\n");
+- kfree(dev);
+- return NULL;
++ goto err_free_resp;
+ }
+
+ return dev;
++
++err_free_resp:
++ kfree(dev->resp);
++
++err_free_cmd:
++ kfree(dev->cmd);
++
++err_free_dev:
++ kfree(dev);
++
++ return NULL;
+ }
+ EXPORT_SYMBOL(init_opal_dev);
+
+--
+2.35.1
+
--- /dev/null
+From c37e243a27f438840db3ffa6c05ce10c5a27e8f3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Nov 2022 15:04:33 +0800
+Subject: bnxt_en: Remove debugfs when pci_register_driver failed
+
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+
+[ Upstream commit 991aef4ee4f6eb999924f429b943441a32835c8f ]
+
+When pci_register_driver failed, we need to remove debugfs,
+which will caused a resource leak, fix it.
+
+Resource leak logs as follows:
+[ 52.184456] debugfs: Directory 'bnxt_en' with parent '/' already present!
+
+Fixes: cabfb09d87bd ("bnxt_en: add debugfs support for DIM")
+Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Reviewed-by: Michael Chan <michael.chan@broadcom.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+index db1864a3f64a..117f5cc7c180 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+@@ -13697,8 +13697,16 @@ static struct pci_driver bnxt_pci_driver = {
+
+ static int __init bnxt_init(void)
+ {
++ int err;
++
+ bnxt_debug_init();
+- return pci_register_driver(&bnxt_pci_driver);
++ err = pci_register_driver(&bnxt_pci_driver);
++ if (err) {
++ bnxt_debug_exit();
++ return err;
++ }
++
++ return 0;
+ }
+
+ static void __exit bnxt_exit(void)
+--
+2.35.1
+
--- /dev/null
+From 3d28f6afacfdedf56ae5911a7a8886a264b15303 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Nov 2022 13:11:31 +0800
+Subject: bpf: Fix memory leaks in __check_func_call
+
+From: Wang Yufen <wangyufen@huawei.com>
+
+[ Upstream commit eb86559a691cea5fa63e57a03ec3dc9c31e97955 ]
+
+kmemleak reports this issue:
+
+unreferenced object 0xffff88817139d000 (size 2048):
+ comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)
+ hex dump (first 32 bytes):
+ 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<0000000045f075f0>] kmalloc_trace+0x27/0xa0
+ [<0000000098b7c90a>] __check_func_call+0x316/0x1230
+ [<00000000b4c3c403>] check_helper_call+0x172e/0x4700
+ [<00000000aa3875b7>] do_check+0x21d8/0x45e0
+ [<000000001147357b>] do_check_common+0x767/0xaf0
+ [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0
+ [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940
+ [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650
+ [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0
+ [<00000000946ee250>] do_syscall_64+0x3b/0x90
+ [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
+
+The root case here is: In function prepare_func_exit(), the callee is
+not released in the abnormal scenario after "state->curframe--;". To
+fix, move "state->curframe--;" to the very bottom of the function,
+right when we free callee and reset frame[] pointer to NULL, as Andrii
+suggested.
+
+In addition, function __check_func_call() has a similar problem. In
+the abnormal scenario before "state->curframe++;", the callee also
+should be released by free_func_state().
+
+Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")
+Fixes: fd978bf7fd31 ("bpf: Add reference tracking to verifier")
+Signed-off-by: Wang Yufen <wangyufen@huawei.com>
+Link: https://lore.kernel.org/r/1667884291-15666-1-git-send-email-wangyufen@huawei.com
+Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/bpf/verifier.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
+index 8a73a165ac76..cceb29b0585f 100644
+--- a/kernel/bpf/verifier.c
++++ b/kernel/bpf/verifier.c
+@@ -5808,11 +5808,11 @@ static int __check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn
+ /* Transfer references to the callee */
+ err = copy_reference_state(callee, caller);
+ if (err)
+- return err;
++ goto err_out;
+
+ err = set_callee_state_cb(env, caller, callee, *insn_idx);
+ if (err)
+- return err;
++ goto err_out;
+
+ clear_caller_saved_regs(env, caller->regs);
+
+@@ -5829,6 +5829,11 @@ static int __check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn
+ print_verifier_state(env, callee);
+ }
+ return 0;
++
++err_out:
++ free_func_state(callee);
++ state->frame[state->curframe + 1] = NULL;
++ return err;
+ }
+
+ int map_set_for_each_callback_args(struct bpf_verifier_env *env,
+@@ -5966,8 +5971,7 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
+ return -EINVAL;
+ }
+
+- state->curframe--;
+- caller = state->frame[state->curframe];
++ caller = state->frame[state->curframe - 1];
+ if (callee->in_callback_fn) {
+ /* enforce R0 return value range [0, 1]. */
+ struct tnum range = tnum_range(0, 1);
+@@ -6006,7 +6010,7 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
+ }
+ /* clear everything in the callee */
+ free_func_state(callee);
+- state->frame[state->curframe + 1] = NULL;
++ state->frame[state->curframe--] = NULL;
+ return 0;
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 1223d4692d437bef78b58a20e13851452f582821 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 07:21:28 -0500
+Subject: bpf: Initialize same number of free nodes for each pcpu_freelist
+
+From: Xu Kuohai <xukuohai@huawei.com>
+
+[ Upstream commit 4b45cd81f737d79d0fbfc0d320a1e518e7f0bbf0 ]
+
+pcpu_freelist_populate() initializes nr_elems / num_possible_cpus() + 1
+free nodes for some CPUs, and then possibly one CPU with fewer nodes,
+followed by remaining cpus with 0 nodes. For example, when nr_elems == 256
+and num_possible_cpus() == 32, CPU 0~27 each gets 9 free nodes, CPU 28 gets
+4 free nodes, CPU 29~31 get 0 free nodes, while in fact each CPU should get
+8 nodes equally.
+
+This patch initializes nr_elems / num_possible_cpus() free nodes for each
+CPU firstly, then allocates the remaining free nodes by one for each CPU
+until no free nodes left.
+
+Fixes: e19494edab82 ("bpf: introduce percpu_freelist")
+Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
+Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
+Acked-by: Yonghong Song <yhs@fb.com>
+Link: https://lore.kernel.org/bpf/20221110122128.105214-1-xukuohai@huawei.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/bpf/percpu_freelist.c | 23 +++++++++++------------
+ 1 file changed, 11 insertions(+), 12 deletions(-)
+
+diff --git a/kernel/bpf/percpu_freelist.c b/kernel/bpf/percpu_freelist.c
+index 3d897de89061..bbab8bb4b2fd 100644
+--- a/kernel/bpf/percpu_freelist.c
++++ b/kernel/bpf/percpu_freelist.c
+@@ -102,22 +102,21 @@ void pcpu_freelist_populate(struct pcpu_freelist *s, void *buf, u32 elem_size,
+ u32 nr_elems)
+ {
+ struct pcpu_freelist_head *head;
+- int i, cpu, pcpu_entries;
++ unsigned int cpu, cpu_idx, i, j, n, m;
+
+- pcpu_entries = nr_elems / num_possible_cpus() + 1;
+- i = 0;
++ n = nr_elems / num_possible_cpus();
++ m = nr_elems % num_possible_cpus();
+
++ cpu_idx = 0;
+ for_each_possible_cpu(cpu) {
+-again:
+ head = per_cpu_ptr(s->freelist, cpu);
+- /* No locking required as this is not visible yet. */
+- pcpu_freelist_push_node(head, buf);
+- i++;
+- buf += elem_size;
+- if (i == nr_elems)
+- break;
+- if (i % pcpu_entries)
+- goto again;
++ j = n + (cpu_idx < m ? 1 : 0);
++ for (i = 0; i < j; i++) {
++ /* No locking required as this is not visible yet. */
++ pcpu_freelist_push_node(head, buf);
++ buf += elem_size;
++ }
++ cpu_idx++;
+ }
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 3b74cee070f7417990fd0049363ddb33926d016a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 16:16:20 +0800
+Subject: bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()
+
+From: Baisong Zhong <zhongbaisong@huawei.com>
+
+[ Upstream commit d3fd203f36d46aa29600a72d57a1b61af80e4a25 ]
+
+We got a syzkaller problem because of aarch64 alignment fault
+if KFENCE enabled. When the size from user bpf program is an odd
+number, like 399, 407, etc, it will cause the struct skb_shared_info's
+unaligned access. As seen below:
+
+ BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
+
+ Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
+ __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]
+ arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]
+ arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]
+ atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]
+ __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
+ skb_clone+0xf4/0x214 net/core/skbuff.c:1481
+ ____bpf_clone_redirect net/core/filter.c:2433 [inline]
+ bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420
+ bpf_prog_d3839dd9068ceb51+0x80/0x330
+ bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]
+ bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53
+ bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594
+ bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
+ __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
+ __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
+
+ kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512
+
+ allocated by task 15074 on cpu 0 at 1342.585390s:
+ kmalloc include/linux/slab.h:568 [inline]
+ kzalloc include/linux/slab.h:675 [inline]
+ bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191
+ bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512
+ bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
+ __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
+ __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
+ __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381
+
+To fix the problem, we adjust @size so that (@size + @hearoom) is a
+multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info
+is aligned to a cache line.
+
+Fixes: 1cf1cae963c2 ("bpf: introduce BPF_PROG_TEST_RUN command")
+Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Cc: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/bpf/20221102081620.1465154-1-zhongbaisong@huawei.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bpf/test_run.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
+index a9fb16b9c735..7583ee98c35b 100644
+--- a/net/bpf/test_run.c
++++ b/net/bpf/test_run.c
+@@ -259,6 +259,7 @@ static void *bpf_test_init(const union bpf_attr *kattr, u32 size,
+ if (user_size > size)
+ return ERR_PTR(-EMSGSIZE);
+
++ size = SKB_DATA_ALIGN(size);
+ data = kzalloc(size + headroom + tailroom, GFP_USER);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+--
+2.35.1
+
--- /dev/null
+From 516d56da763f7e69e5d65808b34f62cd08c9af8f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Nov 2022 10:45:09 +0200
+Subject: bridge: switchdev: Fix memory leaks when changing VLAN protocol
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 9d45921ee4cb364910097e7d1b7558559c2f9fd2 ]
+
+The bridge driver can offload VLANs to the underlying hardware either
+via switchdev or the 8021q driver. When the former is used, the VLAN is
+marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV'
+private flag.
+
+To avoid the memory leaks mentioned in the cited commit, the bridge
+driver will try to delete a VLAN via the 8021q driver if the VLAN is not
+marked with the previously mentioned flag.
+
+When the VLAN protocol of the bridge changes, switchdev drivers are
+notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but
+the 8021q driver is also called to add the existing VLANs with the new
+protocol and delete them with the old protocol.
+
+In case the VLANs were offloaded via switchdev, the above behavior is
+both redundant and buggy. Redundant because the VLANs are already
+programmed in hardware and drivers that support VLAN protocol change
+(currently only mlx5) change the protocol upon the switchdev attribute
+notification. Buggy because the 8021q driver is called despite these
+VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to
+memory leaks [1] when the VLANs are deleted.
+
+Fix by not calling the 8021q driver for VLANs that were already
+programmed via switchdev.
+
+[1]
+unreferenced object 0xffff8881f6771200 (size 256):
+ comm "ip", pid 446855, jiffies 4298238841 (age 55.240s)
+ hex dump (first 32 bytes):
+ 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<00000000012819ac>] vlan_vid_add+0x437/0x750
+ [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920
+ [<000000000632b56f>] br_changelink+0x3d6/0x13f0
+ [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0
+ [<00000000f6276baf>] rtnl_newlink+0x5f/0x90
+ [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00
+ [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340
+ [<0000000010588814>] netlink_unicast+0x438/0x710
+ [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40
+ [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0
+ [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0
+ [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0
+ [<00000000684f7e25>] __sys_sendmsg+0xab/0x130
+ [<000000004538b104>] do_syscall_64+0x3d/0x90
+ [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
+
+Fixes: 279737939a81 ("net: bridge: Fix VLANs memory leak")
+Reported-by: Vlad Buslov <vladbu@nvidia.com>
+Tested-by: Vlad Buslov <vladbu@nvidia.com>
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
+Link: https://lore.kernel.org/r/20221114084509.860831-1-idosch@nvidia.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bridge/br_vlan.c | 17 ++++++++++++++---
+ 1 file changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
+index 10e63ea6a13e..86441ff78a0f 100644
+--- a/net/bridge/br_vlan.c
++++ b/net/bridge/br_vlan.c
+@@ -904,6 +904,8 @@ int __br_vlan_set_proto(struct net_bridge *br, __be16 proto,
+ list_for_each_entry(p, &br->port_list, list) {
+ vg = nbp_vlan_group(p);
+ list_for_each_entry(vlan, &vg->vlan_list, vlist) {
++ if (vlan->priv_flags & BR_VLFLAG_ADDED_BY_SWITCHDEV)
++ continue;
+ err = vlan_vid_add(p->dev, proto, vlan->vid);
+ if (err)
+ goto err_filt;
+@@ -918,8 +920,11 @@ int __br_vlan_set_proto(struct net_bridge *br, __be16 proto,
+ /* Delete VLANs for the old proto from the device filter. */
+ list_for_each_entry(p, &br->port_list, list) {
+ vg = nbp_vlan_group(p);
+- list_for_each_entry(vlan, &vg->vlan_list, vlist)
++ list_for_each_entry(vlan, &vg->vlan_list, vlist) {
++ if (vlan->priv_flags & BR_VLFLAG_ADDED_BY_SWITCHDEV)
++ continue;
+ vlan_vid_del(p->dev, oldproto, vlan->vid);
++ }
+ }
+
+ return 0;
+@@ -928,13 +933,19 @@ int __br_vlan_set_proto(struct net_bridge *br, __be16 proto,
+ attr.u.vlan_protocol = ntohs(oldproto);
+ switchdev_port_attr_set(br->dev, &attr, NULL);
+
+- list_for_each_entry_continue_reverse(vlan, &vg->vlan_list, vlist)
++ list_for_each_entry_continue_reverse(vlan, &vg->vlan_list, vlist) {
++ if (vlan->priv_flags & BR_VLFLAG_ADDED_BY_SWITCHDEV)
++ continue;
+ vlan_vid_del(p->dev, proto, vlan->vid);
++ }
+
+ list_for_each_entry_continue_reverse(p, &br->port_list, list) {
+ vg = nbp_vlan_group(p);
+- list_for_each_entry(vlan, &vg->vlan_list, vlist)
++ list_for_each_entry(vlan, &vg->vlan_list, vlist) {
++ if (vlan->priv_flags & BR_VLFLAG_ADDED_BY_SWITCHDEV)
++ continue;
+ vlan_vid_del(p->dev, proto, vlan->vid);
++ }
+ }
+
+ return err;
+--
+2.35.1
+
--- /dev/null
+From f4ed7a341054e215887ae1d5bd1f9491d7020bbe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Nov 2022 17:27:01 +0300
+Subject: cifs: add check for returning value of SMB2_close_init
+
+From: Anastasia Belova <abelova@astralinux.ru>
+
+[ Upstream commit d520de6cb42e88a1d008b54f935caf9fc05951da ]
+
+If the returning value of SMB2_close_init is an error-value,
+exit the function.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: 352d96f3acc6 ("cifs: multichannel: move channel selection above transport layer")
+
+Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/cifs/smb2ops.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
+index 2d31860d56e9..30b2efafa2de 100644
+--- a/fs/cifs/smb2ops.c
++++ b/fs/cifs/smb2ops.c
+@@ -1371,6 +1371,8 @@ smb2_set_ea(const unsigned int xid, struct cifs_tcon *tcon,
+ rqst[2].rq_nvec = 1;
+ rc = SMB2_close_init(tcon, server,
+ &rqst[2], COMPOUND_FID, COMPOUND_FID, false);
++ if (rc)
++ goto sea_exit;
+ smb2_set_related(&rqst[2]);
+
+ rc = compound_send_recv(xid, ses, server,
+--
+2.35.1
+
--- /dev/null
+From e1677f5212108aca465b8077b90d9dd95813edfc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Nov 2022 17:10:27 +0300
+Subject: cifs: add check for returning value of SMB2_set_info_init
+
+From: Anastasia Belova <abelova@astralinux.ru>
+
+[ Upstream commit a51e5d293dd1c2e7bf6f7be788466cd9b5d280fb ]
+
+If the returning value of SMB2_set_info_init is an error-value,
+exit the function.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: 0967e5457954 ("cifs: use a compound for setting an xattr")
+
+Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/cifs/smb2ops.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
+index 30b2efafa2de..53e87466e3b2 100644
+--- a/fs/cifs/smb2ops.c
++++ b/fs/cifs/smb2ops.c
+@@ -1361,6 +1361,8 @@ smb2_set_ea(const unsigned int xid, struct cifs_tcon *tcon,
+ COMPOUND_FID, current->tgid,
+ FILE_FULL_EA_INFORMATION,
+ SMB2_O_INFO_FILE, 0, data, size);
++ if (rc)
++ goto sea_exit;
+ smb2_set_next_command(tcon, &rqst[1]);
+ smb2_set_related(&rqst[1]);
+
+--
+2.35.1
+
--- /dev/null
+From cab6d28273721330d8e8df6cc93884a686054752 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Nov 2022 18:39:34 +0800
+Subject: cifs: Fix wrong return value checking when GETFLAGS
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+[ Upstream commit 92bbd67a55fee50743b42825d1c016e7fd5c79f9 ]
+
+The return value of CIFSGetExtAttr is negative, should be checked
+with -EOPNOTSUPP rather than EOPNOTSUPP.
+
+Fixes: 64a5cfa6db94 ("Allow setting per-file compression via SMB2/3")
+Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/cifs/ioctl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/fs/cifs/ioctl.c b/fs/cifs/ioctl.c
+index 0359b604bdbc..71883ba9e567 100644
+--- a/fs/cifs/ioctl.c
++++ b/fs/cifs/ioctl.c
+@@ -342,7 +342,7 @@ long cifs_ioctl(struct file *filep, unsigned int command, unsigned long arg)
+ rc = put_user(ExtAttrBits &
+ FS_FL_USER_VISIBLE,
+ (int __user *)arg);
+- if (rc != EOPNOTSUPP)
++ if (rc != -EOPNOTSUPP)
+ break;
+ }
+ #endif /* CONFIG_CIFS_POSIX */
+@@ -371,7 +371,7 @@ long cifs_ioctl(struct file *filep, unsigned int command, unsigned long arg)
+ * pSMBFile->fid.netfid,
+ * extAttrBits,
+ * &ExtAttrMask);
+- * if (rc != EOPNOTSUPP)
++ * if (rc != -EOPNOTSUPP)
+ * break;
+ */
+
+--
+2.35.1
+
--- /dev/null
+From 6e02005550934bcb46f3ae15965192732d227354 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Nov 2022 16:16:43 +0300
+Subject: drbd: use after free in drbd_create_device()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Dan Carpenter <error27@gmail.com>
+
+[ Upstream commit a7a1598189228b5007369a9622ccdf587be0730f ]
+
+The drbd_destroy_connection() frees the "connection" so use the _safe()
+iterator to prevent a use after free.
+
+Fixes: b6f85ef9538b ("drbd: Iterate over all connections")
+Signed-off-by: Dan Carpenter <error27@gmail.com>
+Reviewed-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
+Link: https://lore.kernel.org/r/Y3Jd5iZRbNQ9w6gm@kili
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/drbd/drbd_main.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
+index d59af26d7703..f4e38c208b9f 100644
+--- a/drivers/block/drbd/drbd_main.c
++++ b/drivers/block/drbd/drbd_main.c
+@@ -2699,7 +2699,7 @@ static int init_submitter(struct drbd_device *device)
+ enum drbd_ret_code drbd_create_device(struct drbd_config_context *adm_ctx, unsigned int minor)
+ {
+ struct drbd_resource *resource = adm_ctx->resource;
+- struct drbd_connection *connection;
++ struct drbd_connection *connection, *n;
+ struct drbd_device *device;
+ struct drbd_peer_device *peer_device, *tmp_peer_device;
+ struct gendisk *disk;
+@@ -2815,7 +2815,7 @@ enum drbd_ret_code drbd_create_device(struct drbd_config_context *adm_ctx, unsig
+ return NO_ERROR;
+
+ out_idr_remove_from_resource:
+- for_each_connection(connection, resource) {
++ for_each_connection_safe(connection, n, resource) {
+ peer_device = idr_remove(&connection->peer_devices, vnr);
+ if (peer_device)
+ kref_put(&connection->kref, drbd_destroy_connection);
+--
+2.35.1
+
--- /dev/null
+From f97ce822f3fe633a29171cdfa06cbe37dcc58f96 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 15:07:15 +0800
+Subject: drm/drv: Fix potential memory leak in drm_dev_init()
+
+From: Shang XiaoJing <shangxiaojing@huawei.com>
+
+[ Upstream commit ff963634f7b2e0dc011349abb3fb81a0d074f443 ]
+
+drm_dev_init() will add drm_dev_init_release() as a callback. When
+drmm_add_action() failed, the release function won't be added. As the
+result, the ref cnt added by device_get() in drm_dev_init() won't be put
+by drm_dev_init_release(), which leads to the memleak. Use
+drmm_add_action_or_reset() instead of drmm_add_action() to prevent
+memleak.
+
+unreferenced object 0xffff88810bc0c800 (size 2048):
+ comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s)
+ hex dump (first 32 bytes):
+ e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................
+ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<.............
+ backtrace:
+ [<000000007251f72d>] __kmalloc+0x4b/0x1c0
+ [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0
+ [<000000004452a479>] platform_device_register_full+0x24/0x1c0
+ [<0000000089f4ea61>] 0xffffffffa0736051
+ [<00000000235b2441>] do_one_initcall+0x7a/0x380
+ [<0000000001a4a177>] do_init_module+0x5c/0x230
+ [<000000002bf8a8e2>] load_module+0x227d/0x2420
+ [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140
+ [<00000000c99fc324>] do_syscall_64+0x3f/0x90
+ [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
+
+Fixes: 2cbf7fc6718b ("drm: Use drmm_ for drm_dev_init cleanup")
+Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221101070716.9189-2-shangxiaojing@huawei.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/drm_drv.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
+index b3a1636d1b98..6f1791613757 100644
+--- a/drivers/gpu/drm/drm_drv.c
++++ b/drivers/gpu/drm/drm_drv.c
+@@ -614,7 +614,7 @@ static int drm_dev_init(struct drm_device *dev,
+ mutex_init(&dev->clientlist_mutex);
+ mutex_init(&dev->master_mutex);
+
+- ret = drmm_add_action(dev, drm_dev_init_release, NULL);
++ ret = drmm_add_action_or_reset(dev, drm_dev_init_release, NULL);
+ if (ret)
+ return ret;
+
+--
+2.35.1
+
--- /dev/null
+From 7d6d31457b3624de4aeac0f41b20bcc8731935b6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 15:07:16 +0800
+Subject: drm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()
+
+From: Shang XiaoJing <shangxiaojing@huawei.com>
+
+[ Upstream commit 4979524f5a2a8210e87fde2f642b0dc060860821 ]
+
+drm_vblank_init() call drmm_add_action_or_reset() with
+drm_vblank_init_release() as action. If __drmm_add_action() failed, will
+directly call drm_vblank_init_release() with the vblank whose worker is
+NULL. As the resule, a null-ptr-deref will happen in
+kthread_destroy_worker(). Add the NULL check before calling
+drm_vblank_destroy_worker().
+
+BUG: null-ptr-deref
+KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
+CPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty
+RIP: 0010:kthread_destroy_worker+0x25/0xb0
+ Call Trace:
+ <TASK>
+ drm_vblank_init_release+0x124/0x220 [drm]
+ ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm]
+ __drmm_add_action_or_reset+0x41/0x50 [drm]
+ drm_vblank_init+0x282/0x310 [drm]
+ vkms_init+0x35f/0x1000 [vkms]
+ ? 0xffffffffc4508000
+ ? lock_is_held_type+0xd7/0x130
+ ? __kmem_cache_alloc_node+0x1c2/0x2b0
+ ? lock_is_held_type+0xd7/0x130
+ ? 0xffffffffc4508000
+ do_one_initcall+0xd0/0x4f0
+ ...
+ do_syscall_64+0x35/0x80
+ entry_SYSCALL_64_after_hwframe+0x46/0xb0
+
+Fixes: 5e6c2b4f9161 ("drm/vblank: Add vblank works")
+Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221101070716.9189-3-shangxiaojing@huawei.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/drm_internal.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
+index d05e6a5b6687..f97a0875b9a1 100644
+--- a/drivers/gpu/drm/drm_internal.h
++++ b/drivers/gpu/drm/drm_internal.h
+@@ -104,7 +104,8 @@ static inline void drm_vblank_flush_worker(struct drm_vblank_crtc *vblank)
+
+ static inline void drm_vblank_destroy_worker(struct drm_vblank_crtc *vblank)
+ {
+- kthread_destroy_worker(vblank->worker);
++ if (vblank->worker)
++ kthread_destroy_worker(vblank->worker);
+ }
+
+ int drm_vblank_worker_init(struct drm_vblank_crtc *vblank);
+--
+2.35.1
+
--- /dev/null
+From b3a7b6eaf89be6d4104c26a1a4efc64c31998a6d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 31 Aug 2022 16:16:22 +0200
+Subject: drm/panel: simple: set bpc field for logic technologies displays
+
+From: Aishwarya Kothari <aishwarya.kothari@toradex.com>
+
+[ Upstream commit 876153ab068b2507a19aa3ef481f5b00a2cc780f ]
+
+In case bpc is not set for a panel it then throws a WARN(). Add bpc to
+the panels logictechno_lt170410_2whc and logictechno_lt161010_2nh.
+
+Fixes: 5728fe7fa539 ("drm/panel: simple: add display timings for logic technologies displays")
+Signed-off-by: Aishwarya Kothari <aishwarya.kothari@toradex.com>
+Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220831141622.39605-1-francesco.dolcini@toradex.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/panel/panel-simple.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
+index 1a9685eb8002..fb785f5a106a 100644
+--- a/drivers/gpu/drm/panel/panel-simple.c
++++ b/drivers/gpu/drm/panel/panel-simple.c
+@@ -3090,6 +3090,7 @@ static const struct display_timing logictechno_lt161010_2nh_timing = {
+ static const struct panel_desc logictechno_lt161010_2nh = {
+ .timings = &logictechno_lt161010_2nh_timing,
+ .num_timings = 1,
++ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+@@ -3119,6 +3120,7 @@ static const struct display_timing logictechno_lt170410_2whc_timing = {
+ static const struct panel_desc logictechno_lt170410_2whc = {
+ .timings = &logictechno_lt170410_2whc_timing,
+ .num_timings = 1,
++ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 136,
+--
+2.35.1
+
--- /dev/null
+From 930a62b272875416df12cd9f9261380fffa9362e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 17:44:45 +0800
+Subject: drm/vc4: kms: Fix IS_ERR() vs NULL check for vc4_kms
+
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+
+[ Upstream commit dba9e3467425800f9d3a14e8b6a0f85c731c1650 ]
+
+The drm_atomic_get_new_private_obj_state() function returns NULL
+on error path, drm_atomic_get_old_private_obj_state() function
+returns NULL on error path, too, they does not return error pointers.
+
+By the way, vc4_hvs_get_new/old_global_state() should return
+ERR_PTR(-EINVAL), otherwise there will be null-ptr-defer issue,
+such as follows:
+
+In function vc4_atomic_commit_tail():
+ |-- old_hvs_state = vc4_hvs_get_old_global_state(state); <-- return NULL
+ |-- if (WARN_ON(IS_ERR(old_hvs_state))) <-- no return
+ |-- unsigned long state_rate = max(old_hvs_state->core_clock_rate,
+ new_hvs_state->core_clock_rate); <-- null-ptr-defer
+
+Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit")
+Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221110094445.2930509-6-cuigaosheng1@huawei.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/vc4/vc4_kms.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
+index 6030d4a82155..1bb8bcc45d71 100644
+--- a/drivers/gpu/drm/vc4/vc4_kms.c
++++ b/drivers/gpu/drm/vc4/vc4_kms.c
+@@ -193,8 +193,8 @@ vc4_hvs_get_new_global_state(struct drm_atomic_state *state)
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_new_private_obj_state(state, &vc4->hvs_channels);
+- if (IS_ERR(priv_state))
+- return ERR_CAST(priv_state);
++ if (!priv_state)
++ return ERR_PTR(-EINVAL);
+
+ return to_vc4_hvs_state(priv_state);
+ }
+@@ -206,8 +206,8 @@ vc4_hvs_get_old_global_state(struct drm_atomic_state *state)
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_old_private_obj_state(state, &vc4->hvs_channels);
+- if (IS_ERR(priv_state))
+- return ERR_CAST(priv_state);
++ if (!priv_state)
++ return ERR_PTR(-EINVAL);
+
+ return to_vc4_hvs_state(priv_state);
+ }
+--
+2.35.1
+
--- /dev/null
+From 92aa1132edc6e6e912efd056c698cd6e52b83c6f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Nov 2022 20:16:19 +0100
+Subject: l2tp: Serialize access to sk_user_data with sk_callback_lock
+
+From: Jakub Sitnicki <jakub@cloudflare.com>
+
+[ Upstream commit b68777d54fac21fc833ec26ea1a2a84f975ab035 ]
+
+sk->sk_user_data has multiple users, which are not compatible with each
+other. Writers must synchronize by grabbing the sk->sk_callback_lock.
+
+l2tp currently fails to grab the lock when modifying the underlying tunnel
+socket fields. Fix it by adding appropriate locking.
+
+We err on the side of safety and grab the sk_callback_lock also inside the
+sk_destruct callback overridden by l2tp, even though there should be no
+refs allowing access to the sock at the time when sk_destruct gets called.
+
+v4:
+- serialize write to sk_user_data in l2tp sk_destruct
+
+v3:
+- switch from sock lock to sk_callback_lock
+- document write-protection for sk_user_data
+
+v2:
+- update Fixes to point to origin of the bug
+- use real names in Reported/Tested-by tags
+
+Cc: Tom Parkin <tparkin@katalix.com>
+Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
+Reported-by: Haowei Yan <g1042620637@gmail.com>
+Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/sock.h | 2 +-
+ net/l2tp/l2tp_core.c | 19 +++++++++++++------
+ 2 files changed, 14 insertions(+), 7 deletions(-)
+
+diff --git a/include/net/sock.h b/include/net/sock.h
+index e1a303e4f0f7..3e9db5146765 100644
+--- a/include/net/sock.h
++++ b/include/net/sock.h
+@@ -323,7 +323,7 @@ struct bpf_local_storage;
+ * @sk_tskey: counter to disambiguate concurrent tstamp requests
+ * @sk_zckey: counter to order MSG_ZEROCOPY notifications
+ * @sk_socket: Identd and reporting IO signals
+- * @sk_user_data: RPC layer private data
++ * @sk_user_data: RPC layer private data. Write-protected by @sk_callback_lock.
+ * @sk_frag: cached page frag
+ * @sk_peek_off: current peek_offset value
+ * @sk_send_head: front of stuff to transmit
+diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
+index 93271a2632b8..c77032638a06 100644
+--- a/net/l2tp/l2tp_core.c
++++ b/net/l2tp/l2tp_core.c
+@@ -1150,8 +1150,10 @@ static void l2tp_tunnel_destruct(struct sock *sk)
+ }
+
+ /* Remove hooks into tunnel socket */
++ write_lock_bh(&sk->sk_callback_lock);
+ sk->sk_destruct = tunnel->old_sk_destruct;
+ sk->sk_user_data = NULL;
++ write_unlock_bh(&sk->sk_callback_lock);
+
+ /* Call the original destructor */
+ if (sk->sk_destruct)
+@@ -1471,16 +1473,18 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net,
+ sock = sockfd_lookup(tunnel->fd, &ret);
+ if (!sock)
+ goto err;
+-
+- ret = l2tp_validate_socket(sock->sk, net, tunnel->encap);
+- if (ret < 0)
+- goto err_sock;
+ }
+
++ sk = sock->sk;
++ write_lock(&sk->sk_callback_lock);
++
++ ret = l2tp_validate_socket(sk, net, tunnel->encap);
++ if (ret < 0)
++ goto err_sock;
++
+ tunnel->l2tp_net = net;
+ pn = l2tp_pernet(net);
+
+- sk = sock->sk;
+ sock_hold(sk);
+ tunnel->sock = sk;
+
+@@ -1506,7 +1510,7 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net,
+
+ setup_udp_tunnel_sock(net, sock, &udp_cfg);
+ } else {
+- sk->sk_user_data = tunnel;
++ rcu_assign_sk_user_data(sk, tunnel);
+ }
+
+ tunnel->old_sk_destruct = sk->sk_destruct;
+@@ -1520,6 +1524,7 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net,
+ if (tunnel->fd >= 0)
+ sockfd_put(sock);
+
++ write_unlock(&sk->sk_callback_lock);
+ return 0;
+
+ err_sock:
+@@ -1527,6 +1532,8 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net,
+ sock_release(sock);
+ else
+ sockfd_put(sock);
++
++ write_unlock(&sk->sk_callback_lock);
+ err:
+ return ret;
+ }
+--
+2.35.1
+
--- /dev/null
+From 5172e28586735b43daaff27045d3f19472543ca2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 20:27:39 +0800
+Subject: MIPS: fix duplicate definitions for exported symbols
+
+From: Rongwei Zhang <pudh4418@gmail.com>
+
+[ Upstream commit 612d80784fdc0c2e2ee2e2d901a55ef2f72ebf4b ]
+
+Building with clang-14 fails with:
+
+AS arch/mips/kernel/relocate_kernel.o
+<unknown>:0: error: symbol 'kexec_args' is already defined
+<unknown>:0: error: symbol 'secondary_kexec_args' is already defined
+<unknown>:0: error: symbol 'kexec_start_address' is already defined
+<unknown>:0: error: symbol 'kexec_indirection_page' is already defined
+<unknown>:0: error: symbol 'relocate_new_kernel_size' is already defined
+
+It turns out EXPORT defined in asm/asm.h expands to a symbol definition,
+so there is no need to define these symbols again. Remove duplicated
+symbol definitions.
+
+Fixes: 7aa1c8f47e7e ("MIPS: kdump: Add support")
+Signed-off-by: Rongwei Zhang <pudh4418@gmail.com>
+Reviewed-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kernel/relocate_kernel.S | 15 +++++----------
+ 1 file changed, 5 insertions(+), 10 deletions(-)
+
+diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
+index cfde14b48fd8..f5b2ef979b43 100644
+--- a/arch/mips/kernel/relocate_kernel.S
++++ b/arch/mips/kernel/relocate_kernel.S
+@@ -145,8 +145,7 @@ LEAF(kexec_smp_wait)
+ * kexec_args[0..3] are used to prepare register values.
+ */
+
+-kexec_args:
+- EXPORT(kexec_args)
++EXPORT(kexec_args)
+ arg0: PTR_WD 0x0
+ arg1: PTR_WD 0x0
+ arg2: PTR_WD 0x0
+@@ -159,8 +158,7 @@ arg3: PTR_WD 0x0
+ * their registers a0-a3. secondary_kexec_args[0..3] are used
+ * to prepare register values.
+ */
+-secondary_kexec_args:
+- EXPORT(secondary_kexec_args)
++EXPORT(secondary_kexec_args)
+ s_arg0: PTR_WD 0x0
+ s_arg1: PTR_WD 0x0
+ s_arg2: PTR_WD 0x0
+@@ -171,19 +169,16 @@ kexec_flag:
+
+ #endif
+
+-kexec_start_address:
+- EXPORT(kexec_start_address)
++EXPORT(kexec_start_address)
+ PTR_WD 0x0
+ .size kexec_start_address, PTRSIZE
+
+-kexec_indirection_page:
+- EXPORT(kexec_indirection_page)
++EXPORT(kexec_indirection_page)
+ PTR_WD 0
+ .size kexec_indirection_page, PTRSIZE
+
+ relocate_new_kernel_end:
+
+-relocate_new_kernel_size:
+- EXPORT(relocate_new_kernel_size)
++EXPORT(relocate_new_kernel_size)
+ PTR_WD relocate_new_kernel_end - relocate_new_kernel
+ .size relocate_new_kernel_size, PTRSIZE
+--
+2.35.1
+
--- /dev/null
+From bf544208aae3dbfa8fe5fed7fba6c0d90e6436da Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Nov 2022 09:18:15 +0800
+Subject: MIPS: Loongson64: Add WARN_ON on kexec related kmalloc failed
+
+From: Liao Chang <liaochang1@huawei.com>
+
+[ Upstream commit fa706927f4722a2df723b2a28d139b1904a3e7fa ]
+
+Add WARN_ON on kexec related kmalloc failed, avoid to pass NULL pointer
+to following memcpy and loongson_kexec_prepare.
+
+Fixes: 6ce48897ce47 ("MIPS: Loongson64: Add kexec/kdump support")
+Signed-off-by: Liao Chang <liaochang1@huawei.com>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/loongson64/reset.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c
+index 758d5d26aaaa..e420800043b0 100644
+--- a/arch/mips/loongson64/reset.c
++++ b/arch/mips/loongson64/reset.c
+@@ -16,6 +16,7 @@
+ #include <asm/bootinfo.h>
+ #include <asm/idle.h>
+ #include <asm/reboot.h>
++#include <asm/bug.h>
+
+ #include <loongson.h>
+ #include <boot_param.h>
+@@ -159,8 +160,17 @@ static int __init mips_reboot_setup(void)
+
+ #ifdef CONFIG_KEXEC
+ kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
++ if (WARN_ON(!kexec_argv))
++ return -ENOMEM;
++
+ kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
++ if (WARN_ON(!kdump_argv))
++ return -ENOMEM;
++
+ kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL);
++ if (WARN_ON(!kexec_envp))
++ return -ENOMEM;
++
+ fw_arg1 = KEXEC_ARGV_ADDR;
+ memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE);
+
+--
+2.35.1
+
--- /dev/null
+From fc9cecbae7e2f3a20425583cde1edbbe531627e8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 19:38:23 +0800
+Subject: mISDN: fix misuse of put_device() in mISDN_register_device()
+
+From: Wang ShaoBo <bobo.shaobowang@huawei.com>
+
+[ Upstream commit 2d25107e111a85c56f601a5470f1780ec054e6ac ]
+
+We should not release reference by put_device() before calling device_initialize().
+
+Fixes: e7d1d4d9ac0d ("mISDN: fix possible memory leak in mISDN_register_device()")
+Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/isdn/mISDN/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/isdn/mISDN/core.c b/drivers/isdn/mISDN/core.c
+index 7ea0100f218a..90ee56d07a6e 100644
+--- a/drivers/isdn/mISDN/core.c
++++ b/drivers/isdn/mISDN/core.c
+@@ -222,7 +222,7 @@ mISDN_register_device(struct mISDNdevice *dev,
+
+ err = get_free_devid();
+ if (err < 0)
+- goto error1;
++ return err;
+ dev->id = err;
+
+ device_initialize(&dev->dev);
+--
+2.35.1
+
--- /dev/null
+From 0a215d2522aba480d898131fb01ed4cb75549385 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 21:28:32 +0800
+Subject: mISDN: fix possible memory leak in mISDN_dsp_element_register()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 98a2ac1ca8fd6eca6867726fe238d06e75eb1acd ]
+
+Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
+bus_id string array"), the name of device is allocated dynamically,
+use put_device() to give up the reference, so that the name can be
+freed in kobject_cleanup() when the refcount is 0.
+
+The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the
+kfree() is removed. list_del() is called in mISDN_dsp_dev_release(),
+so it need be initialized.
+
+Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Link: https://lore.kernel.org/r/20221109132832.3270119-1-yangyingliang@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/isdn/mISDN/dsp_pipeline.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/isdn/mISDN/dsp_pipeline.c b/drivers/isdn/mISDN/dsp_pipeline.c
+index c3b2c99b5cd5..cfbcd9e973c2 100644
+--- a/drivers/isdn/mISDN/dsp_pipeline.c
++++ b/drivers/isdn/mISDN/dsp_pipeline.c
+@@ -77,6 +77,7 @@ int mISDN_dsp_element_register(struct mISDN_dsp_element *elem)
+ if (!entry)
+ return -ENOMEM;
+
++ INIT_LIST_HEAD(&entry->list);
+ entry->elem = elem;
+
+ entry->dev.class = elements_class;
+@@ -107,7 +108,7 @@ int mISDN_dsp_element_register(struct mISDN_dsp_element *elem)
+ device_unregister(&entry->dev);
+ return ret;
+ err1:
+- kfree(entry);
++ put_device(&entry->dev);
+ return ret;
+ }
+ EXPORT_SYMBOL(mISDN_dsp_element_register);
+--
+2.35.1
+
--- /dev/null
+From 13c05597d7ccd8d7a8d12fb95727c9beb2a94e35 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Nov 2022 17:55:49 +0800
+Subject: net: ag71xx: call phylink_disconnect_phy if ag71xx_hw_enable() fail
+ in ag71xx_open()
+
+From: Liu Jian <liujian56@huawei.com>
+
+[ Upstream commit c9b895c6878bdb6789dc1d7af60fd10f4a9f1937 ]
+
+If ag71xx_hw_enable() fails, call phylink_disconnect_phy() to clean up.
+And if phylink_of_phy_connect() fails, nothing needs to be done.
+Compile tested only.
+
+Fixes: 892e09153fa3 ("net: ag71xx: port to phylink")
+Signed-off-by: Liu Jian <liujian56@huawei.com>
+Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Link: https://lore.kernel.org/r/20221114095549.40342-1-liujian56@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/atheros/ag71xx.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/atheros/ag71xx.c b/drivers/net/ethernet/atheros/ag71xx.c
+index 416a5c99db5a..7295244b78d0 100644
+--- a/drivers/net/ethernet/atheros/ag71xx.c
++++ b/drivers/net/ethernet/atheros/ag71xx.c
+@@ -1480,7 +1480,7 @@ static int ag71xx_open(struct net_device *ndev)
+ if (ret) {
+ netif_err(ag, link, ndev, "phylink_of_phy_connect filed with err: %i\n",
+ ret);
+- goto err;
++ return ret;
+ }
+
+ max_frame_len = ag71xx_max_frame_len(ndev->mtu);
+@@ -1501,6 +1501,7 @@ static int ag71xx_open(struct net_device *ndev)
+
+ err:
+ ag71xx_rings_cleanup(ag);
++ phylink_disconnect_phy(ag->phylink);
+ return ret;
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 2667e8a3c3c1a481cc374f8981157fb54158053a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 15:01:36 +0000
+Subject: net: bgmac: Drop free_netdev() from bgmac_enet_remove()
+
+From: Wei Yongjun <weiyongjun1@huawei.com>
+
+[ Upstream commit 6f928ab8ee9bfbcb0e631c47ea8a16c3d5116ff1 ]
+
+netdev is allocated in bgmac_alloc() with devm_alloc_etherdev() and will
+be auto released in ->remove and ->probe failure path. Using free_netdev()
+in bgmac_enet_remove() leads to double free.
+
+Fixes: 34a5102c3235 ("net: bgmac: allocate struct bgmac just once & don't copy it")
+Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
+
+Link: https://lore.kernel.org/r/20221109150136.2991171-1-weiyongjun@huaweicloud.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/bgmac.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
+index 6e8bc6726031..fa2a43d465db 100644
+--- a/drivers/net/ethernet/broadcom/bgmac.c
++++ b/drivers/net/ethernet/broadcom/bgmac.c
+@@ -1568,7 +1568,6 @@ void bgmac_enet_remove(struct bgmac *bgmac)
+ phy_disconnect(bgmac->net_dev->phydev);
+ netif_napi_del(&bgmac->napi);
+ bgmac_dma_free(bgmac);
+- free_netdev(bgmac->net_dev);
+ }
+ EXPORT_SYMBOL_GPL(bgmac_enet_remove);
+
+--
+2.35.1
+
--- /dev/null
+From e1732fac2466e371672cb7be75da2ef9d1305b8e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Nov 2022 09:47:34 +0800
+Subject: net: caif: fix double disconnect client in chnl_net_open()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 8fbb53c8bfd8c56ecf1f78dc821778b58f505503 ]
+
+When connecting to client timeout, disconnect client for twice in
+chnl_net_open(). Remove one. Compile tested only.
+
+Fixes: 2aa40aef9deb ("caif: Use link layer MTU instead of fixed MTU")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/caif/chnl_net.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
+index 414dc5671c45..2de6b44deb2c 100644
+--- a/net/caif/chnl_net.c
++++ b/net/caif/chnl_net.c
+@@ -310,9 +310,6 @@ static int chnl_net_open(struct net_device *dev)
+
+ if (result == 0) {
+ pr_debug("connect timeout\n");
+- caif_disconnect_client(dev_net(dev), &priv->chnl);
+- priv->state = CAIF_DISCONNECTED;
+- pr_debug("state disconnected\n");
+ result = -ETIMEDOUT;
+ goto error;
+ }
+--
+2.35.1
+
--- /dev/null
+From 83730ebd680280471ccbf9f92bc797a6b130350f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Nov 2022 23:10:20 +0200
+Subject: net: dsa: make dsa_master_ioctl() see through port_hwtstamp_get()
+ shims
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit ed1fe1bebe18884b11e5536b5ac42e3a48960835 ]
+
+There are multi-generational drivers like mv88e6xxx which have code like
+this:
+
+int mv88e6xxx_port_hwtstamp_get(struct dsa_switch *ds, int port,
+ struct ifreq *ifr)
+{
+ if (!chip->info->ptp_support)
+ return -EOPNOTSUPP;
+
+ ...
+}
+
+DSA wants to deny PTP timestamping on the master if the switch supports
+timestamping too. However it currently relies on the presence of the
+port_hwtstamp_get() callback to determine PTP capability, and this
+clearly does not work in that case (method is present but returns
+-EOPNOTSUPP).
+
+We should not deny PTP on the DSA master for those switches which truly
+do not support hardware timestamping.
+
+Create a dsa_port_supports_hwtstamp() method which actually probes for
+support by calling port_hwtstamp_get() and seeing whether that returned
+-EOPNOTSUPP or not.
+
+Fixes: f685e609a301 ("net: dsa: Deny PTP on master if switch supports it")
+Link: https://patchwork.kernel.org/project/netdevbpf/patch/20221110124345.3901389-1-festevam@gmail.com/
+Reported-by: Fabio Estevam <festevam@gmail.com>
+Reported-by: Steffen Bätz <steffen@innosonix.de>
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Tested-by: Fabio Estevam <festevam@denx.de>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/dsa/dsa_priv.h | 1 +
+ net/dsa/master.c | 3 +--
+ net/dsa/port.c | 16 ++++++++++++++++
+ 3 files changed, 18 insertions(+), 2 deletions(-)
+
+diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
+index a5c9bc7b66c6..e91265434354 100644
+--- a/net/dsa/dsa_priv.h
++++ b/net/dsa/dsa_priv.h
+@@ -198,6 +198,7 @@ static inline struct net_device *dsa_master_find_slave(struct net_device *dev,
+ }
+
+ /* port.c */
++bool dsa_port_supports_hwtstamp(struct dsa_port *dp, struct ifreq *ifr);
+ void dsa_port_set_tag_protocol(struct dsa_port *cpu_dp,
+ const struct dsa_device_ops *tag_ops);
+ int dsa_port_set_state(struct dsa_port *dp, u8 state, bool do_fast_age);
+diff --git a/net/dsa/master.c b/net/dsa/master.c
+index e8e19857621b..69ec510abe83 100644
+--- a/net/dsa/master.c
++++ b/net/dsa/master.c
+@@ -204,8 +204,7 @@ static int dsa_master_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
+ * switch in the tree that is PTP capable.
+ */
+ list_for_each_entry(dp, &dst->ports, list)
+- if (dp->ds->ops->port_hwtstamp_get ||
+- dp->ds->ops->port_hwtstamp_set)
++ if (dsa_port_supports_hwtstamp(dp, ifr))
+ return -EBUSY;
+ break;
+ }
+diff --git a/net/dsa/port.c b/net/dsa/port.c
+index a21015d6bd36..31e8a7a8c3e6 100644
+--- a/net/dsa/port.c
++++ b/net/dsa/port.c
+@@ -75,6 +75,22 @@ static bool dsa_port_can_configure_learning(struct dsa_port *dp)
+ return !err;
+ }
+
++bool dsa_port_supports_hwtstamp(struct dsa_port *dp, struct ifreq *ifr)
++{
++ struct dsa_switch *ds = dp->ds;
++ int err;
++
++ if (!ds->ops->port_hwtstamp_get || !ds->ops->port_hwtstamp_set)
++ return false;
++
++ /* "See through" shim implementations of the "get" method.
++ * This will clobber the ifreq structure, but we will either return an
++ * error, or the master will overwrite it with proper values.
++ */
++ err = ds->ops->port_hwtstamp_get(ds, dp->index, ifr);
++ return err != -EOPNOTSUPP;
++}
++
+ int dsa_port_set_state(struct dsa_port *dp, u8 state, bool do_fast_age)
+ {
+ struct dsa_switch *ds = dp->ds;
+--
+2.35.1
+
--- /dev/null
+From dd685dfeee8822ea7bc4a4574081cf4677494c55 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Nov 2022 02:56:59 +0000
+Subject: net: ena: Fix error handling in ena_init()
+
+From: Yuan Can <yuancan@huawei.com>
+
+[ Upstream commit d349e9be5a2c2d7588a2c4e4bfa0bb3dc1226769 ]
+
+The ena_init() won't destroy workqueue created by
+create_singlethread_workqueue() when pci_register_driver() failed.
+Call destroy_workqueue() when pci_register_driver() failed to prevent the
+resource leak.
+
+Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
+Signed-off-by: Yuan Can <yuancan@huawei.com>
+Acked-by: Shay Agroskin <shayagr@amazon.com>
+Link: https://lore.kernel.org/r/20221114025659.124726-1-yuancan@huawei.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/amazon/ena/ena_netdev.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
+index 8f08e0bae300..f032e58a4c3c 100644
+--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
++++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
+@@ -4583,13 +4583,19 @@ static struct pci_driver ena_pci_driver = {
+
+ static int __init ena_init(void)
+ {
++ int ret;
++
+ ena_wq = create_singlethread_workqueue(DRV_MODULE_NAME);
+ if (!ena_wq) {
+ pr_err("Failed to create workqueue\n");
+ return -ENOMEM;
+ }
+
+- return pci_register_driver(&ena_pci_driver);
++ ret = pci_register_driver(&ena_pci_driver);
++ if (ret)
++ destroy_workqueue(ena_wq);
++
++ return ret;
+ }
+
+ static void __exit ena_cleanup(void)
+--
+2.35.1
+
--- /dev/null
+From f42ba9fcc44237b4e2783510fc6ab2d558e8cc76 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 02:16:42 +0000
+Subject: net: hinic: Fix error handling in hinic_module_init()
+
+From: Yuan Can <yuancan@huawei.com>
+
+[ Upstream commit 8eab9be56cc6b702a445d2b6d0256aa0992316b3 ]
+
+A problem about hinic create debugfs failed is triggered with the
+following log given:
+
+ [ 931.419023] debugfs: Directory 'hinic' with parent '/' already present!
+
+The reason is that hinic_module_init() returns pci_register_driver()
+directly without checking its return value, if pci_register_driver()
+failed, it returns without destroy the newly created debugfs, resulting
+the debugfs of hinic can never be created later.
+
+ hinic_module_init()
+ hinic_dbg_register_debugfs() # create debugfs directory
+ pci_register_driver()
+ driver_register()
+ bus_add_driver()
+ priv = kzalloc(...) # OOM happened
+ # return without destroy debugfs directory
+
+Fix by removing debugfs when pci_register_driver() returns error.
+
+Fixes: 253ac3a97921 ("hinic: add support to query sq info")
+Signed-off-by: Yuan Can <yuancan@huawei.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Link: https://lore.kernel.org/r/20221110021642.80378-1-yuancan@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/huawei/hinic/hinic_main.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
+index 8c6ec7c25809..92fba9a0c371 100644
+--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
++++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
+@@ -1482,8 +1482,15 @@ static struct pci_driver hinic_driver = {
+
+ static int __init hinic_module_init(void)
+ {
++ int ret;
++
+ hinic_dbg_register_debugfs(HINIC_DRV_NAME);
+- return pci_register_driver(&hinic_driver);
++
++ ret = pci_register_driver(&hinic_driver);
++ if (ret)
++ hinic_dbg_unregister_debugfs();
++
++ return ret;
+ }
+
+ static void __exit hinic_module_exit(void)
+--
+2.35.1
+
--- /dev/null
+From 297e6e8fb2a8344592fcc4581042fc36620beae5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Nov 2022 16:20:48 +0800
+Subject: net: hns3: fix setting incorrect phy link ksettings for firmware in
+ resetting process
+
+From: Guangbin Huang <huangguangbin2@huawei.com>
+
+[ Upstream commit 510d7b6ae842e59ee00d57e5f07ac15131b6d899 ]
+
+Currently, if driver is in phy-imp(phy controlled by imp firmware) mode, as
+driver did not update phy link ksettings after initialization process or
+not update advertising when getting phy link ksettings from firmware, it
+may set incorrect phy link ksettings for firmware in resetting process.
+So fix it.
+
+Fixes: f5f2b3e4dcc0 ("net: hns3: add support for imp-controlled PHYs")
+Fixes: c5ef83cbb1e9 ("net: hns3: fix for phy_addr error in hclge_mac_mdio_config")
+Fixes: 2312e050f42b ("net: hns3: Fix for deadlock problem occurring when unregistering ae_algo")
+Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
+Signed-off-by: Hao Lan <lanhao@huawei.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+index 15d10775a757..2102b38b9c35 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+@@ -3172,6 +3172,7 @@ static int hclge_update_tp_port_info(struct hclge_dev *hdev)
+ hdev->hw.mac.autoneg = cmd.base.autoneg;
+ hdev->hw.mac.speed = cmd.base.speed;
+ hdev->hw.mac.duplex = cmd.base.duplex;
++ linkmode_copy(hdev->hw.mac.advertising, cmd.link_modes.advertising);
+
+ return 0;
+ }
+@@ -11669,9 +11670,12 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
+ if (ret)
+ goto err_msi_irq_uninit;
+
+- if (hdev->hw.mac.media_type == HNAE3_MEDIA_TYPE_COPPER &&
+- !hnae3_dev_phy_imp_supported(hdev)) {
+- ret = hclge_mac_mdio_config(hdev);
++ if (hdev->hw.mac.media_type == HNAE3_MEDIA_TYPE_COPPER) {
++ if (hnae3_dev_phy_imp_supported(hdev))
++ ret = hclge_update_tp_port_info(hdev);
++ else
++ ret = hclge_mac_mdio_config(hdev);
++
+ if (ret)
+ goto err_msi_irq_uninit;
+ }
+--
+2.35.1
+
--- /dev/null
+From 7a55e6ccf60b50923053771249e6cae233ed3ac8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 13 Nov 2022 09:29:29 +0000
+Subject: net: ionic: Fix error handling in ionic_init_module()
+
+From: Yuan Can <yuancan@huawei.com>
+
+[ Upstream commit 280c0f7cd0aa4d190619b18243110e052a90775c ]
+
+A problem about ionic create debugfs failed is triggered with the
+following log given:
+
+ [ 415.799514] debugfs: Directory 'ionic' with parent '/' already present!
+
+The reason is that ionic_init_module() returns ionic_bus_register_driver()
+directly without checking its return value, if ionic_bus_register_driver()
+failed, it returns without destroy the newly created debugfs, resulting
+the debugfs of ionic can never be created later.
+
+ ionic_init_module()
+ ionic_debugfs_create() # create debugfs directory
+ ionic_bus_register_driver()
+ pci_register_driver()
+ driver_register()
+ bus_add_driver()
+ priv = kzalloc(...) # OOM happened
+ # return without destroy debugfs directory
+
+Fix by removing debugfs when ionic_bus_register_driver() returns error.
+
+Fixes: fbfb8031533c ("ionic: Add hardware init and device commands")
+Signed-off-by: Yuan Can <yuancan@huawei.com>
+Acked-by: Shannon Nelson <snelson@pensando.io>
+Link: https://lore.kernel.org/r/20221113092929.19161-1-yuancan@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/pensando/ionic/ionic_main.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/pensando/ionic/ionic_main.c b/drivers/net/ethernet/pensando/ionic/ionic_main.c
+index 9ede66842118..538c024afed5 100644
+--- a/drivers/net/ethernet/pensando/ionic/ionic_main.c
++++ b/drivers/net/ethernet/pensando/ionic/ionic_main.c
+@@ -588,8 +588,14 @@ int ionic_port_reset(struct ionic *ionic)
+
+ static int __init ionic_init_module(void)
+ {
++ int ret;
++
+ ionic_debugfs_create();
+- return ionic_bus_register_driver();
++ ret = ionic_bus_register_driver();
++ if (ret)
++ ionic_debugfs_destroy();
++
++ return ret;
+ }
+
+ static void __exit ionic_cleanup_module(void)
+--
+2.35.1
+
--- /dev/null
+From dc823f4efb84ee4e3f6c8c0090b7d10108c8cc43 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 18:30:37 +0800
+Subject: net: liquidio: release resources when liquidio driver open failed
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 8979f428a4afc215e390006e5ea19fd4e22c7ca9 ]
+
+When liquidio driver open failed, it doesn't release resources. Compile
+tested only.
+
+Fixes: 5b07aee11227 ("liquidio: MSIX support for CN23XX")
+Fixes: dbc97bfd3918 ("net: liquidio: Add missing null pointer checks")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/cavium/liquidio/lio_main.c | 34 ++++++++++++++-----
+ 1 file changed, 26 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
+index 2907e13b9df6..7bd97d98afeb 100644
+--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
++++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
+@@ -1798,13 +1798,10 @@ static int liquidio_open(struct net_device *netdev)
+
+ ifstate_set(lio, LIO_IFSTATE_RUNNING);
+
+- if (OCTEON_CN23XX_PF(oct)) {
+- if (!oct->msix_on)
+- if (setup_tx_poll_fn(netdev))
+- return -1;
+- } else {
+- if (setup_tx_poll_fn(netdev))
+- return -1;
++ if (!OCTEON_CN23XX_PF(oct) || (OCTEON_CN23XX_PF(oct) && !oct->msix_on)) {
++ ret = setup_tx_poll_fn(netdev);
++ if (ret)
++ goto err_poll;
+ }
+
+ netif_tx_start_all_queues(netdev);
+@@ -1817,7 +1814,7 @@ static int liquidio_open(struct net_device *netdev)
+ /* tell Octeon to start forwarding packets to host */
+ ret = send_rx_ctrl_cmd(lio, 1);
+ if (ret)
+- return ret;
++ goto err_rx_ctrl;
+
+ /* start periodical statistics fetch */
+ INIT_DELAYED_WORK(&lio->stats_wk.work, lio_fetch_stats);
+@@ -1828,6 +1825,27 @@ static int liquidio_open(struct net_device *netdev)
+ dev_info(&oct->pci_dev->dev, "%s interface is opened\n",
+ netdev->name);
+
++ return 0;
++
++err_rx_ctrl:
++ if (!OCTEON_CN23XX_PF(oct) || (OCTEON_CN23XX_PF(oct) && !oct->msix_on))
++ cleanup_tx_poll_fn(netdev);
++err_poll:
++ if (lio->ptp_clock) {
++ ptp_clock_unregister(lio->ptp_clock);
++ lio->ptp_clock = NULL;
++ }
++
++ if (oct->props[lio->ifidx].napi_enabled == 1) {
++ list_for_each_entry_safe(napi, n, &netdev->napi_list, dev_list)
++ napi_disable(napi);
++
++ oct->props[lio->ifidx].napi_enabled = 0;
++
++ if (OCTEON_CN23XX_PF(oct))
++ oct->droq[0]->ops.poll_mode = 0;
++ }
++
+ return ret;
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 57208393bccd88b5270033b6799d140bbffcd8c9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Nov 2022 09:41:30 +0800
+Subject: net: macvlan: Use built-in RCU list checking
+
+From: Chuang Wang <nashuiliang@gmail.com>
+
+[ Upstream commit 5df1341ea822292275c56744aab9c536d75c33be ]
+
+hlist_for_each_entry_rcu() has built-in RCU and lock checking.
+
+Pass cond argument to hlist_for_each_entry_rcu() to silence false
+lockdep warning when CONFIG_PROVE_RCU_LIST is enabled.
+
+Execute as follow:
+
+ ip link add link eth0 type macvlan mode source macaddr add <MAC-ADDR>
+
+The rtnl_lock is held when macvlan_hash_lookup_source() or
+macvlan_fill_info_macaddr() are called in the non-RCU read side section.
+So, pass lockdep_rtnl_is_held() to silence false lockdep warning.
+
+Fixes: 79cf79abce71 ("macvlan: add source mode")
+Signed-off-by: Chuang Wang <nashuiliang@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/macvlan.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
+index cdc238dda1e1..7fb0ead7b1ef 100644
+--- a/drivers/net/macvlan.c
++++ b/drivers/net/macvlan.c
+@@ -141,7 +141,7 @@ static struct macvlan_source_entry *macvlan_hash_lookup_source(
+ u32 idx = macvlan_eth_hash(addr);
+ struct hlist_head *h = &vlan->port->vlan_source_hash[idx];
+
+- hlist_for_each_entry_rcu(entry, h, hlist) {
++ hlist_for_each_entry_rcu(entry, h, hlist, lockdep_rtnl_is_held()) {
+ if (ether_addr_equal_64bits(entry->addr, addr) &&
+ entry->vlan == vlan)
+ return entry;
+@@ -1635,7 +1635,7 @@ static int macvlan_fill_info_macaddr(struct sk_buff *skb,
+ struct hlist_head *h = &vlan->port->vlan_source_hash[i];
+ struct macvlan_source_entry *entry;
+
+- hlist_for_each_entry_rcu(entry, h, hlist) {
++ hlist_for_each_entry_rcu(entry, h, hlist, lockdep_rtnl_is_held()) {
+ if (entry->vlan != vlan)
+ continue;
+ if (nla_put(skb, IFLA_MACVLAN_MACADDR, ETH_ALEN, entry->addr))
+--
+2.35.1
+
--- /dev/null
+From 77f2760d108f7e715336ce9bb8f413c255eb93ab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Nov 2022 09:20:44 +0000
+Subject: net: mhi: Fix memory leak in mhi_net_dellink()
+
+From: Wei Yongjun <weiyongjun1@huawei.com>
+
+[ Upstream commit f7c125bd79f50ec6094761090be81d02726ec6f4 ]
+
+MHI driver registers network device without setting the
+needs_free_netdev flag, and does NOT call free_netdev() when
+unregisters network device, which causes a memory leak.
+
+This patch calls free_netdev() to fix it since netdev_priv
+is used after unregister.
+
+Fixes: 13adac032982 ("net: mhi_net: Register wwan_ops for link creation")
+Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/mhi_net.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/net/mhi_net.c b/drivers/net/mhi_net.c
+index aaa628f859fd..f84554aa02af 100644
+--- a/drivers/net/mhi_net.c
++++ b/drivers/net/mhi_net.c
+@@ -343,6 +343,8 @@ static void mhi_net_dellink(struct mhi_device *mhi_dev, struct net_device *ndev)
+
+ kfree_skb(mhi_netdev->skbagg_head);
+
++ free_netdev(ndev);
++
+ dev_set_drvdata(&mhi_dev->dev, NULL);
+ }
+
+--
+2.35.1
+
--- /dev/null
+From fb585ec0dc42470d32b1179cf5e16ca1ad28909d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Nov 2022 21:38:53 +0800
+Subject: net: microchip: sparx5: Fix potential null-ptr-deref in
+ sparx_stats_init() and sparx5_start()
+
+From: Shang XiaoJing <shangxiaojing@huawei.com>
+
+[ Upstream commit 639f5d006e36bb303f525d9479448c412b720c39 ]
+
+sparx_stats_init() calls create_singlethread_workqueue() and not
+checked the ret value, which may return NULL. And a null-ptr-deref may
+happen:
+
+sparx_stats_init()
+ create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL
+ queue_delayed_work()
+ queue_delayed_work_on()
+ __queue_delayed_work() # warning here, but continue
+ __queue_work() # access wq->flags, null-ptr-deref
+
+Check the ret value and return -ENOMEM if it is NULL. So as
+sparx5_start().
+
+Fixes: af4b11022e2d ("net: sparx5: add ethtool configuration and statistics support")
+Fixes: b37a1bae742f ("net: sparx5: add mactable support")
+Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c | 3 +++
+ drivers/net/ethernet/microchip/sparx5/sparx5_main.c | 3 +++
+ 2 files changed, 6 insertions(+)
+
+diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c b/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c
+index 10b866e9f726..060274caa4d0 100644
+--- a/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c
++++ b/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c
+@@ -1219,6 +1219,9 @@ int sparx_stats_init(struct sparx5 *sparx5)
+ snprintf(queue_name, sizeof(queue_name), "%s-stats",
+ dev_name(sparx5->dev));
+ sparx5->stats_queue = create_singlethread_workqueue(queue_name);
++ if (!sparx5->stats_queue)
++ return -ENOMEM;
++
+ INIT_DELAYED_WORK(&sparx5->stats_work, sparx5_check_stats_work);
+ queue_delayed_work(sparx5->stats_queue, &sparx5->stats_work,
+ SPX5_STATS_CHECK_DELAY);
+diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+index 5030dfca3879..435ac224e38e 100644
+--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
++++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+@@ -629,6 +629,9 @@ static int sparx5_start(struct sparx5 *sparx5)
+ snprintf(queue_name, sizeof(queue_name), "%s-mact",
+ dev_name(sparx5->dev));
+ sparx5->mact_queue = create_singlethread_workqueue(queue_name);
++ if (!sparx5->mact_queue)
++ return -ENOMEM;
++
+ INIT_DELAYED_WORK(&sparx5->mact_work, sparx5_mact_pull_work);
+ queue_delayed_work(sparx5->mact_queue, &sparx5->mact_work,
+ SPX5_MACT_PULL_DELAY);
+--
+2.35.1
+
--- /dev/null
+From e588514fdc3d946fbe2d7a624b1885ce7dcc40f5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 14:45:52 +0800
+Subject: net: stmmac: ensure tx function is not running in
+ stmmac_xdp_release()
+
+From: Mohd Faizal Abdul Rahim <faizal.abdul.rahim@intel.com>
+
+[ Upstream commit 77711683a50477de39757d67ab1a3638220d6860 ]
+
+When stmmac_xdp_release() is called, there is a possibility that tx
+function is still running on other queues which will lead to tx queue
+timed out and reset adapter.
+
+This commit ensure that tx function is not running xdp before release
+flow continue to run.
+
+Fixes: ac746c8520d9 ("net: stmmac: enhance XDP ZC driver level switching performance")
+Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
+Signed-off-by: Mohd Faizal Abdul Rahim <faizal.abdul.rahim@intel.com>
+Signed-off-by: Noor Azura Ahmad Tarmizi <noor.azura.ahmad.tarmizi@intel.com>
+Link: https://lore.kernel.org/r/20221110064552.22504-1-noor.azura.ahmad.tarmizi@linux.intel.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+index 6f579f498993..8590249d4468 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+@@ -6494,6 +6494,9 @@ void stmmac_xdp_release(struct net_device *dev)
+ struct stmmac_priv *priv = netdev_priv(dev);
+ u32 chan;
+
++ /* Ensure tx function is not running */
++ netif_tx_disable(dev);
++
+ /* Disable NAPI process */
+ stmmac_disable_all_queues(priv);
+
+--
+2.35.1
+
--- /dev/null
+From 39b6dd56f49bf0ca71c4bbe9ac72e272be9d2c3e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Nov 2022 14:22:25 +0000
+Subject: net: thunderbolt: Fix error handling in tbnet_init()
+
+From: Yuan Can <yuancan@huawei.com>
+
+[ Upstream commit f524b7289bbb0c8ffaa2ba3c34c146e43da54fb2 ]
+
+A problem about insmod thunderbolt-net failed is triggered with following
+log given while lsmod does not show thunderbolt_net:
+
+ insmod: ERROR: could not insert module thunderbolt-net.ko: File exists
+
+The reason is that tbnet_init() returns tb_register_service_driver()
+directly without checking its return value, if tb_register_service_driver()
+failed, it returns without removing property directory, resulting the
+property directory can never be created later.
+
+ tbnet_init()
+ tb_register_property_dir() # register property directory
+ tb_register_service_driver()
+ driver_register()
+ bus_add_driver()
+ priv = kzalloc(...) # OOM happened
+ # return without remove property directory
+
+Fix by remove property directory when tb_register_service_driver() returns
+error.
+
+Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
+Signed-off-by: Yuan Can <yuancan@huawei.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/thunderbolt.c | 19 ++++++++++++++-----
+ 1 file changed, 14 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/net/thunderbolt.c b/drivers/net/thunderbolt.c
+index ae2211998ded..129149640225 100644
+--- a/drivers/net/thunderbolt.c
++++ b/drivers/net/thunderbolt.c
+@@ -1377,12 +1377,21 @@ static int __init tbnet_init(void)
+ TBNET_MATCH_FRAGS_ID | TBNET_64K_FRAMES);
+
+ ret = tb_register_property_dir("network", tbnet_dir);
+- if (ret) {
+- tb_property_free_dir(tbnet_dir);
+- return ret;
+- }
++ if (ret)
++ goto err_free_dir;
++
++ ret = tb_register_service_driver(&tbnet_driver);
++ if (ret)
++ goto err_unregister;
+
+- return tb_register_service_driver(&tbnet_driver);
++ return 0;
++
++err_unregister:
++ tb_unregister_property_dir("network", tbnet_dir);
++err_free_dir:
++ tb_property_free_dir(tbnet_dir);
++
++ return ret;
+ }
+ module_init(tbnet_init);
+
+--
+2.35.1
+
--- /dev/null
+From 1c5831e17570d60ec254d5878d47a0cbf67de1f9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Nov 2022 11:05:19 +0000
+Subject: net/x25: Fix skb leak in x25_lapb_receive_frame()
+
+From: Wei Yongjun <weiyongjun1@huawei.com>
+
+[ Upstream commit 2929cceb2fcf0ded7182562e4888afafece82cce ]
+
+x25_lapb_receive_frame() using skb_copy() to get a private copy of
+skb, the new skb should be freed in the undersized/fragmented skb
+error handling path. Otherwise there is a memory leak.
+
+Fixes: cb101ed2c3c7 ("x25: Handle undersized/fragmented skbs")
+Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
+Acked-by: Martin Schiller <ms@dev.tdt.de>
+Link: https://lore.kernel.org/r/20221114110519.514538-1-weiyongjun@huaweicloud.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/x25/x25_dev.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/x25/x25_dev.c b/net/x25/x25_dev.c
+index 5259ef8f5242..748d8630ab58 100644
+--- a/net/x25/x25_dev.c
++++ b/net/x25/x25_dev.c
+@@ -117,7 +117,7 @@ int x25_lapb_receive_frame(struct sk_buff *skb, struct net_device *dev,
+
+ if (!pskb_may_pull(skb, 1)) {
+ x25_neigh_put(nb);
+- return 0;
++ goto drop;
+ }
+
+ switch (skb->data[0]) {
+--
+2.35.1
+
--- /dev/null
+From 4d00fb18aa843904c9ffc01ddd5496ab601428cf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 15:27:57 -0500
+Subject: nfp: change eeprom length to max length enumerators
+
+From: Jaco Coetzee <jaco.coetzee@corigine.com>
+
+[ Upstream commit f3a72878a3de720661b7ed0d6b7f7c506ddb8a52 ]
+
+Extend the size of QSFP EEPROM for types SSF8436 and SFF8636
+from 256 to 640 bytes in order to expose all the EEPROM pages by
+ethtool.
+
+For SFF-8636 and SFF-8436 specifications, the driver exposes
+256 bytes of EEPROM data for ethtool's get_module_eeprom()
+callback, resulting in "netlink error: Invalid argument" when
+an EEPROM read with an offset larger than 256 bytes is attempted.
+
+Changing the length enumerators to the _MAX_LEN
+variants exposes all 640 bytes of the EEPROM allowing upper
+pages 1, 2 and 3 to be read.
+
+Fixes: 96d971e307cc ("ethtool: Add fallback to get_module_eeprom from netlink command")
+Signed-off-by: Jaco Coetzee <jaco.coetzee@corigine.com>
+Reviewed-by: Louis Peens <louis.peens@corigine.com>
+Signed-off-by: Simon Horman <simon.horman@corigine.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
+index 62546d197bfd..865865adfefc 100644
+--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
++++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
+@@ -1264,15 +1264,15 @@ nfp_port_get_module_info(struct net_device *netdev,
+
+ if (data < 0x3) {
+ modinfo->type = ETH_MODULE_SFF_8436;
+- modinfo->eeprom_len = ETH_MODULE_SFF_8436_LEN;
++ modinfo->eeprom_len = ETH_MODULE_SFF_8436_MAX_LEN;
+ } else {
+ modinfo->type = ETH_MODULE_SFF_8636;
+- modinfo->eeprom_len = ETH_MODULE_SFF_8636_LEN;
++ modinfo->eeprom_len = ETH_MODULE_SFF_8636_MAX_LEN;
+ }
+ break;
+ case NFP_INTERFACE_QSFP28:
+ modinfo->type = ETH_MODULE_SFF_8636;
+- modinfo->eeprom_len = ETH_MODULE_SFF_8636_LEN;
++ modinfo->eeprom_len = ETH_MODULE_SFF_8636_MAX_LEN;
+ break;
+ default:
+ netdev_err(netdev, "Unsupported module 0x%x detected\n",
+--
+2.35.1
+
--- /dev/null
+From 1cb93c657d9db06eea54ade030074d624110d790 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 23 Sep 2022 19:52:08 +0100
+Subject: parport_pc: Avoid FIFO port location truncation
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+[ Upstream commit ab126f51c93a15093df604f661c9480854c005a3 ]
+
+Match the data type of a temporary holding a reference to the FIFO port
+with the type of the original reference coming from `struct parport',
+avoiding data truncation with LP64 ports such as SPARC64 that refer to
+PCI port I/O locations via their corresponding MMIO addresses and will
+therefore have non-zero bits in the high 32-bit part of the reference.
+And in any case it is cleaner to have the data types matching here.
+
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Link: https://lore.kernel.org/linux-pci/20220419033752.GA1101844@bhelgaas/
+Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209231912550.29493@angie.orcam.me.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/parport/parport_pc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
+index eda4ded4d5e5..925be41eeebe 100644
+--- a/drivers/parport/parport_pc.c
++++ b/drivers/parport/parport_pc.c
+@@ -468,7 +468,7 @@ static size_t parport_pc_fifo_write_block_pio(struct parport *port,
+ const unsigned char *bufp = buf;
+ size_t left = length;
+ unsigned long expire = jiffies + port->physport->cad->timeout;
+- const int fifo = FIFO(port);
++ const unsigned long fifo = FIFO(port);
+ int poll_for = 8; /* 80 usecs */
+ const struct parport_pc_private *priv = port->physport->private_data;
+ const int fifo_depth = priv->fifo_depth;
+--
+2.35.1
+
--- /dev/null
+From fa658a569dd990b9845bc9c2e468924261489c82 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 16:20:56 +0800
+Subject: pinctrl: devicetree: fix null pointer dereferencing in
+ pinctrl_dt_to_map
+
+From: Zeng Heng <zengheng4@huawei.com>
+
+[ Upstream commit 91d5c5060ee24fe8da88cd585bb43b843d2f0dce ]
+
+Here is the BUG report by KASAN about null pointer dereference:
+
+BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50
+Read of size 1 at addr 0000000000000000 by task python3/2640
+Call Trace:
+ strcmp
+ __of_find_property
+ of_find_property
+ pinctrl_dt_to_map
+
+kasprintf() would return NULL pointer when kmalloc() fail to allocate.
+So directly return ENOMEM, if kasprintf() return NULL pointer.
+
+Fixes: 57291ce295c0 ("pinctrl: core device tree mapping table parsing support")
+Signed-off-by: Zeng Heng <zengheng4@huawei.com>
+Link: https://lore.kernel.org/r/20221110082056.2014898-1-zengheng4@huawei.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pinctrl/devicetree.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
+index 3fb238714718..eac55fee5281 100644
+--- a/drivers/pinctrl/devicetree.c
++++ b/drivers/pinctrl/devicetree.c
+@@ -220,6 +220,8 @@ int pinctrl_dt_to_map(struct pinctrl *p, struct pinctrl_dev *pctldev)
+ for (state = 0; ; state++) {
+ /* Retrieve the pinctrl-* property */
+ propname = kasprintf(GFP_KERNEL, "pinctrl-%d", state);
++ if (!propname)
++ return -ENOMEM;
+ prop = of_find_property(np, propname, &size);
+ kfree(propname);
+ if (!prop) {
+--
+2.35.1
+
--- /dev/null
+From b64d25e1bf72811f3396d3004062be0f84c40188 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Oct 2022 14:17:23 +0200
+Subject: pinctrl: rockchip: list all pins in a possible mux route for PX30
+
+From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
+
+[ Upstream commit bee55f2e7a44e7a7676e264b42f026e34bd244d9 ]
+
+The mux routes are incomplete for the PX30. This was discovered because
+we had a HW design using cif-clkoutm1 with the correct pinmux in the
+Device Tree but the clock would still not work.
+
+There are actually two muxing required: the pin muxing (performed by the
+usual Device Tree pinctrl nodes) and the "function" muxing (m0 vs m1;
+performed by the mux routing inside the driver). The pin muxing was
+correct but the function muxing was not.
+
+This adds the missing pins and their configuration for the mux routes
+that are already specified in the driver.
+
+Note that there are some "conflicts": it is possible *in Device Tree* to
+(attempt to) mux the pins for e.g. clkoutm1 and clkinm0 at the same time
+but this is actually not possible in hardware (because both share the
+same bit for the function muxing). Since it is an impossible hardware
+design, it is not deemed necessary to prevent the user from attempting
+to "misconfigure" the pins/functions.
+
+Fixes: 87065ca9b8e5 ("pinctrl: rockchip: Add pinctrl support for PX30")
+Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
+Link: https://lore.kernel.org/r/20221017-upstream-px30-cif-clkoutm1-v1-0-4ea1389237f7@theobroma-systems.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pinctrl/pinctrl-rockchip.c | 40 ++++++++++++++++++++++++++++++
+ 1 file changed, 40 insertions(+)
+
+diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
+index bae6cc83ea36..25ec0d22f184 100644
+--- a/drivers/pinctrl/pinctrl-rockchip.c
++++ b/drivers/pinctrl/pinctrl-rockchip.c
+@@ -608,14 +608,54 @@ static void rockchip_get_recalced_mux(struct rockchip_pin_bank *bank, int pin,
+ }
+
+ static struct rockchip_mux_route_data px30_mux_route_data[] = {
++ RK_MUXROUTE_SAME(2, RK_PB4, 1, 0x184, BIT(16 + 7)), /* cif-d0m0 */
++ RK_MUXROUTE_SAME(3, RK_PA1, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d0m1 */
++ RK_MUXROUTE_SAME(2, RK_PB6, 1, 0x184, BIT(16 + 7)), /* cif-d1m0 */
++ RK_MUXROUTE_SAME(3, RK_PA2, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d1m1 */
+ RK_MUXROUTE_SAME(2, RK_PA0, 1, 0x184, BIT(16 + 7)), /* cif-d2m0 */
+ RK_MUXROUTE_SAME(3, RK_PA3, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d2m1 */
++ RK_MUXROUTE_SAME(2, RK_PA1, 1, 0x184, BIT(16 + 7)), /* cif-d3m0 */
++ RK_MUXROUTE_SAME(3, RK_PA5, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d3m1 */
++ RK_MUXROUTE_SAME(2, RK_PA2, 1, 0x184, BIT(16 + 7)), /* cif-d4m0 */
++ RK_MUXROUTE_SAME(3, RK_PA7, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d4m1 */
++ RK_MUXROUTE_SAME(2, RK_PA3, 1, 0x184, BIT(16 + 7)), /* cif-d5m0 */
++ RK_MUXROUTE_SAME(3, RK_PB0, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d5m1 */
++ RK_MUXROUTE_SAME(2, RK_PA4, 1, 0x184, BIT(16 + 7)), /* cif-d6m0 */
++ RK_MUXROUTE_SAME(3, RK_PB1, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d6m1 */
++ RK_MUXROUTE_SAME(2, RK_PA5, 1, 0x184, BIT(16 + 7)), /* cif-d7m0 */
++ RK_MUXROUTE_SAME(3, RK_PB4, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d7m1 */
++ RK_MUXROUTE_SAME(2, RK_PA6, 1, 0x184, BIT(16 + 7)), /* cif-d8m0 */
++ RK_MUXROUTE_SAME(3, RK_PB6, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d8m1 */
++ RK_MUXROUTE_SAME(2, RK_PA7, 1, 0x184, BIT(16 + 7)), /* cif-d9m0 */
++ RK_MUXROUTE_SAME(3, RK_PB7, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d9m1 */
++ RK_MUXROUTE_SAME(2, RK_PB7, 1, 0x184, BIT(16 + 7)), /* cif-d10m0 */
++ RK_MUXROUTE_SAME(3, RK_PC6, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d10m1 */
++ RK_MUXROUTE_SAME(2, RK_PC0, 1, 0x184, BIT(16 + 7)), /* cif-d11m0 */
++ RK_MUXROUTE_SAME(3, RK_PC7, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-d11m1 */
++ RK_MUXROUTE_SAME(2, RK_PB0, 1, 0x184, BIT(16 + 7)), /* cif-vsyncm0 */
++ RK_MUXROUTE_SAME(3, RK_PD1, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-vsyncm1 */
++ RK_MUXROUTE_SAME(2, RK_PB1, 1, 0x184, BIT(16 + 7)), /* cif-hrefm0 */
++ RK_MUXROUTE_SAME(3, RK_PD2, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-hrefm1 */
++ RK_MUXROUTE_SAME(2, RK_PB2, 1, 0x184, BIT(16 + 7)), /* cif-clkinm0 */
++ RK_MUXROUTE_SAME(3, RK_PD3, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-clkinm1 */
++ RK_MUXROUTE_SAME(2, RK_PB3, 1, 0x184, BIT(16 + 7)), /* cif-clkoutm0 */
++ RK_MUXROUTE_SAME(3, RK_PD0, 3, 0x184, BIT(16 + 7) | BIT(7)), /* cif-clkoutm1 */
+ RK_MUXROUTE_SAME(3, RK_PC6, 2, 0x184, BIT(16 + 8)), /* pdm-m0 */
+ RK_MUXROUTE_SAME(2, RK_PC6, 1, 0x184, BIT(16 + 8) | BIT(8)), /* pdm-m1 */
++ RK_MUXROUTE_SAME(3, RK_PD3, 2, 0x184, BIT(16 + 8)), /* pdm-sdi0m0 */
++ RK_MUXROUTE_SAME(2, RK_PC5, 2, 0x184, BIT(16 + 8) | BIT(8)), /* pdm-sdi0m1 */
+ RK_MUXROUTE_SAME(1, RK_PD3, 2, 0x184, BIT(16 + 10)), /* uart2-rxm0 */
+ RK_MUXROUTE_SAME(2, RK_PB6, 2, 0x184, BIT(16 + 10) | BIT(10)), /* uart2-rxm1 */
++ RK_MUXROUTE_SAME(1, RK_PD2, 2, 0x184, BIT(16 + 10)), /* uart2-txm0 */
++ RK_MUXROUTE_SAME(2, RK_PB4, 2, 0x184, BIT(16 + 10) | BIT(10)), /* uart2-txm1 */
+ RK_MUXROUTE_SAME(0, RK_PC1, 2, 0x184, BIT(16 + 9)), /* uart3-rxm0 */
+ RK_MUXROUTE_SAME(1, RK_PB7, 2, 0x184, BIT(16 + 9) | BIT(9)), /* uart3-rxm1 */
++ RK_MUXROUTE_SAME(0, RK_PC0, 2, 0x184, BIT(16 + 9)), /* uart3-txm0 */
++ RK_MUXROUTE_SAME(1, RK_PB6, 2, 0x184, BIT(16 + 9) | BIT(9)), /* uart3-txm1 */
++ RK_MUXROUTE_SAME(0, RK_PC2, 2, 0x184, BIT(16 + 9)), /* uart3-ctsm0 */
++ RK_MUXROUTE_SAME(1, RK_PB4, 2, 0x184, BIT(16 + 9) | BIT(9)), /* uart3-ctsm1 */
++ RK_MUXROUTE_SAME(0, RK_PC3, 2, 0x184, BIT(16 + 9)), /* uart3-rtsm0 */
++ RK_MUXROUTE_SAME(1, RK_PB5, 2, 0x184, BIT(16 + 9) | BIT(9)), /* uart3-rtsm1 */
+ };
+
+ static struct rockchip_mux_route_data rk3128_mux_route_data[] = {
+--
+2.35.1
+
--- /dev/null
+From 3a1501c982dd4febff505a6c8c12ff7f74dbd886 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 13 Nov 2022 19:59:50 +0100
+Subject: platform/surface: aggregator: Do not check for repeated unsequenced
+ packets
+
+From: Maximilian Luz <luzmaximilian@gmail.com>
+
+[ Upstream commit d9a477f643eb3de71fbea5ae6103b800ceb8f547 ]
+
+Currently, we check any received packet whether we have already seen it
+previously, regardless of the packet type (sequenced / unsequenced). We
+do this by checking the sequence number. This assumes that sequence
+numbers are valid for both sequenced and unsequenced packets. However,
+this assumption appears to be incorrect.
+
+On some devices, the sequence number field of unsequenced packets (in
+particular HID input events on the Surface Pro 9) is always zero. As a
+result, the current retransmission check kicks in and discards all but
+the first unsequenced packet, breaking (among other things) keyboard and
+touchpad input.
+
+Note that we have, so far, only seen packets being retransmitted in
+sequenced communication. In particular, this happens when there is an
+ACK timeout, causing the EC (or us) to re-send the packet waiting for an
+ACK. Arguably, retransmission / duplication of unsequenced packets
+should not be an issue as there is no logical condition (such as an ACK
+timeout) to determine when a packet should be sent again.
+
+Therefore, remove the retransmission check for unsequenced packets
+entirely to resolve the issue.
+
+Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
+Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
+Link: https://lore.kernel.org/r/20221113185951.224759-1-luzmaximilian@gmail.com
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../surface/aggregator/ssh_packet_layer.c | 24 +++++++++++++++----
+ 1 file changed, 20 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/platform/surface/aggregator/ssh_packet_layer.c b/drivers/platform/surface/aggregator/ssh_packet_layer.c
+index 8a4451c1ffe5..a652c2763175 100644
+--- a/drivers/platform/surface/aggregator/ssh_packet_layer.c
++++ b/drivers/platform/surface/aggregator/ssh_packet_layer.c
+@@ -1596,16 +1596,32 @@ static void ssh_ptl_timeout_reap(struct work_struct *work)
+ ssh_ptl_tx_wakeup_packet(ptl);
+ }
+
+-static bool ssh_ptl_rx_retransmit_check(struct ssh_ptl *ptl, u8 seq)
++static bool ssh_ptl_rx_retransmit_check(struct ssh_ptl *ptl, const struct ssh_frame *frame)
+ {
+ int i;
+
++ /*
++ * Ignore unsequenced packets. On some devices (notably Surface Pro 9),
++ * unsequenced events will always be sent with SEQ=0x00. Attempting to
++ * detect retransmission would thus just block all events.
++ *
++ * While sequence numbers would also allow detection of retransmitted
++ * packets in unsequenced communication, they have only ever been used
++ * to cover edge-cases in sequenced transmission. In particular, the
++ * only instance of packets being retransmitted (that we are aware of)
++ * is due to an ACK timeout. As this does not happen in unsequenced
++ * communication, skip the retransmission check for those packets
++ * entirely.
++ */
++ if (frame->type == SSH_FRAME_TYPE_DATA_NSQ)
++ return false;
++
+ /*
+ * Check if SEQ has been seen recently (i.e. packet was
+ * re-transmitted and we should ignore it).
+ */
+ for (i = 0; i < ARRAY_SIZE(ptl->rx.blocked.seqs); i++) {
+- if (likely(ptl->rx.blocked.seqs[i] != seq))
++ if (likely(ptl->rx.blocked.seqs[i] != frame->seq))
+ continue;
+
+ ptl_dbg(ptl, "ptl: ignoring repeated data packet\n");
+@@ -1613,7 +1629,7 @@ static bool ssh_ptl_rx_retransmit_check(struct ssh_ptl *ptl, u8 seq)
+ }
+
+ /* Update list of blocked sequence IDs. */
+- ptl->rx.blocked.seqs[ptl->rx.blocked.offset] = seq;
++ ptl->rx.blocked.seqs[ptl->rx.blocked.offset] = frame->seq;
+ ptl->rx.blocked.offset = (ptl->rx.blocked.offset + 1)
+ % ARRAY_SIZE(ptl->rx.blocked.seqs);
+
+@@ -1624,7 +1640,7 @@ static void ssh_ptl_rx_dataframe(struct ssh_ptl *ptl,
+ const struct ssh_frame *frame,
+ const struct ssam_span *payload)
+ {
+- if (ssh_ptl_rx_retransmit_check(ptl, frame->seq))
++ if (ssh_ptl_rx_retransmit_check(ptl, frame))
+ return;
+
+ ptl->ops.data_received(ptl, payload);
+--
+2.35.1
+
--- /dev/null
+From ca04541cd816a689e3f093ffbec3ac5f1c41c4f9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 17:31:44 +0100
+Subject: platform/x86/intel: pmc: Don't unconditionally attach Intel PMC when
+ virtualized
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Roger Pau Monné <roger.pau@citrix.com>
+
+[ Upstream commit 2dbfb3f33350e1e868d3d7ed4c176d8777150878 ]
+
+The current logic in the Intel PMC driver will forcefully attach it
+when detecting any CPU on the intel_pmc_core_platform_ids array,
+even if the matching ACPI device is not present.
+
+There's no checking in pmc_core_probe() to assert that the PMC device
+is present, and hence on virtualized environments the PMC device
+probes successfully, even if the underlying registers are not present.
+Before commit 21ae43570940 ("platform/x86: intel_pmc_core: Substitute PCI
+with CPUID enumeration") the driver would check for the presence of a
+specific PCI device, and that prevented the driver from attaching when
+running virtualized.
+
+Fix by only forcefully attaching the PMC device when not running
+virtualized. Note that virtualized platforms can still get the device
+to load if the appropriate ACPI device is present on the tables
+provided to the VM.
+
+Make an exception for the Xen initial domain, which does have full
+hardware access, and hence can attach to the PMC if present.
+
+Fixes: 21ae43570940 ("platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration")
+Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
+Acked-by: David E. Box <david.e.box@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://lore.kernel.org/r/20221110163145.80374-1-roger.pau@citrix.com
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/platform/x86/intel/pmc/pltdrv.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+diff --git a/drivers/platform/x86/intel/pmc/pltdrv.c b/drivers/platform/x86/intel/pmc/pltdrv.c
+index 15ca8afdd973..ddfba38c2104 100644
+--- a/drivers/platform/x86/intel/pmc/pltdrv.c
++++ b/drivers/platform/x86/intel/pmc/pltdrv.c
+@@ -18,6 +18,8 @@
+ #include <asm/cpu_device_id.h>
+ #include <asm/intel-family.h>
+
++#include <xen/xen.h>
++
+ static void intel_pmc_core_release(struct device *dev)
+ {
+ kfree(dev);
+@@ -53,6 +55,13 @@ static int __init pmc_core_platform_init(void)
+ if (acpi_dev_present("INT33A1", NULL, -1))
+ return -ENODEV;
+
++ /*
++ * Skip forcefully attaching the device for VMs. Make an exception for
++ * Xen dom0, which does have full hardware access.
++ */
++ if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR) && !xen_initial_domain())
++ return -ENODEV;
++
+ if (!x86_match_cpu(intel_pmc_core_platform_ids))
+ return -ENODEV;
+
+--
+2.35.1
+
--- /dev/null
+From e925f4fda2f6392d3f43556552cc1c0ac8419c32 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Nov 2022 20:48:28 +0800
+Subject: scsi: scsi_transport_sas: Fix error handling in sas_phy_add()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 5d7bebf2dfb0dc97aac1fbace0910e557ecdb16f ]
+
+If transport_add_device() fails in sas_phy_add(), the kernel will crash
+trying to delete the device in transport_remove_device() called from
+sas_remove_host().
+
+Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108
+CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173
+pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : device_del+0x54/0x3d0
+lr : device_del+0x37c/0x3d0
+Call trace:
+ device_del+0x54/0x3d0
+ attribute_container_class_device_del+0x28/0x38
+ transport_remove_classdev+0x6c/0x80
+ attribute_container_device_trigger+0x108/0x110
+ transport_remove_device+0x28/0x38
+ sas_phy_delete+0x30/0x60 [scsi_transport_sas]
+ do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas]
+ device_for_each_child+0x68/0xb0
+ sas_remove_children+0x40/0x50 [scsi_transport_sas]
+ sas_remove_host+0x20/0x38 [scsi_transport_sas]
+ hisi_sas_remove+0x40/0x68 [hisi_sas_main]
+ hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw]
+ platform_remove+0x2c/0x60
+
+Fix this by checking and handling return value of transport_add_device()
+in sas_phy_add().
+
+Fixes: c7ebbbce366c ("[SCSI] SAS transport class")
+Suggested-by: John Garry <john.g.garry@oracle.com>
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Link: https://lore.kernel.org/r/20221107124828.115557-1-yangyingliang@huawei.com
+Reviewed-by: John Garry <john.g.garry@oracle.com>
+Reviewed-by: Jason Yan <yanaijie@huawei.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/scsi_transport_sas.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c
+index 4a96fb05731d..c6256fdc24b1 100644
+--- a/drivers/scsi/scsi_transport_sas.c
++++ b/drivers/scsi/scsi_transport_sas.c
+@@ -716,12 +716,17 @@ int sas_phy_add(struct sas_phy *phy)
+ int error;
+
+ error = device_add(&phy->dev);
+- if (!error) {
+- transport_add_device(&phy->dev);
+- transport_configure_device(&phy->dev);
++ if (error)
++ return error;
++
++ error = transport_add_device(&phy->dev);
++ if (error) {
++ device_del(&phy->dev);
++ return error;
+ }
++ transport_configure_device(&phy->dev);
+
+- return error;
++ return 0;
+ }
+ EXPORT_SYMBOL(sas_phy_add);
+
+--
+2.35.1
+
--- /dev/null
+From 7ff6de531ccfbdb7f9db7996195230009d3e0cb6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 24 Oct 2022 09:36:13 +0300
+Subject: serial: 8250: omap: Fix missing PM runtime calls for
+ omap8250_set_mctrl()
+
+From: Tony Lindgren <tony@atomide.com>
+
+[ Upstream commit 93810191f5d23652c0b8a1a9b3a4a89d6fd5063e ]
+
+There are cases where omap8250_set_mctrl() may get called after the
+UART has already autoidled causing an asynchronous external abort.
+
+This can happen on ttyport_open():
+
+mem_serial_in from omap8250_set_mctrl+0x38/0xa0
+omap8250_set_mctrl from uart_update_mctrl+0x4c/0x58
+uart_update_mctrl from uart_dtr_rts+0x60/0xa8
+uart_dtr_rts from tty_port_block_til_ready+0xd0/0x2a8
+tty_port_block_til_ready from uart_open+0x14/0x1c
+uart_open from ttyport_open+0x64/0x148
+
+And on ttyport_close():
+
+omap8250_set_mctrl from uart_update_mctrl+0x3c/0x48
+uart_update_mctrl from uart_dtr_rts+0x54/0x9c
+uart_dtr_rts from tty_port_shutdown+0x78/0x9c
+tty_port_shutdown from tty_port_close+0x3c/0x74
+tty_port_close from ttyport_close+0x40/0x58
+
+It can also happen on disassociate_ctty() calling uart_shutdown()
+that ends up calling omap8250_set_mctrl().
+
+Let's fix the issue by adding missing PM runtime calls to
+omap8250_set_mctrl(). To do this, we need to add __omap8250_set_mctrl()
+that can be called from both omap8250_set_mctrl(), and from runtime PM
+resume path when restoring the registers.
+
+Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
+Reported-by: Merlijn Wajer <merlijn@wizzup.org>
+Reported-by: Romain Naour <romain.naour@smile.fr>
+Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
+Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Depends-on: dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
+Link: https://lore.kernel.org/r/20221024063613.25943-1-tony@atomide.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/8250/8250_omap.c | 22 ++++++++++++++++++++--
+ 1 file changed, 20 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
+index 806f7806d3ca..e5d71c99c4e7 100644
+--- a/drivers/tty/serial/8250/8250_omap.c
++++ b/drivers/tty/serial/8250/8250_omap.c
+@@ -157,7 +157,11 @@ static u32 uart_read(struct uart_8250_port *up, u32 reg)
+ return readl(up->port.membase + (reg << up->port.regshift));
+ }
+
+-static void omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
++/*
++ * Called on runtime PM resume path from omap8250_restore_regs(), and
++ * omap8250_set_mctrl().
++ */
++static void __omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
+ {
+ struct uart_8250_port *up = up_to_u8250p(port);
+ struct omap8250_priv *priv = up->port.private_data;
+@@ -181,6 +185,20 @@ static void omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
+ }
+ }
+
++static void omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
++{
++ int err;
++
++ err = pm_runtime_resume_and_get(port->dev);
++ if (err)
++ return;
++
++ __omap8250_set_mctrl(port, mctrl);
++
++ pm_runtime_mark_last_busy(port->dev);
++ pm_runtime_put_autosuspend(port->dev);
++}
++
+ /*
+ * Work Around for Errata i202 (2430, 3430, 3630, 4430 and 4460)
+ * The access to uart register after MDR1 Access
+@@ -341,7 +359,7 @@ static void omap8250_restore_regs(struct uart_8250_port *up)
+
+ omap8250_update_mdr1(up, priv);
+
+- up->port.ops->set_mctrl(&up->port, up->port.mctrl);
++ __omap8250_set_mctrl(&up->port, up->port.mctrl);
+
+ if (up->port.rs485.flags & SER_RS485_ENABLED)
+ serial8250_em485_stop_tx(up);
+--
+2.35.1
+
--- /dev/null
+From 6ea361b4bd6d8951e196838671030080be0f0cc9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Oct 2022 13:58:13 +0300
+Subject: serial: 8250: omap: Fix unpaired pm_runtime_put_sync() in
+ omap8250_remove()
+
+From: Tony Lindgren <tony@atomide.com>
+
+[ Upstream commit e3f0c638f428fd66b5871154b62706772045f91a ]
+
+On remove, we get an error for "Runtime PM usage count underflow!". I guess
+this driver is mostly built-in, and this issue has gone unnoticed for a
+while. Somehow I did not catch this issue with my earlier fix done with
+commit 4e0f5cc65098 ("serial: 8250_omap: Fix probe and remove for PM
+runtime").
+
+Fixes: 4e0f5cc65098 ("serial: 8250_omap: Fix probe and remove for PM runtime")
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Depends-on: dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
+Link: https://lore.kernel.org/r/20221028105813.54290-1-tony@atomide.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/8250/8250_omap.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
+index 5707d86cac76..f3f54cb0cfca 100644
+--- a/drivers/tty/serial/8250/8250_omap.c
++++ b/drivers/tty/serial/8250/8250_omap.c
+@@ -1475,6 +1475,11 @@ static int omap8250_probe(struct platform_device *pdev)
+ static int omap8250_remove(struct platform_device *pdev)
+ {
+ struct omap8250_priv *priv = platform_get_drvdata(pdev);
++ int err;
++
++ err = pm_runtime_resume_and_get(&pdev->dev);
++ if (err)
++ return err;
+
+ pm_runtime_dont_use_autosuspend(&pdev->dev);
+ pm_runtime_put_sync(&pdev->dev);
+--
+2.35.1
+
--- /dev/null
+From e06b776ad84e1f390aeb35f0b585070c46eb3008 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Oct 2022 14:00:44 +0300
+Subject: serial: 8250: omap: Flush PM QOS work on remove
+
+From: Tony Lindgren <tony@atomide.com>
+
+[ Upstream commit d0b68629bd2fb61e0171a62f2e8da3db322f5cf6 ]
+
+Rebinding 8250_omap in a loop will at some point produce a warning for
+kernel/power/qos.c:296 cpu_latency_qos_update_request() with error
+"cpu_latency_qos_update_request called for unknown object". Let's flush
+the possibly pending PM QOS work scheduled from omap8250_runtime_suspend()
+before we disable runtime PM.
+
+Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Link: https://lore.kernel.org/r/20221028110044.54719-1-tony@atomide.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/8250/8250_omap.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
+index f3f54cb0cfca..469fdb91830e 100644
+--- a/drivers/tty/serial/8250/8250_omap.c
++++ b/drivers/tty/serial/8250/8250_omap.c
+@@ -1483,6 +1483,7 @@ static int omap8250_remove(struct platform_device *pdev)
+
+ pm_runtime_dont_use_autosuspend(&pdev->dev);
+ pm_runtime_put_sync(&pdev->dev);
++ flush_work(&priv->qos_work);
+ pm_runtime_disable(&pdev->dev);
+ serial8250_unregister_port(priv->line);
+ cpu_latency_qos_remove_request(&priv->pm_qos_request);
+--
+2.35.1
+
--- /dev/null
+From bc766d73dd56b03bf709b0604c920bc547c17b2d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 13 Oct 2022 13:23:39 +0200
+Subject: serial: 8250_omap: remove wait loop from Errata i202 workaround
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
+
+[ Upstream commit e828e56684d61b17317e0cfdef83791fa61cb76b ]
+
+We were occasionally seeing the "Errata i202: timedout" on an AM335x
+board when repeatedly opening and closing a UART connected to an active
+sender. As new input may arrive at any time, it is possible to miss the
+"RX FIFO empty" condition, forcing the loop to wait until it times out.
+
+Nothing in the i202 Advisory states that such a wait is even necessary;
+other FIFO clear functions like serial8250_clear_fifos() do not wait
+either. For this reason, it seems safe to remove the wait, fixing the
+mentioned issue.
+
+Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
+Link: https://lore.kernel.org/r/20221013112339.2540767-1-matthias.schiffer@ew.tq-group.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/8250/8250_omap.c | 17 -----------------
+ 1 file changed, 17 deletions(-)
+
+diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
+index e5d71c99c4e7..5707d86cac76 100644
+--- a/drivers/tty/serial/8250/8250_omap.c
++++ b/drivers/tty/serial/8250/8250_omap.c
+@@ -211,27 +211,10 @@ static void omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
+ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
+ struct omap8250_priv *priv)
+ {
+- u8 timeout = 255;
+-
+ serial_out(up, UART_OMAP_MDR1, priv->mdr1);
+ udelay(2);
+ serial_out(up, UART_FCR, up->fcr | UART_FCR_CLEAR_XMIT |
+ UART_FCR_CLEAR_RCVR);
+- /*
+- * Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
+- * TX_FIFO_E bit is 1.
+- */
+- while (UART_LSR_THRE != (serial_in(up, UART_LSR) &
+- (UART_LSR_THRE | UART_LSR_DR))) {
+- timeout--;
+- if (!timeout) {
+- /* Should *never* happen. we warn and carry on */
+- dev_crit(up->port.dev, "Errata i202: timedout %x\n",
+- serial_in(up, UART_LSR));
+- break;
+- }
+- udelay(1);
+- }
+ }
+
+ static void omap_8250_get_divisor(struct uart_port *port, unsigned int baud,
+--
+2.35.1
+
--- /dev/null
+From 2679f4bbe6c3dff6ad31068207ead319b42dade1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 12 Oct 2022 20:13:53 +0800
+Subject: serial: imx: Add missing .thaw_noirq hook
+
+From: Shawn Guo <shawn.guo@linaro.org>
+
+[ Upstream commit 4561d8008a467cb05ac632a215391d6b787f40aa ]
+
+The following warning is seen with non-console UART instance when
+system hibernates.
+
+[ 37.371969] ------------[ cut here ]------------
+[ 37.376599] uart3_root_clk already disabled
+[ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0
+...
+[ 37.506986] Call trace:
+[ 37.509432] clk_core_disable+0xa4/0xb0
+[ 37.513270] clk_disable+0x34/0x50
+[ 37.516672] imx_uart_thaw+0x38/0x5c
+[ 37.520250] platform_pm_thaw+0x30/0x6c
+[ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4
+[ 37.528972] device_resume+0x7c/0x160
+[ 37.532633] dpm_resume+0xe8/0x230
+[ 37.536036] hibernation_snapshot+0x288/0x430
+[ 37.540397] hibernate+0x10c/0x2e0
+[ 37.543798] state_store+0xc4/0xd0
+[ 37.547203] kobj_attr_store+0x1c/0x30
+[ 37.550953] sysfs_kf_write+0x48/0x60
+[ 37.554619] kernfs_fop_write_iter+0x118/0x1ac
+[ 37.559063] new_sync_write+0xe8/0x184
+[ 37.562812] vfs_write+0x230/0x290
+[ 37.566214] ksys_write+0x68/0xf4
+[ 37.569529] __arm64_sys_write+0x20/0x2c
+[ 37.573452] invoke_syscall.constprop.0+0x50/0xf0
+[ 37.578156] do_el0_svc+0x11c/0x150
+[ 37.581648] el0_svc+0x30/0x140
+[ 37.584792] el0t_64_sync_handler+0xe8/0xf0
+[ 37.588976] el0t_64_sync+0x1a0/0x1a4
+[ 37.592639] ---[ end trace 56e22eec54676d75 ]---
+
+On hibernating, pm core calls into related hooks in sequence like:
+
+ .freeze
+ .freeze_noirq
+ .thaw_noirq
+ .thaw
+
+With .thaw_noirq hook being absent, the clock will be disabled in a
+unbalanced call which results the warning above.
+
+ imx_uart_freeze()
+ clk_prepare_enable()
+ imx_uart_suspend_noirq()
+ clk_disable()
+ imx_uart_thaw
+ clk_disable_unprepare()
+
+Adding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have
+the call sequence corrected as below and thus fix the warning.
+
+ imx_uart_freeze()
+ clk_prepare_enable()
+ imx_uart_suspend_noirq()
+ clk_disable()
+ imx_uart_resume_noirq()
+ clk_enable()
+ imx_uart_thaw
+ clk_disable_unprepare()
+
+Fixes: 09df0b3464e5 ("serial: imx: fix endless loop during suspend")
+Reviewed-by: Martin Kaiser <martin@kaiser.cx>
+Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
+Link: https://lore.kernel.org/r/20221012121353.2346280-1-shawn.guo@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/imx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
+index c6a93d6a9464..711edb835c27 100644
+--- a/drivers/tty/serial/imx.c
++++ b/drivers/tty/serial/imx.c
+@@ -2563,6 +2563,7 @@ static const struct dev_pm_ops imx_uart_pm_ops = {
+ .suspend_noirq = imx_uart_suspend_noirq,
+ .resume_noirq = imx_uart_resume_noirq,
+ .freeze_noirq = imx_uart_suspend_noirq,
++ .thaw_noirq = imx_uart_resume_noirq,
+ .restore_noirq = imx_uart_resume_noirq,
+ .suspend = imx_uart_suspend,
+ .resume = imx_uart_resume,
+--
+2.35.1
+
spi-intel-use-correct-mask-for-flash-and-protected-r.patch
kvm-x86-pmu-do-not-speculatively-query-intel-gp-pmcs.patch
hugetlbfs-don-t-delete-error-page-from-pagecache.patch
+arm64-dts-qcom-sa8155p-adp-specify-which-ldo-modes-a.patch
+arm64-dts-qcom-sm8150-xperia-kumano-specify-which-ld.patch
+arm64-dts-qcom-sm8250-xperia-edo-specify-which-ldo-m.patch
+arm64-dts-qcom-sm8350-hdk-specify-which-ldo-modes-ar.patch
+spi-stm32-print-summary-callbacks-suppressed-message.patch
+arm-dts-at91-sama7g5-fix-signal-name-of-pin-pb2.patch
+asoc-core-fix-use-after-free-in-snd_soc_exit.patch
+asoc-tas2770-fix-set_tdm_slot-in-case-of-single-slot.patch
+asoc-tas2764-fix-set_tdm_slot-in-case-of-single-slot.patch
+arm-at91-pm-avoid-soft-resetting-ac-dll.patch
+serial-8250-omap-fix-missing-pm-runtime-calls-for-om.patch
+serial-8250_omap-remove-wait-loop-from-errata-i202-w.patch
+serial-8250-omap-fix-unpaired-pm_runtime_put_sync-in.patch
+serial-8250-omap-flush-pm-qos-work-on-remove.patch
+serial-imx-add-missing-.thaw_noirq-hook.patch
+tty-n_gsm-fix-sleep-in-atomic-context-bug-in-gsm_con.patch
+bpf-test_run-fix-alignment-problem-in-bpf_prog_test_.patch
+asoc-soc-utils-remove-__exit-for-snd_soc_util_exit.patch
+pinctrl-rockchip-list-all-pins-in-a-possible-mux-rou.patch
+scsi-scsi_transport_sas-fix-error-handling-in-sas_ph.patch
+block-sed-opal-kmalloc-the-cmd-resp-buffers.patch
+bpf-fix-memory-leaks-in-__check_func_call.patch
+arm64-fix-bit-shifting-ub-in-the-midr_cpu_model-macr.patch
+siox-fix-possible-memory-leak-in-siox_device_add.patch
+parport_pc-avoid-fifo-port-location-truncation.patch
+pinctrl-devicetree-fix-null-pointer-dereferencing-in.patch
+drm-vc4-kms-fix-is_err-vs-null-check-for-vc4_kms.patch
+drm-panel-simple-set-bpc-field-for-logic-technologie.patch
+drm-drv-fix-potential-memory-leak-in-drm_dev_init.patch
+drm-fix-potential-null-ptr-deref-in-drm_vblank_destr.patch
+arm-dts-imx7-fix-nand-controller-size-cells.patch
+arm64-dts-imx8mm-fix-nand-controller-size-cells.patch
+arm64-dts-imx8mn-fix-nand-controller-size-cells.patch
+ata-libata-transport-fix-double-ata_host_put-in-ata_.patch
+ata-libata-transport-fix-error-handling-in-ata_tport.patch
+ata-libata-transport-fix-error-handling-in-ata_tlink.patch
+ata-libata-transport-fix-error-handling-in-ata_tdev_.patch
+nfp-change-eeprom-length-to-max-length-enumerators.patch
+mips-fix-duplicate-definitions-for-exported-symbols.patch
+mips-loongson64-add-warn_on-on-kexec-related-kmalloc.patch
+bpf-initialize-same-number-of-free-nodes-for-each-pc.patch
+net-bgmac-drop-free_netdev-from-bgmac_enet_remove.patch
+misdn-fix-possible-memory-leak-in-misdn_dsp_element_.patch
+net-hinic-fix-error-handling-in-hinic_module_init.patch
+net-stmmac-ensure-tx-function-is-not-running-in-stmm.patch
+soc-imx8m-enable-ocotp-clock-before-reading-the-regi.patch
+net-liquidio-release-resources-when-liquidio-driver-.patch
+misdn-fix-misuse-of-put_device-in-misdn_register_dev.patch
+net-macvlan-use-built-in-rcu-list-checking.patch
+net-caif-fix-double-disconnect-client-in-chnl_net_op.patch
+bnxt_en-remove-debugfs-when-pci_register_driver-fail.patch
+net-mhi-fix-memory-leak-in-mhi_net_dellink.patch
+net-dsa-make-dsa_master_ioctl-see-through-port_hwtst.patch
+xen-pcpu-fix-possible-memory-leak-in-register_pcpu.patch
+net-ionic-fix-error-handling-in-ionic_init_module.patch
+net-ena-fix-error-handling-in-ena_init.patch
+net-hns3-fix-setting-incorrect-phy-link-ksettings-fo.patch
+bridge-switchdev-fix-memory-leaks-when-changing-vlan.patch
+drbd-use-after-free-in-drbd_create_device.patch
+platform-x86-intel-pmc-don-t-unconditionally-attach-.patch
+platform-surface-aggregator-do-not-check-for-repeate.patch
+cifs-add-check-for-returning-value-of-smb2_close_ini.patch
+net-ag71xx-call-phylink_disconnect_phy-if-ag71xx_hw_.patch
+net-x25-fix-skb-leak-in-x25_lapb_receive_frame.patch
+cifs-fix-wrong-return-value-checking-when-getflags.patch
+net-microchip-sparx5-fix-potential-null-ptr-deref-in.patch
+net-thunderbolt-fix-error-handling-in-tbnet_init.patch
+l2tp-serialize-access-to-sk_user_data-with-sk_callba.patch
+cifs-add-check-for-returning-value-of-smb2_set_info_.patch
--- /dev/null
+From 40660e4d5a0a411e663bb6c1b1dfd136b5562ff2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Nov 2022 10:13:34 +0800
+Subject: siox: fix possible memory leak in siox_device_add()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 6e63153db50059fb78b8a8447b132664887d24e3 ]
+
+If device_register() returns error in siox_device_add(),
+the name allocated by dev_set_name() need be freed. As
+comment of device_register() says, it should use put_device()
+to give up the reference in the error path. So fix this
+by calling put_device(), then the name can be freed in
+kobject_cleanup(), and sdevice is freed in siox_device_release(),
+set it to null in error path.
+
+Fixes: bbecb07fa0af ("siox: new driver framework for eckelmann SIOX")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Link: https://lore.kernel.org/r/20221104021334.618189-1-yangyingliang@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/siox/siox-core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
+index 7c4f32d76966..561408583b2b 100644
+--- a/drivers/siox/siox-core.c
++++ b/drivers/siox/siox-core.c
+@@ -839,6 +839,8 @@ static struct siox_device *siox_device_add(struct siox_master *smaster,
+
+ err_device_register:
+ /* don't care to make the buffer smaller again */
++ put_device(&sdevice->dev);
++ sdevice = NULL;
+
+ err_buf_alloc:
+ siox_master_unlock(smaster);
+--
+2.35.1
+
--- /dev/null
+From 232226dcd3c242ccf54cce8707b1c797ce3fe649 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Oct 2022 12:14:18 +0800
+Subject: soc: imx8m: Enable OCOTP clock before reading the register
+
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+
+[ Upstream commit 836fb30949d9edf91d7de696a884ceeae7e426d2 ]
+
+Commit 7d981405d0fd ("soc: imx8m: change to use platform driver") ever
+removed the dependency on bootloader for enabling OCOTP clock. It
+helped to fix a kexec kernel hang issue. But unfortunately it caused
+a regression on CAAM driver and got reverted.
+
+This is the second try to enable the OCOTP clock by directly calling
+clock API instead of indirectly enabling the clock via nvmem API.
+
+Fixes: ac34de14ac30 ("Revert "soc: imx8m: change to use platform driver"")
+Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
+Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soc/imx/soc-imx8m.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
+index cc57a384d74d..28144c699b0c 100644
+--- a/drivers/soc/imx/soc-imx8m.c
++++ b/drivers/soc/imx/soc-imx8m.c
+@@ -11,6 +11,7 @@
+ #include <linux/platform_device.h>
+ #include <linux/arm-smccc.h>
+ #include <linux/of.h>
++#include <linux/clk.h>
+
+ #define REV_B1 0x21
+
+@@ -56,6 +57,7 @@ static u32 __init imx8mq_soc_revision(void)
+ void __iomem *ocotp_base;
+ u32 magic;
+ u32 rev;
++ struct clk *clk;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx8mq-ocotp");
+ if (!np)
+@@ -63,6 +65,13 @@ static u32 __init imx8mq_soc_revision(void)
+
+ ocotp_base = of_iomap(np, 0);
+ WARN_ON(!ocotp_base);
++ clk = of_clk_get_by_name(np, NULL);
++ if (!clk) {
++ WARN_ON(!clk);
++ return 0;
++ }
++
++ clk_prepare_enable(clk);
+
+ /*
+ * SOC revision on older imx8mq is not available in fuses so query
+@@ -79,6 +88,8 @@ static u32 __init imx8mq_soc_revision(void)
+ soc_uid <<= 32;
+ soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW);
+
++ clk_disable_unprepare(clk);
++ clk_put(clk);
+ iounmap(ocotp_base);
+ of_node_put(np);
+
+--
+2.35.1
+
--- /dev/null
+From a6a17c02b59cccbcec2099916a4e0e4d81ed9ac4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Oct 2022 20:35:13 +0200
+Subject: spi: stm32: Print summary 'callbacks suppressed' message
+
+From: Marek Vasut <marex@denx.de>
+
+[ Upstream commit 195583504be28df5d608a4677dd796117aea875f ]
+
+The original fix "spi: stm32: Rate-limit the 'Communication suspended' message"
+still leads to "stm32h7_spi_irq_thread: 1696 callbacks suppressed" spew in the
+kernel log. Since this 'Communication suspended' message is a debug print, add
+RATELIMIT_MSG_ON_RELEASE flag to inhibit the "callbacks suspended" part during
+normal operation and only print summary at the end.
+
+Fixes: ea8be08cc9358 ("spi: stm32: Rate-limit the 'Communication suspended' message")
+Signed-off-by: Marek Vasut <marex@denx.de>
+Link: https://lore.kernel.org/r/20221018183513.206706-1-marex@denx.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-stm32.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
+index 9bd3fd1652f7..96a73f9e2677 100644
+--- a/drivers/spi/spi-stm32.c
++++ b/drivers/spi/spi-stm32.c
+@@ -886,6 +886,7 @@ static irqreturn_t stm32h7_spi_irq_thread(int irq, void *dev_id)
+ static DEFINE_RATELIMIT_STATE(rs,
+ DEFAULT_RATELIMIT_INTERVAL * 10,
+ 1);
++ ratelimit_set_flags(&rs, RATELIMIT_MSG_ON_RELEASE);
+ if (__ratelimit(&rs))
+ dev_dbg_ratelimited(spi->dev, "Communication suspended\n");
+ if (!spi->cur_usedma && (spi->rx_buf && (spi->rx_len > 0)))
+--
+2.35.1
+
--- /dev/null
+From b63bf917ecbf55cd8303fd81756f705e49f194c5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 2 Oct 2022 12:07:09 +0800
+Subject: tty: n_gsm: fix sleep-in-atomic-context bug in gsm_control_send
+
+From: Duoming Zhou <duoming@zju.edu.cn>
+
+[ Upstream commit 7b7dfe4833c70a11cdfa51b38705103bd31eddaa ]
+
+The function gsm_dlci_t1() is a timer handler that runs in an
+atomic context, but it calls "kzalloc(..., GFP_KERNEL)" that
+may sleep. As a result, the sleep-in-atomic-context bug will
+happen. The process is shown below:
+
+gsm_dlci_t1()
+ gsm_dlci_open()
+ gsm_modem_update()
+ gsm_modem_upd_via_msc()
+ gsm_control_send()
+ kzalloc(sizeof(.., GFP_KERNEL) //may sleep
+
+This patch changes the gfp_t parameter of kzalloc() from GFP_KERNEL to
+GFP_ATOMIC in order to mitigate the bug.
+
+Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
+Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
+Link: https://lore.kernel.org/r/20221002040709.27849-1-duoming@zju.edu.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/n_gsm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
+index 154697be11b0..813a45887171 100644
+--- a/drivers/tty/n_gsm.c
++++ b/drivers/tty/n_gsm.c
+@@ -1577,7 +1577,7 @@ static struct gsm_control *gsm_control_send(struct gsm_mux *gsm,
+ unsigned int command, u8 *data, int clen)
+ {
+ struct gsm_control *ctrl = kzalloc(sizeof(struct gsm_control),
+- GFP_KERNEL);
++ GFP_ATOMIC);
+ unsigned long flags;
+ if (ctrl == NULL)
+ return NULL;
+--
+2.35.1
+
--- /dev/null
+From ce0bf3495e930efec87a907b1523a26f47dbd40d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Nov 2022 23:24:41 +0800
+Subject: xen/pcpu: fix possible memory leak in register_pcpu()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit da36a2a76b01b210ffaa55cdc2c99bc8783697c5 ]
+
+In device_add(), dev_set_name() is called to allocate name, if it returns
+error, the name need be freed. As comment of device_register() says, it
+should use put_device() to give up the reference in the error path. So fix
+this by calling put_device(), then the name can be freed in kobject_cleanup().
+
+Fixes: f65c9bb3fb72 ("xen/pcpu: Xen physical cpus online/offline sys interface")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Link: https://lore.kernel.org/r/20221110152441.401630-1-yangyingliang@huawei.com
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/xen/pcpu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
+index 47aa3a1ccaf5..fd3a644b0855 100644
+--- a/drivers/xen/pcpu.c
++++ b/drivers/xen/pcpu.c
+@@ -228,7 +228,7 @@ static int register_pcpu(struct pcpu *pcpu)
+
+ err = device_register(dev);
+ if (err) {
+- pcpu_release(dev);
++ put_device(dev);
+ return err;
+ }
+
+--
+2.35.1
+