* [PATCH v6 03/11] arm64: dts: ti: k3-am62a7-sk: Fix wkup R5F memory region size
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
The wkup_r5fss0_core0_memory_region was reserved with only
0x0f00000 but the MCU SDK linker for the wkup R5F firmware on
AM62A defines the DM code/data DDR footprint differently:
/* DDR for DM R5F code/data [ size 27 MiB + 364 KB ] */
DDR : ORIGIN = 0x9CAA5000 LENGTH = 0x1B5B000
which results in an end at 0x9e600000. For this memory region which
starts at 0x9c900000 this means a length of:
0x9e600000 - 0x9c900000 = 0x1d00000
Link: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd
Fixes: 77c29ebe76d8 ("arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index c1e9067b3bdd5ab0591541d4685bb17a5dac4f65..63a4fb03dc0acac63bc573e290ec613617f492f0 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -61,7 +61,7 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
wkup_r5fss0_core0_memory_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0xf00000>;
+ reg = <0x00 0x9c900000 0x00 0x01d00000>;
no-map;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 06/11] arm64: dts: ti: var-som-am62p: Fix wkup R5F memory region size
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
The wkup_r5fss0_core0_memory_region was reserved with only
0x0f00000 but the MCU SDK linker for the wkup R5F firmware on
AM62P defines the DM code/data DDR footprint differently:
/* DDR for DM R5F code/data [ size 27 MiB + 396 KB ] */
DDR : ORIGIN = 0x9CAA5000 LENGTH = 0x1B63000
which results in an end at 0x9e608000. For this memory region which
starts at 0x9c900000 this means a length of:
0x9e608000 - 0x9c900000 = 0x1d08000
Link: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/linker.cmd
Fixes: 571562e76458 ("arm64: dts: ti: Add support for Variscite VAR-SOM-AM62P")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
index fc5a3942cde001ce33fa295f68a3850b622cac7d..1408c970f1942e8a720c9cf071b2f49eafa9db5e 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
@@ -71,7 +71,7 @@ wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
wkup_r5fss0_core0_memory_region: r5f-memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01e00000>;
+ reg = <0x00 0x9c900000 0x00 0x01d08000>;
no-map;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 11/11] arm64: dts: ti: k3-am62p-ti-ipc-firmware: Add r5f nodes to pre-ram bootphase
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
For IO+DDR the wkup_r5fss0_core0 and the
wkup_r5fss0_core0_lpm_metadata_region need to be accessed before RAM
setup is done. These are used to read the lpm metadata region in which
data is stored to resume. This needs to be done before RAM is in use to
avoid overwriting data.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
index 8f7409da83392d2d1f160a9645ef4d68f7aaa1bf..04fcd5115b9d95e6e23c4e43782c06501a0fa601 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
@@ -40,6 +40,7 @@ wkup_r5fss0_core0_lpm_metadata_region: memory@9ca08000 {
compatible = "shared-dma-pool";
reg = <0x00 0x9ca08000 0x00 0x1000>;
no-map;
+ bootph-pre-ram;
};
wkup_r5fss0_core0_lpm_rest_region: memory@9ca09000 {
@@ -89,6 +90,7 @@ &wkup_r5fss0_core0 {
"lpm-metadata", "lpm-context",
"dm-firmware";
status = "okay";
+ bootph-pre-ram;
};
&mcu_r5fss0 {
--
2.53.0
^ permalink raw reply related
* [PATCH v6 08/11] arm64: dts: ti: k3-am62p-ti-ipc-firmware: Move wkup reserved memory
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
Move the reserved memory regions used for wkup_r5fss0_core0 to the
k3-am62p-ti-ipc-firmware.dtsi. These are all the same for the other
boards as well, so we can combine them here similar to what is already
done for the mcu_r5fss0_core0 memory regions.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 12 ------------
arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 12 ------------
arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi | 12 ------------
4 files changed, 12 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
index 5d7f701420e2d8308b637f3064c560e485ed85f2..f77651109564224408723b72baba93e39a82be07 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
@@ -17,6 +17,18 @@ mcu_r5fss0_core0_memory_region: memory@9b900000 {
reg = <0x00 0x9b900000 0x00 0xf00000>;
no-map;
};
+
+ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9c800000 0x00 0x100000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_memory_region: memory@9c900000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9c900000 0x00 0x01d08000>;
+ no-map;
+ };
};
&mailbox0_cluster0 {
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
index 8a5ff5c457579c7b1be7157d235fd4b4e5c6af11..49c78b6b8b2b43fe381c761823bbd93725f331aa 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
@@ -161,18 +161,6 @@ secure_ddr: optee@9e800000 {
reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
no-map;
};
-
- wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
- compatible = "shared-dma-pool";
- reg = <0x00 0x9c800000 0x00 0x100000>;
- no-map;
- };
-
- wkup_r5fss0_core0_memory_region: memory@9c900000 {
- compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01d08000>;
- no-map;
- };
};
};
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
index 16549fd7340a556798cf5a242746c219d3168d83..6444aa0c106197eb44088ec99d7c7dba7f8f854d 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
@@ -49,18 +49,6 @@ reserved_memory: reserved-memory {
#size-cells = <2>;
ranges;
- wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
- compatible = "shared-dma-pool";
- reg = <0x00 0x9c800000 0x00 0x100000>;
- no-map;
- };
-
- wkup_r5fss0_core0_memory_region: memory@9c900000 {
- compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01d08000>;
- no-map;
- };
-
secure_tfa_ddr: tfa@9e780000 {
reg = <0x00 0x9e780000 0x00 0x80000>;
no-map;
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
index 1408c970f1942e8a720c9cf071b2f49eafa9db5e..76295e47eca9d6373a89430355330c9a4ac9be32 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-var-som.dtsi
@@ -63,18 +63,6 @@ rtos_ipc_memory_region: rtos-ipc-memory@9b500000 {
no-map;
};
- wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
- compatible = "shared-dma-pool";
- reg = <0x00 0x9c800000 0x00 0x00100000>;
- no-map;
- };
-
- wkup_r5fss0_core0_memory_region: r5f-memory@9c900000 {
- compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01d08000>;
- no-map;
- };
-
secure_tfa_ddr: tfa@9e780000 {
reg = <0x00 0x9e780000 0x00 0x80000>;
no-map;
--
2.53.0
^ permalink raw reply related
* [PATCH v6 09/11] arm64: dts: ti: k3-am62a-ti-ipc-firmware: Split r5f memory region
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
Split the firmware memory region in more specific parts so it is better
described where to find which information. Specifically the LPM metadata
region is important as bootloader software like U-Boot has to know where
that data is to be able to read that data.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
.../boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi | 38 +++++++++++++++++++---
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi
index 682b1c9f3071ddf23044c1fde1e88f2b901ec64c..fe10d3e75ceee35f84d34b892f9925efceb7743a 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi
@@ -36,12 +36,36 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
no-map;
};
- wkup_r5fss0_core0_memory_region: memory@9c900000 {
+ wkup_r5fss0_core0_ipc_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01d00000>;
+ reg = <0x00 0x9c900000 0x00 0x100000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_fs_stub_region: memory@9ca00000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca00000 0x00 0x8000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_metadata_region: memory@9ca08000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca08000 0x00 0x1000>;
no-map;
bootph-pre-ram;
};
+
+ wkup_r5fss0_core0_lpm_rest_region: memory@9ca09000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca09000 0x00 0x97000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_dm_region: memory@9caa0000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9caa0000 0x00 0x1b60000>;
+ no-map;
+ };
};
&mailbox0_cluster0 {
@@ -78,8 +102,14 @@ &wkup_r5fss0 {
&wkup_r5fss0_core0 {
mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
- <&wkup_r5fss0_core0_memory_region>;
- memory-region-names = "dma", "firmware";
+ <&wkup_r5fss0_core0_ipc_region>,
+ <&wkup_r5fss0_core0_lpm_fs_stub_region>,
+ <&wkup_r5fss0_core0_lpm_metadata_region>,
+ <&wkup_r5fss0_core0_lpm_rest_region>,
+ <&wkup_r5fss0_core0_dm_region>;
+ memory-region-names = "dma", "ipc", "lpm-stub",
+ "lpm-metadata", "lpm-context",
+ "dm-firmware";
bootph-pre-ram;
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 10/11] arm64: dts: ti: k3-am62p-ti-ipc-firmware: Split r5f memory region
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
Split the firmware memory region in more specific parts so it is better
described where to find which information. Specifically the LPM metadata
region is important as bootloader software like U-Boot has to know where
that data is to be able to read that data.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
.../boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi | 38 +++++++++++++++++++---
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
index f77651109564224408723b72baba93e39a82be07..8f7409da83392d2d1f160a9645ef4d68f7aaa1bf 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
@@ -24,9 +24,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
no-map;
};
- wkup_r5fss0_core0_memory_region: memory@9c900000 {
+ wkup_r5fss0_core0_ipc_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01d08000>;
+ reg = <0x00 0x9c900000 0x00 0x100000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_fs_stub_region: memory@9ca00000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca00000 0x00 0x8000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_metadata_region: memory@9ca08000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca08000 0x00 0x1000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_lpm_rest_region: memory@9ca09000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9ca09000 0x00 0x97000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_dm_region: memory@9caa0000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9caa0000 0x00 0x1b68000>;
no-map;
};
};
@@ -56,8 +80,14 @@ &wkup_r5fss0 {
&wkup_r5fss0_core0 {
mboxes = <&mailbox0_cluster0 &mbox_r5_0>;
memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
- <&wkup_r5fss0_core0_memory_region>;
- memory-region-names = "dma", "firmware";
+ <&wkup_r5fss0_core0_ipc_region>,
+ <&wkup_r5fss0_core0_lpm_fs_stub_region>,
+ <&wkup_r5fss0_core0_lpm_metadata_region>,
+ <&wkup_r5fss0_core0_lpm_rest_region>,
+ <&wkup_r5fss0_core0_dm_region>;
+ memory-region-names = "dma", "ipc", "lpm-stub",
+ "lpm-metadata", "lpm-context",
+ "dm-firmware";
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v8 07/12] iommu/arm-smmu-v3: Add CMDQ_PROD_STOP_FLAG to gate CMDQ submissions
From: Pranjal Shrivastava @ 2026-06-09 18:58 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rDgXxAhJFUX6=xars9H92t8NBDqcFRxU7d5wJQ7buUbNA@mail.gmail.com>
On Tue, Jun 09, 2026 at 11:20:52AM -0700, Daniel Mentz wrote:
> On Tue, Jun 9, 2026 at 3:05 AM Pranjal Shrivastava <praan@google.com> wrote:
> > >
> > > > Even if the worker CPU reorders the PTE write after the STOP_FLAG check,
> > > > it is benign because the SMMU is incapable of fetching that (or any) PTE
> > > > while the gate is closed. Because GATE_CLOSED == SMMUEN = 0, implying no
> > > > access to any HW structures whatsoever.
> > > >
> > > > The real synchronization happens in the Resume Path:
> > > >
> > > > 1. arm_smmu_device_reset() clears all caches / TLBs.
> > > > (None of these can have entries before SMMUEN=1)
> > > >
> > > > 2. We execute a full smp_mb() before setting SMMUEN=1. (that's why we
> > > > need smp_mb before SMMUEN=1). This barrier ensures that any PTE
> > > > writes made by any thread—including those that were elided while the
> > > > gate was closed, are globally visible before the SMMU hardware starts
> > > > fetching into TLBs again. (This is why Jason suggested this in v6 [1])
> > >
> > > A barrier on one CPU has no bearing on whether writes by any other CPU
> > > can be observed by any particular agent in the system.
> > >
> > > Let's compare this with the long comment in
> > > arm_smmu_domain_inv_range() which is what I believe Jason was
> > > referring to. In that example, you see smp_mb() in the code path on
> > > CPU0 and dma_wmb() in the code path on CPU1. Hence, barriers exist on
> > > both sides. If you compare the runtime PM design with
> > > arm_smmu_domain_inv_range(), then smp_mb() belongs in the CPU thread
> > > that performs the translation table updates not the one that performs
> > > the suspend/resume operation.
> > >
> >
> > I might be missing something here, so please bear with me. My
> > understanding it that's needed because the IOMMU is live & actively
> > caching, which is not true for our case.
>
> I think the "invs" design (Per-domain invalidation array) is more
> similar than you think! An SMMU being absent from invs is equivalent
> to the STOP flag, and the STE pointing to TTB0 is roughly the
> equivalent of SMMEN=1 i.e. the IOMMU is not actively caching a
> particular translation domain until an STE (or CD) points to it.
>
> > [Assuming we use non-relaxed semantics & ordering for the STOP flag,
> > i.e. set STOP_FLAG + barrier & clear STOP_FLAG (implicit dma_wmb())]
> >
> > In our case, during the resume op, we first clear the STOP_FLAG before
> > setting SMMUEN=1 in program order. Thus, any PTE invalidations occurring
> > before SMMUEN=1 are executed, i.e. EVEN when the SMMU is guaranteed not
> > to access any structures, we've resumed invalidations.
>
> "[...] we first clear the STOP_FLAG before setting SMMUEN=1 in program
> order." I think this should be modified to "we first clear the
> STOP_FLAG and ensure that the cleared STOP_FLAG is observable by all
> other CPUs before setting SMMUEN=1"
>
Ack. The goal was to explain the algorithm for this thread, I won't be
commenting it in code. Are you suggesting I should convert my
explaination of the algorithm above into in-line comments and make sure
to include the STOP_FLAG observability part?
> Re "Thus, any PTE invalidations occurring before SMMUEN=1 are
> executed,": I think that "a PTE invalidation occurring" is not clearly
> defined. Also, it's not clear to me what this statement implies. It's
> paramount that invalidations are performed when SMMUEN=1. The fact
> that we perform invalidations before SMMUEN=1 is more of a side effect
> of our methodology.
By "invalidations occurring before SMMUEN=1", I mean that once the STOP_FLAG
is cleared, any concurrent unmaps (PTE updates) will successfully submit
invalidation cmds to the cmdq. Since SMMU translation (SMMUEN) is still
disabled at this point, these invalidations execute safely without racing
against SMMU caching (which was the concern in the previous email).
>
> I would define a set of invariants:
>
> * If an agent observes the STOP flag, it is guaranteed that SMMUEN=0
> (with ABORT set) at the time of observation.
> * Any transition from a set STOP flag to SMMUEN=1 involves an
> invalidate-all operation prior to setting SMMUEN=1
>
> Hence, if a CPU observes the STOP flag, it is assured that (a)
> transactions are blocked and (b) if the SMMU is ever re-enabled, an
> invalidate-all is performed prior to it being enabled.
>
> I would then argue that all operations support these invariants. For
> example, we need proper barriers in the iommu_unmap path to ensure
> that the STOP flag is only checked *after* the translation table
> update is made. Hence, we need a memory barrier.
>
> I look at it this way: Every elided invalidation creates an
> "invalidation deficit", and this deficit is tolerable for two reasons:
> (a) SMMU blocks all transactions while there is a deficit. (b) An
> invalidate-all eliminates any deficit accrued while the STOP flag was
> set.
Ack, which means you agree with the design proposed in my last reply.
I'll document these invariants in line if that's what you're suggesting
here?
>
> > Let's consider a few examples:
> >
> > 1. SUSPEND (say CPU0 is suspending)
> >
> > [CPU0] SMMUEN = 0 ==> SMMU stops accessing HW structures (ABORT NOT set)
>
> I thought we never disable the SMMU unless ABORT is set.
Yes, that is evident from the code [1]. I made a mistake in ordering
while trying to explain why & how this works.
>
>
> > HW structures not accessed means no TLB / CFG
> > cache accesses as well according to the spec.
> >
> > [CPU1] ==> PTE update => Invalidate => Succeeds (although SMMUEN = 0)
> >
> > [CPU0] GBPA.Abort set ==> Txns are blocked
> >
> > [CPU2] => PTE update => Invalidate => Succeeds [Txns blocked + SMMUEN=0]
> >
> > [CPU0] ==> SET STOP_FLAG ==> Elision begins
> >
> > [CPU3] ==> PTE update ==> Invalidation ==> Elided [Txns blocked + SMMUEN=0]
> >
> > Hence, the races in the suspend sequence are handled correctly.
>
> I'm not sure if this description demonstrates that every possible race
> is handled correctly. If I compare this with Nicolin's presentation in
> arm_smmu_domain_inv_range, I like that presentation, as it explicitly
> mentions loads and barriers. For example, it has an smp_mb() followed
> by "// load the updated invs". I think you should make have something
> like "smp_mb() ; CHECK STOP_FLAG" in your presentation. Currently, the
> STOP_FLAG checking is somehow implicit in "Invalidation".
Ack. The goal of this diagram was to explain the working of the design,
this is NOT the comment/document I plan to include in code.
I'll add this as an in-line comment if that's what you're suggesting? OR
are you also suggesting I should have this in my cover letter?
>
> >
> > 2. RESUME (say CPU0 is resuming)
> >
> > [CPU1] ==> Update PTE ==> Invalidate ==> Elided [Txns blocked + SMMUEN=0]
> >
> > [CPU0] ==> Clear STOP_FLAGs [Txns still blocked + SMMUEN=0]
> >
> > [CPU2] ==> Update PTE ==> Invalidate ==> Succeeds [Txns blocked + SMMUEN=0]
> >
> > [CPU0] ==> Invalidate all TLB ==> Succeeds [Txns still blocked + SMMUEN=0]
> > [CPU0] ==> Invalidate all CFG ==> Succeeds [Txns still blocked + SMMUEN=0]
> >
> > [CPU2] ==> Update PTE ==> Invalidate ==> Succeeds [Txns still blocked + SMMUEN=0]
> >
> > [CPU0] ==> Set SMMUEN = 1 [SMMU can now access in memory structures]
> > However, the TLBs and CFG caches are clean because everything
> > until this point couldn't have cached anything anyway.
>
> My concern with this diagram is that it appears sequential, suggesting
> operations happen in a specific order across CPUs when they, in fact,
> occur in parallel. I find these diagrams more useful for describing
> failure cases than for proving that every race is handled correctly.
>
Ack. Again, the goal was to explain it to you and not propose how the
comments are gonna look like. I'll use your preferred way to explain in
the future.
> >
> > Hence, right after clearing the STOP_FLAG, we're taking in invalidations
> > as normal in the resume, much before the real caching can begin.
> >
> > Thus, by resuming invalidations before SMMUEN=1, we guarantee a
> > consistent state before the very first translation is performed.
> >
> > Apart from this, I guess I'll drop the can_elide check from all
> > invalidation paths.
> >
> > Does that sound fine?
>
> Dropping can_elide sounds fine. However, if you still use this
> function, for example in the gerror handler, then you might consider
> renaming it.
Ack, I'll name it back to arm_smmu_is_suspended().
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Roman Vivchar @ 2026-06-09 19:15 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <aihbxowyAIlSeDjH@ashevche-desk.local>
Hi Andy,
On Tuesday, June 9th, 2026 at 9:30 PM, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Jun 09, 2026 at 04:31:59PM +0300, Roman Vivchar via B4 Relay wrote:
>
...
>
> > + ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19, val,
> > + !(val & AUXADC_ADC19_BUSY_MASK),
> > + 10, 500);
>
> It's better to split on logical boundaries:
>
> ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19,
> val, !(val & AUXADC_ADC19_BUSY_MASK),
> 10, 500);
>
Agreed.
...
>
> > + case IIO_CHAN_INFO_RAW:
> > + scoped_guard(mutex, &auxadc->lock) {
>
> I'm wondering why we haven't moved to guard()() here
The compiler would complain about 'cannot jump from switch statement'
due to default case.
Best regards,
Roman
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.2 (#1)
From: Arnd Bergmann @ 2026-06-09 19:29 UTC (permalink / raw)
To: Aleksander Jan Bajkowski, Gregory Clement, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
In-Reply-To: <4e690104-b42f-4a2b-ac52-5ebfc82f6853@wp.pl>
On Tue, Jun 9, 2026, at 19:35, Aleksander Jan Bajkowski wrote:
> On 09/06/2026 18:11, Arnd Bergmann wrote:
>> I'm a bit surprised by this oneline change. Since you successfully tested
>> this, I assume the change is correct, but I have two questions that
>> I would like to have an answer for before I pull it.
> By the way, the upstream safexcel driver works correctly only on
> coherent
> platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512
> selftests fail. Since the selftests pass on Armada's SoC, I assume I'm
> right.
It's not necessarily proof that this is correct, but it is quite likely.
After checking the datasheet some more and finding that this should
indeed be coherent everywhere, I remembered that even the old
32-bit Armada 370 had a coherency manager. At the time, we used a hack
in arch/arm/mach-mvebu/coherency.c to mark all device nodes as coherent,
since the original DTB did not contain the correct annotations.
I suspect that the Armada 37xx started out with a copy of the
old DT files and also never had the annotation, but then never
had the same hack because arch/arm64 does not have platform
specific code.
> I have a plan to send a patch upstream, which has long been maintained
> downstream in OpenWRT[1]. But I need to think a bit more about how to do
> this properly.
> [1]
> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.18/401-crypto-fix-eip97-cache-incoherent.patch
The patch is basically correct, I think you should just change two
details:
- instead of defining your own SYSTEM_CACHELINE_SIZE macro, just use
the existing CRYPTO_DMA_ALIGN macro that is used in crypto_dma_align
- move the 'state[]' and 'cache[]' arrays to the beginning of
safexcel_ahash_req so you don't have to manually align them.
>> - I would expect a missing 'dma-coherent' property to cause data
>> corruption, as the DMA master may write directly into the L2
>> cache, which is then invalidated before the CPU accesses it.
>> Do you have any idea how this one ends up working even when
>> the property is missing?
> No idea. Don't have access the Armada SoC TRM. Maybe the folks at
> Marvel will be able to explain it.
ok
Arnd
^ permalink raw reply
* [PATCHv2] dmaengine: st_fdma: simplify allocation by using flexible array
From: Rosen Penev @ 2026-06-09 19:30 UTC (permalink / raw)
To: dmaengine
Cc: Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be|_ptr)?b
Use a flexible array member to combine kzalloc and kcalloc to a single
allocation.
Add __counted_by for extra runtime analysis. Assign counting variable
after allocation before any array accesses.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
v2: Update subject
drivers/dma/st_fdma.c | 27 ++++++++-------------------
drivers/dma/st_fdma.h | 4 ++--
2 files changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index d9547017f3bd..3ec0d6731b8d 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -710,16 +710,6 @@ static const struct of_device_id st_fdma_match[] = {
};
MODULE_DEVICE_TABLE(of, st_fdma_match);
-static int st_fdma_parse_dt(struct platform_device *pdev,
- const struct st_fdma_driverdata *drvdata,
- struct st_fdma_dev *fdev)
-{
- snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
- drvdata->name, drvdata->id);
-
- return of_property_read_u32(pdev->dev.of_node, "dma-channels",
- &fdev->nr_channels);
-}
#define FDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
@@ -742,27 +732,26 @@ static int st_fdma_probe(struct platform_device *pdev)
struct st_fdma_dev *fdev;
struct device_node *np = pdev->dev.of_node;
const struct st_fdma_driverdata *drvdata;
+ u32 nr_channels;
int ret, i;
drvdata = device_get_match_data(&pdev->dev);
- fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
- if (!fdev)
- return -ENOMEM;
-
- ret = st_fdma_parse_dt(pdev, drvdata, fdev);
+ ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", &nr_channels);
if (ret) {
dev_err(&pdev->dev, "unable to find platform data\n");
- goto err;
+ return ret;
}
- fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
- sizeof(struct st_fdma_chan), GFP_KERNEL);
- if (!fdev->chans)
+ fdev = devm_kzalloc(&pdev->dev, struct_size(fdev, chans, nr_channels), GFP_KERNEL);
+ if (!fdev)
return -ENOMEM;
+ fdev->nr_channels = nr_channels;
fdev->dev = &pdev->dev;
fdev->drvdata = drvdata;
+ snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf", drvdata->name, drvdata->id);
+
platform_set_drvdata(pdev, fdev);
fdev->irq = platform_get_irq(pdev, 0);
diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
index f1e746f7bc7d..27ded555879f 100644
--- a/drivers/dma/st_fdma.h
+++ b/drivers/dma/st_fdma.h
@@ -136,13 +136,13 @@ struct st_fdma_dev {
int irq;
- struct st_fdma_chan *chans;
-
spinlock_t dreq_lock;
unsigned long dreq_mask;
u32 nr_channels;
char fw_name[FW_NAME_SIZE];
+
+ struct st_fdma_chan chans[] __counted_by(nr_channels);
};
/* Peripheral Registers*/
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next v2 03/14] net: pcs: pcs-xpcs-regmap: support XPCS memory-mapped MDIO bus via regmap
From: Alex Elder @ 2026-06-09 19:31 UTC (permalink / raw)
To: Maxime Chevallier, andrew+netdev, davem, edumazet, kuba, pabeni,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh
Cc: Daniel Thompson, mohd.anwar, a0987203069, alexandre.torgue, ast,
boon.khai.ng, chenchuangyu, chenhuacai, daniel, hawk, hkallweit1,
inochiama, john.fastabend, julianbraha, livelycarpet87,
mcoquelin.stm32, me, prabhakar.mahadev-lad.rj, richardcochran,
rohan.g.thomas, sdf, siyanteng, weishangjuan, wens, netdev, bpf,
linux-arm-msm, devicetree, linux-gpio, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <566af63b-05a9-43f8-94e9-19af737c848a@bootlin.com>
On 6/5/26 10:35 AM, Maxime Chevallier wrote:
>> + const struct xpcs_regmap_config *config)
>> +{
>> + static atomic_t id = ATOMIC_INIT(-1);
>> + struct dw_xpcs_regmap *pxpcs;
>> + struct dw_xpcs *xpcs;
>> + int ret;
>> +
>> + pxpcs = devm_kzalloc(dev, sizeof(*pxpcs), GFP_KERNEL);
>> + if (!pxpcs)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + pxpcs->dev = dev;
>> + pxpcs->regmap = config->regmap;
>> + pxpcs->reg_indir = config->reg_indir;
> Looking at the overall series, is there any reason for this flag ?
>
> Looks like the reg_indir=false path isn't used at all in this series.
>
> Maybe just drop it and let anyone add it back should the need arise ?
You're right that it's always true (in this one case it's used).
I think it's fine to get rid of the reg_indir flag, and that
will simplify a lot of things. It eliminates the need for the
xpcs_regmap_config structure (just register with regmap pointer
instead).
The "pcs-xpcs-regmap.h" header could be removed too if we declared
devm_xpcs_regmap_register() in "drivers/net/pcs/pcs-xpcs.h". (I
won't do this unless you or someone else suggests it though.)
I will rearrange the code to support only the indirect access
method for this code.
-Alex
^ permalink raw reply
* Re: [PATCH net-next v2 13/14] net: stmmac: tc956x: add TC956x/QPS615 support
From: Alex Elder @ 2026-06-09 19:32 UTC (permalink / raw)
To: Maxime Chevallier, andrew+netdev, davem, edumazet, kuba, pabeni,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh
Cc: Daniel Thompson, mohd.anwar, a0987203069, alexandre.torgue, ast,
boon.khai.ng, chenchuangyu, chenhuacai, daniel, hawk, hkallweit1,
inochiama, john.fastabend, julianbraha, livelycarpet87,
mcoquelin.stm32, me, prabhakar.mahadev-lad.rj, richardcochran,
rohan.g.thomas, sdf, siyanteng, weishangjuan, wens, netdev, bpf,
linux-arm-msm, devicetree, linux-gpio, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <c60d1819-18d7-4d4c-a997-586599323d7e@bootlin.com>
On 6/5/26 11:05 AM, Maxime Chevallier wrote:
> Hi Alex,
>
> On 6/5/26 03:00, Alex Elder wrote:
>> From: Daniel Thompson <daniel@riscstar.com>
>>
>> Toshiba TC956x is an Ethernet AVB/TSN bridge and is essentially a
>> small and highly-specialized SoC. TC956x includes an "eMAC" subsystem
>> that can be accessed, along with several other peripherals, via two
>> PCIe endpoint functions. There is a main driver for the endpoint that
>> decomposes things and creates auxiliary bus devices to model the SoC.
>>
>> The eMAC consists of a Designware XGMAC, XPCS and PMA. Each eMAC is
>> supported by an MSIGEN that bridges TC956x level interrupts to PCIe
>> MSIs.
>>
>> Add a driver for the eMAC/MSIGEN combination.
>>
>> Co-developed-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>> ---
> [...]
>
>> +static int tc956x_lookup_max_speed(phy_interface_t phy_interface)
>> +{
>> + switch (phy_interface) {
>> + case PHY_INTERFACE_MODE_SGMII:
>
> The SGMII definition we use in the kernel is the Cisco SGMII de-facto
> standard that only supports 10/100/1000M. Some vendors use flavours with
> names such as HS-SGMII and such, that's basically SGMII clocked at 2.5G
> with aneg disabled. It kinda becomes 2500BaseX then.
So for SGMII then, the max speed returned/used should be
SPEED_1000, correct? And for 2500BASEX it's SPEED_2500.
(I'll fix this.)
For USXGMII I presume we'd use SPEED_10000 as the max_speed.
Can someone explain when the plat_stmmacenet_data->max_speed value
must be set? It seems like plat_stmmacenet_data->phy_interface
should normally imply the right maximum speed. It looks like
phylink_interface_max_speed() has a big switch statement related
to this.
Thanks.
-Alex
> So all in all, we don't support 2500M on SGMII.
>
>> + case PHY_INTERFACE_MODE_2500BASEX:
>> + return SPEED_2500;
>> +
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>
> Maxime
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Andy Shevchenko @ 2026-06-09 19:33 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <hacDZbv1Whk_g8AMSfJqKHrgXfyVKt2o3_UGK-1k9jNRJyMxEFPztGhytHvHbc1x9j-F84I_ZuprmXWf2Azbtdqj2vnVal4PO1gG_DijYyA=@protonmail.com>
On Tue, Jun 09, 2026 at 07:15:42PM +0000, Roman Vivchar wrote:
> On Tuesday, June 9th, 2026 at 9:30 PM, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, Jun 09, 2026 at 04:31:59PM +0300, Roman Vivchar via B4 Relay wrote:
...
> > > + case IIO_CHAN_INFO_RAW:
> > > + scoped_guard(mutex, &auxadc->lock) {
> >
> > I'm wondering why we haven't moved to guard()() here
>
> The compiler would complain about 'cannot jump from switch statement'
> due to default case.
I am not sure I follow. See the examples in the existing drivers. They are
warning clean in that sense.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 1/8] can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
From: Vincent Mailhol @ 2026-06-09 19:35 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Haibo Chen
In-Reply-To: <20260609142954.1807421-2-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> On platforms with multiple IRQ lines (S32G2, MCF5441X), all lines are
> registered to the same flexcan_irq() handler. Since these are distinct IRQ
> numbers, they can be dispatched concurrently on different CPUs. Both
> instances then read the same iflag and ESR registers unconditionally,
> leading to duplicate frame processing.
>
> Fix this by splitting the monolithic handler into focused parts:
> - flexcan_do_mb(): processes mailbox events
> - flexcan_do_state(): processes device state change events
> - flexcan_do_berr(): processes bus error events
>
> Introduce dedicated IRQ handlers for multi-IRQ platforms:
> - flexcan_irq_mb(): mailbox-only, used for mb-0, mb-1 IRQ lines
> - flexcan_irq_boff(): state-change-only, used for boff/state IRQ line
> - flexcan_irq_berr(): bus-error-only, used for berr IRQ line
>
> The combined flexcan_irq() handler is preserved for single-IRQ
> platforms with no functional change.
>
> Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Dave Hansen @ 2026-06-09 19:33 UTC (permalink / raw)
To: Xueyuan Chen, akpm, linux-mm
Cc: linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs, liam,
vbabka, rppt, surenb, mhocko, ziy, baolin.wang, npache,
ryan.roberts, dev.jain, baohua, lance.yang, yang, jannh
In-Reply-To: <20260609143801.7917-2-xueyuan.chen21@gmail.com>
On 6/9/26 07:37, Xueyuan Chen wrote:
> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
> +{
> + return false;
> +}
This is a rather wonky function. It's going to cause all kinds of fun if
it is used like this:
arch_make_pages_readonly(syscall_table, 1);
It's also kinda weird to have it return a bool, and not check that bool
at the single call site. Some things come to mind:
1. This function needs commenting. It needs to say what it does, when
architectures should override it and what their implementations
should look like. It needs to be clear that this can't be used for
anything really important. What should architectures do with alias
mappings? Are they allowed to touch non-direct map aliases? Are they
required to?
2. The return type needs to be reconsidered. Is 'bool' even acceptable?
Should it just be 'void' if callers can't do anything when it fails?
3. What should the naming be? "readonly" vs "ro". Should it have a
"maybe" since it's kinda optional?
4. Should this new API be folio or page-based in the first place?
5. Is mm/huge_memory.c the right place to define a generic mm function,
even a stub?
^ permalink raw reply
* Re: [PATCH v5 2/8] can: flexcan: disable all IRQ lines in flexcan_chip_interrupts_enable()
From: Vincent Mailhol @ 2026-06-09 19:38 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Haibo Chen
In-Reply-To: <20260609142954.1807421-3-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> flexcan_chip_interrupts_enable() disables only the primary IRQ line while
> writing to the IMASK and CTRL registers.
>
> On multi-IRQ platforms (S32G2, MCF5441X), the additional IRQ lines (boff,
> err, secondary-mb) remain active so their handlers can fire while
> registers are inconsistent.
>
> Disable all registered IRQ lines around the IMASK/CTRL writes. This
> also fixes the resume path, which calls this function.
>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH] media: bcm2835-unicam: Fix asc leaked in error/remove path
From: Laurent Pinchart @ 2026-06-09 19:39 UTC (permalink / raw)
To: Eugen Hristev
Cc: Raspberry Pi Kernel Maintenance, Mauro Carvalho Chehab,
Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Hans Verkuil, Naushir Patuck, Sakari Ailus,
Dave Stevenson, Jean-Michel Hautbois, linux-media,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260609-bcmpiclean-v1-1-23bdeb19caf6@kernel.org>
On Tue, Jun 09, 2026 at 08:05:23PM +0300, Eugen Hristev wrote:
> v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when
> v4l2_async_nf_cleanup() is called.
>
> Call v4l2_async_nf_cleanup() properly in the driver paths.
>
> Discovered with kmemleak after rmmod:
>
> unreferenced object 0xffff000084526b80 (size 64):
> comm "modprobe", pid 185, jiffies 4295013512
> hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................
> 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`.......
> backtrace (crc ac584083):
> [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44
> [<00000000d2fd9301>] __kmalloc+0x1b0/0x250
> [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c
> [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64
>
> Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface")
> Signed-off-by: Eugen Hristev <ehristev@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/media/platform/broadcom/bcm2835-unicam.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
> index 8d28ba0b59a3..1508843ae58c 100644
> --- a/drivers/media/platform/broadcom/bcm2835-unicam.c
> +++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
> @@ -2613,6 +2613,7 @@ static int unicam_async_nf_init(struct unicam_device *unicam)
> return 0;
>
> error:
> + v4l2_async_nf_cleanup(&unicam->notifier);
> fwnode_handle_put(ep_handle);
> return ret;
> }
> @@ -2745,6 +2746,7 @@ static void unicam_remove(struct platform_device *pdev)
> v4l2_device_unregister(&unicam->v4l2_dev);
> media_device_unregister(&unicam->mdev);
> v4l2_async_nf_unregister(&unicam->notifier);
> + v4l2_async_nf_cleanup(&unicam->notifier);
>
> unicam_subdev_cleanup(unicam);
>
>
> ---
> base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
> change-id: 20260609-bcmpiclean-69a8ee3192b0
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v5 3/8] can: flexcan: split rx/tx masks per mailbox IRQ line
From: Vincent Mailhol @ 2026-06-09 19:42 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Haibo Chen
In-Reply-To: <20260609142954.1807421-4-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> On S32G2, which has two mailbox IRQ lines (mb-0 for MBs 0-7, mb-1
> for MBs 8-63), both handlers currently process the full rx_mask/tx_mask
> range.
>
> Introduce FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK and
> FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK to describe the split, and pass
> the selected mask to flexcan_do_mb() via a new mb_mask parameter.
>
> In flexcan_irq_mb(), the irq argument selects the correct mask: the
> primary MB IRQ uses MB0_MASK and the secondary uses MB1_MASK.
>
> For single-IRQ platforms, mb_mask is ~0ULL with no functional change.
>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Looks better than v5!
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> drivers/net/can/flexcan/flexcan-core.c | 39 ++++++++++++++++++--------
> 1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
> index 7dde2e623def..0ed838f0719a 100644
> --- a/drivers/net/can/flexcan/flexcan-core.c
> +++ b/drivers/net/can/flexcan/flexcan-core.c
> @@ -182,6 +182,12 @@
> #define FLEXCAN_IFLAG_RX_FIFO_WARN BIT(6)
> #define FLEXCAN_IFLAG_RX_FIFO_AVAILABLE BIT(5)
>
> +/* On platforms with FLEXCAN_QUIRK_SECONDARY_MB_IRQ, the MB IRQ lines are
> + * split.
> + */
> +#define FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK GENMASK_ULL(7, 0)
> +#define FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK GENMASK_ULL(63, 8)
Nitpick: priv->rx_mask, priv->tx_mask and your mb_mask variable all have
type u64 so you could have used GENMASK_U64() to stay coherent with the
type. But you don't have to send a v6 just for this.
> /* FLEXCAN message buffers */
> #define FLEXCAN_MB_CODE_MASK (0xf << 24)
> #define FLEXCAN_MB_CODE_RX_BUSY_BIT (0x1 << 24)
> @@ -957,14 +963,16 @@ static inline void flexcan_write64(struct flexcan_priv *priv, u64 val, void __io
> priv->write(lower_32_bits(val), addr);
> }
>
> -static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv)
> +static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv,
> + u64 rx_mask)
> {
> - return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->rx_mask);
> + return flexcan_read64_mask(priv, &priv->regs->iflag1, rx_mask);
> }
>
> -static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv)
> +static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv,
> + u64 tx_mask)
> {
> - return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->tx_mask);
> + return flexcan_read64_mask(priv, &priv->regs->iflag1, tx_mask);
> }
>
> static inline struct flexcan_priv *rx_offload_to_priv(struct can_rx_offload *offload)
> @@ -1071,12 +1079,14 @@ static struct sk_buff *flexcan_mailbox_read(struct can_rx_offload *offload,
> }
>
> /* Process mailbox (RX + TX) events */
> -static irqreturn_t flexcan_do_mb(struct net_device *dev)
> +static irqreturn_t flexcan_do_mb(struct net_device *dev, u64 mb_mask)
> {
> struct net_device_stats *stats = &dev->stats;
> struct flexcan_priv *priv = netdev_priv(dev);
> struct flexcan_regs __iomem *regs = priv->regs;
> irqreturn_t handled = IRQ_NONE;
> + u64 rx_mask = priv->rx_mask & mb_mask;
> + u64 tx_mask = priv->tx_mask & mb_mask;
> u64 reg_iflag_tx;
>
> /* reception interrupt */
> @@ -1084,7 +1094,8 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> u64 reg_iflag_rx;
> int ret;
>
> - while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv))) {
> + while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv,
> + rx_mask))) {
> handled = IRQ_HANDLED;
> ret = can_rx_offload_irq_offload_timestamp(&priv->offload,
> reg_iflag_rx);
> @@ -1110,10 +1121,10 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> }
> }
>
> - reg_iflag_tx = flexcan_read_reg_iflag_tx(priv);
> + reg_iflag_tx = flexcan_read_reg_iflag_tx(priv, tx_mask);
>
> /* transmission complete interrupt */
> - if (reg_iflag_tx & priv->tx_mask) {
> + if (reg_iflag_tx & tx_mask) {
> u32 reg_ctrl = priv->read(&priv->tx_mb->can_ctrl);
>
> handled = IRQ_HANDLED;
> @@ -1125,7 +1136,7 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> /* after sending a RTR frame MB is in RX mode */
> priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
> &priv->tx_mb->can_ctrl);
> - flexcan_write64(priv, priv->tx_mask, ®s->iflag1);
> + flexcan_write64(priv, tx_mask, ®s->iflag1);
> netif_wake_queue(dev);
> }
>
> @@ -1228,7 +1239,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
> struct flexcan_priv *priv = netdev_priv(dev);
> irqreturn_t handled;
>
> - handled = flexcan_do_mb(dev);
> + handled = flexcan_do_mb(dev, ~0ULL);
> handled |= flexcan_do_state(dev);
> handled |= flexcan_do_berr(dev);
>
> @@ -1244,8 +1255,14 @@ static irqreturn_t flexcan_irq_mb(int irq, void *dev_id)
> struct net_device *dev = dev_id;
> struct flexcan_priv *priv = netdev_priv(dev);
> irqreturn_t handled;
> + u64 mb_mask = ~0ULL;
> +
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> + mb_mask = (irq == priv->irq_secondary_mb) ?
> + FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK :
> + FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK;
>
> - handled = flexcan_do_mb(dev);
> + handled = flexcan_do_mb(dev, mb_mask);
>
> if (handled)
> can_rx_offload_irq_finish(&priv->offload);
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* [PATCH v6 04/11] arm64: dts: ti: k3-am62p-verdin: Fix wkup R5F memory region size
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
The wkup_r5fss0_core0_memory_region was reserved with only
0x0f00000 but the MCU SDK linker for the wkup R5F firmware on
AM62P defines the DM code/data DDR footprint differently:
/* DDR for DM R5F code/data [ size 27 MiB + 396 KB ] */
DDR : ORIGIN = 0x9CAA5000 LENGTH = 0x1B63000
which results in an end at 0x9e608000. For this memory region which
starts at 0x9c900000 this means a length of:
0x9e608000 - 0x9c900000 = 0x1d08000
Link: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/linker.cmd
Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
index 7ee894d59113aa727d41b7ecd6b2bc7e12760823..8a5ff5c457579c7b1be7157d235fd4b4e5c6af11 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
@@ -170,7 +170,7 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
wkup_r5fss0_core0_memory_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01e00000>;
+ reg = <0x00 0x9c900000 0x00 0x01d08000>;
no-map;
};
};
--
2.53.0
^ permalink raw reply related
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Andrew Morton @ 2026-06-09 19:45 UTC (permalink / raw)
To: Xueyuan Chen
Cc: linux-mm, linux-kernel, linux-arm-kernel, x86, catalin.marinas,
will, tglx, mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs,
liam, vbabka, rppt, surenb, mhocko, ziy, baolin.wang, npache,
ryan.roberts, dev.jain, baohua, lance.yang, yang, jannh,
Dave Hansen
In-Reply-To: <20260609143801.7917-2-xueyuan.chen21@gmail.com>
On Tue, 9 Jun 2026 22:37:59 +0800 Xueyuan Chen <xueyuan.chen21@gmail.com> wrote:
> The huge zero folio is shared globally, and its contents should never
> change after initialization. As Jann Horn pointed out[1], the kernel has
> had bugs, including security bugs, where read-only pages were later written
> to. If the persistent huge zero folio is read-only in the direct map, such
> writes fault instead of silently corrupting the shared zero contents.
>
> Add arch_make_pages_readonly() so mm code can request read-only direct-map
> protection for a page range. Direct-map protection is
> architecture-specific, so the generic weak implementation does nothing.
>
> This was inspired by Jann Horn's read-only zero page work[1] and follow-up
> discussion[2] with Yang Shi.
>
> [1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
> [2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/
>
> ...
>
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -308,6 +308,11 @@ static unsigned long shrink_huge_zero_folio_scan(struct shrinker *shrink,
> return 0;
> }
>
> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
> +{
> + return false;
> +}
> +
> static struct shrinker *huge_zero_folio_shrinker;
>
> #ifdef CONFIG_SYSFS
> @@ -982,8 +987,14 @@ static int __init thp_shrinker_init(void)
> * that get_huge_zero_folio() will most likely not fail as
> * thp_shrinker_init() is invoked early on during boot.
> */
> - if (!get_huge_zero_folio())
> + if (!get_huge_zero_folio()) {
> pr_warn("Allocating persistent huge zero folio failed\n");
> + return 0;
> + }
> +
> + arch_make_pages_readonly(folio_page(huge_zero_folio, 0),
> + HPAGE_PMD_NR);
Can it simply pass the folio?
^ permalink raw reply
* Re: [PATCH v5 5/8] can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
From: Vincent Mailhol @ 2026-06-09 19:51 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Larisa Grigore,
Haibo Chen
In-Reply-To: <20260609142954.1807421-6-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> Introduce FLEXCAN_QUIRK_IRQ_BERR quirk to handle hardware integration
> where the FlexCAN module has a dedicated interrupt line for signaling
> bus errors and device state changes.
>
> This adds the flexcan_irq_esr() handler which composes
> flexcan_do_state() and flexcan_do_berr() to handle platforms where
> these events share a single IRQ line.
>
> Also extend flexcan_chip_interrupts_enable() to disable/enable the
> new IRQ line during IMASK register writes.
>
> This is required for NXP S32N79 SoC support.
>
> Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
> Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> drivers/net/can/flexcan/flexcan-core.c | 54 +++++++++++++++++++++-----
> drivers/net/can/flexcan/flexcan.h | 2 +
> 2 files changed, 47 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
> index 0ed838f0719a..adf3af57fb0a 100644
> --- a/drivers/net/can/flexcan/flexcan-core.c
> +++ b/drivers/net/can/flexcan/flexcan-core.c
> @@ -1300,6 +1300,22 @@ static irqreturn_t flexcan_irq_boff(int irq, void *dev_id)
> return handled;
> }
>
> +/* Combined bus error and state change IRQ handler */
> +static irqreturn_t flexcan_irq_esr(int irq, void *dev_id)
> +{
> + struct net_device *dev = dev_id;
> + struct flexcan_priv *priv = netdev_priv(dev);
> + irqreturn_t handled;
> +
> + handled = flexcan_do_state(dev);
> + handled |= flexcan_do_berr(dev);
> +
> + if (handled)
> + can_rx_offload_irq_finish(&priv->offload);
> +
> + return handled;
> +}
> +
> static void flexcan_set_bittiming_ctrl(const struct net_device *dev)
> {
> const struct flexcan_priv *priv = netdev_priv(dev);
> @@ -1540,10 +1556,10 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
> u64 reg_imask;
>
> disable_irq(dev->irq);
> - if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> + if (quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> disable_irq(priv->irq_boff);
> + if (quirks & (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
> disable_irq(priv->irq_err);
> - }
> if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> disable_irq(priv->irq_secondary_mb);
>
> @@ -1554,10 +1570,10 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
> enable_irq(dev->irq);
> if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> enable_irq(priv->irq_secondary_mb);
> - if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> - enable_irq(priv->irq_boff);
> + if (quirks & (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
> enable_irq(priv->irq_err);
> - }
> + if (quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> + enable_irq(priv->irq_boff);
> }
>
> static void flexcan_chip_interrupts_disable(const struct net_device *dev)
> @@ -1881,7 +1897,8 @@ static int flexcan_open(struct net_device *dev)
>
> can_rx_offload_enable(&priv->offload);
>
> - if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> + if (priv->devtype_data.quirks &
> + (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
> err = request_irq(dev->irq, flexcan_irq_mb,
> IRQF_SHARED, dev->name, dev);
> else
> @@ -1902,6 +1919,13 @@ static int flexcan_open(struct net_device *dev)
> goto out_free_irq_boff;
> }
>
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
> + err = request_irq(priv->irq_err,
> + flexcan_irq_esr, IRQF_SHARED, dev->name, dev);
> + if (err)
> + goto out_free_irq_boff;
> + }
> +
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
> err = request_irq(priv->irq_secondary_mb,
> flexcan_irq_mb, IRQF_SHARED, dev->name, dev);
> @@ -1916,7 +1940,8 @@ static int flexcan_open(struct net_device *dev)
> return 0;
>
> out_free_irq_err:
> - if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> + if (priv->devtype_data.quirks &
> + (FLEXCAN_QUIRK_IRQ_BERR | FLEXCAN_QUIRK_NR_IRQ_3))
> free_irq(priv->irq_err, dev);
> out_free_irq_boff:
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> @@ -1948,10 +1973,12 @@ static int flexcan_close(struct net_device *dev)
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> free_irq(priv->irq_secondary_mb, dev);
>
> - if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> + if (priv->devtype_data.quirks &
> + (FLEXCAN_QUIRK_IRQ_BERR | FLEXCAN_QUIRK_NR_IRQ_3))
> free_irq(priv->irq_err, dev);
> +
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> free_irq(priv->irq_boff, dev);
> - }
>
> free_irq(dev->irq, dev);
> can_rx_offload_disable(&priv->offload);
> @@ -2338,12 +2365,21 @@ static int flexcan_probe(struct platform_device *pdev)
> if (transceiver)
> priv->can.bitrate_max = transceiver->attrs.max_link_rate;
>
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
> + priv->irq_err = platform_get_irq_byname(pdev, "berr");
> + if (priv->irq_err < 0) {
> + err = priv->irq_err;
> + goto failed_platform_get_irq;
> + }
> + }
> +
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> priv->irq_boff = platform_get_irq(pdev, 1);
> if (priv->irq_boff < 0) {
> err = priv->irq_boff;
> goto failed_platform_get_irq;
> }
> +
Nitpick: you shouldn't have unrelated changes, like this newline
addition, in you patches.
@Marc, do you mind removing this while applying?
> priv->irq_err = platform_get_irq(pdev, 2);
> if (priv->irq_err < 0) {
> err = priv->irq_err;
> diff --git a/drivers/net/can/flexcan/flexcan.h b/drivers/net/can/flexcan/flexcan.h
> index 16692a2502eb..bbb1a8dd4777 100644
> --- a/drivers/net/can/flexcan/flexcan.h
> +++ b/drivers/net/can/flexcan/flexcan.h
> @@ -74,6 +74,8 @@
> * both need to have an interrupt handler registered.
> */
> #define FLEXCAN_QUIRK_SECONDARY_MB_IRQ BIT(18)
> +/* Setup dedicated bus error and state change IRQ */
> +#define FLEXCAN_QUIRK_IRQ_BERR BIT(19)
>
> struct flexcan_devtype_data {
> u32 quirks; /* quirks needed for different IP cores */
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Diederik de Haas @ 2026-06-09 19:51 UTC (permalink / raw)
To: Jonas Karlman, Diederik de Haas
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, devicetree@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-usb@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <9e8f806d-72ec-4eb4-8967-3f82eb0e7dd4@kwiboo.se>
Hi Jonas,
On Tue Jun 9, 2026 at 8:06 PM CEST, Jonas Karlman wrote:
> Hi Diederik,
>
> On 6/9/2026 6:32 PM, Diederik de Haas wrote:
>> Hi Jonas,
>>
>> On Tue Jun 9, 2026 at 5:41 PM CEST, Jonas Karlman wrote:
>>> The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
>>> being enabled, or the system may freeze when registers are accessed.
>>>
>>> Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
>>> constraint as RK3588.
>>>
>>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>>> ---
>>> Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
>>> next patch make use of these new compatibles and adds the missing
>>> clk_usbphy1_480m clock references.
>>> ---
>>> .../devicetree/bindings/usb/generic-ehci.yaml | 10 ++++++++++
>>> .../devicetree/bindings/usb/generic-ohci.yaml | 5 ++++-
>>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>>> index 55a5aa7d7a54..c49a1bbc8cfd 100644
>>> --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>>> @@ -52,6 +52,7 @@ properties:
>>> - ibm,476gtr-ehci
>>> - nxp,lpc1850-ehci
>>> - qca,ar7100-ehci
>>> + - rockchip,rk3568-ehci
>>> - rockchip,rk3588-ehci
>>> - snps,hsdk-v1.0-ehci
>>> - socionext,uniphier-ehci
>>> @@ -186,6 +187,15 @@ allOf:
>>> required:
>>> - clocks
>>> - clock-names
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: rockchip,rk3568-ehci
>>> + then:
>>> + properties:
>>> + clocks:
>>> + minItems: 4
>>
>> I think that the constraint for rk3588 is this:
>> - minItems: 1
>> - maxItems: 4
>>
>> Like ~ every other compatible; there's no 'branch' for rk3588-ehci.
>>
>> That's different from what you add for rk3568. Is that deliberate?
>> Because from the commit message I assumed they should be the same.
>
> It was deliberate, the intention is to use min/maxItems: 4 for rk3568
Thanks :-)
> for both EHCI and OHCI. I left out anything related to k3588 to keep
> existing behavior and avoid any possible breakage, and why I used
> 'similar' and not 'same' in the commit message ;-)
>
> Did a check and the rk3588 variant also uses 4 clocks so I will add same
> constraint for the rk3588 variant and address Sashiko's concern in v2.
FWIW: I would be absolutely fine if you restrict this patch set to just RK3568.
For the same reason you mentioned. All I wanted to know if it was deliberate
and you confirmed that :-)
Cheers,
Diederik
> Regards,
> Jonas
>
>>
>>> unevaluatedProperties: false
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>>> index d42f448fa204..5f1b4d2bff89 100644
>>> --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>>> @@ -47,6 +47,7 @@ properties:
>>> - hpe,gxp-ohci
>>> - ibm,476gtr-ohci
>>> - ingenic,jz4740-ohci
>>> + - rockchip,rk3568-ohci
>>> - rockchip,rk3588-ohci
>>> - snps,hsdk-v1.0-ohci
>>> - const: generic-ohci
>>> @@ -198,7 +199,9 @@ allOf:
>>> properties:
>>> compatible:
>>> contains:
>>> - const: rockchip,rk3588-ohci
>>> + enum:
>>> + - rockchip,rk3568-ohci
>>> + - rockchip,rk3588-ohci
>>
>> Here they clearly do have the same constraint.
>>
>> Cheers,
>> Diederik
>>
>>> then:
>>> properties:
>>> clocks:
>>
^ permalink raw reply
* Re: [PATCH v5 6/8] can: flexcan: add NXP S32N79 SoC support
From: Vincent Mailhol @ 2026-06-09 19:52 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Andra-Teodora Ilie,
Larisa Grigore, Haibo Chen
In-Reply-To: <20260609142954.1807421-7-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> Add device data and compatible string for NXP S32N79 SoC.
>
> FlexCAN IP integration on S32N79 SoC uses two interrupts:
> - one for mailboxes 0-127
> - one for signaling bus errors and device state changes
>
> Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
> Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
> Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
> Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* [PATCH v6 02/11] arm64: dts: ti: k3-am62d2-evm: Fix wkup R5F memory region size
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
The wkup_r5fss0_core0_memory_region was reserved with only
0x0f00000 but the MCU SDK linker for the wkup R5F firmware on
AM62A defines the DM code/data DDR footprint differently:
/* DDR for DM R5F code/data [ size 27 MiB + 364 KB ] */
DDR : ORIGIN = 0x9CAA5000 LENGTH = 0x1B5B000
which results in an end at 0x9e600000. For this memory region which
starts at 0x9c900000 this means a length of:
0x9e600000 - 0x9c900000 = 0x1d00000
Link: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd
Fixes: 1544bca2f188 ("arm64: dts: ti: Add support for AM62D2-EVM")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62d2-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts b/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
index f5ceb6a1b5debabf1ead67eea634b48db1540186..463a3f6130b8f2927a032137e87c01df446cffda 100644
--- a/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
@@ -67,7 +67,7 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
wkup_r5fss0_core0_memory_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0xf00000>;
+ reg = <0x00 0x9c900000 0x00 0x01d00000>;
no-map;
bootph-pre-ram;
};
--
2.53.0
^ permalink raw reply related
* [PATCH] ARM/PCI: remove stale CONFIG_PCI_HOST_ITE8152 reference
From: Ethan Nelson-Moore @ 2026-06-09 20:08 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: Ethan Nelson-Moore, Russell King, Bjorn Helgaas,
Ilpo Järvinen, Kuninori Morimoto
The IT8152 driver was removed in commit 6da5238fa384 ("ARM: 8993/1:
remove it8152 PCI controller driver"), but a reference to its config
symbol remained in arch/arm/kernel/bios32.c. Remove it.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/arm/kernel/bios32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index ac0e890510da..eff8d9e3c14c 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -528,12 +528,10 @@ void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
}
}
-#ifndef CONFIG_PCI_HOST_ITE8152
void pcibios_set_master(struct pci_dev *dev)
{
/* No special bus mastering setup handling */
}
-#endif
char * __init pcibios_setup(char *str)
{
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox