From: Sasha Levin Date: Sat, 9 Nov 2024 02:46:09 +0000 (-0500) Subject: Fixes for 6.1 X-Git-Tag: v5.15.172~88 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=35ef3ec1f490c205ccd9448e2c4a85122a64ba8c;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 6.1 Signed-off-by: Sasha Levin --- diff --git a/queue-6.1/arm-dts-rockchip-drop-grf-reference-from-rk3036-hdmi.patch b/queue-6.1/arm-dts-rockchip-drop-grf-reference-from-rk3036-hdmi.patch new file mode 100644 index 00000000000..e62a174f233 --- /dev/null +++ b/queue-6.1/arm-dts-rockchip-drop-grf-reference-from-rk3036-hdmi.patch @@ -0,0 +1,39 @@ +From da06b43f398cac1c4502bba2c1bae4605f64a1ca Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 22:39:38 +0200 +Subject: ARM: dts: rockchip: drop grf reference from rk3036 hdmi + +From: Heiko Stuebner + +[ Upstream commit 1580ccb6ed9dc76b8ff3e2d8912e8215c8b0fa6d ] + +Neither the binding nor the driver implementation specify/use the grf +reference provided in the rk3036. And neither does the newer rk3128 +user of the hdmi controller. So drop the rockchip,grf property. + +Fixes: b7217cf19c63 ("ARM: dts: rockchip: add hdmi device node for rk3036") +Cc: Caesar Wang +Reviewed-by: Dragan Simic +Signed-off-by: Heiko Stuebner +Link: https://lore.kernel.org/r/20241008203940.2573684-13-heiko@sntech.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm/boot/dts/rk3036.dtsi | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi +index e6bb1d7a2b4ec..4e208528eebf2 100644 +--- a/arch/arm/boot/dts/rk3036.dtsi ++++ b/arch/arm/boot/dts/rk3036.dtsi +@@ -398,7 +398,6 @@ + interrupts = ; + clocks = <&cru PCLK_HDMI>; + clock-names = "pclk"; +- rockchip,grf = <&grf>; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_ctl>; + status = "disabled"; +-- +2.43.0 + diff --git a/queue-6.1/arm-dts-rockchip-fix-rk3036-acodec-node.patch b/queue-6.1/arm-dts-rockchip-fix-rk3036-acodec-node.patch new file mode 100644 index 00000000000..bd561c67933 --- /dev/null +++ b/queue-6.1/arm-dts-rockchip-fix-rk3036-acodec-node.patch @@ -0,0 +1,49 @@ +From dbe9187a3a91e1a5543977267907823ccd3c9b53 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 22:39:37 +0200 +Subject: ARM: dts: rockchip: fix rk3036 acodec node + +From: Heiko Stuebner + +[ Upstream commit c7206853cd7d31c52575fb1dc7616b4398f3bc8f ] + +The acodec node is not conformant to the binding. + +Set the correct nodename, use the correct compatible, add the needed +#sound-dai-cells and sort the rockchip,grf below clocks properties +as expected. + +Fixes: faea098e1808 ("ARM: dts: rockchip: add core rk3036 dtsi") +Reviewed-by: Dragan Simic +Signed-off-by: Heiko Stuebner +Link: https://lore.kernel.org/r/20241008203940.2573684-12-heiko@sntech.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm/boot/dts/rk3036.dtsi | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi +index c420c7c642cb0..e6bb1d7a2b4ec 100644 +--- a/arch/arm/boot/dts/rk3036.dtsi ++++ b/arch/arm/boot/dts/rk3036.dtsi +@@ -382,12 +382,13 @@ + }; + }; + +- acodec: acodec-ana@20030000 { +- compatible = "rk3036-codec"; ++ acodec: audio-codec@20030000 { ++ compatible = "rockchip,rk3036-codec"; + reg = <0x20030000 0x4000>; +- rockchip,grf = <&grf>; + clock-names = "acodec_pclk"; + clocks = <&cru PCLK_ACODEC>; ++ rockchip,grf = <&grf>; ++ #sound-dai-cells = <0>; + status = "disabled"; + }; + +-- +2.43.0 + diff --git a/queue-6.1/arm-dts-rockchip-fix-the-realtek-audio-codec-on-rk30.patch b/queue-6.1/arm-dts-rockchip-fix-the-realtek-audio-codec-on-rk30.patch new file mode 100644 index 00000000000..2f0581406f9 --- /dev/null +++ b/queue-6.1/arm-dts-rockchip-fix-the-realtek-audio-codec-on-rk30.patch @@ -0,0 +1,41 @@ +From cfcf738dd829aa2ea6c3afa2c5bd5a594a83709a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 22:39:40 +0200 +Subject: ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin + +From: Heiko Stuebner + +[ Upstream commit 77a9a7f2d3b94d29d13d71b851114d593a2147cf ] + +Both the node name as well as the compatible were not named +according to the binding expectations, fix that. + +Fixes: 47bf3a5c9e2a ("ARM: dts: rockchip: add the sound setup for rk3036-kylin board") +Cc: Caesar Wang +Reviewed-by: Dragan Simic +Signed-off-by: Heiko Stuebner +Link: https://lore.kernel.org/r/20241008203940.2573684-15-heiko@sntech.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm/boot/dts/rk3036-kylin.dts | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/arm/boot/dts/rk3036-kylin.dts b/arch/arm/boot/dts/rk3036-kylin.dts +index 67e1e04139e73..43926d0962bbd 100644 +--- a/arch/arm/boot/dts/rk3036-kylin.dts ++++ b/arch/arm/boot/dts/rk3036-kylin.dts +@@ -304,8 +304,8 @@ + &i2c2 { + status = "okay"; + +- rt5616: rt5616@1b { +- compatible = "rt5616"; ++ rt5616: audio-codec@1b { ++ compatible = "realtek,rt5616"; + reg = <0x1b>; + clocks = <&cru SCLK_I2S_OUT>; + clock-names = "mclk"; +-- +2.43.0 + diff --git a/queue-6.1/arm-dts-rockchip-fix-the-spi-controller-on-rk3036.patch b/queue-6.1/arm-dts-rockchip-fix-the-spi-controller-on-rk3036.patch new file mode 100644 index 00000000000..2aad692f0b7 --- /dev/null +++ b/queue-6.1/arm-dts-rockchip-fix-the-spi-controller-on-rk3036.patch @@ -0,0 +1,48 @@ +From 58aa10b42e18b8121869dd40185eb96e25e6c5a0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 22:39:39 +0200 +Subject: ARM: dts: rockchip: Fix the spi controller on rk3036 + +From: Heiko Stuebner + +[ Upstream commit 8bade1ad1f0821aef31f6a8fb1027ae292566d85 ] + +Compatible and clock names did not match the existing binding. +So set the correct values and re-order+rename the clocks. + +It looks like no rk3036 board did use the spi controller so far, +so this was never detected on a running device yet. + +Fixes: f629fcfab2cd ("ARM: dts: rockchip: support the spi for rk3036") +Cc: Caesar Wang +Reviewed-by: Dragan Simic +Signed-off-by: Heiko Stuebner +Link: https://lore.kernel.org/r/20241008203940.2573684-14-heiko@sntech.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm/boot/dts/rk3036.dtsi | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi +index 4e208528eebf2..5bdbadd879fe8 100644 +--- a/arch/arm/boot/dts/rk3036.dtsi ++++ b/arch/arm/boot/dts/rk3036.dtsi +@@ -550,11 +550,11 @@ + }; + + spi: spi@20074000 { +- compatible = "rockchip,rockchip-spi"; ++ compatible = "rockchip,rk3036-spi"; + reg = <0x20074000 0x1000>; + interrupts = ; +- clocks = <&cru PCLK_SPI>, <&cru SCLK_SPI>; +- clock-names = "apb-pclk","spi_pclk"; ++ clocks = <&cru SCLK_SPI>, <&cru PCLK_SPI>; ++ clock-names = "spiclk", "apb_pclk"; + dmas = <&pdma 8>, <&pdma 9>; + dma-names = "tx", "rx"; + pinctrl-names = "default"; +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-imx8-ss-vpu-fix-imx8qm-vpu-irqs.patch b/queue-6.1/arm64-dts-imx8-ss-vpu-fix-imx8qm-vpu-irqs.patch new file mode 100644 index 00000000000..1b01f731c0c --- /dev/null +++ b/queue-6.1/arm64-dts-imx8-ss-vpu-fix-imx8qm-vpu-irqs.patch @@ -0,0 +1,68 @@ +From 6783b369986e7c3b4194f69757d3f2282e80ef7e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Sep 2024 13:41:03 +0200 +Subject: arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs + +From: Alexander Stein + +[ Upstream commit eed2d8e8d0051a6551e4dffba99e16eb88c676ac ] + +imx8-ss-vpu only contained imx8qxp IRQ numbers, only mu2_m0 uses the +correct imx8qm IRQ number, as imx8qxp lacks this MU. +Fix this by providing imx8qm IRQ numbers in the main imx8-ss-vpu.dtsi +and override the IRQ numbers in SoC-specific imx8qxp-ss-vpu.dtsi, similar +to reg property for VPU core devices. + +Fixes: 0d9968d98467d ("arm64: dts: freescale: imx8q: add imx vpu codec entries") +Signed-off-by: Alexander Stein +Signed-off-by: Shawn Guo +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/freescale/imx8-ss-vpu.dtsi | 4 ++-- + arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi | 8 ++++++++ + 2 files changed, 10 insertions(+), 2 deletions(-) + +diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-vpu.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-vpu.dtsi +index c6540768bdb92..87211c18d65a9 100644 +--- a/arch/arm64/boot/dts/freescale/imx8-ss-vpu.dtsi ++++ b/arch/arm64/boot/dts/freescale/imx8-ss-vpu.dtsi +@@ -15,7 +15,7 @@ vpu: vpu@2c000000 { + mu_m0: mailbox@2d000000 { + compatible = "fsl,imx6sx-mu"; + reg = <0x2d000000 0x20000>; +- interrupts = ; ++ interrupts = ; + #mbox-cells = <2>; + power-domains = <&pd IMX_SC_R_VPU_MU_0>; + status = "disabled"; +@@ -24,7 +24,7 @@ vpu: vpu@2c000000 { + mu1_m0: mailbox@2d020000 { + compatible = "fsl,imx6sx-mu"; + reg = <0x2d020000 0x20000>; +- interrupts = ; ++ interrupts = ; + #mbox-cells = <2>; + power-domains = <&pd IMX_SC_R_VPU_MU_1>; + status = "disabled"; +diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi +index 7894a3ab26d6b..f81937b5fb720 100644 +--- a/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi ++++ b/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi +@@ -5,6 +5,14 @@ + * Author: Alexander Stein + */ + ++&mu_m0 { ++ interrupts = ; ++}; ++ ++&mu1_m0 { ++ interrupts = ; ++}; ++ + &vpu_core0 { + reg = <0x2d040000 0x10000>; + }; +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-imx8mp-correct-sdhc-ipg-clk.patch b/queue-6.1/arm64-dts-imx8mp-correct-sdhc-ipg-clk.patch new file mode 100644 index 00000000000..0c2789785f4 --- /dev/null +++ b/queue-6.1/arm64-dts-imx8mp-correct-sdhc-ipg-clk.patch @@ -0,0 +1,55 @@ +From b5436c7e124f81ac73dfed95db190546fc32e4f3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 12 Oct 2024 10:52:21 +0800 +Subject: arm64: dts: imx8mp: correct sdhc ipg clk + +From: Peng Fan + +[ Upstream commit eab6ba2aa3bbaf598a66e31f709bf84b7bb7dc8a ] + +The ipg clk for sdhc sources from IPG_CLK_ROOT per i.MX 8M Plus +Applications Processor Reference Manual, Table 5-2. System Clocks. + +Fixes: 6d9b8d20431f ("arm64: dts: freescale: Add i.MX8MP dtsi support") +Signed-off-by: Peng Fan +Reviewed-by: Fabio Estevam +Signed-off-by: Shawn Guo +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/freescale/imx8mp.dtsi | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi +index 8c34b3e12a66a..86af7115ac60c 100644 +--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi ++++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi +@@ -934,7 +934,7 @@ + compatible = "fsl,imx8mp-usdhc", "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc"; + reg = <0x30b40000 0x10000>; + interrupts = ; +- clocks = <&clk IMX8MP_CLK_DUMMY>, ++ clocks = <&clk IMX8MP_CLK_IPG_ROOT>, + <&clk IMX8MP_CLK_NAND_USDHC_BUS>, + <&clk IMX8MP_CLK_USDHC1_ROOT>; + clock-names = "ipg", "ahb", "per"; +@@ -948,7 +948,7 @@ + compatible = "fsl,imx8mp-usdhc", "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc"; + reg = <0x30b50000 0x10000>; + interrupts = ; +- clocks = <&clk IMX8MP_CLK_DUMMY>, ++ clocks = <&clk IMX8MP_CLK_IPG_ROOT>, + <&clk IMX8MP_CLK_NAND_USDHC_BUS>, + <&clk IMX8MP_CLK_USDHC2_ROOT>; + clock-names = "ipg", "ahb", "per"; +@@ -962,7 +962,7 @@ + compatible = "fsl,imx8mp-usdhc", "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc"; + reg = <0x30b60000 0x10000>; + interrupts = ; +- clocks = <&clk IMX8MP_CLK_DUMMY>, ++ clocks = <&clk IMX8MP_CLK_IPG_ROOT>, + <&clk IMX8MP_CLK_NAND_USDHC_BUS>, + <&clk IMX8MP_CLK_USDHC3_ROOT>; + clock-names = "ipg", "ahb", "per"; +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-imx8qm-fix-vpu-core-alias-name.patch b/queue-6.1/arm64-dts-imx8qm-fix-vpu-core-alias-name.patch new file mode 100644 index 00000000000..2ef1ac2f688 --- /dev/null +++ b/queue-6.1/arm64-dts-imx8qm-fix-vpu-core-alias-name.patch @@ -0,0 +1,43 @@ +From e76fe67a07308a9d74056d5c1f0575b1c543e9cf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 21 Jul 2023 13:10:37 +0200 +Subject: arm64: dts: imx8qm: Fix VPU core alias name + +From: Alexander Stein + +[ Upstream commit f6038de293f28503eccbfcfa84d39faf56d09150 ] + +Alias names use dashes instead of underscores, fix this. Silences also +dtbs_check warning: +imx8qxp-tqma8xqp-mba8xx.dtb: aliases: 'vpu_core0', 'vpu_core1', 'vpu_core2' + do not match any of the regexes: '^[a-z][a-z0-9\\-]*$', 'pinctrl-[0-9]+' +from schema $id: http://devicetree.org/schemas/aliases.yaml# + +Signed-off-by: Alexander Stein +Signed-off-by: Shawn Guo +Stable-dep-of: eed2d8e8d005 ("arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs") +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi +index f4ea18bb95abf..dce699dffb9bf 100644 +--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi ++++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi +@@ -46,9 +46,9 @@ + serial1 = &lpuart1; + serial2 = &lpuart2; + serial3 = &lpuart3; +- vpu_core0 = &vpu_core0; +- vpu_core1 = &vpu_core1; +- vpu_core2 = &vpu_core2; ++ vpu-core0 = &vpu_core0; ++ vpu-core1 = &vpu_core1; ++ vpu-core2 = &vpu_core2; + }; + + cpus { +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-imx8qxp-add-vpu-subsystem-file.patch b/queue-6.1/arm64-dts-imx8qxp-add-vpu-subsystem-file.patch new file mode 100644 index 00000000000..b51767fa82e --- /dev/null +++ b/queue-6.1/arm64-dts-imx8qxp-add-vpu-subsystem-file.patch @@ -0,0 +1,70 @@ +From ab538b81c6bd188d748f27d114de720833131386 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 14 Dec 2023 14:20:00 +0100 +Subject: arm64: dts: imx8qxp: Add VPU subsystem file + +From: Alexander Stein + +[ Upstream commit 6bcd8b2fa2a9826fb6a849a9bfd7bdef145cabb6 ] + +imx8qxp re-uses imx8qm VPU subsystem file, but it has different base +addresses. Also imx8qxp has only two VPU cores, delete vpu_vore2 and +mu2_m0 accordingly. + +Signed-off-by: Alexander Stein +Reviewed-by: Fabio Estevam +Signed-off-by: Shawn Guo +Stable-dep-of: eed2d8e8d005 ("arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs") +Signed-off-by: Sasha Levin +--- + .../boot/dts/freescale/imx8qxp-ss-vpu.dtsi | 17 +++++++++++++++++ + arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 2 +- + 2 files changed, 18 insertions(+), 1 deletion(-) + create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi + +diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi +new file mode 100644 +index 0000000000000..7894a3ab26d6b +--- /dev/null ++++ b/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi +@@ -0,0 +1,17 @@ ++// SPDX-License-Identifier: (GPL-2.0-or-later OR X11) ++/* ++ * Copyright 2023 TQ-Systems GmbH , ++ * D-82229 Seefeld, Germany. ++ * Author: Alexander Stein ++ */ ++ ++&vpu_core0 { ++ reg = <0x2d040000 0x10000>; ++}; ++ ++&vpu_core1 { ++ reg = <0x2d050000 0x10000>; ++}; ++ ++/delete-node/ &mu2_m0; ++/delete-node/ &vpu_core2; +diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi +index dce699dffb9bf..bec66bb240829 100644 +--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi ++++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi +@@ -48,7 +48,6 @@ + serial3 = &lpuart3; + vpu-core0 = &vpu_core0; + vpu-core1 = &vpu_core1; +- vpu-core2 = &vpu_core2; + }; + + cpus { +@@ -316,6 +315,7 @@ + }; + + #include "imx8qxp-ss-img.dtsi" ++#include "imx8qxp-ss-vpu.dtsi" + #include "imx8qxp-ss-adma.dtsi" + #include "imx8qxp-ss-conn.dtsi" + #include "imx8qxp-ss-lsio.dtsi" +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-rockchip-fix-bluetooth-properties-on-rock9.patch b/queue-6.1/arm64-dts-rockchip-fix-bluetooth-properties-on-rock9.patch new file mode 100644 index 00000000000..d72e64f013c --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-fix-bluetooth-properties-on-rock9.patch @@ -0,0 +1,41 @@ +From 6466027ff71db4baa2692a5fd028dfad93d828d7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 22:39:30 +0200 +Subject: arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards + +From: Heiko Stuebner + +[ Upstream commit ea74528aaea5a1dfc8e3de09ef2af37530eca526 ] + +The expected clock-name is different, and extclk also is deprecated +in favor of txco for clocks that are not crystals. + +So fix it to match the binding. + +Fixes: c72235c288c8 ("arm64: dts: rockchip: Add on-board WiFi/BT support for Rock960 boards") +Cc: Manivannan Sadhasivam +Reviewed-by: Dragan Simic +Signed-off-by: Heiko Stuebner +Link: https://lore.kernel.org/r/20241008203940.2573684-5-heiko@sntech.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi +index 94e39ed633971..d38b25a0c77f4 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi +@@ -575,7 +575,7 @@ + bluetooth { + compatible = "brcm,bcm43438-bt"; + clocks = <&rk808 1>; +- clock-names = "ext_clock"; ++ clock-names = "txco"; + device-wakeup-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>; + host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>; + shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>; +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-rockchip-fix-led-triggers-on-rk3308-roc-cc.patch b/queue-6.1/arm64-dts-rockchip-fix-led-triggers-on-rk3308-roc-cc.patch new file mode 100644 index 00000000000..cbd0e4d9330 --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-fix-led-triggers-on-rk3308-roc-cc.patch @@ -0,0 +1,52 @@ +From 8c4546fccc99be5ecc4aa178aba4ffa768502c4c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 22:39:33 +0200 +Subject: arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc + +From: Heiko Stuebner + +[ Upstream commit 3a53a7187f41ec3db12cf4c2cb0db4ba87c2f3a1 ] + +There are two LEDs on the board, power and user events. +Currently both are assigned undocumented IR(-remote) +triggers that are probably only part of the vendor-kernel. + +To make dtbs check happier, assign the power-led to a generic +default-on trigger and the user led to the documented rc-feedback +trigger that should mostly match its current usage. + +Fixes: 4403e1237be3 ("arm64: dts: rockchip: Add devicetree for board roc-rk3308-cc") +Cc: Andy Yan +Reviewed-by: Dragan Simic +Signed-off-by: Heiko Stuebner +Link: https://lore.kernel.org/r/20241008203940.2573684-8-heiko@sntech.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts +index 7ea48167747c6..70aeca428b380 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts +@@ -36,14 +36,14 @@ + + power_led: led-0 { + label = "firefly:red:power"; +- linux,default-trigger = "ir-power-click"; ++ linux,default-trigger = "default-on"; + default-state = "on"; + gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>; + }; + + user_led: led-1 { + label = "firefly:blue:user"; +- linux,default-trigger = "ir-user-click"; ++ linux,default-trigger = "rc-feedback"; + default-state = "off"; + gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_HIGH>; + }; +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-rockchip-fix-rt5651-compatible-value-on-rk.patch b/queue-6.1/arm64-dts-rockchip-fix-rt5651-compatible-value-on-rk.patch new file mode 100644 index 00000000000..ef76fd52f38 --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-fix-rt5651-compatible-value-on-rk.patch @@ -0,0 +1,38 @@ +From f848a3d15c768ea3718bc3f3292f2553ce4e5290 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Sep 2024 15:48:40 +0200 +Subject: arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610 + +From: Geert Uytterhoeven + +[ Upstream commit 2f39bba3b4f037d6c3c9174eed5befcef1c79abb ] + +There are no DT bindings and driver support for a "rockchip,rt5651" +codec. Replace "rockchip,rt5651" by "realtek,rt5651", which matches the +"simple-audio-card,name" property in the "rt5651-sound" node. + +Fixes: 904f983256fdd24b ("arm64: dts: rockchip: Add dts for a rk3399 based board EAIDK-610") +Signed-off-by: Geert Uytterhoeven +Link: https://lore.kernel.org/r/a9877b8b1bd0de279d2ec8294d5be14587203a82.1727358193.git.geert+renesas@glider.be +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts b/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts +index d1f343345f674..1f156f5a8666a 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts +@@ -541,7 +541,7 @@ + status = "okay"; + + rt5651: audio-codec@1a { +- compatible = "rockchip,rt5651"; ++ compatible = "realtek,rt5651"; + reg = <0x1a>; + clocks = <&cru SCLK_I2S_8CH_OUT>; + clock-names = "mclk"; +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-rockchip-fix-rt5651-compatible-value-on-rk.patch-32368 b/queue-6.1/arm64-dts-rockchip-fix-rt5651-compatible-value-on-rk.patch-32368 new file mode 100644 index 00000000000..c226411a388 --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-fix-rt5651-compatible-value-on-rk.patch-32368 @@ -0,0 +1,39 @@ +From 8eb5fc8e7179e3a8022837e8cd976863e1502063 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Sep 2024 15:48:41 +0200 +Subject: arm64: dts: rockchip: Fix rt5651 compatible value on + rk3399-sapphire-excavator + +From: Geert Uytterhoeven + +[ Upstream commit 577b5761679da90e691acc939ebbe7879fff5f31 ] + +There are no DT bindings and driver support for a "rockchip,rt5651" +codec. Replace "rockchip,rt5651" by "realtek,rt5651", which matches the +"simple-audio-card,name" property in the "rt5651-sound" node. + +Fixes: 0a3c78e251b3a266 ("arm64: dts: rockchip: Add support for rk3399 excavator main board") +Signed-off-by: Geert Uytterhoeven +Link: https://lore.kernel.org/r/abc6c89811b3911785601d6d590483eacb145102.1727358193.git.geert+renesas@glider.be +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts +index dbec2b7173a0b..31ea3d0182c06 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts +@@ -163,7 +163,7 @@ + status = "okay"; + + rt5651: rt5651@1a { +- compatible = "rockchip,rt5651"; ++ compatible = "realtek,rt5651"; + reg = <0x1a>; + clocks = <&cru SCLK_I2S_8CH_OUT>; + clock-names = "mclk"; +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-rockchip-fix-wakeup-prop-names-on-pinenote.patch b/queue-6.1/arm64-dts-rockchip-fix-wakeup-prop-names-on-pinenote.patch new file mode 100644 index 00000000000..b4c89441462 --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-fix-wakeup-prop-names-on-pinenote.patch @@ -0,0 +1,43 @@ +From f103fb837e8b6ff0da78e6959927fc447f426b09 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 13:15:38 +0200 +Subject: arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node + +From: Diederik de Haas + +[ Upstream commit 87299d6ee95a37d2d576dd8077ea6860f77ad8e2 ] + +The "brcm,bluetooth.yaml" binding has 'device-wakeup-gpios' and +'host-wakeup-gpios' property names, not '*-wake-gpios'. +Fix the incorrect property names. + +Note that the "realtek,bluetooth.yaml" binding does use the +'*-wake-gpios' property names. + +Fixes: d449121e5e8a ("arm64: dts: rockchip: Add Pine64 PineNote board") +Signed-off-by: Diederik de Haas +Link: https://lore.kernel.org/r/20241008113344.23957-4-didi.debian@cknow.org +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi +index 8d61f824c12dc..52ab14308a5c1 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi +@@ -685,8 +685,8 @@ + compatible = "brcm,bcm43438-bt"; + clocks = <&rk817 1>; + clock-names = "lpo"; +- device-wake-gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_HIGH>; +- host-wake-gpios = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>; ++ device-wakeup-gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_HIGH>; ++ host-wakeup-gpios = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&bt_enable_h>, <&bt_host_wake_l>, <&bt_wake_h>; + pinctrl-names = "default"; +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-rockchip-remove-cooling-cells-from-fan-on-.patch b/queue-6.1/arm64-dts-rockchip-remove-cooling-cells-from-fan-on-.patch new file mode 100644 index 00000000000..5dcc81603f6 --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-remove-cooling-cells-from-fan-on-.patch @@ -0,0 +1,52 @@ +From d8613f987b13717795b31d267644bc5e8b31b07e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 22:39:32 +0200 +Subject: arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma + lion + +From: Heiko Stuebner + +[ Upstream commit 5ed96580568c4f79a0aff11a67f10b3e9229ba86 ] + +All Theobroma boards use a ti,amc6821 as fan controller. +It normally runs in an automatically controlled way and while it may be +possible to use it as part of a dt-based thermal management, this is +not yet specified in the binding, nor implemented in any kernel. + +Newer boards already don't contain that #cooling-cells property, but +older ones do. So remove them for now, they can be re-added if thermal +integration gets implemented in the future. + +There are two further occurences in v6.12-rc in px30-ringneck and +rk3399-puma, but those already get removed by the i2c-mux conversion +scheduled for 6.13 . As the undocumented property is in the kernel so +long, I opted for not causing extra merge conflicts between 6.12 and 6.13 + +Fixes: d99a02bcfa81 ("arm64: dts: rockchip: add RK3368-uQ7 (Lion) SoM") +Cc: Quentin Schulz +Cc: Klaus Goger +Reviewed-by: Quentin Schulz +Reviewed-by: Dragan Simic +Signed-off-by: Heiko Stuebner +Link: https://lore.kernel.org/r/20241008203940.2573684-7-heiko@sntech.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi b/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi +index 5753e57fd7161..e8859cfd2d39b 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi +@@ -60,7 +60,6 @@ + fan: fan@18 { + compatible = "ti,amc6821"; + reg = <0x18>; +- #cooling-cells = <2>; + }; + + rtc_twi: rtc@6f { +-- +2.43.0 + diff --git a/queue-6.1/arm64-dts-rockchip-remove-hdmi-s-2nd-interrupt-on-rk.patch b/queue-6.1/arm64-dts-rockchip-remove-hdmi-s-2nd-interrupt-on-rk.patch new file mode 100644 index 00000000000..60bcc94951f --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-remove-hdmi-s-2nd-interrupt-on-rk.patch @@ -0,0 +1,53 @@ +From f70aa8a24c0dc70c5aa831860c484fcce2bb0807 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 13:15:37 +0200 +Subject: arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328 + +From: Diederik de Haas + +[ Upstream commit de50a7e3681771c6b990238af82bf1dea9b11b21 ] + +The "synopsys,dw-hdmi.yaml" binding specifies that the interrupts +property of the hdmi node has 'maxItems: 1', so the hdmi node in +rk3328.dtsi having 2 is incorrect. + +Paragraph 1.3 ("System Interrupt connection") of the RK3328 TRM v1.1 +page 16 and 17 define the following hdmi related interrupts: +- 67 hdmi_intr +- 103 hdmi_intr_wakeup + +The difference of 32 is due to a different base used in the TRM. + +The RK3399 (which uses the same binding) has '23: hdmi_irq' and +'24: hdmi_wakeup_irq' according to its TRM (page 19). +The RK3568 (also same binding) has '76: hdmi_wakeup' and '77: hdmi' +according to page 17 of its TRM. +In both cases the non-wakeup IRQ was used, so use that too for rk3328. + +Helped-by: Heiko Stuebner +Fixes: 725e351c265a ("arm64: dts: rockchip: add rk3328 display nodes") +Signed-off-by: Diederik de Haas +Link: https://lore.kernel.org/r/20241008113344.23957-3-didi.debian@cknow.org +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3328.dtsi | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi +index 5adb2fbc2aafa..75ea512e9724f 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi +@@ -724,8 +724,7 @@ + compatible = "rockchip,rk3328-dw-hdmi"; + reg = <0x0 0xff3c0000 0x0 0x20000>; + reg-io-width = <4>; +- interrupts = , +- ; ++ interrupts = ; + clocks = <&cru PCLK_HDMI>, + <&cru SCLK_HDMI_SFC>, + <&cru SCLK_RTC32K>; +-- +2.43.0 + diff --git a/queue-6.1/can-c_can-fix-rx-tx-_errors-statistics.patch b/queue-6.1/can-c_can-fix-rx-tx-_errors-statistics.patch new file mode 100644 index 00000000000..8443c37dfa5 --- /dev/null +++ b/queue-6.1/can-c_can-fix-rx-tx-_errors-statistics.patch @@ -0,0 +1,71 @@ +From efbb99fbc3d6c3b9c34082cb2a6ddaba174fedd3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 14 Oct 2024 15:53:13 +0200 +Subject: can: c_can: fix {rx,tx}_errors statistics + +From: Dario Binacchi + +[ Upstream commit 4d6d26537940f3b3e17138987ed9e4a334780bf7 ] + +The c_can_handle_bus_err() function was incorrectly incrementing only the +receive error counter, even in cases of bit or acknowledgment errors that +occur during transmission. The patch fixes the issue by incrementing the +appropriate counter based on the type of error. + +Fixes: 881ff67ad450 ("can: c_can: Added support for Bosch C_CAN controller") +Signed-off-by: Dario Binacchi +Link: https://patch.msgid.link/20241014135319.2009782-1-dario.binacchi@amarulasolutions.com +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + drivers/net/can/c_can/c_can_main.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/can/c_can/c_can_main.c b/drivers/net/can/c_can/c_can_main.c +index c63f7fc1e6917..511615dc33419 100644 +--- a/drivers/net/can/c_can/c_can_main.c ++++ b/drivers/net/can/c_can/c_can_main.c +@@ -1011,7 +1011,6 @@ static int c_can_handle_bus_err(struct net_device *dev, + + /* common for all type of bus errors */ + priv->can.can_stats.bus_error++; +- stats->rx_errors++; + + /* propagate the error condition to the CAN stack */ + skb = alloc_can_err_skb(dev, &cf); +@@ -1027,26 +1026,32 @@ static int c_can_handle_bus_err(struct net_device *dev, + case LEC_STUFF_ERROR: + netdev_dbg(dev, "stuff error\n"); + cf->data[2] |= CAN_ERR_PROT_STUFF; ++ stats->rx_errors++; + break; + case LEC_FORM_ERROR: + netdev_dbg(dev, "form error\n"); + cf->data[2] |= CAN_ERR_PROT_FORM; ++ stats->rx_errors++; + break; + case LEC_ACK_ERROR: + netdev_dbg(dev, "ack error\n"); + cf->data[3] = CAN_ERR_PROT_LOC_ACK; ++ stats->tx_errors++; + break; + case LEC_BIT1_ERROR: + netdev_dbg(dev, "bit1 error\n"); + cf->data[2] |= CAN_ERR_PROT_BIT1; ++ stats->tx_errors++; + break; + case LEC_BIT0_ERROR: + netdev_dbg(dev, "bit0 error\n"); + cf->data[2] |= CAN_ERR_PROT_BIT0; ++ stats->tx_errors++; + break; + case LEC_CRC_ERROR: + netdev_dbg(dev, "CRC error\n"); + cf->data[3] = CAN_ERR_PROT_LOC_CRC_SEQ; ++ stats->rx_errors++; + break; + default: + break; +-- +2.43.0 + diff --git a/queue-6.1/hid-core-zero-initialize-the-report-buffer.patch b/queue-6.1/hid-core-zero-initialize-the-report-buffer.patch new file mode 100644 index 00000000000..85f6086759d --- /dev/null +++ b/queue-6.1/hid-core-zero-initialize-the-report-buffer.patch @@ -0,0 +1,41 @@ +From 0c303219cc6c1e1e921253e8777ffefc60f21471 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 29 Oct 2024 15:44:35 +0100 +Subject: HID: core: zero-initialize the report buffer +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jiri Kosina + +[ Upstream commit 177f25d1292c7e16e1199b39c85480f7f8815552 ] + +Since the report buffer is used by all kinds of drivers in various ways, let's +zero-initialize it during allocation to make sure that it can't be ever used +to leak kernel memory via specially-crafted report. + +Fixes: 27ce405039bf ("HID: fix data access in implement()") +Reported-by: Benoît Sevens +Acked-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + drivers/hid/hid-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c +index e2e52aa0eeba9..b5887658c6af6 100644 +--- a/drivers/hid/hid-core.c ++++ b/drivers/hid/hid-core.c +@@ -1878,7 +1878,7 @@ u8 *hid_alloc_report_buf(struct hid_report *report, gfp_t flags) + + u32 len = hid_report_len(report) + 7; + +- return kmalloc(len, flags); ++ return kzalloc(len, flags); + } + EXPORT_SYMBOL_GPL(hid_alloc_report_buf); + +-- +2.43.0 + diff --git a/queue-6.1/i40e-fix-race-condition-by-adding-filter-s-intermedi.patch b/queue-6.1/i40e-fix-race-condition-by-adding-filter-s-intermedi.patch new file mode 100644 index 00000000000..fcae2aad3f4 --- /dev/null +++ b/queue-6.1/i40e-fix-race-condition-by-adding-filter-s-intermedi.patch @@ -0,0 +1,134 @@ +From 7ddf1bb4e49332966952983e9b19511031252799 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 16 Oct 2024 11:30:11 +0200 +Subject: i40e: fix race condition by adding filter's intermediate sync state + +From: Aleksandr Loktionov + +[ Upstream commit f30490e9695ef7da3d0899c6a0293cc7cd373567 ] + +Fix a race condition in the i40e driver that leads to MAC/VLAN filters +becoming corrupted and leaking. Address the issue that occurs under +heavy load when multiple threads are concurrently modifying MAC/VLAN +filters by setting mac and port VLAN. + +1. Thread T0 allocates a filter in i40e_add_filter() within + i40e_ndo_set_vf_port_vlan(). +2. Thread T1 concurrently frees the filter in __i40e_del_filter() within + i40e_ndo_set_vf_mac(). +3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which + refers to the already freed filter memory, causing corruption. + +Reproduction steps: +1. Spawn multiple VFs. +2. Apply a concurrent heavy load by running parallel operations to change + MAC addresses on the VFs and change port VLANs on the host. +3. Observe errors in dmesg: +"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, + please set promiscuous on manually for VF XX". + +Exact code for stable reproduction Intel can't open-source now. + +The fix involves implementing a new intermediate filter state, +I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. +These filters cannot be deleted from the hash list directly but +must be removed using the full process. + +Fixes: 278e7d0b9d68 ("i40e: store MAC/VLAN filters in a hash with the MAC Address as key") +Signed-off-by: Aleksandr Loktionov +Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) +Reviewed-by: Michal Schmidt +Tested-by: Michal Schmidt +Signed-off-by: Tony Nguyen +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/intel/i40e/i40e.h | 1 + + drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 1 + + drivers/net/ethernet/intel/i40e/i40e_main.c | 12 ++++++++++-- + 3 files changed, 12 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h +index 5293fc00938cf..22ac8c48ca340 100644 +--- a/drivers/net/ethernet/intel/i40e/i40e.h ++++ b/drivers/net/ethernet/intel/i40e/i40e.h +@@ -790,6 +790,7 @@ enum i40e_filter_state { + I40E_FILTER_ACTIVE, /* Added to switch by FW */ + I40E_FILTER_FAILED, /* Rejected by FW */ + I40E_FILTER_REMOVE, /* To be removed */ ++ I40E_FILTER_NEW_SYNC, /* New, not sent yet, is in i40e_sync_vsi_filters() */ + /* There is no 'removed' state; the filter struct is freed */ + }; + struct i40e_mac_filter { +diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c +index 62497f5565c59..b438cf846c41b 100644 +--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c ++++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c +@@ -105,6 +105,7 @@ static char *i40e_filter_state_string[] = { + "ACTIVE", + "FAILED", + "REMOVE", ++ "NEW_SYNC", + }; + + /** +diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c +index 5f46a0677d195..3b165d8f03dc2 100644 +--- a/drivers/net/ethernet/intel/i40e/i40e_main.c ++++ b/drivers/net/ethernet/intel/i40e/i40e_main.c +@@ -1251,6 +1251,7 @@ int i40e_count_filters(struct i40e_vsi *vsi) + + hash_for_each_safe(vsi->mac_filter_hash, bkt, h, f, hlist) { + if (f->state == I40E_FILTER_NEW || ++ f->state == I40E_FILTER_NEW_SYNC || + f->state == I40E_FILTER_ACTIVE) + ++cnt; + } +@@ -1437,6 +1438,8 @@ static int i40e_correct_mac_vlan_filters(struct i40e_vsi *vsi, + + new->f = add_head; + new->state = add_head->state; ++ if (add_head->state == I40E_FILTER_NEW) ++ add_head->state = I40E_FILTER_NEW_SYNC; + + /* Add the new filter to the tmp list */ + hlist_add_head(&new->hlist, tmp_add_list); +@@ -1546,6 +1549,8 @@ static int i40e_correct_vf_mac_vlan_filters(struct i40e_vsi *vsi, + return -ENOMEM; + new_mac->f = add_head; + new_mac->state = add_head->state; ++ if (add_head->state == I40E_FILTER_NEW) ++ add_head->state = I40E_FILTER_NEW_SYNC; + + /* Add the new filter to the tmp list */ + hlist_add_head(&new_mac->hlist, tmp_add_list); +@@ -2437,7 +2442,8 @@ static int + i40e_aqc_broadcast_filter(struct i40e_vsi *vsi, const char *vsi_name, + struct i40e_mac_filter *f) + { +- bool enable = f->state == I40E_FILTER_NEW; ++ bool enable = f->state == I40E_FILTER_NEW || ++ f->state == I40E_FILTER_NEW_SYNC; + struct i40e_hw *hw = &vsi->back->hw; + int aq_ret; + +@@ -2611,6 +2617,7 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi) + + /* Add it to the hash list */ + hlist_add_head(&new->hlist, &tmp_add_list); ++ f->state = I40E_FILTER_NEW_SYNC; + } + + /* Count the number of active (current and new) VLAN +@@ -2762,7 +2769,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi) + spin_lock_bh(&vsi->mac_filter_hash_lock); + hlist_for_each_entry_safe(new, h, &tmp_add_list, hlist) { + /* Only update the state if we're still NEW */ +- if (new->f->state == I40E_FILTER_NEW) ++ if (new->f->state == I40E_FILTER_NEW || ++ new->f->state == I40E_FILTER_NEW_SYNC) + new->f->state = new->state; + hlist_del(&new->hlist); + netdev_hw_addr_refcnt(new->f, vsi->netdev, -1); +-- +2.43.0 + diff --git a/queue-6.1/ice-change-q_index-variable-type-to-s16-to-store-1-v.patch b/queue-6.1/ice-change-q_index-variable-type-to-s16-to-store-1-v.patch new file mode 100644 index 00000000000..acd36825b78 --- /dev/null +++ b/queue-6.1/ice-change-q_index-variable-type-to-s16-to-store-1-v.patch @@ -0,0 +1,89 @@ +From 6d05396deb7e9eba6f5734d8e6656cf4cfdc66bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 28 Oct 2024 12:59:22 -0400 +Subject: ice: change q_index variable type to s16 to store -1 value + +From: Mateusz Polchlopek + +[ Upstream commit 64502dac974a5d9951d16015fa2e16a14e5f2bb2 ] + +Fix Flow Director not allowing to re-map traffic to 0th queue when action +is configured to drop (and vice versa). + +The current implementation of ethtool callback in the ice driver forbids +change Flow Director action from 0 to -1 and from -1 to 0 with an error, +e.g: + + # ethtool -U eth2 flow-type tcp4 src-ip 1.1.1.1 loc 1 action 0 + # ethtool -U eth2 flow-type tcp4 src-ip 1.1.1.1 loc 1 action -1 + rmgr: Cannot insert RX class rule: Invalid argument + +We set the value of `u16 q_index = 0` at the beginning of the function +ice_set_fdir_input_set(). In case of "drop traffic" action (which is +equal to -1 in ethtool) we store the 0 value. Later, when want to change +traffic rule to redirect to queue with index 0 it returns an error +caused by duplicate found. + +Fix this behaviour by change of the type of field `q_index` from u16 to s16 +in `struct ice_fdir_fltr`. This allows to store -1 in the field in case +of "drop traffic" action. What is more, change the variable type in the +function ice_set_fdir_input_set() and assign at the beginning the new +`#define ICE_FDIR_NO_QUEUE_IDX` which is -1. Later, if the action is set +to another value (point specific queue index) the variable value is +overwritten in the function. + +Fixes: cac2a27cd9ab ("ice: Support IPv4 Flow Director filters") +Reviewed-by: Przemek Kitszel +Signed-off-by: Mateusz Polchlopek +Reviewed-by: Simon Horman +Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) +Signed-off-by: Tony Nguyen +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c | 3 ++- + drivers/net/ethernet/intel/ice/ice_fdir.h | 4 +++- + 2 files changed, 5 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c +index 1839a37139dc1..b6bbf2376ef5c 100644 +--- a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c ++++ b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c +@@ -1694,11 +1694,12 @@ static int + ice_set_fdir_input_set(struct ice_vsi *vsi, struct ethtool_rx_flow_spec *fsp, + struct ice_fdir_fltr *input) + { +- u16 dest_vsi, q_index = 0; ++ s16 q_index = ICE_FDIR_NO_QUEUE_IDX; + u16 orig_q_index = 0; + struct ice_pf *pf; + struct ice_hw *hw; + int flow_type; ++ u16 dest_vsi; + u8 dest_ctl; + + if (!vsi || !fsp || !input) +diff --git a/drivers/net/ethernet/intel/ice/ice_fdir.h b/drivers/net/ethernet/intel/ice/ice_fdir.h +index b384d2a4ab198..063ea3d516532 100644 +--- a/drivers/net/ethernet/intel/ice/ice_fdir.h ++++ b/drivers/net/ethernet/intel/ice/ice_fdir.h +@@ -50,6 +50,8 @@ + */ + #define ICE_FDIR_IPV4_PKT_FLAG_MF 0x20 + ++#define ICE_FDIR_NO_QUEUE_IDX -1 ++ + enum ice_fltr_prgm_desc_dest { + ICE_FLTR_PRGM_DESC_DEST_DROP_PKT, + ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QINDEX, +@@ -181,7 +183,7 @@ struct ice_fdir_fltr { + u16 flex_fltr; + + /* filter control */ +- u16 q_index; ++ s16 q_index; + u16 orig_q_index; + u16 dest_vsi; + u8 dest_ctl; +-- +2.43.0 + diff --git a/queue-6.1/net-arc-fix-the-device-for-dma_map_single-dma_unmap_.patch b/queue-6.1/net-arc-fix-the-device-for-dma_map_single-dma_unmap_.patch new file mode 100644 index 00000000000..f059f68348b --- /dev/null +++ b/queue-6.1/net-arc-fix-the-device-for-dma_map_single-dma_unmap_.patch @@ -0,0 +1,154 @@ +From 38d2d7db1b8a79fa718a982c2b82ee233ac5d541 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 4 Nov 2024 21:01:38 +0800 +Subject: net: arc: fix the device for dma_map_single/dma_unmap_single + +From: Johan Jonker + +[ Upstream commit 71803c1dfa29e0d13b99e48fda11107cc8caebc7 ] + +The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent +which has dma_mask, ndev->dev.parent is just pdev->dev. +Or it would cause the following issue: + +[ 39.933526] ------------[ cut here ]------------ +[ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8 + +Fixes: f959dcd6ddfd ("dma-direct: Fix potential NULL pointer dereference") +Signed-off-by: David Wu +Signed-off-by: Johan Jonker +Signed-off-by: Andy Yan +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/arc/emac_main.c | 27 ++++++++++++++++----------- + 1 file changed, 16 insertions(+), 11 deletions(-) + +diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c +index ba0646b3b122e..a32b5f7c0b969 100644 +--- a/drivers/net/ethernet/arc/emac_main.c ++++ b/drivers/net/ethernet/arc/emac_main.c +@@ -111,6 +111,7 @@ static void arc_emac_tx_clean(struct net_device *ndev) + { + struct arc_emac_priv *priv = netdev_priv(ndev); + struct net_device_stats *stats = &ndev->stats; ++ struct device *dev = ndev->dev.parent; + unsigned int i; + + for (i = 0; i < TX_BD_NUM; i++) { +@@ -140,7 +141,7 @@ static void arc_emac_tx_clean(struct net_device *ndev) + stats->tx_bytes += skb->len; + } + +- dma_unmap_single(&ndev->dev, dma_unmap_addr(tx_buff, addr), ++ dma_unmap_single(dev, dma_unmap_addr(tx_buff, addr), + dma_unmap_len(tx_buff, len), DMA_TO_DEVICE); + + /* return the sk_buff to system */ +@@ -174,6 +175,7 @@ static void arc_emac_tx_clean(struct net_device *ndev) + static int arc_emac_rx(struct net_device *ndev, int budget) + { + struct arc_emac_priv *priv = netdev_priv(ndev); ++ struct device *dev = ndev->dev.parent; + unsigned int work_done; + + for (work_done = 0; work_done < budget; work_done++) { +@@ -223,9 +225,9 @@ static int arc_emac_rx(struct net_device *ndev, int budget) + continue; + } + +- addr = dma_map_single(&ndev->dev, (void *)skb->data, ++ addr = dma_map_single(dev, (void *)skb->data, + EMAC_BUFFER_SIZE, DMA_FROM_DEVICE); +- if (dma_mapping_error(&ndev->dev, addr)) { ++ if (dma_mapping_error(dev, addr)) { + if (net_ratelimit()) + netdev_err(ndev, "cannot map dma buffer\n"); + dev_kfree_skb(skb); +@@ -237,7 +239,7 @@ static int arc_emac_rx(struct net_device *ndev, int budget) + } + + /* unmap previosly mapped skb */ +- dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr), ++ dma_unmap_single(dev, dma_unmap_addr(rx_buff, addr), + dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE); + + pktlen = info & LEN_MASK; +@@ -423,6 +425,7 @@ static int arc_emac_open(struct net_device *ndev) + { + struct arc_emac_priv *priv = netdev_priv(ndev); + struct phy_device *phy_dev = ndev->phydev; ++ struct device *dev = ndev->dev.parent; + int i; + + phy_dev->autoneg = AUTONEG_ENABLE; +@@ -445,9 +448,9 @@ static int arc_emac_open(struct net_device *ndev) + if (unlikely(!rx_buff->skb)) + return -ENOMEM; + +- addr = dma_map_single(&ndev->dev, (void *)rx_buff->skb->data, ++ addr = dma_map_single(dev, (void *)rx_buff->skb->data, + EMAC_BUFFER_SIZE, DMA_FROM_DEVICE); +- if (dma_mapping_error(&ndev->dev, addr)) { ++ if (dma_mapping_error(dev, addr)) { + netdev_err(ndev, "cannot dma map\n"); + dev_kfree_skb(rx_buff->skb); + return -ENOMEM; +@@ -548,6 +551,7 @@ static void arc_emac_set_rx_mode(struct net_device *ndev) + static void arc_free_tx_queue(struct net_device *ndev) + { + struct arc_emac_priv *priv = netdev_priv(ndev); ++ struct device *dev = ndev->dev.parent; + unsigned int i; + + for (i = 0; i < TX_BD_NUM; i++) { +@@ -555,7 +559,7 @@ static void arc_free_tx_queue(struct net_device *ndev) + struct buffer_state *tx_buff = &priv->tx_buff[i]; + + if (tx_buff->skb) { +- dma_unmap_single(&ndev->dev, ++ dma_unmap_single(dev, + dma_unmap_addr(tx_buff, addr), + dma_unmap_len(tx_buff, len), + DMA_TO_DEVICE); +@@ -579,6 +583,7 @@ static void arc_free_tx_queue(struct net_device *ndev) + static void arc_free_rx_queue(struct net_device *ndev) + { + struct arc_emac_priv *priv = netdev_priv(ndev); ++ struct device *dev = ndev->dev.parent; + unsigned int i; + + for (i = 0; i < RX_BD_NUM; i++) { +@@ -586,7 +591,7 @@ static void arc_free_rx_queue(struct net_device *ndev) + struct buffer_state *rx_buff = &priv->rx_buff[i]; + + if (rx_buff->skb) { +- dma_unmap_single(&ndev->dev, ++ dma_unmap_single(dev, + dma_unmap_addr(rx_buff, addr), + dma_unmap_len(rx_buff, len), + DMA_FROM_DEVICE); +@@ -679,6 +684,7 @@ static netdev_tx_t arc_emac_tx(struct sk_buff *skb, struct net_device *ndev) + unsigned int len, *txbd_curr = &priv->txbd_curr; + struct net_device_stats *stats = &ndev->stats; + __le32 *info = &priv->txbd[*txbd_curr].info; ++ struct device *dev = ndev->dev.parent; + dma_addr_t addr; + + if (skb_padto(skb, ETH_ZLEN)) +@@ -692,10 +698,9 @@ static netdev_tx_t arc_emac_tx(struct sk_buff *skb, struct net_device *ndev) + return NETDEV_TX_BUSY; + } + +- addr = dma_map_single(&ndev->dev, (void *)skb->data, len, +- DMA_TO_DEVICE); ++ addr = dma_map_single(dev, (void *)skb->data, len, DMA_TO_DEVICE); + +- if (unlikely(dma_mapping_error(&ndev->dev, addr))) { ++ if (unlikely(dma_mapping_error(dev, addr))) { + stats->tx_dropped++; + stats->tx_errors++; + dev_kfree_skb_any(skb); +-- +2.43.0 + diff --git a/queue-6.1/net-arc-rockchip-fix-emac-mdio-node-support.patch b/queue-6.1/net-arc-rockchip-fix-emac-mdio-node-support.patch new file mode 100644 index 00000000000..221f7d28c88 --- /dev/null +++ b/queue-6.1/net-arc-rockchip-fix-emac-mdio-node-support.patch @@ -0,0 +1,58 @@ +From 0be50e574443496a2c83c556e369b6b11810182f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 4 Nov 2024 21:01:39 +0800 +Subject: net: arc: rockchip: fix emac mdio node support + +From: Johan Jonker + +[ Upstream commit 0a1c7a7b0adbf595ce7f218609db53749e966573 ] + +The binding emac_rockchip.txt is converted to YAML. +Changed against the original binding is an added MDIO subnode. +This make the driver failed to find the PHY, and given the 'mdio +has invalid PHY address' it is probably looking in the wrong node. +Fix emac_mdio.c so that it can handle both old and new +device trees. + +Fixes: 1dabb74971b3 ("ARM: dts: rockchip: restyle emac nodes") +Signed-off-by: Johan Jonker +Tested-by: Andy Yan +Link: https://lore.kernel.org/r/20220603163539.537-3-jbx6244@gmail.com +Signed-off-by: Andy Yan +Reviewed-by: Andrew Lunn +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/arc/emac_mdio.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/arc/emac_mdio.c b/drivers/net/ethernet/arc/emac_mdio.c +index 87f40c2ba9040..078b1a72c1613 100644 +--- a/drivers/net/ethernet/arc/emac_mdio.c ++++ b/drivers/net/ethernet/arc/emac_mdio.c +@@ -133,6 +133,7 @@ int arc_mdio_probe(struct arc_emac_priv *priv) + struct arc_emac_mdio_bus_data *data = &priv->bus_data; + struct device_node *np = priv->dev->of_node; + const char *name = "Synopsys MII Bus"; ++ struct device_node *mdio_node; + struct mii_bus *bus; + int error; + +@@ -164,7 +165,13 @@ int arc_mdio_probe(struct arc_emac_priv *priv) + + snprintf(bus->id, MII_BUS_ID_SIZE, "%s", bus->name); + +- error = of_mdiobus_register(bus, priv->dev->of_node); ++ /* Backwards compatibility for EMAC nodes without MDIO subnode. */ ++ mdio_node = of_get_child_by_name(np, "mdio"); ++ if (!mdio_node) ++ mdio_node = of_node_get(np); ++ ++ error = of_mdiobus_register(bus, mdio_node); ++ of_node_put(mdio_node); + if (error) { + mdiobus_free(bus); + return dev_err_probe(priv->dev, error, +-- +2.43.0 + diff --git a/queue-6.1/net-enetc-set-mac-address-to-the-vf-net_device.patch b/queue-6.1/net-enetc-set-mac-address-to-the-vf-net_device.patch new file mode 100644 index 00000000000..1d3dc44bc81 --- /dev/null +++ b/queue-6.1/net-enetc-set-mac-address-to-the-vf-net_device.patch @@ -0,0 +1,66 @@ +From 327e02289c4cbdefd32bdb11cfee68ddb27a2606 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 29 Oct 2024 17:04:06 +0800 +Subject: net: enetc: set MAC address to the VF net_device + +From: Wei Fang + +[ Upstream commit badccd49b93bb945bf4e5cc8707db67cdc5e27e5 ] + +The MAC address of VF can be configured through the mailbox mechanism of +ENETC, but the previous implementation forgot to set the MAC address in +net_device, resulting in the SMAC of the sent frames still being the old +MAC address. Since the MAC address in the hardware has been changed, Rx +cannot receive frames with the DMAC address as the new MAC address. The +most obvious phenomenon is that after changing the MAC address, we can +see that the MAC address of eno0vf0 has not changed through the "ifconfig +eno0vf0" command and the IP address cannot be obtained . + +root@ls1028ardb:~# ifconfig eno0vf0 down +root@ls1028ardb:~# ifconfig eno0vf0 hw ether 00:04:9f:3a:4d:56 up +root@ls1028ardb:~# ifconfig eno0vf0 +eno0vf0: flags=4163 mtu 1500 + ether 66:36:2c:3b:87:76 txqueuelen 1000 (Ethernet) + RX packets 794 bytes 69239 (69.2 KB) + RX errors 0 dropped 0 overruns 0 frame 0 + TX packets 11 bytes 2226 (2.2 KB) + TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 + +Fixes: beb74ac878c8 ("enetc: Add vf to pf messaging support") +Signed-off-by: Wei Fang +Reviewed-by: Vladimir Oltean +Reviewed-by: Claudiu Manoil +Link: https://patch.msgid.link/20241029090406.841836-1-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/freescale/enetc/enetc_vf.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c b/drivers/net/ethernet/freescale/enetc/enetc_vf.c +index dfcaac302e245..b15db70769e5e 100644 +--- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc_vf.c +@@ -78,11 +78,18 @@ static int enetc_vf_set_mac_addr(struct net_device *ndev, void *addr) + { + struct enetc_ndev_priv *priv = netdev_priv(ndev); + struct sockaddr *saddr = addr; ++ int err; + + if (!is_valid_ether_addr(saddr->sa_data)) + return -EADDRNOTAVAIL; + +- return enetc_msg_vsi_set_primary_mac_addr(priv, saddr); ++ err = enetc_msg_vsi_set_primary_mac_addr(priv, saddr); ++ if (err) ++ return err; ++ ++ eth_hw_addr_set(ndev, saddr->sa_data); ++ ++ return 0; + } + + static int enetc_vf_set_features(struct net_device *ndev, +-- +2.43.0 + diff --git a/queue-6.1/net-hns3-fix-kernel-crash-when-uninstalling-driver.patch b/queue-6.1/net-hns3-fix-kernel-crash-when-uninstalling-driver.patch new file mode 100644 index 00000000000..6d4350ef3ce --- /dev/null +++ b/queue-6.1/net-hns3-fix-kernel-crash-when-uninstalling-driver.patch @@ -0,0 +1,89 @@ +From 56477c976d424b455a63da0688c599d7e9d98a6a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 1 Nov 2024 17:15:07 +0800 +Subject: net: hns3: fix kernel crash when uninstalling driver + +From: Peiyang Wang + +[ Upstream commit df3dff8ab6d79edc942464999d06fbaedf8cdd18 ] + +When the driver is uninstalled and the VF is disabled concurrently, a +kernel crash occurs. The reason is that the two actions call function +pci_disable_sriov(). The num_VFs is checked to determine whether to +release the corresponding resources. During the second calling, num_VFs +is not 0 and the resource release function is called. However, the +corresponding resource has been released during the first invoking. +Therefore, the problem occurs: + +[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 +... +[15278.131557][T50670] Call trace: +[15278.134686][T50670] klist_put+0x28/0x12c +[15278.138682][T50670] klist_del+0x14/0x20 +[15278.142592][T50670] device_del+0xbc/0x3c0 +[15278.146676][T50670] pci_remove_bus_device+0x84/0x120 +[15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 +[15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c +[15278.162485][T50670] sriov_disable+0x50/0x11c +[15278.166829][T50670] pci_disable_sriov+0x24/0x30 +[15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] +[15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] +[15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 +[15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 +[15278.193848][T50670] invoke_syscall+0x50/0x11c +[15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 +[15278.203837][T50670] do_el0_svc+0x34/0xcc +[15278.207834][T50670] el0_svc+0x20/0x30 + +For details, see the following figure. + + rmmod hclge disable VFs +---------------------------------------------------- +hclge_exit() sriov_numvfs_store() + ... device_lock() + pci_disable_sriov() hns3_pci_sriov_configure() + pci_disable_sriov() + sriov_disable() + sriov_disable() if !num_VFs : + if !num_VFs : return; + return; sriov_del_vfs() + sriov_del_vfs() ... + ... klist_put() + klist_put() ... + ... num_VFs = 0; + num_VFs = 0; device_unlock(); + +In this patch, when driver is removing, we get the device_lock() +to protect num_VFs, just like sriov_numvfs_store(). + +Fixes: 0dd8a25f355b ("net: hns3: disable sriov before unload hclge layer") +Signed-off-by: Peiyang Wang +Signed-off-by: Jijie Shao +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20241101091507.3644584-1-shaojijie@huawei.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/hisilicon/hns3/hnae3.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c +index 67b0bf310daaa..9a63fbc694083 100644 +--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c ++++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c +@@ -25,8 +25,11 @@ void hnae3_unregister_ae_algo_prepare(struct hnae3_ae_algo *ae_algo) + pci_id = pci_match_id(ae_algo->pdev_id_table, ae_dev->pdev); + if (!pci_id) + continue; +- if (IS_ENABLED(CONFIG_PCI_IOV)) ++ if (IS_ENABLED(CONFIG_PCI_IOV)) { ++ device_lock(&ae_dev->pdev->dev); + pci_disable_sriov(ae_dev->pdev); ++ device_unlock(&ae_dev->pdev->dev); ++ } + } + } + EXPORT_SYMBOL(hnae3_unregister_ae_algo_prepare); +-- +2.43.0 + diff --git a/queue-6.1/net-phy-ti-add-phy_rst_after_clk_en-flag.patch b/queue-6.1/net-phy-ti-add-phy_rst_after_clk_en-flag.patch new file mode 100644 index 00000000000..0a7d88f456f --- /dev/null +++ b/queue-6.1/net-phy-ti-add-phy_rst_after_clk_en-flag.patch @@ -0,0 +1,43 @@ +From 3c00fdf10df3307fe30dfa180398c4253ee33791 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 2 Nov 2024 16:15:05 +0100 +Subject: net: phy: ti: add PHY_RST_AFTER_CLK_EN flag + +From: Diogo Silva + +[ Upstream commit 256748d5480bb3c4b731236c6d6fc86a8e2815d8 ] + +DP83848 datasheet (section 4.7.2) indicates that the reset pin should be +toggled after the clocks are running. Add the PHY_RST_AFTER_CLK_EN to +make sure that this indication is respected. + +In my experience not having this flag enabled would lead to, on some +boots, the wrong MII mode being selected if the PHY was initialized on +the bootloader and was receiving data during Linux boot. + +Signed-off-by: Diogo Silva +Reviewed-by: Andrew Lunn +Fixes: 34e45ad9378c ("net: phy: dp83848: Add TI DP83848 Ethernet PHY") +Link: https://patch.msgid.link/20241102151504.811306-1-paissilva@ld-100007.ds1.internal +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/phy/dp83848.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c +index 937061acfc613..351411f0aa6f4 100644 +--- a/drivers/net/phy/dp83848.c ++++ b/drivers/net/phy/dp83848.c +@@ -147,6 +147,8 @@ MODULE_DEVICE_TABLE(mdio, dp83848_tbl); + /* IRQ related */ \ + .config_intr = dp83848_config_intr, \ + .handle_interrupt = dp83848_handle_interrupt, \ ++ \ ++ .flags = PHY_RST_AFTER_CLK_EN, \ + } + + static struct phy_driver dp83848_driver[] = { +-- +2.43.0 + diff --git a/queue-6.1/net-stmmac-fix-unbalanced-irq-wake-disable-warning-o.patch b/queue-6.1/net-stmmac-fix-unbalanced-irq-wake-disable-warning-o.patch new file mode 100644 index 00000000000..8cdb428cf84 --- /dev/null +++ b/queue-6.1/net-stmmac-fix-unbalanced-irq-wake-disable-warning-o.patch @@ -0,0 +1,50 @@ +From 2b2efccb96c53fb48d3c5d02576a7b74b66da1bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 1 Nov 2024 17:17:29 -0400 +Subject: net: stmmac: Fix unbalanced IRQ wake disable warning on single irq + case +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Nícolas F. R. A. Prado + +[ Upstream commit 25d70702142ac2115e75e01a0a985c6ea1d78033 ] + +Commit a23aa0404218 ("net: stmmac: ethtool: Fixed calltrace caused by +unbalanced disable_irq_wake calls") introduced checks to prevent +unbalanced enable and disable IRQ wake calls. However it only +initialized the auxiliary variable on one of the paths, +stmmac_request_irq_multi_msi(), missing the other, +stmmac_request_irq_single(). + +Add the same initialization on stmmac_request_irq_single() to prevent +"Unbalanced IRQ wake disable" warnings from being printed the first +time disable_irq_wake() is called on platforms that run on that code +path. + +Fixes: a23aa0404218 ("net: stmmac: ethtool: Fixed calltrace caused by unbalanced disable_irq_wake calls") +Signed-off-by: Nícolas F. R. A. Prado +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20241101-stmmac-unbalanced-wake-single-fix-v1-1-5952524c97f0@collabora.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +index 045e57c444fd7..14e5b94b0b5ab 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c ++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +@@ -3665,6 +3665,7 @@ static int stmmac_request_irq_single(struct net_device *dev) + /* Request the Wake IRQ in case of another line + * is used for WoL + */ ++ priv->wol_irq_disabled = true; + if (priv->wol_irq > 0 && priv->wol_irq != dev->irq) { + ret = request_irq(priv->wol_irq, stmmac_interrupt, + IRQF_SHARED, dev->name, dev); +-- +2.43.0 + diff --git a/queue-6.1/nfs-avoid-i_lock-contention-in-nfs_clear_invalid_map.patch b/queue-6.1/nfs-avoid-i_lock-contention-in-nfs_clear_invalid_map.patch new file mode 100644 index 00000000000..446c2f20c82 --- /dev/null +++ b/queue-6.1/nfs-avoid-i_lock-contention-in-nfs_clear_invalid_map.patch @@ -0,0 +1,79 @@ +From 60b43e3f82992dc200765a25cbf09c49004cf6d6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 18 Oct 2024 17:15:41 -0400 +Subject: nfs: avoid i_lock contention in nfs_clear_invalid_mapping + +From: Mike Snitzer + +[ Upstream commit 867da60d463bb2a3e28c9235c487e56e96cffa00 ] + +Multi-threaded buffered reads to the same file exposed significant +inode spinlock contention in nfs_clear_invalid_mapping(). + +Eliminate this spinlock contention by checking flags without locking, +instead using smp_rmb and smp_load_acquire accordingly, but then take +spinlock and double-check these inode flags. + +Also refactor nfs_set_cache_invalid() slightly to use +smp_store_release() to pair with nfs_clear_invalid_mapping()'s +smp_load_acquire(). + +While this fix is beneficial for all multi-threaded buffered reads +issued by an NFS client, this issue was identified in the context of +surprisingly low LOCALIO performance with 4K multi-threaded buffered +read IO. This fix dramatically speeds up LOCALIO performance: + +before: read: IOPS=1583k, BW=6182MiB/s (6482MB/s)(121GiB/20002msec) +after: read: IOPS=3046k, BW=11.6GiB/s (12.5GB/s)(232GiB/20001msec) + +Fixes: 17dfeb911339 ("NFS: Fix races in nfs_revalidate_mapping") +Signed-off-by: Mike Snitzer +Reviewed-by: Jeff Layton +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/inode.c | 20 +++++++++++++++----- + 1 file changed, 15 insertions(+), 5 deletions(-) + +diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c +index 82e846611d5e1..719448d81aed2 100644 +--- a/fs/nfs/inode.c ++++ b/fs/nfs/inode.c +@@ -206,12 +206,15 @@ void nfs_set_cache_invalid(struct inode *inode, unsigned long flags) + nfs_fscache_invalidate(inode, 0); + flags &= ~NFS_INO_REVAL_FORCED; + +- nfsi->cache_validity |= flags; ++ flags |= nfsi->cache_validity; ++ if (inode->i_mapping->nrpages == 0) ++ flags &= ~NFS_INO_INVALID_DATA; + +- if (inode->i_mapping->nrpages == 0) { +- nfsi->cache_validity &= ~NFS_INO_INVALID_DATA; +- nfs_ooo_clear(nfsi); +- } else if (nfsi->cache_validity & NFS_INO_INVALID_DATA) { ++ /* pairs with nfs_clear_invalid_mapping()'s smp_load_acquire() */ ++ smp_store_release(&nfsi->cache_validity, flags); ++ ++ if (inode->i_mapping->nrpages == 0 || ++ nfsi->cache_validity & NFS_INO_INVALID_DATA) { + nfs_ooo_clear(nfsi); + } + trace_nfs_set_cache_invalid(inode, 0); +@@ -1331,6 +1334,13 @@ int nfs_clear_invalid_mapping(struct address_space *mapping) + TASK_KILLABLE|TASK_FREEZABLE_UNSAFE); + if (ret) + goto out; ++ smp_rmb(); /* pairs with smp_wmb() below */ ++ if (test_bit(NFS_INO_INVALIDATING, bitlock)) ++ continue; ++ /* pairs with nfs_set_cache_invalid()'s smp_store_release() */ ++ if (!(smp_load_acquire(&nfsi->cache_validity) & NFS_INO_INVALID_DATA)) ++ goto out; ++ /* Slow-path that double-checks with spinlock held */ + spin_lock(&inode->i_lock); + if (test_bit(NFS_INO_INVALIDATING, bitlock)) { + spin_unlock(&inode->i_lock); +-- +2.43.0 + diff --git a/queue-6.1/nfsv3-handle-out-of-order-write-replies.patch b/queue-6.1/nfsv3-handle-out-of-order-write-replies.patch new file mode 100644 index 00000000000..280322e30b7 --- /dev/null +++ b/queue-6.1/nfsv3-handle-out-of-order-write-replies.patch @@ -0,0 +1,341 @@ +From e8f2daccf4b58f592a1bff3485db647472afd359 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 22 Mar 2023 09:27:04 +1100 +Subject: NFSv3: handle out-of-order write replies. + +From: NeilBrown + +[ Upstream commit 3db63daabe210af32a09533fe7d8d47c711a103c ] + +NFSv3 includes pre/post wcc attributes which allow the client to +determine if all changes to the file have been made by the client +itself, or if any might have been made by some other client. + +If there are gaps in the pre/post ctime sequence it must be assumed that +some other client changed the file in that gap and the local cache must +be suspect. The next time the file is opened the cache should be +invalidated. + +Since Commit 1c341b777501 ("NFS: Add deferred cache invalidation for +close-to-open consistency violations") in linux 5.3 the Linux client has +been triggering this invalidation. The chunk in nfs_update_inode() in +particularly triggers. + +Unfortunately Linux NFS assumes that all replies will be processed in +the order sent, and will arrive in the order processed. This is not +true in general. Consequently Linux NFS might ignore the wcc info in a +WRITE reply because the reply is in response to a WRITE that was sent +before some other request for which a reply has already been seen. This +is detected by Linux using the gencount tests in nfs_inode_attr_cmp(). + +Also, when the gencount tests pass it is still possible that the request +were processed on the server in a different order, and a gap seen in +the ctime sequence might be filled in by a subsequent reply, so gaps +should not immediately trigger delayed invalidation. + +The net result is that writing to a server and then reading the file +back can result in going to the server for the read rather than serving +it from cache - all because a couple of replies arrived out-of-order. +This is a performance regression over kernels before 5.3, though the +change in 5.3 is a correctness improvement. + +This has been seen with Linux writing to a Netapp server which +occasionally re-orders requests. In testing the majority of requests +were in-order, but a few (maybe 2 or three at a time) could be +re-ordered. + +This patch addresses the problem by recording any gaps seen in the +pre/post ctime sequence and not triggering invalidation until either +there are too many gaps to fit in the table, or until there are no more +active writes and the remaining gaps cannot be resolved. + +We allocate a table of 16 gaps on demand. If the allocation fails we +revert to current behaviour which is of little cost as we are unlikely +to be able to cache the writes anyway. + +In the table we store "start->end" pair when iversion is updated and +"end<-start" pairs pre/post pairs reported by the server. Usually these +exactly cancel out and so nothing is stored. When there are +out-of-order replies we do store gaps and these will eventually be +cancelled against later replies when this client is the only writer. + +If the final write is out-of-order there may be one gap remaining when +the file is closed. This will be noticed and if there is precisely on +gap and if the iversion can be advanced to match it, then we do so. + +This patch makes no attempt to handle directories correctly. The same +problem potentially exists in the out-of-order replies to create/unlink +requests can cause future lookup requires to be sent to the server +unnecessarily. A similar scheme using the same primitives could be used +to notice and handle out-of-order replies. + +Signed-off-by: NeilBrown +Signed-off-by: Anna Schumaker +Stable-dep-of: 867da60d463b ("nfs: avoid i_lock contention in nfs_clear_invalid_mapping") +Signed-off-by: Sasha Levin +--- + fs/nfs/inode.c | 112 +++++++++++++++++++++++++++++++++++------ + include/linux/nfs_fs.h | 47 +++++++++++++++++ + 2 files changed, 144 insertions(+), 15 deletions(-) + +diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c +index cf8c3771e4bfb..82e846611d5e1 100644 +--- a/fs/nfs/inode.c ++++ b/fs/nfs/inode.c +@@ -208,11 +208,12 @@ void nfs_set_cache_invalid(struct inode *inode, unsigned long flags) + + nfsi->cache_validity |= flags; + +- if (inode->i_mapping->nrpages == 0) +- nfsi->cache_validity &= ~(NFS_INO_INVALID_DATA | +- NFS_INO_DATA_INVAL_DEFER); +- else if (nfsi->cache_validity & NFS_INO_INVALID_DATA) +- nfsi->cache_validity &= ~NFS_INO_DATA_INVAL_DEFER; ++ if (inode->i_mapping->nrpages == 0) { ++ nfsi->cache_validity &= ~NFS_INO_INVALID_DATA; ++ nfs_ooo_clear(nfsi); ++ } else if (nfsi->cache_validity & NFS_INO_INVALID_DATA) { ++ nfs_ooo_clear(nfsi); ++ } + trace_nfs_set_cache_invalid(inode, 0); + } + EXPORT_SYMBOL_GPL(nfs_set_cache_invalid); +@@ -677,9 +678,10 @@ static int nfs_vmtruncate(struct inode * inode, loff_t offset) + trace_nfs_size_truncate(inode, offset); + i_size_write(inode, offset); + /* Optimisation */ +- if (offset == 0) +- NFS_I(inode)->cache_validity &= ~(NFS_INO_INVALID_DATA | +- NFS_INO_DATA_INVAL_DEFER); ++ if (offset == 0) { ++ NFS_I(inode)->cache_validity &= ~NFS_INO_INVALID_DATA; ++ nfs_ooo_clear(NFS_I(inode)); ++ } + NFS_I(inode)->cache_validity &= ~NFS_INO_INVALID_SIZE; + + spin_unlock(&inode->i_lock); +@@ -1099,7 +1101,7 @@ void nfs_inode_attach_open_context(struct nfs_open_context *ctx) + + spin_lock(&inode->i_lock); + if (list_empty(&nfsi->open_files) && +- (nfsi->cache_validity & NFS_INO_DATA_INVAL_DEFER)) ++ nfs_ooo_test(nfsi)) + nfs_set_cache_invalid(inode, NFS_INO_INVALID_DATA | + NFS_INO_REVAL_FORCED); + list_add_tail_rcu(&ctx->list, &nfsi->open_files); +@@ -1342,8 +1344,8 @@ int nfs_clear_invalid_mapping(struct address_space *mapping) + + set_bit(NFS_INO_INVALIDATING, bitlock); + smp_wmb(); +- nfsi->cache_validity &= +- ~(NFS_INO_INVALID_DATA | NFS_INO_DATA_INVAL_DEFER); ++ nfsi->cache_validity &= ~NFS_INO_INVALID_DATA; ++ nfs_ooo_clear(nfsi); + spin_unlock(&inode->i_lock); + trace_nfs_invalidate_mapping_enter(inode); + ret = nfs_invalidate_mapping(inode, mapping); +@@ -1805,6 +1807,66 @@ static int nfs_inode_finish_partial_attr_update(const struct nfs_fattr *fattr, + return 0; + } + ++static void nfs_ooo_merge(struct nfs_inode *nfsi, ++ u64 start, u64 end) ++{ ++ int i, cnt; ++ ++ if (nfsi->cache_validity & NFS_INO_DATA_INVAL_DEFER) ++ /* No point merging anything */ ++ return; ++ ++ if (!nfsi->ooo) { ++ nfsi->ooo = kmalloc(sizeof(*nfsi->ooo), GFP_ATOMIC); ++ if (!nfsi->ooo) { ++ nfsi->cache_validity |= NFS_INO_DATA_INVAL_DEFER; ++ return; ++ } ++ nfsi->ooo->cnt = 0; ++ } ++ ++ /* add this range, merging if possible */ ++ cnt = nfsi->ooo->cnt; ++ for (i = 0; i < cnt; i++) { ++ if (end == nfsi->ooo->gap[i].start) ++ end = nfsi->ooo->gap[i].end; ++ else if (start == nfsi->ooo->gap[i].end) ++ start = nfsi->ooo->gap[i].start; ++ else ++ continue; ++ /* Remove 'i' from table and loop to insert the new range */ ++ cnt -= 1; ++ nfsi->ooo->gap[i] = nfsi->ooo->gap[cnt]; ++ i = -1; ++ } ++ if (start != end) { ++ if (cnt >= ARRAY_SIZE(nfsi->ooo->gap)) { ++ nfsi->cache_validity |= NFS_INO_DATA_INVAL_DEFER; ++ kfree(nfsi->ooo); ++ nfsi->ooo = NULL; ++ return; ++ } ++ nfsi->ooo->gap[cnt].start = start; ++ nfsi->ooo->gap[cnt].end = end; ++ cnt += 1; ++ } ++ nfsi->ooo->cnt = cnt; ++} ++ ++static void nfs_ooo_record(struct nfs_inode *nfsi, ++ struct nfs_fattr *fattr) ++{ ++ /* This reply was out-of-order, so record in the ++ * pre/post change id, possibly cancelling ++ * gaps created when iversion was jumpped forward. ++ */ ++ if ((fattr->valid & NFS_ATTR_FATTR_CHANGE) && ++ (fattr->valid & NFS_ATTR_FATTR_PRECHANGE)) ++ nfs_ooo_merge(nfsi, ++ fattr->change_attr, ++ fattr->pre_change_attr); ++} ++ + static int nfs_refresh_inode_locked(struct inode *inode, + struct nfs_fattr *fattr) + { +@@ -1815,8 +1877,12 @@ static int nfs_refresh_inode_locked(struct inode *inode, + + if (attr_cmp > 0 || nfs_inode_finish_partial_attr_update(fattr, inode)) + ret = nfs_update_inode(inode, fattr); +- else if (attr_cmp == 0) +- ret = nfs_check_inode_attributes(inode, fattr); ++ else { ++ nfs_ooo_record(NFS_I(inode), fattr); ++ ++ if (attr_cmp == 0) ++ ret = nfs_check_inode_attributes(inode, fattr); ++ } + + trace_nfs_refresh_inode_exit(inode, ret); + return ret; +@@ -1907,6 +1973,8 @@ int nfs_post_op_update_inode_force_wcc_locked(struct inode *inode, struct nfs_fa + if (attr_cmp < 0) + return 0; + if ((fattr->valid & NFS_ATTR_FATTR) == 0 || !attr_cmp) { ++ /* Record the pre/post change info before clearing PRECHANGE */ ++ nfs_ooo_record(NFS_I(inode), fattr); + fattr->valid &= ~(NFS_ATTR_FATTR_PRECHANGE + | NFS_ATTR_FATTR_PRESIZE + | NFS_ATTR_FATTR_PREMTIME +@@ -2061,6 +2129,15 @@ static int nfs_update_inode(struct inode *inode, struct nfs_fattr *fattr) + + /* More cache consistency checks */ + if (fattr->valid & NFS_ATTR_FATTR_CHANGE) { ++ if (!have_writers && nfsi->ooo && nfsi->ooo->cnt == 1 && ++ nfsi->ooo->gap[0].end == inode_peek_iversion_raw(inode)) { ++ /* There is one remaining gap that hasn't been ++ * merged into iversion - do that now. ++ */ ++ inode_set_iversion_raw(inode, nfsi->ooo->gap[0].start); ++ kfree(nfsi->ooo); ++ nfsi->ooo = NULL; ++ } + if (!inode_eq_iversion_raw(inode, fattr->change_attr)) { + /* Could it be a race with writeback? */ + if (!(have_writers || have_delegation)) { +@@ -2082,8 +2159,11 @@ static int nfs_update_inode(struct inode *inode, struct nfs_fattr *fattr) + dprintk("NFS: change_attr change on server for file %s/%ld\n", + inode->i_sb->s_id, + inode->i_ino); +- } else if (!have_delegation) +- nfsi->cache_validity |= NFS_INO_DATA_INVAL_DEFER; ++ } else if (!have_delegation) { ++ nfs_ooo_record(nfsi, fattr); ++ nfs_ooo_merge(nfsi, inode_peek_iversion_raw(inode), ++ fattr->change_attr); ++ } + inode_set_iversion_raw(inode, fattr->change_attr); + } + } else { +@@ -2237,6 +2317,7 @@ struct inode *nfs_alloc_inode(struct super_block *sb) + return NULL; + nfsi->flags = 0UL; + nfsi->cache_validity = 0UL; ++ nfsi->ooo = NULL; + #if IS_ENABLED(CONFIG_NFS_V4) + nfsi->nfs4_acl = NULL; + #endif /* CONFIG_NFS_V4 */ +@@ -2249,6 +2330,7 @@ EXPORT_SYMBOL_GPL(nfs_alloc_inode); + + void nfs_free_inode(struct inode *inode) + { ++ kfree(NFS_I(inode)->ooo); + kmem_cache_free(nfs_inode_cachep, NFS_I(inode)); + } + EXPORT_SYMBOL_GPL(nfs_free_inode); +diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h +index ac7d799d9d387..dc6c3cc2c2b36 100644 +--- a/include/linux/nfs_fs.h ++++ b/include/linux/nfs_fs.h +@@ -190,6 +190,39 @@ struct nfs_inode { + /* Open contexts for shared mmap writes */ + struct list_head open_files; + ++ /* Keep track of out-of-order replies. ++ * The ooo array contains start/end pairs of ++ * numbers from the changeid sequence when ++ * the inode's iversion has been updated. ++ * It also contains end/start pair (i.e. reverse order) ++ * of sections of the changeid sequence that have ++ * been seen in replies from the server. ++ * Normally these should match and when both ++ * A:B and B:A are found in ooo, they are both removed. ++ * And if a reply with A:B causes an iversion update ++ * of A:B, then neither are added. ++ * When a reply has pre_change that doesn't match ++ * iversion, then the changeid pair and any consequent ++ * change in iversion ARE added. Later replies ++ * might fill in the gaps, or possibly a gap is caused ++ * by a change from another client. ++ * When a file or directory is opened, if the ooo table ++ * is not empty, then we assume the gaps were due to ++ * another client and we invalidate the cached data. ++ * ++ * We can only track a limited number of concurrent gaps. ++ * Currently that limit is 16. ++ * We allocate the table on demand. If there is insufficient ++ * memory, then we probably cannot cache the file anyway ++ * so there is no loss. ++ */ ++ struct { ++ int cnt; ++ struct { ++ u64 start, end; ++ } gap[16]; ++ } *ooo; ++ + #if IS_ENABLED(CONFIG_NFS_V4) + struct nfs4_cached_acl *nfs4_acl; + /* NFSv4 state */ +@@ -616,6 +649,20 @@ nfs_fileid_to_ino_t(u64 fileid) + return ino; + } + ++static inline void nfs_ooo_clear(struct nfs_inode *nfsi) ++{ ++ nfsi->cache_validity &= ~NFS_INO_DATA_INVAL_DEFER; ++ kfree(nfsi->ooo); ++ nfsi->ooo = NULL; ++} ++ ++static inline bool nfs_ooo_test(struct nfs_inode *nfsi) ++{ ++ return (nfsi->cache_validity & NFS_INO_DATA_INVAL_DEFER) || ++ (nfsi->ooo && nfsi->ooo->cnt > 0); ++ ++} ++ + #define NFS_JUKEBOX_RETRY_TIME (5 * HZ) + + /* We need to block new opens while a file is being unlinked. +-- +2.43.0 + diff --git a/queue-6.1/nfsv3-only-use-nfs-timeout-for-mount-when-protocols-.patch b/queue-6.1/nfsv3-only-use-nfs-timeout-for-mount-when-protocols-.patch new file mode 100644 index 00000000000..225a36de9aa --- /dev/null +++ b/queue-6.1/nfsv3-only-use-nfs-timeout-for-mount-when-protocols-.patch @@ -0,0 +1,61 @@ +From 1bbec60fd491ba8763072161dcedac1e4de9dfdc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 4 Oct 2024 11:07:23 +1000 +Subject: NFSv3: only use NFS timeout for MOUNT when protocols are compatible + +From: NeilBrown + +[ Upstream commit 6e2a10343ecb71c4457bc16be05758f9c7aae7d9 ] + +If a timeout is specified in the mount options, it currently applies to +both the NFS protocol and (with v3) the MOUNT protocol. This is +sensible when they both use the same underlying protocol, or those +protocols are compatible w.r.t timeouts as RDMA and TCP are. + +However if, for example, NFS is using TCP and MOUNT is using UDP then +using the same timeout doesn't make much sense. + +If you + mount -o vers=3,proto=tcp,mountproto=udp,timeo=600,retrans=5 \ + server:/path /mountpoint + +then the timeo=600 which was intended for the NFS/TCP request will +apply to the MOUNT/UDP requests with the result that there will only be +one request sent (because UDP has a maximum timeout of 60 seconds). +This is not what a reasonable person might expect. + +This patch disables the sharing of timeout information in cases where +the underlying protocols are not compatible. + +Fixes: c9301cb35b59 ("nfs: hornor timeo and retrans option when mounting NFSv3") +Signed-off-by: NeilBrown +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/super.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +diff --git a/fs/nfs/super.c b/fs/nfs/super.c +index f7b4df29ac5f0..3dffeb1d17b9c 100644 +--- a/fs/nfs/super.c ++++ b/fs/nfs/super.c +@@ -866,7 +866,15 @@ static int nfs_request_mount(struct fs_context *fc, + * Now ask the mount server to map our export path + * to a file handle. + */ +- status = nfs_mount(&request, ctx->timeo, ctx->retrans); ++ if ((request.protocol == XPRT_TRANSPORT_UDP) == ++ !(ctx->flags & NFS_MOUNT_TCP)) ++ /* ++ * NFS protocol and mount protocol are both UDP or neither UDP ++ * so timeouts are compatible. Use NFS timeouts for MOUNT ++ */ ++ status = nfs_mount(&request, ctx->timeo, ctx->retrans); ++ else ++ status = nfs_mount(&request, NFS_UNSPEC_TIMEO, NFS_UNSPEC_RETRANS); + if (status != 0) { + dfprintk(MOUNT, "NFS: unable to mount server %s, error %d\n", + request.hostname, status); +-- +2.43.0 + diff --git a/queue-6.1/platform-x86-amd-pmc-detect-when-stb-is-not-availabl.patch b/queue-6.1/platform-x86-amd-pmc-detect-when-stb-is-not-availabl.patch new file mode 100644 index 00000000000..b69345fb67e --- /dev/null +++ b/queue-6.1/platform-x86-amd-pmc-detect-when-stb-is-not-availabl.patch @@ -0,0 +1,60 @@ +From 07b62fd48c27a8993d84377e10d825c202ea9f3e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 28 Oct 2024 11:02:41 -0700 +Subject: platform/x86/amd/pmc: Detect when STB is not available +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Corey Hickey + +[ Upstream commit bceec87a73804bb4c33b9a6c96e2d27cd893a801 ] + +Loading the amd_pmc module as: + + amd_pmc enable_stb=1 + +...can result in the following messages in the kernel ring buffer: + + amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff + ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff + WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 + +Further debugging reveals that this occurs when the requests for +S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, +indicating that the STB is inaccessible. To prevent the ioremap +warning and provide clarity to the user, handle the invalid address +and display an error message. + +Link: https://lore.kernel.org/platform-driver-x86/c588ff5d-3e04-4549-9a86-284b9b4419ba@amd.com +Fixes: 3d7d407dfb05 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature") +Acked-by: Shyam Sundar S K +Signed-off-by: Corey Hickey +Reviewed-by: Ilpo Järvinen +Link: https://lore.kernel.org/r/20241028180241.1341624-1-bugfood-ml@fatooh.org +Reviewed-by: Hans de Goede +Signed-off-by: Hans de Goede +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/amd/pmc.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/drivers/platform/x86/amd/pmc.c b/drivers/platform/x86/amd/pmc.c +index eb9fc6cb13e33..f237c1ea8d350 100644 +--- a/drivers/platform/x86/amd/pmc.c ++++ b/drivers/platform/x86/amd/pmc.c +@@ -878,6 +878,11 @@ static int amd_pmc_s2d_init(struct amd_pmc_dev *dev) + amd_pmc_send_cmd(dev, S2D_PHYS_ADDR_LOW, &phys_addr_low, STB_SPILL_TO_DRAM, 1); + amd_pmc_send_cmd(dev, S2D_PHYS_ADDR_HIGH, &phys_addr_hi, STB_SPILL_TO_DRAM, 1); + ++ if (!phys_addr_hi && !phys_addr_low) { ++ dev_err(dev->dev, "STB is not enabled on the system; disable enable_stb or contact system vendor\n"); ++ return -EINVAL; ++ } ++ + stb_phys_addr = ((u64)phys_addr_hi << 32 | phys_addr_low); + + /* Clear msg_port for other SMU operation */ +-- +2.43.0 + diff --git a/queue-6.1/sctp-properly-validate-chunk-size-in-sctp_sf_ootb.patch b/queue-6.1/sctp-properly-validate-chunk-size-in-sctp_sf_ootb.patch new file mode 100644 index 00000000000..83e3d6f5597 --- /dev/null +++ b/queue-6.1/sctp-properly-validate-chunk-size-in-sctp_sf_ootb.patch @@ -0,0 +1,49 @@ +From f7ef1c0e468bad2886af7828892b51cc73cb5c3b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 29 Oct 2024 13:46:21 -0400 +Subject: sctp: properly validate chunk size in sctp_sf_ootb() + +From: Xin Long + +[ Upstream commit 0ead60804b64f5bd6999eec88e503c6a1a242d41 ] + +A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add +size validation when walking chunks") is also required in sctp_sf_ootb() +to address a crash reported by syzbot: + + BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 + sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 + sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 + sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 + sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 + sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 + sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 + ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 + ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 + +Reported-by: syzbot+f0cbb34d39392f2746ca@syzkaller.appspotmail.com +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Xin Long +Link: https://patch.msgid.link/a29ebb6d8b9f8affd0f9abb296faafafe10c17d8.1730223981.git.lucien.xin@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/sctp/sm_statefuns.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c +index a56749a50e5c5..4848d5d50a5f5 100644 +--- a/net/sctp/sm_statefuns.c ++++ b/net/sctp/sm_statefuns.c +@@ -3752,7 +3752,7 @@ enum sctp_disposition sctp_sf_ootb(struct net *net, + } + + ch = (struct sctp_chunkhdr *)ch_end; +- } while (ch_end < skb_tail_pointer(skb)); ++ } while (ch_end + sizeof(*ch) < skb_tail_pointer(skb)); + + if (ootb_shut_ack) + return sctp_sf_shut_8_4_5(net, ep, asoc, type, arg, commands); +-- +2.43.0 + diff --git a/queue-6.1/security-keys-fix-slab-out-of-bounds-in-key_task_per.patch b/queue-6.1/security-keys-fix-slab-out-of-bounds-in-key_task_per.patch new file mode 100644 index 00000000000..2b8cc2b8968 --- /dev/null +++ b/queue-6.1/security-keys-fix-slab-out-of-bounds-in-key_task_per.patch @@ -0,0 +1,110 @@ +From 3378ab10f1846232ed7c082ccecc16876b5db53c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 12:46:39 +0000 +Subject: security/keys: fix slab-out-of-bounds in key_task_permission + +From: Chen Ridong + +[ Upstream commit 4a74da044ec9ec8679e6beccc4306b936b62873f ] + +KASAN reports an out of bounds read: +BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 +BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] +BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 +security/keys/permission.c:54 +Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 + +CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 +Call Trace: + __dump_stack lib/dump_stack.c:82 [inline] + dump_stack+0x107/0x167 lib/dump_stack.c:123 + print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 + __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 + kasan_report+0x3a/0x50 mm/kasan/report.c:585 + __kuid_val include/linux/uidgid.h:36 [inline] + uid_eq include/linux/uidgid.h:63 [inline] + key_task_permission+0x394/0x410 security/keys/permission.c:54 + search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 + +This issue was also reported by syzbot. + +It can be reproduced by following these steps(more details [1]): +1. Obtain more than 32 inputs that have similar hashes, which ends with the + pattern '0xxxxxxxe6'. +2. Reboot and add the keys obtained in step 1. + +The reproducer demonstrates how this issue happened: +1. In the search_nested_keyrings function, when it iterates through the + slots in a node(below tag ascend_to_node), if the slot pointer is meta + and node->back_pointer != NULL(it means a root), it will proceed to + descend_to_node. However, there is an exception. If node is the root, + and one of the slots points to a shortcut, it will be treated as a + keyring. +2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. + However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as + ASSOC_ARRAY_PTR_SUBTYPE_MASK. +3. When 32 keys with the similar hashes are added to the tree, the ROOT + has keys with hashes that are not similar (e.g. slot 0) and it splits + NODE A without using a shortcut. When NODE A is filled with keys that + all hashes are xxe6, the keys are similar, NODE A will split with a + shortcut. Finally, it forms the tree as shown below, where slot 6 points + to a shortcut. + + NODE A + +------>+---+ + ROOT | | 0 | xxe6 + +---+ | +---+ + xxxx | 0 | shortcut : : xxe6 + +---+ | +---+ + xxe6 : : | | | xxe6 + +---+ | +---+ + | 6 |---+ : : xxe6 + +---+ +---+ + xxe6 : : | f | xxe6 + +---+ +---+ + xxe6 | f | + +---+ + +4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, + it may be mistakenly transferred to a key*, leading to a read + out-of-bounds read. + +To fix this issue, one should jump to descend_to_node if the ptr is a +shortcut, regardless of whether the node is root or not. + +[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ + +[jarkko: tweaked the commit message a bit to have an appropriate closes + tag.] +Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") +Reported-by: syzbot+5b415c07907a2990d1a3@syzkaller.appspotmail.com +Closes: https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/ +Signed-off-by: Chen Ridong +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Sasha Levin +--- + security/keys/keyring.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +diff --git a/security/keys/keyring.c b/security/keys/keyring.c +index 4448758f643a5..f331725d5a370 100644 +--- a/security/keys/keyring.c ++++ b/security/keys/keyring.c +@@ -772,8 +772,11 @@ static bool search_nested_keyrings(struct key *keyring, + for (; slot < ASSOC_ARRAY_FAN_OUT; slot++) { + ptr = READ_ONCE(node->slots[slot]); + +- if (assoc_array_ptr_is_meta(ptr) && node->back_pointer) +- goto descend_to_node; ++ if (assoc_array_ptr_is_meta(ptr)) { ++ if (node->back_pointer || ++ assoc_array_ptr_is_shortcut(ptr)) ++ goto descend_to_node; ++ } + + if (!keyring_ptr_is_keyring(ptr)) + continue; +-- +2.43.0 + diff --git a/queue-6.1/series b/queue-6.1/series index e69de29bb2d..8cb568532be 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -0,0 +1,33 @@ +arm64-dts-rockchip-fix-rt5651-compatible-value-on-rk.patch +arm64-dts-rockchip-fix-rt5651-compatible-value-on-rk.patch-32368 +arm64-dts-rockchip-remove-hdmi-s-2nd-interrupt-on-rk.patch +arm64-dts-rockchip-fix-wakeup-prop-names-on-pinenote.patch +arm64-dts-rockchip-fix-bluetooth-properties-on-rock9.patch +arm64-dts-rockchip-remove-cooling-cells-from-fan-on-.patch +arm64-dts-rockchip-fix-led-triggers-on-rk3308-roc-cc.patch +arm64-dts-imx8qm-fix-vpu-core-alias-name.patch +arm64-dts-imx8qxp-add-vpu-subsystem-file.patch +arm64-dts-imx8-ss-vpu-fix-imx8qm-vpu-irqs.patch +arm64-dts-imx8mp-correct-sdhc-ipg-clk.patch +arm-dts-rockchip-fix-rk3036-acodec-node.patch +arm-dts-rockchip-drop-grf-reference-from-rk3036-hdmi.patch +arm-dts-rockchip-fix-the-spi-controller-on-rk3036.patch +arm-dts-rockchip-fix-the-realtek-audio-codec-on-rk30.patch +hid-core-zero-initialize-the-report-buffer.patch +platform-x86-amd-pmc-detect-when-stb-is-not-availabl.patch +sunrpc-handle-enotconn-in-xs_tcp_setup_socket.patch +nfsv3-only-use-nfs-timeout-for-mount-when-protocols-.patch +nfsv3-handle-out-of-order-write-replies.patch +nfs-avoid-i_lock-contention-in-nfs_clear_invalid_map.patch +security-keys-fix-slab-out-of-bounds-in-key_task_per.patch +net-enetc-set-mac-address-to-the-vf-net_device.patch +sctp-properly-validate-chunk-size-in-sctp_sf_ootb.patch +can-c_can-fix-rx-tx-_errors-statistics.patch +ice-change-q_index-variable-type-to-s16-to-store-1-v.patch +i40e-fix-race-condition-by-adding-filter-s-intermedi.patch +net-hns3-fix-kernel-crash-when-uninstalling-driver.patch +net-phy-ti-add-phy_rst_after_clk_en-flag.patch +net-stmmac-fix-unbalanced-irq-wake-disable-warning-o.patch +virtio_net-add-hash_key_length-check.patch +net-arc-fix-the-device-for-dma_map_single-dma_unmap_.patch +net-arc-rockchip-fix-emac-mdio-node-support.patch diff --git a/queue-6.1/sunrpc-handle-enotconn-in-xs_tcp_setup_socket.patch b/queue-6.1/sunrpc-handle-enotconn-in-xs_tcp_setup_socket.patch new file mode 100644 index 00000000000..760b65718fd --- /dev/null +++ b/queue-6.1/sunrpc-handle-enotconn-in-xs_tcp_setup_socket.patch @@ -0,0 +1,46 @@ +From 3e718b9694153cbbef210fb3661d2999841ac7de Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 9 Oct 2024 16:28:06 +1100 +Subject: sunrpc: handle -ENOTCONN in xs_tcp_setup_socket() + +From: NeilBrown + +[ Upstream commit 10f0740234f0b157b41bdc7e9c3555a9b86c1599 ] + +xs_tcp_finish_connecting() can return -ENOTCONN but the switch statement +in xs_tcp_setup_socket() treats that as an unhandled error. + +If we treat it as a known error it would propagate back to +call_connect_status() which does handle that error code. This appears +to be the intention of the commit (given below) which added -ENOTCONN as +a return status for xs_tcp_finish_connecting(). + +So add -ENOTCONN to the switch statement as an error to pass through to +the caller. + +Link: https://bugzilla.suse.com/show_bug.cgi?id=1231050 +Link: https://access.redhat.com/discussions/3434091 +Fixes: 01d37c428ae0 ("SUNRPC: xprt_connect() don't abort the task if the transport isn't bound") +Signed-off-by: NeilBrown +Reviewed-by: Benjamin Coddington +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + net/sunrpc/xprtsock.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c +index 02f651f85e739..190dae11f634a 100644 +--- a/net/sunrpc/xprtsock.c ++++ b/net/sunrpc/xprtsock.c +@@ -2351,6 +2351,7 @@ static void xs_tcp_setup_socket(struct work_struct *work) + case -EHOSTUNREACH: + case -EADDRINUSE: + case -ENOBUFS: ++ case -ENOTCONN: + break; + default: + printk("%s: connect returned unhandled error %d\n", +-- +2.43.0 + diff --git a/queue-6.1/virtio_net-add-hash_key_length-check.patch b/queue-6.1/virtio_net-add-hash_key_length-check.patch new file mode 100644 index 00000000000..16554ec5765 --- /dev/null +++ b/queue-6.1/virtio_net-add-hash_key_length-check.patch @@ -0,0 +1,43 @@ +From ede1f63fcd566ab7121ef31413dec86e5948ac54 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 4 Nov 2024 16:57:04 +0800 +Subject: virtio_net: Add hash_key_length check + +From: Philo Lu + +[ Upstream commit 3f7d9c1964fcd16d02a8a9d4fd6f6cb60c4cc530 ] + +Add hash_key_length check in virtnet_probe() to avoid possible out of +bound errors when setting/reading the hash key. + +Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.") +Signed-off-by: Philo Lu +Signed-off-by: Xuan Zhuo +Acked-by: Joe Damato +Acked-by: Michael S. Tsirkin +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/virtio_net.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c +index e3e5107adaca6..11aa0a7d54cd7 100644 +--- a/drivers/net/virtio_net.c ++++ b/drivers/net/virtio_net.c +@@ -3887,6 +3887,12 @@ static int virtnet_probe(struct virtio_device *vdev) + if (vi->has_rss || vi->has_rss_hash_report) { + vi->rss_key_size = + virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size)); ++ if (vi->rss_key_size > VIRTIO_NET_RSS_MAX_KEY_SIZE) { ++ dev_err(&vdev->dev, "rss_max_key_size=%u exceeds the limit %u.\n", ++ vi->rss_key_size, VIRTIO_NET_RSS_MAX_KEY_SIZE); ++ err = -EINVAL; ++ goto free; ++ } + + vi->rss_hash_types_supported = + virtio_cread32(vdev, offsetof(struct virtio_net_config, supported_hash_types)); +-- +2.43.0 +