* [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 07/11] arm64: dts: ti: k3-am62a-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-am62a-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.
It also moves the bootph-pre-ram flags from k3-am62d2-evm.dts into the
firmware dtsi so that all boards inherit them.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi | 12 ------------
arch/arm64/boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi | 14 ++++++++++++++
arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 12 ------------
arch/arm64/boot/dts/ti/k3-am62d2-evm.dts | 17 -----------------
4 files changed, 14 insertions(+), 41 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi
index e13da7c95a30459e7649f284689039b89a95f651..228ffa4be4be7b32e43a06d807d3fee073d203dc 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi
@@ -59,18 +59,6 @@ linux,cma {
linux,cma-default;
};
- 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 0x01d00000>;
- no-map;
- };
-
secure_tfa_ddr: tfa@9e780000 {
reg = <0x00 0x9e780000 0x00 0x80000>;
alignment = <0x1000>;
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 06d4e815b1670beafb8852b76a3f6a79295ce8ca..682b1c9f3071ddf23044c1fde1e88f2b901ec64c 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
@@ -29,6 +29,19 @@ 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 0x01d00000>;
+ no-map;
+ bootph-pre-ram;
+ };
};
&mailbox0_cluster0 {
@@ -67,6 +80,7 @@ &wkup_r5fss0_core0 {
memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
<&wkup_r5fss0_core0_memory_region>;
memory-region-names = "dma", "firmware";
+ bootph-pre-ram;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index 63a4fb03dc0acac63bc573e290ec613617f492f0..8dda657f854cc4456c38dae812f9e00646c6c0d0 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -53,18 +53,6 @@ linux,cma {
linux,cma-default;
};
- 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 0x01d00000>;
- no-map;
- };
-
secure_tfa_ddr: tfa@9e780000 {
reg = <0x00 0x9e780000 0x00 0x80000>;
alignment = <0x1000>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts b/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
index 463a3f6130b8f2927a032137e87c01df446cffda..dd6937789a9c6b7c92ef5ad1fcc3ae94a90e2353 100644
--- a/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
@@ -59,19 +59,6 @@ secure_tfa_ddr: tfa@80000000 {
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 0x01d00000>;
- no-map;
- bootph-pre-ram;
- };
-
secure_ddr: optee@9e800000 {
reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
no-map;
@@ -776,10 +763,6 @@ partition@3fc0000 {
};
};
-&wkup_r5fss0_core0 {
- bootph-pre-ram;
-};
-
&mcu_r5fss0_core0 {
firmware-name = "am62d-mcu-r5f0_0-fw";
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 05/11] arm64: dts: ti: k3-am62p5-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
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: b05a6c145001 ("arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processors")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
index b770ed82be9d8f5827c49ed871351a6423db8026..16549fd7340a556798cf5a242746c219d3168d83 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
@@ -57,7 +57,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 0x01d08000>;
no-map;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 01/11] arm64: dts: ti: k3-am62a-phycore-som: 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: 8dd0ac27fcd1 ("arm64: dts: ti: k3-am62a-phycore-som: Enable Co-processors")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi
index de4048a3564bcac9558f88c94381f07db30d4f99..e13da7c95a30459e7649f284689039b89a95f651 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi
@@ -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;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 00/11] arm64: dts: ti: k3-am62a7-sk: 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)
Hi,
Split the firmware memory region in more specific parts so it is better
described where which information is stored. 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 and resume from RAM.
The bindings are already applied. The remaining patches use the new
layout for the platforms that are capable to support IO+DDR. For IO+DDR
the new layout is necessary as it defines the location of the LPM
metadata.
Additionally the two important devicetree nodes for resuming from IO+DDR
have the bootph-pre-ram flag added as this data needs to be read before
the RAM is in use.
The changes in this series were suggested as part of the IO+DDR u-boot series:
https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
Best
Markus
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
Changes in v6:
- Added fixes for the length of the wkup_r5fss0_core0_memory_region.
Thanks Francesco for pointing that out. am62a firmware is shorter than
am62p firmware. I calculated both and fixed all devicetrees using
them. All patches have different Fixes tags so I kept them separate.
- Fixed the length of the split memory layout as well.
- Removed the double definition of memory regions for the var-som board.
- Link to v5: https://lore.kernel.org/r/20260601-topic-am62a-ioddr-dt-v6-19-v5-0-3856a023aff2@baylibre.com
Changes in v5:
- Move all changes into k3-am62a/p-ti-ipc-firmware.dtsi
- Dropped the patch that adds bootph-pre-ram to k3-am62a stuff as it is
already present in k3-am62d2-evm.dts and got moved into the
firmware.dtsi file which covers am62a as well then.
- Link to v4: https://lore.kernel.org/r/20260429-topic-am62a-ioddr-dt-v6-19-v4-0-fc27d6ac753c@baylibre.com
Changes in v4:
- Rebased to v7.1-rc1
- Dropped all already applied patches that are the bindings and the
initial introduction of memory-region-names
- Link to v3: https://lore.kernel.org/r/20260318-topic-am62a-ioddr-dt-v6-19-v3-0-c41473cb23c3@baylibre.com
Changes in v3:
- Squash the enforcement of the memory-region-names requirement in the
patch adding the memory-region-names, as suggested.
- Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
Changes in v2:
- Make memory-region-names required if memory-region is present
- Fixup memory-region and memory-region-names conditions. Require either
2 or 6 regions for memory-region and memory-region-names
- Reword and restructure the binding documentation for memory-region and
memory-region-names
- Add memory-region-names to all uses of memory-region
- Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
---
Markus Schneider-Pargmann (TI) (11):
arm64: dts: ti: k3-am62a-phycore-som: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62d2-evm: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62a7-sk: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62p-verdin: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62p5-sk: Fix wkup R5F memory region size
arm64: dts: ti: var-som-am62p: Fix wkup R5F memory region size
arm64: dts: ti: k3-am62a-ti-ipc-firmware: Move wkup reserved memory
arm64: dts: ti: k3-am62p-ti-ipc-firmware: Move wkup reserved memory
arm64: dts: ti: k3-am62a-ti-ipc-firmware: Split r5f memory region
arm64: dts: ti: k3-am62p-ti-ipc-firmware: Split r5f memory region
arm64: dts: ti: k3-am62p-ti-ipc-firmware: Add r5f nodes to pre-ram bootphase
arch/arm64/boot/dts/ti/k3-am62a-phycore-som.dtsi | 12 ------
.../boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi | 48 +++++++++++++++++++++-
arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 12 ------
arch/arm64/boot/dts/ti/k3-am62d2-evm.dts | 17 --------
.../boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi | 48 +++++++++++++++++++++-
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 ------
8 files changed, 92 insertions(+), 81 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260210-topic-am62a-ioddr-dt-v6-19-0da7712081d7
Best regards,
--
Markus Schneider-Pargmann (TI) <msp@baylibre.com>
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
From: Stefano Radaelli @ 2026-06-09 18:35 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Daniel Baluta, Josua Mayer, Dario Binacchi,
Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve, Conor Dooley
In-Reply-To: <20260609-clumsy-material-b74a9b6bc7b7@spud>
Hi Conor,
On Tue, Jun 09, 2026 at 05:15:43PM +0100, Conor Dooley wrote:
> On Tue, Jun 09, 2026 at 11:51:18AM +0200, Stefano Radaelli wrote:
> > From: Stefano Radaelli <stefano.r@variscite.com>
> >
> > Add DT compatible strings for Variscite DART-MX8MP SoM and Variscite
> > development carrier Board.
> >
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
>
> My mailbox looking like
> | 169 ND Jun 09 Stefano Radaell ( 27K) ┌─>[PATCH v5 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
> | 170 ND Jun 09 sashiko-bot@ker (7.2K) │ ┌─>
> is a pretty clear indication that you're iterating too quickly.
> Try to slow down and leave people time to respond before sending new
> versions, not just respin for every automated response you get.
>
Sorry about that. I was making small fixes and re-sending the series
immediately, without realizing that this could create unnecessary noise
in the review process.
I'll make sure to leave enough time between revisions from now on,
so reviewers have a chance to look at the current version before I send
an updated one.
Thanks for the feedback, and sorry for the inconvenience.
Best Regards,
Stefano
^ permalink raw reply
* Re: [PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Daniel Mentz @ 2026-06-09 18:34 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <aifsSxEXX64J1Etq@google.com>
On Tue, Jun 9, 2026 at 3:34 AM Pranjal Shrivastava <praan@google.com> wrote:
> > I'm not sure if I have a good suggestion here. Have you considered the
> > following: Do not call arm_smmu_handle_gerror() from
> > arm_smmu_runtime_suspend(). Instead, call disable_irq() at the end of
> > the suspend handler (and enable_irq() at the beginning of the resume
> > handler)?
>
> I thought about using disable_irq(), but I think doing it at the
> hardware level (IRQ_CTRL) is better.
>
> By disabling in IRQ_CTRL and keeping the manual arm_smmu_handle_gerror()
> call at the end of suspend, we ensure that we don't lose any gerror info
> We catch and handle any errors that occurred during the drain/quiesce
> phase right before the power-down.
I think the beauty of disable_irq() is that it synchronizes any
potentially running hard IRQ handler, which helps avoid races.
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Andy Shevchenko @ 2026-06-09 18:30 UTC (permalink / raw)
To: rva333
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: <20260609-mt6323-adc-v2-2-aa93a22309f9@protonmail.com>
On Tue, Jun 09, 2026 at 04:31:59PM +0300, Roman Vivchar via B4 Relay wrote:
> The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
> provides support for reading various channels including battery and
> charger voltages, battery and chip temperature, current sensing and
> accessory detection.
>
> Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
A few nit-picks, most important from which is the scoped_guard() versus
guard()() use.
...
> +static int mt6323_auxadc_prepare_channel(struct mt6323_auxadc *auxadc)
> +{
> + struct regmap *map = auxadc->regmap;
> + u32 val;
> + int ret;
> +
> + ret = regmap_read(map, MT6323_AUXADC_CON19, &val);
> + if (ret)
> + return ret;
> +
> + /* The ADC is idle. */
> + if (!(val & AUXADC_CON19_DECI_GDLY_MASK))
> + return 0;
> + 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);
> + if (ret)
> + return ret;
> +
> + return regmap_clear_bits(map, MT6323_AUXADC_CON19,
> + AUXADC_CON19_DECI_GDLY_MASK);
> +}
...
> +static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
> + const struct iio_chan_spec *chan, int *out)
> +{
> + struct regmap *map = auxadc->regmap;
> + u32 val;
> + int ret;
> +
> + ret = regmap_read_poll_timeout(map, chan->address, val, (val & AUXADC_READY_MASK),
> + 1 * USEC_PER_MSEC, 100 * USEC_PER_MSEC);
Perhaps
ret = regmap_read_poll_timeout(map, chan->address,
val, (val & AUXADC_READY_MASK),
1 * USEC_PER_MSEC, 100 * USEC_PER_MSEC);
(see above why).
> + if (ret)
> + return ret;
> +
> + *out = FIELD_GET(AUXADC_DATA_MASK, val);
> +
> + return 0;
> +}
...
> + case IIO_CHAN_INFO_RAW:
> + scoped_guard(mutex, &auxadc->lock) {
I'm wondering why we haven't moved to guard()() here
case IIO_CHAN_INFO_RAW: {
guard(mutex)(&auxadc->lock);
> + ret = mt6323_auxadc_prepare_channel(auxadc);
> + if (ret)
> + return ret;
> +
> + ret = mt6323_auxadc_request(auxadc, chan->channel);
> + if (ret)
> + return ret;
> +
> + /* Hardware limitation: the AUXADC needs a delay to become ready. */
> + fsleep(300);
> +
> + ret = mt6323_auxadc_read(auxadc, chan, val);
> +
> + if (mt6323_auxadc_release(auxadc, chan->channel))
> + dev_err(&indio_dev->dev,
> + "failed to release channel %d\n", chan->channel);
> +
> + if (ret)
> + return ret;
> + }
> + return IIO_VAL_INT;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 07/12] iommu/arm-smmu-v3: Add CMDQ_PROD_STOP_FLAG to gate CMDQ submissions
From: Daniel Mentz @ 2026-06-09 18:20 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <aiflaI4svEJvZbsC@google.com>
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"
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.
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.
> 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.
> 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".
>
> 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.
>
> 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.
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Frank Li @ 2026-06-09 18:18 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Laurentiu Mihalcea, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <CANLsYkxw6rbWNom8rNfKurKAXKpihqV1LTd51D5YXG4oFP6-wg@mail.gmail.com>
On Tue, Jun 09, 2026 at 11:33:03AM -0600, Mathieu Poirier wrote:
> [You don't often get email from mathieu.poirier@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Tue, 9 Jun 2026 at 11:06, Frank Li <Frank.li@oss.nxp.com> wrote:
> >
> > On Tue, Jun 09, 2026 at 10:40:06AM -0600, Mathieu Poirier wrote:
> > > [You don't often get email from mathieu.poirier@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> > > > From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > > >
> > > > The names of the carveout regions are derived using the names of the
> > > > reserved memory devicetree nodes, which are referenced using the
> > > > "memory-region" property. This adds a restriction on the names of said
> > > > devicetree nodes, often bearing specific names such as: "vdevbuffer",
> > > > "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> > > > specification's recommendation, which states that the devicetree node
> > > > names should be generic.
> > >
> > > I don't see what is so restrictive in using the node name of the reserved-memory
> > > regions. Function of_reserved_mem_region_to_resource() is already doing all the
> > > parsing, packaging everything in a neat and easy to use "struct resource". What
> > > will you gain with this new "memory-region-names" that can't be done with the
> > > current solution?
> >
> > DT Binding check can't find such wrong if node name is not what expected.
> > Binding can't restrict memory's node name because there ware not specific
> > compatible string for it.
> >
>
> But what "wrong" could that be, and what kind of restriction are you
> hoping to enforce? What specific problem are you hoping to solve?
The sometime miss rsc-table or wrong use rsc_table as node name, dt check
will be pass, but related driver will be failure.
>
> I'll wait to see what the DT people think about this - I personally
> don't see the value in it.
It will align dt spec and align ABI defination requirement. Node name can't
be used as ABI except that is defined. It will elimiated this kinds
hide ABI.
Frank
>
> > Frank
> >
> > >
> > > >
> > > > Fix this by documenting an additional, optional property:
> > > > "memory-region-names". This way, the carveout names can use the values
> > > > passed via "memory-region-names", while keeping the devicetree node
> > > > names of the reserved memory regions generic.
> > > >
> > > > There are no restrictions imposed on the values of the strings passed via
> > > > the new property since the software allows any name to be used, with some
> > > > names (e.g. "vdev%dbuffer", "vdev%dvring%d", "rsc-table") bearing a
> > > > special meaning.
> > > >
> > > > Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > > > ---
> > > > .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > > index c18f71b64889..8e3e6676a95e 100644
> > > > --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > > +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > > @@ -62,6 +62,10 @@ properties:
> > > > minItems: 1
> > > > maxItems: 32
> > > >
> > > > + memory-region-names:
> > > > + minItems: 1
> > > > + maxItems: 32
> > > > +
> > > > power-domains:
> > > > minItems: 2
> > > > maxItems: 8
> > > > --
> > > > 2.43.0
> > > >
> > >
^ permalink raw reply
* [RFC PATCH 2/6] firmware: smccc: Detect hypervisor via RSI host call in CCA Realms
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
Modify arm_smccc_hypervisor_has_uuid() to check is_realm_world() and
use rsi_host_call() to query the hypervisor vendor UUID when inside a
Realm. The realm path is factored into a helper,
arm_smccc_realm_get_hypervisor_uuid(), that owns a file-static
rsi_host_call buffer (uuid_hc) serialized by a spinlock.
The RSI-specific includes, file-static state and helper are guarded
with CONFIG_ARM64 because <asm/rsi.h> does not exist on 32-bit ARM.
For non-Realm environments, the existing arm_smccc_1_1_invoke() path
is unchanged.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
drivers/firmware/smccc/smccc.c | 41 +++++++++++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
index bdee057db2fd3..6b465e65472b0 100644
--- a/drivers/firmware/smccc/smccc.c
+++ b/drivers/firmware/smccc/smccc.c
@@ -12,6 +12,12 @@
#include <linux/platform_device.h>
#include <asm/archrandom.h>
+#ifdef CONFIG_ARM64
+#include <linux/cleanup.h>
+#include <linux/spinlock.h>
+#include <asm/rsi.h>
+#endif
+
static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
@@ -67,12 +73,45 @@ s32 arm_smccc_get_soc_id_revision(void)
}
EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
+#ifdef CONFIG_ARM64
+static struct rsi_host_call uuid_hc;
+static DEFINE_SPINLOCK(uuid_hc_lock);
+
+/*
+ * Helper function to get the hypervisor UUID via an RsiHostCall.
+ */
+static bool arm_smccc_realm_get_hypervisor_uuid(struct arm_smccc_res *res)
+{
+ guard(spinlock_irqsave)(&uuid_hc_lock);
+
+ memset(&uuid_hc, 0, sizeof(uuid_hc));
+ uuid_hc.gprs[0] = ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID;
+
+ if (rsi_host_call(__pa_symbol(&uuid_hc)) != RSI_SUCCESS)
+ return false;
+
+ res->a0 = uuid_hc.gprs[0];
+ res->a1 = uuid_hc.gprs[1];
+ res->a2 = uuid_hc.gprs[2];
+ res->a3 = uuid_hc.gprs[3];
+ return true;
+}
+#endif
+
bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid)
{
struct arm_smccc_res res = {};
uuid_t uuid;
- arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
+#ifdef CONFIG_ARM64
+ if (is_realm_world()) {
+ if (!arm_smccc_realm_get_hypervisor_uuid(&res))
+ return false;
+ } else
+#endif
+ arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID,
+ &res);
+
if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
return false;
--
2.45.4
^ permalink raw reply related
* [RFC PATCH 5/6] arm64: hyperv: Route hypercalls through RSI host call in CCA Realms
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
Modify the five hypercall wrapper functions to check is_realm_world()
and use the per-CPU rsi_host_call structure when inside a Realm.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/hyperv/hv_core.c | 175 +++++++++++++++++++++++++++++-------
1 file changed, 141 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/hyperv/hv_core.c b/arch/arm64/hyperv/hv_core.c
index e33a9e3c366a1..1759998ef2667 100644
--- a/arch/arm64/hyperv/hv_core.c
+++ b/arch/arm64/hyperv/hv_core.c
@@ -16,6 +16,7 @@
#include <asm-generic/bug.h>
#include <hyperv/hvhdk.h>
#include <asm/mshyperv.h>
+#include <asm/rsi.h>
/*
* hv_do_hypercall- Invoke the specified hypercall
@@ -25,12 +26,32 @@ u64 hv_do_hypercall(u64 control, void *input, void *output)
struct arm_smccc_res res;
u64 input_address;
u64 output_address;
+ struct rsi_host_call *hostcall;
+ unsigned long flags;
+ u64 ret;
input_address = input ? virt_to_phys(input) : 0;
output_address = output ? virt_to_phys(output) : 0;
- arm_smccc_1_1_hvc(HV_FUNC_ID, control,
- input_address, output_address, &res);
+ if (is_realm_world()) {
+ local_irq_save(flags);
+ hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ memset(hostcall, 0, sizeof(*hostcall));
+ hostcall->gprs[0] = HV_FUNC_ID;
+ hostcall->gprs[1] = control;
+ hostcall->gprs[2] = input_address;
+ hostcall->gprs[3] = output_address;
+
+ if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)
+ ret = hostcall->gprs[0];
+ else
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ local_irq_restore(flags);
+ return ret;
+ }
+
+ arm_smccc_1_1_hvc(HV_FUNC_ID, control, input_address,
+ output_address, &res);
return res.a0;
}
EXPORT_SYMBOL_GPL(hv_do_hypercall);
@@ -45,9 +66,28 @@ u64 hv_do_fast_hypercall8(u16 code, u64 input)
{
struct arm_smccc_res res;
u64 control;
+ struct rsi_host_call *hostcall;
+ unsigned long flags;
+ u64 ret;
control = (u64)code | HV_HYPERCALL_FAST_BIT;
+ if (is_realm_world()) {
+ local_irq_save(flags);
+ hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ memset(hostcall, 0, sizeof(*hostcall));
+ hostcall->gprs[0] = HV_FUNC_ID;
+ hostcall->gprs[1] = control;
+ hostcall->gprs[2] = input;
+
+ if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)
+ ret = hostcall->gprs[0];
+ else
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ local_irq_restore(flags);
+ return ret;
+ }
+
arm_smccc_1_1_hvc(HV_FUNC_ID, control, input, &res);
return res.a0;
}
@@ -62,9 +102,29 @@ u64 hv_do_fast_hypercall16(u16 code, u64 input1, u64 input2)
{
struct arm_smccc_res res;
u64 control;
+ struct rsi_host_call *hostcall;
+ unsigned long flags;
+ u64 ret;
control = (u64)code | HV_HYPERCALL_FAST_BIT;
+ if (is_realm_world()) {
+ local_irq_save(flags);
+ hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ memset(hostcall, 0, sizeof(*hostcall));
+ hostcall->gprs[0] = HV_FUNC_ID;
+ hostcall->gprs[1] = control;
+ hostcall->gprs[2] = input1;
+ hostcall->gprs[3] = input2;
+
+ if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)
+ ret = hostcall->gprs[0];
+ else
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ local_irq_restore(flags);
+ return ret;
+ }
+
arm_smccc_1_1_hvc(HV_FUNC_ID, control, input1, input2, &res);
return res.a0;
}
@@ -76,24 +136,44 @@ EXPORT_SYMBOL_GPL(hv_do_fast_hypercall16);
void hv_set_vpreg(u32 msr, u64 value)
{
struct arm_smccc_res res;
+ struct rsi_host_call *hostcall;
+ unsigned long flags;
+ u64 status;
+
+ if (is_realm_world()) {
+ local_irq_save(flags);
+ hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ memset(hostcall, 0, sizeof(*hostcall));
+ hostcall->gprs[0] = HV_FUNC_ID;
+ hostcall->gprs[1] = HVCALL_SET_VP_REGISTERS |
+ HV_HYPERCALL_FAST_BIT |
+ HV_HYPERCALL_REP_COMP_1;
+ hostcall->gprs[2] = HV_PARTITION_ID_SELF;
+ hostcall->gprs[3] = HV_VP_INDEX_SELF;
+ hostcall->gprs[4] = msr;
+ hostcall->gprs[6] = value;
- arm_smccc_1_1_hvc(HV_FUNC_ID,
- HVCALL_SET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
- HV_HYPERCALL_REP_COMP_1,
- HV_PARTITION_ID_SELF,
- HV_VP_INDEX_SELF,
- msr,
- 0,
- value,
- 0,
- &res);
+ if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)
+ status = hostcall->gprs[0];
+ else
+ status = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ local_irq_restore(flags);
+ } else {
+ arm_smccc_1_1_hvc(HV_FUNC_ID,
+ HVCALL_SET_VP_REGISTERS |
+ HV_HYPERCALL_FAST_BIT |
+ HV_HYPERCALL_REP_COMP_1,
+ HV_PARTITION_ID_SELF, HV_VP_INDEX_SELF, msr,
+ 0, value, 0, &res);
+ status = res.a0;
+ }
/*
- * Something is fundamentally broken in the hypervisor if
- * setting a VP register fails. There's really no way to
- * continue as a guest VM, so panic.
+ * Something is fundamentally broken in the hypervisor (or, in a
+ * Realm, the RMM denied the host call) if setting a VP register
+ * fails. There's really no way to continue as a guest VM, so panic.
*/
- BUG_ON(!hv_result_success(res.a0));
+ BUG_ON(!hv_result_success(status));
}
EXPORT_SYMBOL_GPL(hv_set_vpreg);
@@ -108,29 +188,56 @@ void hv_get_vpreg_128(u32 msr, struct hv_get_vp_registers_output *result)
{
struct arm_smccc_1_2_regs args;
struct arm_smccc_1_2_regs res;
+ struct rsi_host_call *hostcall;
+ u64 status;
- args.a0 = HV_FUNC_ID;
- args.a1 = HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
- HV_HYPERCALL_REP_COMP_1;
- args.a2 = HV_PARTITION_ID_SELF;
- args.a3 = HV_VP_INDEX_SELF;
- args.a4 = msr;
+ if (is_realm_world()) {
+ unsigned long flags;
- /*
- * Use the SMCCC 1.2 interface because the results are in registers
- * beyond X0-X3.
- */
- arm_smccc_1_2_hvc(&args, &res);
+ local_irq_save(flags);
+ hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ memset(hostcall, 0, sizeof(*hostcall));
+
+ hostcall->gprs[0] = HV_FUNC_ID;
+ hostcall->gprs[1] = HVCALL_GET_VP_REGISTERS |
+ HV_HYPERCALL_FAST_BIT |
+ HV_HYPERCALL_REP_COMP_1;
+ hostcall->gprs[2] = HV_PARTITION_ID_SELF;
+ hostcall->gprs[3] = HV_VP_INDEX_SELF;
+ hostcall->gprs[4] = msr;
+
+ if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS) {
+ status = hostcall->gprs[0];
+ result->as64.low = hostcall->gprs[6];
+ result->as64.high = hostcall->gprs[7];
+ } else {
+ status = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ }
+ local_irq_restore(flags);
+ } else {
+ args.a0 = HV_FUNC_ID;
+ args.a1 = HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
+ HV_HYPERCALL_REP_COMP_1;
+ args.a2 = HV_PARTITION_ID_SELF;
+ args.a3 = HV_VP_INDEX_SELF;
+ args.a4 = msr;
+
+ /*
+ * Use the SMCCC 1.2 interface because the results are in
+ * registers beyond X0-X3.
+ */
+ arm_smccc_1_2_hvc(&args, &res);
+ status = res.a0;
+ result->as64.low = res.a6;
+ result->as64.high = res.a7;
+ }
/*
- * Something is fundamentally broken in the hypervisor if
- * getting a VP register fails. There's really no way to
- * continue as a guest VM, so panic.
+ * Something is fundamentally broken in the hypervisor (or, in a
+ * Realm, the RMM denied the host call) if getting a VP register
+ * fails. There's really no way to continue as a guest VM, so panic.
*/
- BUG_ON(!hv_result_success(res.a0));
-
- result->as64.low = res.a6;
- result->as64.high = res.a7;
+ BUG_ON(!hv_result_success(status));
}
EXPORT_SYMBOL_GPL(hv_get_vpreg_128);
--
2.45.4
^ permalink raw reply related
* [RFC PATCH 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
In hv_common_cpu_init(), the per-CPU hypercall input/output pages need
to be marked as decrypted (shared) for confidential VM isolation types.
This is already done for SNP and TDX isolation; extend the same handling
to Arm CCA Realm guests so that the host hypervisor can access the
shared hypercall buffers.
is_realm_world() is only declared in arch/arm64/include/asm/rsi.h, so
using it directly in the arch-neutral drivers/hv/hv_common.c would
break the x86 build. Introduce a Hyper-V-specific helper following the
established hv_isolation_type_snp() / hv_isolation_type_tdx() pattern.
On architectures other than arm64 the weak default keeps the existing
behaviour.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/hyperv/mshyperv.c | 5 +++++
drivers/hv/hv_common.c | 9 ++++++++-
include/asm-generic/mshyperv.h | 1 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index 08fec82691683..b595b2b9bdbbb 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -208,3 +208,8 @@ bool hv_is_hyperv_initialized(void)
return hyperv_initialized;
}
EXPORT_SYMBOL_GPL(hv_is_hyperv_initialized);
+
+bool hv_isolation_type_cca(void)
+{
+ return is_realm_world();
+}
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 6b67ac6167891..010c7d98b5de1 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -499,7 +499,8 @@ int hv_common_cpu_init(unsigned int cpu)
}
if (!ms_hyperv.paravisor_present &&
- (hv_isolation_type_snp() || hv_isolation_type_tdx())) {
+ (hv_isolation_type_snp() || hv_isolation_type_tdx() ||
+ hv_isolation_type_cca())) {
ret = set_memory_decrypted((unsigned long)mem, pgcount);
if (ret) {
/* It may be unsafe to free 'mem' */
@@ -666,6 +667,12 @@ bool __weak hv_isolation_type_tdx(void)
}
EXPORT_SYMBOL_GPL(hv_isolation_type_tdx);
+bool __weak hv_isolation_type_cca(void)
+{
+ return false;
+}
+EXPORT_SYMBOL_GPL(hv_isolation_type_cca);
+
void __weak hv_setup_vmbus_handler(void (*handler)(void))
{
}
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index bf601d67cecb9..1fa79abce743c 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -79,6 +79,7 @@ u64 hv_do_fast_hypercall16(u16 control, u64 input1, u64 input2);
bool hv_isolation_type_snp(void);
bool hv_isolation_type_tdx(void);
+bool hv_isolation_type_cca(void);
/*
* On architectures where Hyper-V doesn't support AEOI (e.g., ARM64),
--
2.45.4
^ permalink raw reply related
* [RFC PATCH 1/6] arm64: rsi: Add RSI host call structure and helper function
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
Add struct rsi_host_call to rsi_smc.h, which represents the host call
data structure used by the Realm Management Monitor (RMM) for the
RSI_HOST_CALL interface. The structure contains a 16-bit immediate field
and 31 general-purpose register values, aligned to 256 bytes as required
by the CCA RMM specification.
Add rsi_host_call() static inline wrapper in rsi_cmds.h that invokes
SMC_RSI_HOST_CALL with the physical address of the host call structure.
This will be used by Hyper-V guest code to route hypercalls through the
RSI interface when running inside an Arm CCA Realm.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/include/asm/rsi_cmds.h | 9 +++++++++
arch/arm64/include/asm/rsi_smc.h | 6 ++++++
2 files changed, 15 insertions(+)
diff --git a/arch/arm64/include/asm/rsi_cmds.h b/arch/arm64/include/asm/rsi_cmds.h
index 2c8763876dfb7..83b4b1f598454 100644
--- a/arch/arm64/include/asm/rsi_cmds.h
+++ b/arch/arm64/include/asm/rsi_cmds.h
@@ -159,4 +159,13 @@ static inline unsigned long rsi_attestation_token_continue(phys_addr_t granule,
return res.a0;
}
+static inline long rsi_host_call(phys_addr_t host_call_struct)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(SMC_RSI_HOST_CALL, host_call_struct, 0, 0, 0, 0, 0, 0,
+ &res);
+ return res.a0;
+}
+
#endif /* __ASM_RSI_CMDS_H */
diff --git a/arch/arm64/include/asm/rsi_smc.h b/arch/arm64/include/asm/rsi_smc.h
index e19253f96c940..ffea93340ed7f 100644
--- a/arch/arm64/include/asm/rsi_smc.h
+++ b/arch/arm64/include/asm/rsi_smc.h
@@ -142,6 +142,12 @@ struct realm_config {
*/
} __aligned(0x1000);
+struct rsi_host_call {
+ u16 immediate;
+ u64 gprs[31];
+} __aligned(256);
+static_assert(sizeof(struct rsi_host_call) == 256);
+
#endif /* __ASSEMBLER__ */
/*
--
2.45.4
^ permalink raw reply related
* [RFC PATCH 6/6] arm64: hyperv: Implement hv_is_isolation_supported() for CCA Realms
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
Provide an arm64 implementation of hv_is_isolation_supported() that
overrides the __weak default in drivers/hv/hv_common.c.
The implementation deliberately does not depend on
hv_is_hyperv_initialized() because hv_common_init() consults
hv_is_isolation_supported() before hyperv_initialized is set.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/hyperv/mshyperv.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index b595b2b9bdbbb..b9b1c2f8e3ec7 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -213,3 +213,8 @@ bool hv_isolation_type_cca(void)
{
return is_realm_world();
}
+
+bool hv_is_isolation_supported(void)
+{
+ return is_realm_world();
+}
--
2.45.4
^ permalink raw reply related
* [RFC PATCH 0/6] arm64: hyperv: Add Realm support for Hyper-V
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
From: Kameron Carr <kameroncarr@microsoft.com>
Realms (CoCo VMs on ARM) require host calls to be routed through the RMM
(Realm Management Monitor) via the RSI (Realm Service Interface). This
series implements most of the necessary changes to support Realms on
Hyper-V.
One required change is not included in this series. The two buffers
allocated via vzalloc() in netvsc_init_buf() cannot be decrypted in
vmbus_establish_gpadl(). Currently only linearly mapped memory can be
decrypted. See my RFC patch [1]. I will implement the accompanying netvsc
changes based on the feedback I receive on that patch.
This patch series was tested by booting a Realm on Cobalt 200 running
Windows. I decreased the buffer size and used kzalloc() in
netvsc_init_buf() in my testing as a workaround for the issue mentioned
above.
[1] https://lore.kernel.org/all/20260521205834.1012925-1-kameroncarr@linux.microsoft.com/
Kameron Carr (6):
arm64: rsi: Add RSI host call structure and helper function
firmware: smccc: Detect hypervisor via RSI host call in CCA Realms
arm64: hyperv: Add per-CPU RSI host call infrastructure for CCA Realms
Drivers: hv: Mark shared memory as decrypted for CCA Realms
arm64: hyperv: Route hypercalls through RSI host call in CCA Realms
arm64: hyperv: Implement hv_is_isolation_supported() for CCA Realms
arch/arm64/hyperv/hv_core.c | 175 ++++++++++++++++++++++++------
arch/arm64/hyperv/mshyperv.c | 88 ++++++++++++++-
arch/arm64/include/asm/mshyperv.h | 3 +
arch/arm64/include/asm/rsi_cmds.h | 9 ++
arch/arm64/include/asm/rsi_smc.h | 6 +
drivers/firmware/smccc/smccc.c | 41 ++++++-
drivers/hv/hv_common.c | 9 +-
include/asm-generic/mshyperv.h | 1 +
8 files changed, 294 insertions(+), 38 deletions(-)
base-commit: 7a035678fc2bdee81881170764ef08a91a076147
--
2.45.4
^ permalink raw reply
* [RFC PATCH 3/6] arm64: hyperv: Add per-CPU RSI host call infrastructure for CCA Realms
From: Kameron Carr @ 2026-06-09 18:10 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
arnd, thuth, linux-hyperv, linux-arm-kernel, linux-kernel,
linux-arch, mhklinux
In-Reply-To: <20260609181030.2378391-1-kameroncarr@linux.microsoft.com>
Arm CCA Realms cannot issue Hyper-V hypercalls via HVC; the guest must
route them through the RSI_HOST_CALL interface, which takes the IPA of a
per-CPU rsi_host_call structure as its argument.
Add hyperv_pcpu_hostcall_struct as a per-CPU pointer to that buffer and
allocate it for the boot CPU during hyperv_init() and for each secondary
CPU in hv_cpu_init(). The allocation is gated on is_realm_world() so
non-Realm arm64 Hyper-V guests pay no memory cost.
Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
---
arch/arm64/hyperv/mshyperv.c | 78 ++++++++++++++++++++++++++++++-
arch/arm64/include/asm/mshyperv.h | 3 ++
2 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index 4fdc26ade1d74..08fec82691683 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -15,10 +15,16 @@
#include <linux/errno.h>
#include <linux/version.h>
#include <linux/cpuhotplug.h>
+#include <linux/slab.h>
+#include <linux/percpu.h>
#include <asm/mshyperv.h>
+#include <asm/rsi.h>
static bool hyperv_initialized;
+void * __percpu *hyperv_pcpu_hostcall_struct;
+EXPORT_SYMBOL_GPL(hyperv_pcpu_hostcall_struct);
+
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
{
hv_get_vpreg_128(HV_REGISTER_HYPERVISOR_VERSION,
@@ -60,6 +66,46 @@ static bool __init hyperv_detect_via_acpi(void)
#endif
+static void hv_hostcall_free(void)
+{
+ int cpu;
+
+ if (!hyperv_pcpu_hostcall_struct)
+ return;
+
+ for_each_possible_cpu(cpu)
+ kfree(*per_cpu_ptr(hyperv_pcpu_hostcall_struct, cpu));
+ free_percpu(hyperv_pcpu_hostcall_struct);
+ hyperv_pcpu_hostcall_struct = NULL;
+}
+
+static int hv_cpu_init(unsigned int cpu)
+{
+ void **hostcall_struct;
+ gfp_t flags;
+ void *mem;
+
+ if (hyperv_pcpu_hostcall_struct) {
+ /* hv_cpu_init() can be called with IRQs disabled from hv_resume() */
+ flags = irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL;
+
+ hostcall_struct = (void **)this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ /*
+ * The hostcall_struct memory is not freed when the CPU
+ * goes offline. If a previously offlined CPU is brought
+ * back online, the memory is reused here.
+ */
+ if (!*hostcall_struct) {
+ mem = kzalloc_obj(struct rsi_host_call, flags);
+ if (!mem)
+ return -ENOMEM;
+ *hostcall_struct = mem;
+ }
+ }
+
+ return hv_common_cpu_init(cpu);
+}
+
static bool __init hyperv_detect_via_smccc(void)
{
uuid_t hyperv_uuid = UUID_INIT(
@@ -73,6 +119,8 @@ static bool __init hyperv_detect_via_smccc(void)
static int __init hyperv_init(void)
{
struct hv_get_vp_registers_output result;
+ void **hostcall_struct;
+ void *mem;
u64 guest_id;
int ret;
@@ -85,6 +133,27 @@ static int __init hyperv_init(void)
if (!hyperv_detect_via_acpi() && !hyperv_detect_via_smccc())
return 0;
+ /*
+ * The RSI host-call buffer is only ever used when
+ * is_realm_world() is true. Skip the per-CPU allocation on
+ * non-Realm guests.
+ */
+ if (is_realm_world()) {
+ hyperv_pcpu_hostcall_struct = alloc_percpu(void *);
+ if (!hyperv_pcpu_hostcall_struct)
+ return -ENOMEM;
+
+ hostcall_struct = (void **)this_cpu_ptr(hyperv_pcpu_hostcall_struct);
+ if (!*hostcall_struct) {
+ mem = kzalloc_obj(struct rsi_host_call);
+ if (!mem) {
+ ret = -ENOMEM;
+ goto free_hostcall_mem;
+ }
+ *hostcall_struct = mem;
+ }
+ }
+
/* Setup the guest ID */
guest_id = hv_generate_guest_id(LINUX_VERSION_CODE);
hv_set_vpreg(HV_REGISTER_GUEST_OS_ID, guest_id);
@@ -106,12 +175,13 @@ static int __init hyperv_init(void)
ret = hv_common_init();
if (ret)
- return ret;
+ goto free_hostcall_mem;
ret = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "arm64/hyperv_init:online",
- hv_common_cpu_init, hv_common_cpu_die);
+ hv_cpu_init, hv_common_cpu_die);
if (ret < 0) {
hv_common_free();
+ hv_hostcall_free();
return ret;
}
@@ -125,6 +195,10 @@ static int __init hyperv_init(void)
hyperv_initialized = true;
return 0;
+
+free_hostcall_mem:
+ hv_hostcall_free();
+ return ret;
}
early_initcall(hyperv_init);
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index b721d3134ab66..65a00bd14c6cb 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -63,4 +63,7 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
#include <asm-generic/mshyperv.h>
+/* Per-CPU RSI host call structure for CCA Realms */
+extern void *__percpu *hyperv_pcpu_hostcall_struct;
+
#endif
--
2.45.4
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Jonas Karlman @ 2026-06-09 18:06 UTC (permalink / raw)
To: 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: <DJ4NVA328NUV.LSPMVBFE0PD8@cknow-tech.com>
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
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.
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 v3] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Catalin Marinas @ 2026-06-09 17:58 UTC (permalink / raw)
To: Jinjie Ruan
Cc: Will Deacon, corbet, skhan, punit.agrawal, jic23,
osama.abdelkader, chenl311, fengchengwen, suzuki.poulose, maz,
lpieralisi, timothy.hayes, sascha.bischoff, arnd,
mrigendra.chaubey, pierre.gondois, dietmar.eggemann, yangyicong,
sudeep.holla, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <02932ef7-5819-4cf5-8e78-8fd3fd40274f@huawei.com>
Hi Jinjie,
On Wed, Jun 03, 2026 at 02:38:11PM +0800, Jinjie Ruan wrote:
> On 6/2/2026 7:09 PM, Will Deacon wrote:
> > On Wed, May 20, 2026 at 10:20:23AM +0800, Jinjie Ruan wrote:
> >> When booting with ACPI, arm64 smp_prepare_cpus() currently sets all
> >> enumerated CPUs as "present" regardless of their status in the MADT. This
> >> causes issues with SMT hotplug control. For instance, with QEMU's
> >> "-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as
> >> follows: the first four CPUs are marked Enabled while the remaining four
> >> are marked Online Capable to support potential hot-plugging.
> >>
> >> Fix this by:
> >>
> >> 1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
> >> entry before calling set_cpu_present() during SMP initialization.
> >>
> >> 2. Properly managing the present mask in acpi_map_cpu() and
> >> acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
> >> other architectures like x86 and LoongArch.
> >>
> >> 3. Update the arm64 CPU hotplug documentation to no longer state that all
> >> online-capable vCPUs are marked as present by the kernel at boot time.
> >>
> >> This ensures that only physically available or explicitly enabled CPUs
> >> are in the present mask, keeping the SMT control logic consistent with
> >> the actual hardware state.
> >
> > Please can you check the Sashiko review comment?
> >
> > https://sashiko.dev/#/patchset/20260520022023.126670-1-ruanjinjie@huawei.com
>
> I think commit eba4675008a6 ("arm64: arch_register_cpu() variant to
> check if an ACPI handle is now available.") introduced this bug.
>
> It introduced an architectural safety block inside
> arch_unregister_cpu(). If a hot-unplug operation is determined to be a
> physical hardware removal (where _STA evaluates to
> !ACPI_STA_DEVICE_PRESENT), it aborts the unregistration transaction
> early to protect unreadied arm64 infrastructure, thereby skipping
> unregister_cpu().
>
> However, the generic ACPI processor driver path in
> acpi_processor_post_eject() currently treats arch_unregister_cpu() as
> an unconditional void operation. When arch_unregister_cpu() bails out
> early, the subsequent cleanup flow blindly proceeds to call
> acpi_unmap_cpu(), clears global per-cpu processor arrays, and
> unconditionally free the 'struct acpi_processor' object.
>
> I think we can fix this by:
>
> 1. Refactoring arch_unregister_cpu() to return an integer
> transaction status. It returns -EOPNOTSUPP when aborting due to physical
> hot-remove blocking, -EINVAL/-EIO on firmware failures, and 0 only upon
> successful unregistration.
>
> 2. Guarding the downstream execution flow in
> acpi_processor_post_eject(). If arch_unregister_cpu() returns a error
> code, the hot-unplug transaction is considered aborted.
I wonder whether we need all this guarding. In the worst case, we could
rewrite the function, something like below, to always unregister and
only warn:
void arch_unregister_cpu(int cpu)
{
acpi_handle acpi_handle = acpi_get_processor_handle(cpu);
struct cpu *c = &per_cpu(cpu_devices, cpu);
acpi_status status;
unsigned long long sta;
if (!acpi_handle) {
pr_err_once("Removing a CPU without associated ACPI handle\n");
} else {
status = acpi_evaluate_integer(acpi_handle, "_STA", NULL, &sta);
if (!ACPI_FAILURE(status) &&
cpu_present(cpu) && !(sta & ACPI_STA_DEVICE_PRESENT))
pr_err_once("Changing CPU present bit is not supported\n");
}
unregister_cpu(c);
}
However, on the first condition, can we actually trigger !acpi_handle?
If not, we could just drop it. I tried to look up the paths and I don't
think we'd ever end up in this function with !acpi_handle. So this
leaves us with the next checks.
On the second/third conditions, it's more about preventing physical CPU
hotplug as we haven't properly defined it for arm yet but we could just
add a WARN_ONCE() to make it more visible and still proceed with the
unregistering. I think with your proposal, we don't fully unroll the
state anyway just by returning an error in arch_unregister_cpu(), so I'd
rather continue here.
What does firmware do for virtual CPU hotplug w.r.t. _STA? I noticed a
slight change in wording in the cpu-hotplug.rst doc with your patch from
On virtual systems the _STA method must always report the CPU as
``present``
to
On virtual systems the _STA method must report the CPU as ``present``
when it is activated by the firmware
Was your intention that _STA.PRESENT can become 0 when hot-unplugging
virtual CPUs?
--
Catalin
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlb
From: Yosry Ahmed @ 2026-06-09 17:57 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Oliver Upton, Zenghui Yu
In-Reply-To: <86ldcotbub.wl-maz@kernel.org>
> > If yes, I think the code looks confusing, at least to a layman like
> > myself. It initially seems like the lock protects against concurrent
> > initializations, but then the NULL check is not done again under the
> > lock. The goal of the lock is not clear without the original report.
> >
> > Mayeb it's clearer to explicitly use barriers if the goal is preventing
> > reordering?
>
> This would require both the initialisation of vncr_tlb to use a store
> release, *and* all the other call sites to use a load acquire.
>
> I really don't think it is worth the churn, nor the (very small)
> burden on the readers.
That's fair. I was mainly just pointing out my initial confusion and
that others may share it. Avoiding the churn on the readers' side is
understandable. Maybe a comment here would help explain why the lock
needs to be held?
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Frank Li @ 2026-06-09 17:06 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Laurentiu Mihalcea, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <aihB5rVLsVqzg6cb@p14s>
On Tue, Jun 09, 2026 at 10:40:06AM -0600, Mathieu Poirier wrote:
> [You don't often get email from mathieu.poirier@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> > From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> >
> > The names of the carveout regions are derived using the names of the
> > reserved memory devicetree nodes, which are referenced using the
> > "memory-region" property. This adds a restriction on the names of said
> > devicetree nodes, often bearing specific names such as: "vdevbuffer",
> > "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> > specification's recommendation, which states that the devicetree node
> > names should be generic.
>
> I don't see what is so restrictive in using the node name of the reserved-memory
> regions. Function of_reserved_mem_region_to_resource() is already doing all the
> parsing, packaging everything in a neat and easy to use "struct resource". What
> will you gain with this new "memory-region-names" that can't be done with the
> current solution?
DT Binding check can't find such wrong if node name is not what expected.
Binding can't restrict memory's node name because there ware not specific
compatible string for it.
Frank
>
> >
> > Fix this by documenting an additional, optional property:
> > "memory-region-names". This way, the carveout names can use the values
> > passed via "memory-region-names", while keeping the devicetree node
> > names of the reserved memory regions generic.
> >
> > There are no restrictions imposed on the values of the strings passed via
> > the new property since the software allows any name to be used, with some
> > names (e.g. "vdev%dbuffer", "vdev%dvring%d", "rsc-table") bearing a
> > special meaning.
> >
> > Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > ---
> > .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > index c18f71b64889..8e3e6676a95e 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > @@ -62,6 +62,10 @@ properties:
> > minItems: 1
> > maxItems: 32
> >
> > + memory-region-names:
> > + minItems: 1
> > + maxItems: 32
> > +
> > power-domains:
> > minItems: 2
> > maxItems: 8
> > --
> > 2.43.0
> >
>
^ permalink raw reply
* [PATCH v5 4/6] soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Add cpuhotplug support for Exynos850 platforms. This SoC requires
its own specific set of writes/updates to PMU and PMU interrupts
generation block in order to put a CPU or a group of CPUs into
a different sleep states or prepare these entities for a CPU_OFF
or wake-up out of idle state or after CPU online.
Without these writes/updates the CPU(s) wake-up or online fails.
This also requires syscon regmap with raw spinlocks, so add
its initialisation to main exynos pmu probe() routine.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/soc/samsung/Makefile | 2 +-
drivers/soc/samsung/exynos-pmu.c | 24 ++++++++
drivers/soc/samsung/exynos-pmu.h | 1 +
drivers/soc/samsung/exynos850-pmu.c | 95 +++++++++++++++++++++++++++++
include/linux/soc/samsung/exynos-regs-pmu.h | 5 ++
5 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 636a762608c9..7f544e3c1fcc 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -7,7 +7,7 @@ exynos_chipid-y += exynos-chipid.o exynos-asv.o
obj-$(CONFIG_EXYNOS_USI) += exynos-usi.o
obj-$(CONFIG_EXYNOS_PMU) += exynos_pmu.o
-exynos_pmu-y += exynos-pmu.o gs101-pmu.o
+exynos_pmu-y += exynos-pmu.o gs101-pmu.o exynos850-pmu.o
obj-$(CONFIG_EXYNOS_PMU_ARM_DRIVERS) += exynos3250-pmu.o exynos4-pmu.o \
exynos5250-pmu.o exynos5420-pmu.o
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index f170abe08ef1..cec0a7211c93 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -92,6 +92,14 @@ static const struct regmap_config regmap_smccfg = {
.use_raw_spinlock = true,
};
+static const struct regmap_config regmap_pmu = {
+ .name = "pmu_regs",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .use_raw_spinlock = true,
+};
+
static const struct regmap_config regmap_pmu_intr = {
.name = "pmu_intr_gen",
.reg_bits = 32,
@@ -133,6 +141,7 @@ static const struct of_device_id exynos_pmu_of_device_ids[] = {
.compatible = "samsung,exynos7-pmu",
}, {
.compatible = "samsung,exynos850-pmu",
+ .data = &exynos850_pmu_data,
},
{ /*sentinel*/ },
};
@@ -488,6 +497,21 @@ static int exynos_pmu_probe(struct platform_device *pdev)
ret = of_syscon_register_regmap(dev->of_node, regmap);
if (ret)
return ret;
+ /*
+ * For SoCs that support cpuhotplug/cpuidle via PMU updates callbacks.
+ * Such callbacks are executed under raw_spinlock so we need a custom
+ * regmap too.
+ */
+ } else if (pmu_context->pmu_data && pmu_context->pmu_data->pmu_cpuhp) {
+ regmap = devm_regmap_init_mmio(dev, pmu_base_addr, ®map_pmu);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap),
+ "hotplug regmap init failed\n");
+
+ ret = of_syscon_register_regmap(dev->of_node, regmap);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to register hotplug regmap with syscon\n");
} else {
/* let syscon create mmio regmap */
regmap = syscon_node_to_regmap(dev->of_node);
diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index 733e188fa2b1..4ecbf53cd4f7 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -104,6 +104,7 @@ extern const struct exynos_pmu_data exynos5250_pmu_data;
extern const struct exynos_pmu_data exynos5420_pmu_data;
#endif
extern const struct exynos_pmu_data gs101_pmu_data;
+extern const struct exynos_pmu_data exynos850_pmu_data;
extern void pmu_raw_writel(u32 val, u32 offset);
extern u32 pmu_raw_readl(u32 offset);
diff --git a/drivers/soc/samsung/exynos850-pmu.c b/drivers/soc/samsung/exynos850-pmu.c
new file mode 100644
index 000000000000..0503c54d6363
--- /dev/null
+++ b/drivers/soc/samsung/exynos850-pmu.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2026 Linaro Ltd.
+ *
+ * Exynos850 PMU support
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/bits.h>
+#include <linux/printk.h>
+#include <linux/regmap.h>
+#include <linux/soc/samsung/exynos-pmu.h>
+#include <linux/soc/samsung/exynos-regs-pmu.h>
+#include <linux/topology.h>
+#include <asm/cputype.h>
+
+#include "exynos-pmu.h"
+
+static int exynos850_cpu_pmu_offline(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ int cluster_id, core_id;
+ u32 reg, mask;
+
+ cluster_id = topology_cluster_id(cpu);
+ if (cluster_id < 0) {
+ pr_err_ratelimited("invalid cluster ID for cpu: %u\n", cpu);
+ return -EINVAL;
+ }
+
+ core_id = topology_core_id(cpu);
+ if (core_id < 0) {
+ pr_err_ratelimited("invalid core ID for cpu: %u\n", cpu);
+ return -EINVAL;
+ }
+
+ /* set cpu inform hint */
+ regmap_write(pmu_context->pmureg, EXYNOS850_CPU_INFORM(cpu), CPU_INFORM_C2);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, BIT(cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ mask = (BIT(cpu + 8));
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ regmap_update_bits(pmu_context->pmureg,
+ EXYNOS850_CLUSTER_CPU_INT_EN(cluster_id, core_id), 1 << 3, 1 << 3);
+ return 0;
+}
+
+static int exynos850_cpu_pmu_online(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ int cluster_id, core_id;
+ u32 reg, mask;
+
+ cluster_id = topology_cluster_id(cpu);
+ if (cluster_id < 0) {
+ pr_err_ratelimited("invalid cluster ID for cpu: %u\n", cpu);
+ return -EINVAL;
+ }
+
+ core_id = topology_core_id(cpu);
+ if (core_id < 0) {
+ pr_err_ratelimited("invalid core ID for cpu: %u\n", cpu);
+ return -EINVAL;
+ }
+
+ /* clear cpu inform hint */
+ regmap_write(pmu_context->pmureg, EXYNOS850_CPU_INFORM(cpu), CPU_INFORM_CLEAR);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, (0 << cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_UPEND, ®);
+
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_CLEAR, reg & mask);
+
+ regmap_update_bits(pmu_context->pmureg,
+ EXYNOS850_CLUSTER_CPU_INT_EN(cluster_id, core_id), 1 << 3, 0 << 3);
+ return 0;
+}
+
+const struct exynos_pmu_data exynos850_pmu_data = {
+ .pmu_cpuhp = true,
+ .cpu_pmu_offline = exynos850_cpu_pmu_offline,
+ .cpu_pmu_online = exynos850_cpu_pmu_online,
+};
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h b/include/linux/soc/samsung/exynos-regs-pmu.h
index 9c4d3da41dbf..c7a82635fc36 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -1015,6 +1015,11 @@
#define EXYNOS_GRP2_INTR_BID_UPEND (0x0208)
#define EXYNOS_GRP2_INTR_BID_CLEAR (0x020c)
+/* Exynos850 PMU Alive */
+#define EXYNOS850_CPU_INFORM(cpu) (0x0860 + ((cpu) & 7) * 4)
+#define EXYNOS850_CLUSTER_CPU_OFFSET(cl, cpu) (0x1000 + (((cl) * 0x400) + ((cpu) * 0x80)))
+#define EXYNOS850_CLUSTER_CPU_INT_EN(cl, cpu) (EXYNOS850_CLUSTER_CPU_OFFSET(cl, cpu) + 0x44)
+
/* exynosautov920 */
#define EXYNOSAUTOV920_PHY_CTRL_USB20 (0x0710)
#define EXYNOSAUTOV920_PHY_CTRL_USB31 (0x0714)
--
2.51.0
^ permalink raw reply related
* [PATCH v5 6/6] arm64: dts: exynos850: add PMU interrupt generation node
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Add pmu_intr_gen node for Exynos850. This hw block is required
for different power management routines like CPU hotplug and
different sleep and idle states.
Also reference this node from main PMU node.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
arch/arm64/boot/dts/exynos/exynos850.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
index 3881f573ec08..04662b1c5458 100644
--- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
@@ -214,6 +214,7 @@ gic: interrupt-controller@12a01000 {
pmu_system_controller: system-controller@11860000 {
compatible = "samsung,exynos850-pmu", "syscon";
reg = <0x11860000 0x10000>;
+ google,pmu-intr-gen-syscon = <&pmu_intr_gen>;
poweroff: syscon-poweroff {
compatible = "syscon-poweroff";
@@ -231,6 +232,11 @@ reboot: syscon-reboot {
};
};
+ pmu_intr_gen: syscon@11870000 {
+ compatible = "samsung,exynos850-pmu-intr-gen", "syscon";
+ reg = <0x11870000 0x10000>;
+ };
+
watchdog_cl0: watchdog@10050000 {
compatible = "samsung,exynos850-wdt";
reg = <0x10050000 0x100>;
--
2.51.0
^ permalink raw reply related
* [PATCH v5 5/6] MAINTAINERS: add Exynos850 PMU entry
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Add Exynos850 PMU entry describing new file
drivers/soc/samsung/exynos850-pmu.c.
Add myself as M there since I contributed Exynos850
PMU support and intend to maintain that.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 498ca30a00c5..60c25fed8ffa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23645,6 +23645,13 @@ F: arch/arm64/boot/dts/exynos/exynos2200*
F: drivers/clk/samsung/clk-exynos2200.c
F: include/dt-bindings/clock/samsung,exynos2200-cmu.h
+SAMSUNG EXYNOS850 PMU SUPPORT
+M: Alexey Klimov <alexey.klimov@linaro.org>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-samsung-soc@vger.kernel.org
+S: Maintained
+F: drivers/soc/samsung/exynos850-pmu.c
+
SAMSUNG EXYNOS850 SoC SUPPORT
M: Sam Protsenko <semen.protsenko@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.51.0
^ permalink raw reply related
* [PATCH v5 3/6] soc: samsung: exynos-pmu: generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
The cpuhotplug and cpuidle support for GS101-based SoCs which
utilizes GS101 PMU interrupts generation block can be generalised
to be (re)used for other Exynos-based SoCs. Also, the GS101 PMU
interrupts generation block is not exclusive to Google GS101 SoCs
and should be made more Exynos-generic.
Specifically, apply the following changes:
- rename gs101-specific calls, structs, names to be exynos-prefixed;
- move exynos_pmu_context and CPU_INFORM_* defines into exynos-pmu.h;
- introduce cpu_pmu_{offline,online} callbacks in driver-specific
exynos_pmu_data which can be used to hold PMU and PMU intr gen
update routines for different platforms and update cpuidle and cpuhotplug
support to use them;
- add checks for the presense of cpu_pmu_{offline,online} callbacks;
- move and rename gs101-specific cpu{offline,online} PMU updates
routines into gs101-pmu.c file, also removing underscore prefix;
- update gs101_pmu_data to use newly introduced callbacks;
- rename PMU interrupts generation GS101_INTR_* regs to EXYNOS_INTR_*.
This allows other platforms to add cpuhotplug and cpuidle support in
a similar manner, using their own platform-specific PMU and
PMU intr gen update routines.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Tested-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/soc/samsung/exynos-pmu.c | 122 ++++++----------------------
drivers/soc/samsung/exynos-pmu.h | 33 ++++++++
drivers/soc/samsung/gs101-pmu.c | 49 +++++++++++
include/linux/soc/samsung/exynos-regs-pmu.h | 10 +--
4 files changed, 112 insertions(+), 102 deletions(-)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index 846313a28e9a..f170abe08ef1 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -24,24 +24,6 @@
#include "exynos-pmu.h"
-struct exynos_pmu_context {
- struct device *dev;
- const struct exynos_pmu_data *pmu_data;
- struct regmap *pmureg;
- struct regmap *pmuintrgen;
- /*
- * Serialization lock for CPU hot plug and cpuidle ACPM hint
- * programming. Also protects in_cpuhp, sys_insuspend & sys_inreboot
- * flags.
- */
- raw_spinlock_t cpupm_lock;
- unsigned long *in_cpuhp;
- bool sys_insuspend;
- bool sys_inreboot;
- int cpuhp_prepare_state;
- int cpuhp_online_state;
-};
-
void __iomem *pmu_base_addr;
static struct exynos_pmu_context *pmu_context;
/* forward declaration */
@@ -221,43 +203,8 @@ struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np,
}
EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle);
-/*
- * CPU_INFORM register "hint" values are required to be programmed in addition to
- * the standard PSCI calls to have functional CPU hotplug and CPU idle states.
- * This is required to workaround limitations in the el3mon/ACPM firmware.
- */
-#define CPU_INFORM_CLEAR 0
-#define CPU_INFORM_C2 1
-
-/*
- * __gs101_cpu_pmu_ prefix functions are common code shared by CPU PM notifiers
- * (CPUIdle) and CPU hotplug callbacks. Functions should be called with IRQs
- * disabled and cpupm_lock held.
- */
-static int __gs101_cpu_pmu_online(unsigned int cpu)
- __must_hold(&pmu_context->cpupm_lock)
-{
- u32 reg, mask;
-
- /* clear cpu inform hint */
- regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu),
- CPU_INFORM_CLEAR);
-
- mask = BIT(cpu);
-
- regmap_update_bits(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_ENABLE,
- mask, (0 << cpu));
-
- regmap_read(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_UPEND, ®);
-
- regmap_write(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_CLEAR,
- reg & mask);
-
- return 0;
-}
-
/* Called from CPU PM notifier (CPUIdle code path) with IRQs disabled */
-static int gs101_cpu_pmu_online(void)
+static int exynos_cpu_pmu_online(void)
{
int cpu;
@@ -269,20 +216,20 @@ static int gs101_cpu_pmu_online(void)
}
cpu = smp_processor_id();
- __gs101_cpu_pmu_online(cpu);
+ pmu_context->pmu_data->cpu_pmu_online(pmu_context, cpu);
raw_spin_unlock(&pmu_context->cpupm_lock);
return NOTIFY_OK;
}
/* Called from CPU hot plug callback with IRQs enabled */
-static int gs101_cpuhp_pmu_online(unsigned int cpu)
+static int exynos_cpuhp_pmu_online(unsigned int cpu)
{
unsigned long flags;
raw_spin_lock_irqsave(&pmu_context->cpupm_lock, flags);
- __gs101_cpu_pmu_online(cpu);
+ pmu_context->pmu_data->cpu_pmu_online(pmu_context, cpu);
/*
* Mark this CPU as having finished the hotplug.
* This means this CPU can now enter C2 idle state.
@@ -293,33 +240,8 @@ static int gs101_cpuhp_pmu_online(unsigned int cpu)
return 0;
}
-/* Common function shared by both CPU hot plug and CPUIdle */
-static int __gs101_cpu_pmu_offline(unsigned int cpu)
- __must_hold(&pmu_context->cpupm_lock)
-{
- u32 reg, mask;
-
- /* set cpu inform hint */
- regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_C2);
-
- mask = BIT(cpu);
- regmap_update_bits(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_ENABLE,
- mask, BIT(cpu));
-
- regmap_read(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_UPEND, ®);
- regmap_write(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_CLEAR,
- reg & mask);
-
- mask = (BIT(cpu + 8));
- regmap_read(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_UPEND, ®);
- regmap_write(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_CLEAR,
- reg & mask);
-
- return 0;
-}
-
/* Called from CPU PM notifier (CPUIdle code path) with IRQs disabled */
-static int gs101_cpu_pmu_offline(void)
+static int exynos_cpu_pmu_offline(void)
{
int cpu;
@@ -337,14 +259,14 @@ static int gs101_cpu_pmu_offline(void)
return NOTIFY_OK;
}
- __gs101_cpu_pmu_offline(cpu);
+ pmu_context->pmu_data->cpu_pmu_offline(pmu_context, cpu);
raw_spin_unlock(&pmu_context->cpupm_lock);
return NOTIFY_OK;
}
/* Called from CPU hot plug callback with IRQs enabled */
-static int gs101_cpuhp_pmu_offline(unsigned int cpu)
+static int exynos_cpuhp_pmu_offline(unsigned int cpu)
{
unsigned long flags;
@@ -354,29 +276,29 @@ static int gs101_cpuhp_pmu_offline(unsigned int cpu)
* ACPM the CPU entering hotplug should not enter C2 idle state.
*/
set_bit(cpu, pmu_context->in_cpuhp);
- __gs101_cpu_pmu_offline(cpu);
+ pmu_context->pmu_data->cpu_pmu_offline(pmu_context, cpu);
raw_spin_unlock_irqrestore(&pmu_context->cpupm_lock, flags);
return 0;
}
-static int gs101_cpu_pm_notify_callback(struct notifier_block *self,
+static int exynos_cpu_pm_notify_callback(struct notifier_block *self,
unsigned long action, void *v)
{
switch (action) {
case CPU_PM_ENTER:
- return gs101_cpu_pmu_offline();
+ return exynos_cpu_pmu_offline();
case CPU_PM_EXIT:
- return gs101_cpu_pmu_online();
+ return exynos_cpu_pmu_online();
}
return NOTIFY_OK;
}
-static struct notifier_block gs101_cpu_pm_notifier = {
- .notifier_call = gs101_cpu_pm_notify_callback,
+static struct notifier_block exynos_cpu_pm_notifier = {
+ .notifier_call = exynos_cpu_pm_notify_callback,
/*
* We want to be called first, as the ACPM hint and handshake is what
* puts the CPU into C2.
@@ -408,7 +330,7 @@ static struct notifier_block exynos_cpupm_reboot_nb = {
static void destroy_cpuhp_and_cpuidle(void)
{
- cpu_pm_unregister_notifier(&gs101_cpu_pm_notifier);
+ cpu_pm_unregister_notifier(&exynos_cpu_pm_notifier);
unregister_reboot_notifier(&exynos_cpupm_reboot_nb);
if (pmu_context->cpuhp_prepare_state != CPUHP_INVALID)
@@ -424,6 +346,12 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
void __iomem *virt_addr;
int ret, cpu;
+ if (!pmu_context->pmu_data->cpu_pmu_offline || !pmu_context->pmu_data->cpu_pmu_online) {
+ dev_err(dev,
+ "PMU write/update sequence is not present for cpuhotplug and cpuidle\n");
+ return -ENODEV;
+ }
+
intr_gen_node = of_parse_phandle(dev->of_node,
"google,pmu-intr-gen-syscon", 0);
if (!intr_gen_node) {
@@ -475,28 +403,28 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
/* set PMU to power on */
for_each_online_cpu(cpu)
- gs101_cpuhp_pmu_online(cpu);
+ exynos_cpuhp_pmu_online(cpu);
/* register CPU hotplug callbacks */
pmu_context->cpuhp_prepare_state = CPUHP_INVALID;
pmu_context->cpuhp_online_state = CPUHP_INVALID;
ret = cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "soc/exynos-pmu:prepare",
- gs101_cpuhp_pmu_online, NULL);
+ exynos_cpuhp_pmu_online, NULL);
if (ret < 0)
return ret;
pmu_context->cpuhp_prepare_state = ret;
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "soc/exynos-pmu:online",
- NULL, gs101_cpuhp_pmu_offline);
+ NULL, exynos_cpuhp_pmu_offline);
if (ret < 0)
goto clean_cpuhp_states;
pmu_context->cpuhp_online_state = ret;
/* register CPU PM notifiers for cpuidle */
- ret = cpu_pm_register_notifier(&gs101_cpu_pm_notifier);
+ ret = cpu_pm_register_notifier(&exynos_cpu_pm_notifier);
if (ret)
goto clean_cpuhp_states;
@@ -505,7 +433,7 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
/* Success */
return ret;
- cpu_pm_unregister_notifier(&gs101_cpu_pm_notifier);
+ cpu_pm_unregister_notifier(&exynos_cpu_pm_notifier);
clean_cpuhp_states:
if (pmu_context->cpuhp_prepare_state != CPUHP_INVALID)
diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index fbe381e2a2e1..733e188fa2b1 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -13,6 +13,14 @@
#define PMU_TABLE_END (-1U)
+/*
+ * CPU_INFORM register "hint" values are required to be programmed in addition to
+ * the standard PSCI calls to have functional CPU hotplug and CPU idle states.
+ * This is required to workaround limitations in the el3mon/ACPM firmware.
+ */
+#define CPU_INFORM_CLEAR 0
+#define CPU_INFORM_C2 1
+
struct regmap_access_table;
struct exynos_pmu_conf {
@@ -20,6 +28,24 @@ struct exynos_pmu_conf {
u8 val[NUM_SYS_POWERDOWN];
};
+struct exynos_pmu_context {
+ struct device *dev;
+ const struct exynos_pmu_data *pmu_data;
+ struct regmap *pmureg;
+ struct regmap *pmuintrgen;
+ /*
+ * Serialization lock for CPU hot plug and cpuidle ACPM hint
+ * programming. Also protects in_cpuhp, sys_insuspend & sys_inreboot
+ * flags.
+ */
+ raw_spinlock_t cpupm_lock;
+ unsigned long *in_cpuhp;
+ bool sys_insuspend;
+ bool sys_inreboot;
+ int cpuhp_prepare_state;
+ int cpuhp_online_state;
+};
+
/**
* struct exynos_pmu_data - of_device_id (match) data
*
@@ -44,6 +70,10 @@ struct exynos_pmu_conf {
* used (i.e. when @pmu_secure is @true).
* @wr_table: A table of writable register ranges in case a custom regmap is
* used (i.e. when @pmu_secure is @true).
+ * @cpu_pmu_offline: Optional callback to be called before entering CPU offline
+ * or idle state. Only valid when pmu_cpuhp set to true.
+ * @cpu_pmu_online: Optional callback to be called after CPU onlined or after
+ * exiting idle state. Only valid when pmu_cpuhp set to true.
*/
struct exynos_pmu_data {
const struct exynos_pmu_conf *pmu_config;
@@ -57,6 +87,9 @@ struct exynos_pmu_data {
const struct regmap_access_table *rd_table;
const struct regmap_access_table *wr_table;
+
+ int (*cpu_pmu_offline)(struct exynos_pmu_context *pmu_context, unsigned int cpu);
+ int (*cpu_pmu_online)(struct exynos_pmu_context *pmu_context, unsigned int cpu);
};
extern void __iomem *pmu_base_addr;
diff --git a/drivers/soc/samsung/gs101-pmu.c b/drivers/soc/samsung/gs101-pmu.c
index 17dadc1b9c6e..ec75ff062ce0 100644
--- a/drivers/soc/samsung/gs101-pmu.c
+++ b/drivers/soc/samsung/gs101-pmu.c
@@ -322,11 +322,60 @@ static const struct regmap_access_table gs101_pmu_wr_table = {
.n_no_ranges = ARRAY_SIZE(gs101_pmu_ro_registers),
};
+/*
+ * gs101_cpu_pmu_ prefix functions are common code shared by CPU PM notifiers
+ * (CPUIdle) and CPU hotplug callbacks. Functions should be called with IRQs
+ * disabled and cpupm_lock held.
+ */
+static int gs101_cpu_pmu_online(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ u32 reg, mask;
+
+ /* clear cpu inform hint */
+ regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_CLEAR);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, (0 << cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_UPEND, ®);
+
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_CLEAR, reg & mask);
+
+ return 0;
+}
+
+/* Common function shared by both CPU hot plug and CPUIdle */
+static int gs101_cpu_pmu_offline(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ u32 reg, mask;
+
+ /* set cpu inform hint */
+ regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_C2);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, BIT(cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ mask = (BIT(cpu + 8));
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ return 0;
+}
+
const struct exynos_pmu_data gs101_pmu_data = {
.pmu_secure = true,
.pmu_cpuhp = true,
.rd_table = &gs101_pmu_rd_table,
.wr_table = &gs101_pmu_wr_table,
+ .cpu_pmu_offline = gs101_cpu_pmu_offline,
+ .cpu_pmu_online = gs101_cpu_pmu_online,
};
/*
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h b/include/linux/soc/samsung/exynos-regs-pmu.h
index db8a7ca81080..9c4d3da41dbf 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -1009,11 +1009,11 @@
#define GS101_PHY_CTRL_UFS 0x3ec8
/* PMU INTR GEN */
-#define GS101_GRP1_INTR_BID_UPEND (0x0108)
-#define GS101_GRP1_INTR_BID_CLEAR (0x010c)
-#define GS101_GRP2_INTR_BID_ENABLE (0x0200)
-#define GS101_GRP2_INTR_BID_UPEND (0x0208)
-#define GS101_GRP2_INTR_BID_CLEAR (0x020c)
+#define EXYNOS_GRP1_INTR_BID_UPEND (0x0108)
+#define EXYNOS_GRP1_INTR_BID_CLEAR (0x010c)
+#define EXYNOS_GRP2_INTR_BID_ENABLE (0x0200)
+#define EXYNOS_GRP2_INTR_BID_UPEND (0x0208)
+#define EXYNOS_GRP2_INTR_BID_CLEAR (0x020c)
/* exynosautov920 */
#define EXYNOSAUTOV920_PHY_CTRL_USB20 (0x0710)
--
2.51.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