[PATCH 0/7] soc: st: add RISAB dump debug driver.

[PATCH 0/7] soc: st: add RISAB dump debug driver.

[Gatien Chevallier]

The RISAB peripheral is part of the RIF and is used to protect internal
RAMs.

Memory firewalls configuration on stm32mp2x platforms can be quite
complex. The RIF configuration is done by the Trusted Domain CID
(TDCID) that is running in secure priviledged mode. However, the
configuration can be read in any mode.

In order to facilitate the memory firewall configuration (check if
correctly applied, what rights for which range, etc...), add a RISAB
configuration dump driver that is embedded only when CONFIG_DEBUGFS
is set. This driver creates a debugfs entry to dump the whole RISAB
configuration in a readable format [1], as for the RIFSC.

[1]: https://wiki.st.com/stm32mpu/wiki/How_to_analyze_IAC_%26_SERC_errors#RISAB_dump

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
Gatien Chevallier (7):
      dt-bindings: soc: st: document the RISAB firewall peripheral
      soc: st: add RISAB dump debug driver
      arm64: dts: st: add RISAB1/2/3/4/5/6 nodes to stm32mp251.dtsi
      arm64: dts: st: add RISAB1/2/3/4/5/6 nodes to stm32mp231.dtsi
      arm64: dts: st: enable all RISAB instances on the stm32mp257f-ev1 board
      arm64: dts: st: enable all RISAB instances on the stm32mp257f-dk board
      arm64: dts: st: enable all RISAB instances on the stm32mp235f-dk board

 .../bindings/soc/st/st,stm32mp25-risab.yaml        |  74 +++++
 MAINTAINERS                                        |   6 +
 arch/arm64/boot/dts/st/stm32mp231.dtsi             |  48 +++
 arch/arm64/boot/dts/st/stm32mp235f-dk.dts          |  24 ++
 arch/arm64/boot/dts/st/stm32mp251.dtsi             |  48 +++
 arch/arm64/boot/dts/st/stm32mp257f-dk.dts          |  24 ++
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts         |  24 ++
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/st/Kconfig                             |  11 +
 drivers/soc/st/Makefile                            |   1 +
 drivers/soc/st/stm32_risab.c                       | 329 +++++++++++++++++++++
 12 files changed, 591 insertions(+)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260209-stm32_risab-4fbcdb834c43

Best regards,
-- 
Gatien Chevallier <gatien.chevallier@foss.st.com>

[PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Gatien Chevallier]

Add documentation on the RISAB peripheral that is a memory firewall on
the stm32mp2x platforms.

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 .../bindings/soc/st/st,stm32mp25-risab.yaml        | 74 ++++++++++++++++++++++
 MAINTAINERS                                        |  5 ++
 2 files changed, 79 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml b/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml
new file mode 100644
index 000000000000..d05a683c594d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/st/st,stm32mp25-risab.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Resource isolation peripheral unit for address space protection
+       (block-based)
+
+maintainers:
+  - Gatien Chevallier <gatien.chevallier@foss.st.com>
+
+description:
+  The RIF (resource isolation framework) is a comprehensive set of hardware
+  blocks designed to enforce and manage isolation of STM32 hardware resources,
+  like memory and peripherals. The RISAB peripheral is part of the RIF and is
+  used to protect internal RAMs by applying access rights per RISAB fixed-size
+  page. Through RISAB registers, a trusted domain, or the domain to whom the
+  page configuration has been delegated, assigns memory pages to one or more
+  security domains (secure, privilege, compartment).
+
+properties:
+  compatible:
+    const: st,stm32mp25-risab
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: RISAB bus clock
+
+  memory-region:
+    minItems: 1
+    maxItems: 32
+    description:
+      Phandle to nodes describing memory regions to be configured in the RISAB
+      by the trusted domain of at least a RISAB page size.
+      These regions cannot overlap. A zone must be within st,mem-map range and
+      can be represented by one or more pages.
+
+  st,mem-map:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description: Memory address range covered by the RISAB.
+    items:
+      - description: Memory range base address
+      - description: Memory range size
+
+  st,srwiad:
+    description:
+      When set, the trusted domain configures the RISAB to allow secure
+      read/write data accesses to non-secure blocks and pages. Secure execute
+      remains illegal.
+    type: boolean
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - st,mem-map
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+
+    risab1: risab@420f0000 {
+        compatible = "st,stm32mp25-risab";
+        reg = <0x420f0000 0x1000>;
+        clocks = <&rcc CK_ICN_LS_MCU>;
+        st,mem-map = <0xa000000 0x20000>;
+        st,srwiad;
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index e08767323763..b9a1276e94a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25092,6 +25092,11 @@ F:	Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
 F:	Documentation/devicetree/bindings/dma/stm32/
 F:	drivers/dma/stm32/
 
+STM32 SoC FIREWALL DRIVERS
+M:	Gatien Chevallier <gatien.chevallier@foss.st.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/soc/st/*risa*
+
 STM32 TIMER/LPTIMER DRIVERS
 M:	Fabrice Gasnier <fabrice.gasnier@foss.st.com>
 S:	Maintained

-- 
2.43.0

[PATCH 2/7] soc: st: add RISAB dump debug driver

[Gatien Chevallier]

This driver creates an entry in the debugfs to dump RISAB memory
regions configurations.

Signed-off-by: Theo GOUREAU <theo.goureau-ext@st.com>
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 MAINTAINERS                  |   1 +
 drivers/soc/Kconfig          |   1 +
 drivers/soc/Makefile         |   1 +
 drivers/soc/st/Kconfig       |  11 ++
 drivers/soc/st/Makefile      |   1 +
 drivers/soc/st/stm32_risab.c | 329 +++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 344 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b9a1276e94a9..64a5b894c6b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25096,6 +25096,7 @@ STM32 SoC FIREWALL DRIVERS
 M:	Gatien Chevallier <gatien.chevallier@foss.st.com>
 S:	Maintained
 F:	Documentation/devicetree/bindings/soc/st/*risa*
+F:	drivers/soc/st/*risa*
 
 STM32 TIMER/LPTIMER DRIVERS
 M:	Fabrice Gasnier <fabrice.gasnier@foss.st.com>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index a2d65adffb80..dfe5cec59262 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -24,6 +24,7 @@ source "drivers/soc/renesas/Kconfig"
 source "drivers/soc/rockchip/Kconfig"
 source "drivers/soc/samsung/Kconfig"
 source "drivers/soc/sophgo/Kconfig"
+source "drivers/soc/st/Kconfig"
 source "drivers/soc/sunxi/Kconfig"
 source "drivers/soc/tegra/Kconfig"
 source "drivers/soc/ti/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index c9e689080ceb..894bd6ebaaa4 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -30,6 +30,7 @@ obj-y				+= renesas/
 obj-y				+= rockchip/
 obj-$(CONFIG_SOC_SAMSUNG)	+= samsung/
 obj-y				+= sophgo/
+obj-y				+= st/
 obj-y				+= sunxi/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-y				+= ti/
diff --git a/drivers/soc/st/Kconfig b/drivers/soc/st/Kconfig
new file mode 100644
index 000000000000..6c293af58f2a
--- /dev/null
+++ b/drivers/soc/st/Kconfig
@@ -0,0 +1,11 @@
+if ARCH_STM32 || COMPILE_TEST
+
+config STM32_RISAB
+	tristate "STM32 RISAB"
+	depends on (ARM64  || COMPILE_TEST) && DEBUG_FS
+	default y
+	help
+	  Say y to enable RISAB dump debug helper driver. This creates an entry
+	  in the debugfs to dump RISAB pages and blocks RIF configurations.
+
+endif # ARCH_STM32 || COMPILE_TEST
diff --git a/drivers/soc/st/Makefile b/drivers/soc/st/Makefile
new file mode 100644
index 000000000000..6b53f3eda801
--- /dev/null
+++ b/drivers/soc/st/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_STM32_RISAB) += stm32_risab.o
diff --git a/drivers/soc/st/stm32_risab.c b/drivers/soc/st/stm32_risab.c
new file mode 100644
index 000000000000..f1f0300817e2
--- /dev/null
+++ b/drivers/soc/st/stm32_risab.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, STMicroelectronics - All Rights Reserved
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/debugfs.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+/*
+ * RISAB constants
+ */
+#define RISAB_NUMBER_OF_PAGES_MAX	32
+#define RISAB_BLOCKS_PER_PAGES		8
+#define RISAB_NUMBER_OF_CID		7
+#define RISAB_PAGE_SIZE			0x1000
+
+/*
+ * RISAB configuration register
+ */
+#define RISAB_CR	0x000
+#define RISAB_CR_SRWIAD	BIT(31)
+#define RISAB_CR_GLOCK	BIT(0)
+
+/*
+ * RISAB configuration lock register
+ */
+#define RISAB_RCFGLOCKR	0x010
+
+/*
+ * RISAB page y=0..31 security and privileged configuration registers
+ */
+#define RISAB_PG_SECCFGR(y)	(0x100 + 0x4 * (y))
+#define RISAB_PG_PRIVCFGR(y)	(0x200 + 0x4 * (y))
+#define RISAB_PG_C2PRIVCFGR(y)	(0x600 + 0x4 * (y))
+
+/*
+ * RISAB compartment x=0..6 privilege, read and write configuration registers
+ */
+#define RISAB_CIDPRIVCFGR(x)	(0x800 + 0x20 * (x))
+#define RISAB_CIDRDCFGR(x)	(0x808 + 0x20 * (x))
+#define RISAB_CIDWRCFGR(x)	(0x810 + 0x20 * (x))
+
+/*
+ * RISAB page y=0..31 CID configuration registers
+ */
+#define RISAB_PG_CIDCFGR(y)		(0xA00 + 0x4 * (y))
+#define RISAB_PG_CIDCFGR_DCCID_MASK	GENMASK(6, 4)
+#define RISAB_PG_CIDCFGR_DCEN		BIT(2)
+#define RISAB_PG_CIDCFGR_CFEN		BIT(0)
+
+/*
+ * RISAB hardware configuration registers
+ */
+#define RISAB_HWCFGR1				0xFF0
+#define RISAB_HWCFGR1_LOG_NUM_PAGE_MASK		GENMASK(27, 24)
+#define RISAB_HWCFGR1_LOG_NUM_PAGE_SHIFT	24
+
+struct risab_debug_data {
+	bool sec[RISAB_BLOCKS_PER_PAGES];
+	bool priv[RISAB_BLOCKS_PER_PAGES];
+	bool c2priv[RISAB_BLOCKS_PER_PAGES];
+	u8 dccid;
+	bool dcen;
+	bool cfen;
+};
+
+struct risab_generic_debug_data {
+	bool srwiad;
+	bool glock;
+	bool rlock[RISAB_NUMBER_OF_PAGES_MAX];
+	bool ppriv[RISAB_NUMBER_OF_CID][RISAB_NUMBER_OF_PAGES_MAX];
+	bool prden[RISAB_NUMBER_OF_CID][RISAB_NUMBER_OF_PAGES_MAX];
+	bool pwren[RISAB_NUMBER_OF_CID][RISAB_NUMBER_OF_PAGES_MAX];
+};
+
+struct risab_pdata {
+	void __iomem *base;
+	struct device *dev;
+	struct dentry *dbg_entry;
+	u32 risab_map_base;
+	struct clk *clk;
+	u32 nb_pages;
+};
+
+static void stm32_risab_fill_dev_dbg_entry(struct risab_pdata *pdata,
+					   struct risab_debug_data *dbg_entry, int page)
+{
+	u32 risab_pg_c2privcfgr = readl_relaxed(pdata->base + RISAB_PG_C2PRIVCFGR(page));
+	u32 risab_pg_privcfgr = readl_relaxed(pdata->base + RISAB_PG_PRIVCFGR(page));
+	u32 risab_pg_seccfgr = readl_relaxed(pdata->base + RISAB_PG_SECCFGR(page));
+	u32 risab_pg_cidcfgr = readl_relaxed(pdata->base + RISAB_PG_CIDCFGR(page));
+	int block;
+
+	for (block = 0; block < RISAB_BLOCKS_PER_PAGES; block++) {
+		dbg_entry->sec[block] = risab_pg_seccfgr & BIT(block);
+		dbg_entry->priv[block] = risab_pg_privcfgr & BIT(block);
+		dbg_entry->c2priv[block] = risab_pg_c2privcfgr & BIT(block);
+	}
+
+	dbg_entry->dccid = FIELD_GET(RISAB_PG_CIDCFGR_DCCID_MASK, risab_pg_cidcfgr);
+	dbg_entry->dcen = risab_pg_cidcfgr & RISAB_PG_CIDCFGR_DCEN;
+	dbg_entry->cfen = risab_pg_cidcfgr & RISAB_PG_CIDCFGR_CFEN;
+}
+
+static void stm32_risab_fill_dev_generic_dbg_entry(struct risab_pdata *pdata,
+						   struct risab_generic_debug_data *dbg_entry)
+{
+	u32 risab_rcfglockr = readl_relaxed(pdata->base + RISAB_RCFGLOCKR);
+	u32 risab_cr = readl_relaxed(pdata->base + RISAB_CR);
+	int page, compartment;
+
+	dbg_entry->srwiad = risab_cr & RISAB_CR_SRWIAD;
+	dbg_entry->glock = risab_cr & RISAB_CR_GLOCK;
+
+	for (page = 0; page < pdata->nb_pages; page++)
+		dbg_entry->rlock[page] = risab_rcfglockr & BIT(page);
+
+	for (compartment = 0; compartment < RISAB_NUMBER_OF_CID; compartment++) {
+		u32 risab_cidprivcfgr = readl_relaxed(pdata->base + RISAB_CIDPRIVCFGR(compartment));
+		u32 risab_cidrdcfgr = readl_relaxed(pdata->base + RISAB_CIDRDCFGR(compartment));
+		u32 risab_cidwrcfgr = readl_relaxed(pdata->base + RISAB_CIDWRCFGR(compartment));
+
+		for (page = 0; page < pdata->nb_pages; page++) {
+			dbg_entry->ppriv[compartment][page] = risab_cidprivcfgr & BIT(page);
+			dbg_entry->prden[compartment][page] = risab_cidrdcfgr & BIT(page);
+			dbg_entry->pwren[compartment][page] = risab_cidwrcfgr & BIT(page);
+		}
+	}
+}
+
+static int stm32_risab_conf_dump_show(struct seq_file *s, void *data)
+{
+	struct risab_pdata *pdata = (struct risab_pdata *)s->private;
+	struct risab_generic_debug_data generic_dbg_entry;
+	struct risab_debug_data dbg_entry;
+	int ret, page, compartment, block;
+
+	ret = clk_prepare_enable(pdata->clk);
+	if (ret) {
+		dev_err(pdata->dev, "Couldn't enable RISAB clock");
+		return ret;
+	}
+
+	stm32_risab_fill_dev_generic_dbg_entry(pdata, &generic_dbg_entry);
+
+	seq_puts(s, "=============================================\n");
+	seq_printf(s, "        RISAB dump (%s)\n", pdata->dev->of_node->full_name);
+	seq_puts(s, "=============================================\n");
+
+	seq_printf(s, "Secure read/write illegal access disable (SRWIAD): %d.\n",
+		   generic_dbg_entry.srwiad);
+	seq_printf(s, "Global lock (GLOCK): %d.\n", generic_dbg_entry.glock);
+
+	seq_puts(s, "| Page                       |");
+	seq_puts(s, "| Res. |");
+	seq_puts(s, "|     priv. (p) read (r) write (w) per compartment      |");
+	seq_puts(s, "| Delegated |");
+	seq_puts(s, "|    CID    |");
+	seq_puts(s, "| secure (s) default priv. (p) compartment2 priv. (P) per block |\n");
+
+	seq_puts(s, "|     start add.  end add.   |");
+	seq_puts(s, "| lock |");
+	seq_puts(s, "| CID0  | CID1  | CID2  | CID3  | CID4  | CID5  | CID6  |");
+	seq_puts(s, "| conf. CID |");
+	seq_puts(s, "| filtering |");
+	seq_puts(s, "| blck0 | blck1 | blck2 | blck3 | blck4 | blck5 | blck6 | blck7 |\n");
+
+	for (page = 0; page < pdata->nb_pages; page++) {
+		stm32_risab_fill_dev_dbg_entry(pdata, &dbg_entry, page);
+		seq_printf(s, "| %2d  0x%08x  0x%08x |",
+			   page,
+			   pdata->risab_map_base + page * RISAB_PAGE_SIZE,
+			   pdata->risab_map_base + (page + 1) * RISAB_PAGE_SIZE - 1
+		);
+		seq_printf(s, "| %3s  |", generic_dbg_entry.rlock[page] ? "Yes" : "No");
+		for (compartment = 0; compartment < RISAB_NUMBER_OF_CID; compartment++) {
+			seq_printf(s, "| %1s %1s %1s ",
+				   generic_dbg_entry.ppriv[compartment][page] ? "p" : " ",
+				   generic_dbg_entry.prden[compartment][page] ? "r" : " ",
+				   generic_dbg_entry.pwren[compartment][page] ? "w" : " "
+			);
+		}
+
+		if (dbg_entry.dcen)
+			seq_printf(s, "||  0x%04x   |", dbg_entry.dccid);
+		else
+			seq_puts(s, "|| disabled  |");
+
+		seq_printf(s, "| %-9s |", dbg_entry.cfen ? "enabled" : "disabled");
+		for (block = 0; block < RISAB_BLOCKS_PER_PAGES; block++) {
+			seq_printf(s, "| %1s %1s %1s ",
+				   dbg_entry.sec[block] ? "s" : " ",
+				   dbg_entry.priv[block] && !dbg_entry.cfen ? "p" : " ",
+				   dbg_entry.c2priv[block] ? "P" : " "
+			);
+		}
+		seq_puts(s, "|\n");
+	}
+
+	clk_disable_unprepare(pdata->clk);
+
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(stm32_risab_conf_dump);
+
+static int stm32_risab_register_debugfs(struct risab_pdata *pdata)
+{
+	struct dentry *root = NULL;
+
+	root = debugfs_lookup("stm32_firewall", NULL);
+	if (!root)
+		root = debugfs_create_dir("stm32_firewall", NULL);
+
+	if (IS_ERR(root))
+		return PTR_ERR(root);
+
+	pdata->dbg_entry = debugfs_create_file(dev_name(pdata->dev), 0444,
+					       root, pdata, &stm32_risab_conf_dump_fops);
+
+	return 0;
+}
+
+static int stm32_risab_get_nb_pages(struct risab_pdata *pdata)
+{
+	u32 risab_hwcfgr1, nb_pages_shift;
+	int ret, nb_page;
+
+	ret = clk_prepare_enable(pdata->clk);
+	if (ret) {
+		dev_err(pdata->dev, "Failed to enable clk: %d\n", ret);
+		return ret;
+	}
+
+	risab_hwcfgr1 = readl_relaxed(pdata->base + RISAB_HWCFGR1);
+	nb_pages_shift = FIELD_GET(RISAB_HWCFGR1_LOG_NUM_PAGE_MASK,
+				   risab_hwcfgr1);
+	nb_page = BIT(nb_pages_shift);
+
+	if (nb_page > RISAB_NUMBER_OF_PAGES_MAX) {
+		dev_err(pdata->dev, "RISAB number of pages is greater than %d",
+			RISAB_NUMBER_OF_PAGES_MAX);
+		ret = -EINVAL;
+		goto err_clk_disable;
+	}
+
+	ret = nb_page;
+
+err_clk_disable:
+	clk_disable_unprepare(pdata->clk);
+
+	return ret;
+}
+
+static int stm32_risab_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct risab_pdata *pdata;
+	void __iomem *mmio;
+	int err, nb_pages;
+	struct clk *clk;
+
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	mmio =  devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(mmio))
+		return PTR_ERR(mmio);
+
+	clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return dev_err_probe(&pdev->dev, PTR_ERR(clk), "Failed to get clk\n");
+
+	pdata->base = mmio;
+	pdata->clk = clk;
+	pdata->dev = &pdev->dev;
+
+	err = of_property_read_u32(np, "st,mem-map", &pdata->risab_map_base);
+	if (err) {
+		return dev_err_probe(&pdev->dev, err,
+				     "Couldn't read the memory range covered by the RISAB\n");
+	}
+
+	nb_pages = stm32_risab_get_nb_pages(pdata);
+	if (nb_pages < 0)
+		return dev_err_probe(&pdev->dev, nb_pages, "Couldn't read RISAB number of pages\n");
+
+	pdata->nb_pages = nb_pages;
+
+	platform_set_drvdata(pdev, pdata);
+
+	return stm32_risab_register_debugfs(pdata);
+}
+
+static void stm32_risab_remove(struct platform_device *pdev)
+{
+	struct risab_pdata *pdata = platform_get_drvdata(pdev);
+
+	debugfs_remove(pdata->dbg_entry);
+}
+
+static const struct of_device_id stm32_risab_match[] = {
+	{ .compatible = "st,stm32mp25-risab", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, stm32_risab_match);
+
+static struct platform_driver stm32_risab_driver = {
+	.probe  = stm32_risab_probe,
+	.remove = stm32_risab_remove,
+	.driver = {
+		.name = "stm32-risab",
+		.of_match_table = stm32_risab_match,
+	},
+};
+module_platform_driver(stm32_risab_driver);
+
+MODULE_AUTHOR("Gatien Chevallier <gatien.chevallier@foss.st.com>");
+MODULE_LICENSE("GPL");

-- 
2.43.0

[PATCH 3/7] arm64: dts: st: add RISAB1/2/3/4/5/6 nodes to stm32mp251.dtsi

[Gatien Chevallier]

Add RISAB1/2/3/4/5/6 nodes to the stm32mp251.dtsi device tree SoC
file.

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 48 ++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index a8e6e0f77b83..e9d8338b2017 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -1733,6 +1733,54 @@ pcie@0,0 {
 			};
 		};
 
+		risab1: risab@420f0000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x420f0000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa000000 0x20000>;
+			status = "disabled";
+		};
+
+		risab2: risab@42100000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42100000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa020000 0x20000>;
+			status = "disabled";
+		};
+
+		risab3: risab@42110000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42110000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa040000 0x20000>;
+			status = "disabled";
+		};
+
+		risab4: risab@42120000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42120000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa060000 0x20000>;
+			status = "disabled";
+		};
+
+		risab5: risab@42130000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42130000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa080000 0x20000>;
+			status = "disabled";
+		};
+
+		risab6: risab@42140000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42140000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa0a0000 0x20000>;
+			status = "disabled";
+		};
+
 		bsec: efuse@44000000 {
 			compatible = "st,stm32mp25-bsec";
 			reg = <0x44000000 0x1000>;

-- 
2.43.0

[PATCH 4/7] arm64: dts: st: add RISAB1/2/3/4/5/6 nodes to stm32mp231.dtsi

[Gatien Chevallier]

Add RISAB1/2/3/4/5/6 nodes to the stm32mp231.dtsi device tree SoC
file.

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp231.dtsi | 48 ++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp231.dtsi b/arch/arm64/boot/dts/st/stm32mp231.dtsi
index 88e214d395ab..1376d506f372 100644
--- a/arch/arm64/boot/dts/st/stm32mp231.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp231.dtsi
@@ -755,6 +755,54 @@ stmmac_axi_config_1: stmmac-axi-config {
 			};
 		};
 
+		risab1: risab@420f0000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x420f0000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa000000 0x20000>;
+			status = "disabled";
+		};
+
+		risab2: risab@42100000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42100000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa020000 0x20000>;
+			status = "disabled";
+		};
+
+		risab3: risab@42110000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42110000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa040000 0x20000>;
+			status = "disabled";
+		};
+
+		risab4: risab@42120000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42120000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa060000 0x20000>;
+			status = "disabled";
+		};
+
+		risab5: risab@42130000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42130000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa080000 0x20000>;
+			status = "disabled";
+		};
+
+		risab6: risab@42140000 {
+			compatible = "st,stm32mp25-risab";
+			reg = <0x42140000 0x1000>;
+			clocks = <&scmi_clk CK_SCMI_ICN_LS_MCU>;
+			st,mem-map = <0xa0a0000 0x20000>;
+			status = "disabled";
+		};
+
 		bsec: efuse@44000000 {
 			compatible = "st,stm32mp25-bsec";
 			reg = <0x44000000 0x1000>;

-- 
2.43.0

[PATCH 5/7] arm64: dts: st: enable all RISAB instances on the stm32mp257f-ev1 board

[Gatien Chevallier]

To be able to dump the RISAB configurations, enable all RISAB instances
on the stm32mp257f-ev1 board.

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index bb6d6393d2e4..973acea6d248 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -352,6 +352,30 @@ pcie@0,0 {
 	};
 };
 
+&risab1 {
+	status = "okay";
+};
+
+&risab2 {
+	status = "okay";
+};
+
+&risab3 {
+	status = "okay";
+};
+
+&risab4 {
+	status = "okay";
+};
+
+&risab5 {
+	status = "okay";
+};
+
+&risab6 {
+	status = "okay";
+};
+
 &rtc {
 	status = "okay";
 };

-- 
2.43.0

[PATCH 6/7] arm64: dts: st: enable all RISAB instances on the stm32mp257f-dk board

[Gatien Chevallier]

To be able to dump the RISAB configurations, enable all RISAB instances
on the stm32mp257f-dk board.

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-dk.dts | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-dk.dts b/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
index e718d888ce21..42894ba954cc 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
@@ -100,6 +100,30 @@ phy1_eth1: ethernet-phy@1 {
 	};
 };
 
+&risab1 {
+	status = "okay";
+};
+
+&risab2 {
+	status = "okay";
+};
+
+&risab3 {
+	status = "okay";
+};
+
+&risab4 {
+	status = "okay";
+};
+
+&risab5 {
+	status = "okay";
+};
+
+&risab6 {
+	status = "okay";
+};
+
 &scmi_regu {
 	scmi_vddio1: regulator@0 {
 		regulator-min-microvolt = <1800000>;

-- 
2.43.0

[PATCH 7/7] arm64: dts: st: enable all RISAB instances on the stm32mp235f-dk board

[Gatien Chevallier]

To be able to dump the RISAB configurations, enable all RISAB instances
on the stm32mp235f-dk board.

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp235f-dk.dts | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp235f-dk.dts b/arch/arm64/boot/dts/st/stm32mp235f-dk.dts
index c3e688068223..b76549b9f64b 100644
--- a/arch/arm64/boot/dts/st/stm32mp235f-dk.dts
+++ b/arch/arm64/boot/dts/st/stm32mp235f-dk.dts
@@ -100,6 +100,30 @@ phy1_eth1: ethernet-phy@1 {
 	};
 };
 
+&risab1 {
+	status = "okay";
+};
+
+&risab2 {
+	status = "okay";
+};
+
+&risab3 {
+	status = "okay";
+};
+
+&risab4 {
+	status = "okay";
+};
+
+&risab5 {
+	status = "okay";
+};
+
+&risab6 {
+	status = "okay";
+};
+
 &scmi_regu {
 	scmi_vddio1: regulator@0 {
 		regulator-min-microvolt = <1800000>;

-- 
2.43.0

Re: [PATCH 2/7] soc: st: add RISAB dump debug driver

[Krzysztof Kozlowski]

On 09/02/2026 15:59, Gatien Chevallier wrote:
> +
> +static int stm32_risab_register_debugfs(struct risab_pdata *pdata)
> +{
> +	struct dentry *root = NULL;
> +
> +	root = debugfs_lookup("stm32_firewall", NULL);
> +	if (!root)
> +		root = debugfs_create_dir("stm32_firewall", NULL);
> +
> +	if (IS_ERR(root))
> +		return PTR_ERR(root);
> +
> +	pdata->dbg_entry = debugfs_create_file(dev_name(pdata->dev), 0444,
> +					       root, pdata, &stm32_risab_conf_dump_fops);

soc drivers should not have any user-space interfaces. This was
requested by Arnd many times in the past, nothing new, including about
debugfs. Otherwise it opens cans of worms, because soc platform
maintainer can dump here whatever the subsystem rejected.

Find suitable subsystem and get its approval for such debugfs entry.

Your commit msg is so vague it is another reason this is not mergeable.
Explains nothing about the feature, nothing about the risk or impact on
the system when user does (while (1); read stm32_risab_conf_dump_fops).

Not mentioning that it does not explain WHY do we want this driver in
the first place...

Best regards,
Krzysztof

Re: [PATCH 3/7] arm64: dts: st: add RISAB1/2/3/4/5/6 nodes to stm32mp251.dtsi

[Krzysztof Kozlowski]

On 09/02/2026 15:59, Gatien Chevallier wrote:
> Add RISAB1/2/3/4/5/6 nodes to the stm32mp251.dtsi device tree SoC
> file.

And what is RISAB?

> 
> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
> ---
>  arch/arm64/boot/dts/st/stm32mp251.dtsi | 48 ++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
> index a8e6e0f77b83..e9d8338b2017 100644
> --- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
> +++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
> @@ -1733,6 +1733,54 @@ pcie@0,0 {
>  			};
>  		};
>  
> +		risab1: risab@420f0000 {

It appears here as node name as well, so it must be a generic name, but
I do not recall it in DT spec or my knowledge.

Best regards,
Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Krzysztof Kozlowski]

On 09/02/2026 15:59, Gatien Chevallier wrote:
> Add documentation on the RISAB peripheral that is a memory firewall on

What is RISAB? It's in capitals, so some sort of acronym?

> the stm32mp2x platforms.
> 
> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
> ---
>  .../bindings/soc/st/st,stm32mp25-risab.yaml        | 74 ++++++++++++++++++++++

soc is not a dumping ground. Find suitable subsystem for it.


>  MAINTAINERS                                        |  5 ++
>  2 files changed, 79 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml b/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml
> new file mode 100644
> index 000000000000..d05a683c594d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/st/st,stm32mp25-risab.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STM32 Resource isolation peripheral unit for address space protection
> +       (block-based)

So maybe here would be RISAB explanation... Use proper capital lettes in
the title (e.g. AP or Chicago style, I don't think we do any preference
or consistency, especially that most of us including myself don't even
know the difference).

> +
> +maintainers:
> +  - Gatien Chevallier <gatien.chevallier@foss.st.com>
> +
> +description:
> +  The RIF (resource isolation framework) is a comprehensive set of hardware
> +  blocks designed to enforce and manage isolation of STM32 hardware resources,
> +  like memory and peripherals. The RISAB peripheral is part of the RIF and is
> +  used to protect internal RAMs by applying access rights per RISAB fixed-size
> +  page. Through RISAB registers, a trusted domain, or the domain to whom the
> +  page configuration has been delegated, assigns memory pages to one or more
> +  security domains (secure, privilege, compartment).
> +
> +properties:
> +  compatible:
> +    const: st,stm32mp25-risab
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    items:
> +      - description: RISAB bus clock
> +
> +  memory-region:
> +    minItems: 1
> +    maxItems: 32
> +    description:
> +      Phandle to nodes describing memory regions to be configured in the RISAB
> +      by the trusted domain of at least a RISAB page size.
> +      These regions cannot overlap. A zone must be within st,mem-map range and
> +      can be represented by one or more pages.
> +
> +  st,mem-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description: Memory address range covered by the RISAB.
> +    items:
> +      - description: Memory range base address
> +      - description: Memory range size

Why do you need this property if you have memory-region already? This
also should be part of <reg>, although this mixing with memory-region is
anyway confusing.

> +
> +  st,srwiad:
> +    description:
> +      When set, the trusted domain configures the RISAB to allow secure
> +      read/write data accesses to non-secure blocks and pages. Secure execute
> +      remains illegal.
> +    type: boolean

Shouldn't this be a property of given block from memory-regions, not
entire RISAB?

> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - st,mem-map
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +
> +    risab1: risab@420f0000 {

Drop unused label.

> +        compatible = "st,stm32mp25-risab";
> +        reg = <0x420f0000 0x1000>;
> +        clocks = <&rcc CK_ICN_LS_MCU>;
> +        st,mem-map = <0xa000000 0x20000>;
> +        st,srwiad;
> +    };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e08767323763..b9a1276e94a9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25092,6 +25092,11 @@ F:	Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
>  F:	Documentation/devicetree/bindings/dma/stm32/
>  F:	drivers/dma/stm32/
>  
> +STM32 SoC FIREWALL DRIVERS

s/SoC/SOC/


Best regards,
Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Gatien CHEVALLIER]

On 2/10/26 08:57, Krzysztof Kozlowski wrote:
> On 09/02/2026 15:59, Gatien Chevallier wrote:
>> Add documentation on the RISAB peripheral that is a memory firewall on
> 
> What is RISAB? It's in capitals, so some sort of acronym?
> 

I'll add a small description as well in the commit message to justify
the acronym.

>> the stm32mp2x platforms.
>>
>> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
>> ---
>>   .../bindings/soc/st/st,stm32mp25-risab.yaml        | 74 ++++++++++++++++++++++
> 
> soc is not a dumping ground. Find suitable subsystem for it.
> 

Considering the RISAB filters bus accesses, I guess its place
is next to the RIFSC in drivers/bus. Plus, all stm32 firewalls
would be located at the same spot.

> 
>>   MAINTAINERS                                        |  5 ++
>>   2 files changed, 79 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml b/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml
>> new file mode 100644
>> index 000000000000..d05a683c594d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/st/st,stm32mp25-risab.yaml
>> @@ -0,0 +1,74 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/soc/st/st,stm32mp25-risab.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: STM32 Resource isolation peripheral unit for address space protection
>> +       (block-based)
> 
> So maybe here would be RISAB explanation... Use proper capital lettes in
> the title (e.g. AP or Chicago style, I don't think we do any preference
> or consistency, especially that most of us including myself don't even
> know the difference).
> 

It is the non-acronym version. Very well, I will change that for V2.

>> +
>> +maintainers:
>> +  - Gatien Chevallier <gatien.chevallier@foss.st.com>
>> +
>> +description:
>> +  The RIF (resource isolation framework) is a comprehensive set of hardware
>> +  blocks designed to enforce and manage isolation of STM32 hardware resources,
>> +  like memory and peripherals. The RISAB peripheral is part of the RIF and is
>> +  used to protect internal RAMs by applying access rights per RISAB fixed-size
>> +  page. Through RISAB registers, a trusted domain, or the domain to whom the
>> +  page configuration has been delegated, assigns memory pages to one or more
>> +  security domains (secure, privilege, compartment).
>> +
>> +properties:
>> +  compatible:
>> +    const: st,stm32mp25-risab
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    items:
>> +      - description: RISAB bus clock
>> +
>> +  memory-region:
>> +    minItems: 1
>> +    maxItems: 32
>> +    description:
>> +      Phandle to nodes describing memory regions to be configured in the RISAB
>> +      by the trusted domain of at least a RISAB page size.
>> +      These regions cannot overlap. A zone must be within st,mem-map range and
>> +      can be represented by one or more pages.
>> +
>> +  st,mem-map:
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    description: Memory address range covered by the RISAB.
>> +    items:
>> +      - description: Memory range base address
>> +      - description: Memory range size
> 
> Why do you need this property if you have memory-region already? This
> also should be part of <reg>, although this mixing with memory-region is
> anyway confusing.
> 

The RISAB is a memory firewall peripheral covering internal RAMs. It is
possible to configure multiple memory regions within these RAMs (done by
the Trusted Domain) with security, privilege and compartment isolation.
This peripheral allow 4kBytes page granularity. Each page can hold
different access rights, with 32 pages at most (hence the maxItems: 32).
That is some information that can be added to the documentation.

Moreover, when a region is delegated to a non-secure privileged
component, this component can configure the privilege level necessary to
access the region.

This property gives me the opportunity to get the memory range covered
by the RISAB. "reg" here is used to access the actual RISAB registers
holding the configuration.

>> +
>> +  st,srwiad:
>> +    description:
>> +      When set, the trusted domain configures the RISAB to allow secure
>> +      read/write data accesses to non-secure blocks and pages. Secure execute
>> +      remains illegal.
>> +    type: boolean
> 
> Shouldn't this be a property of given block from memory-regions, not
> entire RISAB?
> 

It is a global setting for the whole RISAB (in RISAB_CR register) so I
think it's fine keeping it at RISAB level.

>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - st,mem-map
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>> +
>> +    risab1: risab@420f0000 {
> 
> Drop unused label.
> 

Ack

Thanks,
Gatien

>> +        compatible = "st,stm32mp25-risab";
>> +        reg = <0x420f0000 0x1000>;
>> +        clocks = <&rcc CK_ICN_LS_MCU>;
>> +        st,mem-map = <0xa000000 0x20000>;
>> +        st,srwiad;
>> +    };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e08767323763..b9a1276e94a9 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -25092,6 +25092,11 @@ F:	Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
>>   F:	Documentation/devicetree/bindings/dma/stm32/
>>   F:	drivers/dma/stm32/
>>   
>> +STM32 SoC FIREWALL DRIVERS
> 
> s/SoC/SOC/
> 
> 
> Best regards,
> Krzysztof

Re: [PATCH 2/7] soc: st: add RISAB dump debug driver

[Gatien CHEVALLIER]

On 2/10/26 08:50, Krzysztof Kozlowski wrote:
> On 09/02/2026 15:59, Gatien Chevallier wrote:
>> +
>> +static int stm32_risab_register_debugfs(struct risab_pdata *pdata)
>> +{
>> +	struct dentry *root = NULL;
>> +
>> +	root = debugfs_lookup("stm32_firewall", NULL);
>> +	if (!root)
>> +		root = debugfs_create_dir("stm32_firewall", NULL);
>> +
>> +	if (IS_ERR(root))
>> +		return PTR_ERR(root);
>> +
>> +	pdata->dbg_entry = debugfs_create_file(dev_name(pdata->dev), 0444,
>> +					       root, pdata, &stm32_risab_conf_dump_fops);
> 
> soc drivers should not have any user-space interfaces. This was
> requested by Arnd many times in the past, nothing new, including about
> debugfs. Otherwise it opens cans of worms, because soc platform
> maintainer can dump here whatever the subsystem rejected.
> 
> Find suitable subsystem and get its approval for such debugfs entry.
> 
> Your commit msg is so vague it is another reason this is not mergeable.
> Explains nothing about the feature, nothing about the risk or impact on
> the system when user does (while (1); read stm32_risab_conf_dump_fops).
> 
> Not mentioning that it does not explain WHY do we want this driver in
> the first place...
> 
> Best regards,
> Krzysztof

My bad, I did not know that and only checked in the directory to see
that there were other debugfs entries in it.

You're right, it's too vague, I will develop the commit message in V2.

Best regards,
Gatien

Re: [PATCH 3/7] arm64: dts: st: add RISAB1/2/3/4/5/6 nodes to stm32mp251.dtsi

[Gatien CHEVALLIER]

On 2/10/26 08:51, Krzysztof Kozlowski wrote:
> On 09/02/2026 15:59, Gatien Chevallier wrote:
>> Add RISAB1/2/3/4/5/6 nodes to the stm32mp251.dtsi device tree SoC
>> file.
> 
> And what is RISAB?
> 
>>
>> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
>> ---
>>   arch/arm64/boot/dts/st/stm32mp251.dtsi | 48 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 48 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
>> index a8e6e0f77b83..e9d8338b2017 100644
>> --- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
>> +++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
>> @@ -1733,6 +1733,54 @@ pcie@0,0 {
>>   			};
>>   		};
>>   
>> +		risab1: risab@420f0000 {
> 
> It appears here as node name as well, so it must be a generic name, but
> I do not recall it in DT spec or my knowledge.
> 
> Best regards,
> Krzysztof

This will change as well.

Best regards,
Gatien

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Krzysztof Kozlowski]

On 10/02/2026 10:55, Gatien CHEVALLIER wrote:
>>> +  memory-region:
>>> +    minItems: 1
>>> +    maxItems: 32
>>> +    description:
>>> +      Phandle to nodes describing memory regions to be configured in the RISAB
>>> +      by the trusted domain of at least a RISAB page size.
>>> +      These regions cannot overlap. A zone must be within st,mem-map range and
>>> +      can be represented by one or more pages.
>>> +
>>> +  st,mem-map:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +    description: Memory address range covered by the RISAB.
>>> +    items:
>>> +      - description: Memory range base address
>>> +      - description: Memory range size
>>
>> Why do you need this property if you have memory-region already? This
>> also should be part of <reg>, although this mixing with memory-region is
>> anyway confusing.
>>
> 
> The RISAB is a memory firewall peripheral covering internal RAMs. It is
> possible to configure multiple memory regions within these RAMs (done by
> the Trusted Domain) with security, privilege and compartment isolation.
> This peripheral allow 4kBytes page granularity. Each page can hold
> different access rights, with 32 pages at most (hence the maxItems: 32).
> That is some information that can be added to the documentation.
> 
> Moreover, when a region is delegated to a non-secure privileged
> component, this component can configure the privilege level necessary to
> access the region.
> 
> This property gives me the opportunity to get the memory range covered
> by the RISAB. "reg" here is used to access the actual RISAB registers
> holding the configuration.

Looks awfully like memory regions still :/

> 
>>> +
>>> +  st,srwiad:
>>> +    description:
>>> +      When set, the trusted domain configures the RISAB to allow secure
>>> +      read/write data accesses to non-secure blocks and pages. Secure execute
>>> +      remains illegal.
>>> +    type: boolean
>>
>> Shouldn't this be a property of given block from memory-regions, not
>> entire RISAB?
>>
> 
> It is a global setting for the whole RISAB (in RISAB_CR register) so I
> think it's fine keeping it at RISAB level.

And in the next version of your IP? It really feels like description of
memory region, not the entire device.


Best regards,
Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Gatien CHEVALLIER]

On 2/13/26 16:06, Krzysztof Kozlowski wrote:
> On 10/02/2026 10:55, Gatien CHEVALLIER wrote:
>>>> +  memory-region:
>>>> +    minItems: 1
>>>> +    maxItems: 32
>>>> +    description:
>>>> +      Phandle to nodes describing memory regions to be configured in the RISAB
>>>> +      by the trusted domain of at least a RISAB page size.
>>>> +      These regions cannot overlap. A zone must be within st,mem-map range and
>>>> +      can be represented by one or more pages.
>>>> +
>>>> +  st,mem-map:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>> +    description: Memory address range covered by the RISAB.
>>>> +    items:
>>>> +      - description: Memory range base address
>>>> +      - description: Memory range size
>>>
>>> Why do you need this property if you have memory-region already? This
>>> also should be part of <reg>, although this mixing with memory-region is
>>> anyway confusing.
>>>
>>
>> The RISAB is a memory firewall peripheral covering internal RAMs. It is
>> possible to configure multiple memory regions within these RAMs (done by
>> the Trusted Domain) with security, privilege and compartment isolation.
>> This peripheral allow 4kBytes page granularity. Each page can hold
>> different access rights, with 32 pages at most (hence the maxItems: 32).
>> That is some information that can be added to the documentation.
>>
>> Moreover, when a region is delegated to a non-secure privileged
>> component, this component can configure the privilege level necessary to
>> access the region.
>>
>> This property gives me the opportunity to get the memory range covered
>> by the RISAB. "reg" here is used to access the actual RISAB registers
>> holding the configuration.
> 
> Looks awfully like memory regions still :/
> 

IIUC the memory-region property references memory regions within
a reserved memory. Which is not really what I want to describe
here as I want to get the boundaries of the whole range. The
memory-region property would be used by the Trusted Domain / kernel
to get each regions (or only one that represents the whole range) of the
internal RAM to apply desired access rights to them / use them.

Describing the memory range using a reserved memory would make the
kernel exclude this memory range from the normal usage, no?

I think declaring a "boundaries" memory region with no usage for the
kernel wouldn't make sense. The kernel may not be able to access the
whole memory range.

>>
>>>> +
>>>> +  st,srwiad:
>>>> +    description:
>>>> +      When set, the trusted domain configures the RISAB to allow secure
>>>> +      read/write data accesses to non-secure blocks and pages. Secure execute
>>>> +      remains illegal.
>>>> +    type: boolean
>>>
>>> Shouldn't this be a property of given block from memory-regions, not
>>> entire RISAB?
>>>
>>
>> It is a global setting for the whole RISAB (in RISAB_CR register) so I
>> think it's fine keeping it at RISAB level.
> 
> And in the next version of your IP? It really feels like description of
> memory region, not the entire device.
> 

Then I would expect it to be part of the page-based configuration and
this property could be constrained to current platforms. Is that fine?

Best regards,
Gatien

> 
> Best regards,
> Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Krzysztof Kozlowski]

On 17/02/2026 14:12, Gatien CHEVALLIER wrote:
> 
> 
> On 2/13/26 16:06, Krzysztof Kozlowski wrote:
>> On 10/02/2026 10:55, Gatien CHEVALLIER wrote:
>>>>> +  memory-region:
>>>>> +    minItems: 1
>>>>> +    maxItems: 32
>>>>> +    description:
>>>>> +      Phandle to nodes describing memory regions to be configured in the RISAB
>>>>> +      by the trusted domain of at least a RISAB page size.
>>>>> +      These regions cannot overlap. A zone must be within st,mem-map range and
>>>>> +      can be represented by one or more pages.
>>>>> +
>>>>> +  st,mem-map:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>> +    description: Memory address range covered by the RISAB.
>>>>> +    items:
>>>>> +      - description: Memory range base address
>>>>> +      - description: Memory range size
>>>>
>>>> Why do you need this property if you have memory-region already? This
>>>> also should be part of <reg>, although this mixing with memory-region is
>>>> anyway confusing.
>>>>
>>>
>>> The RISAB is a memory firewall peripheral covering internal RAMs. It is
>>> possible to configure multiple memory regions within these RAMs (done by
>>> the Trusted Domain) with security, privilege and compartment isolation.
>>> This peripheral allow 4kBytes page granularity. Each page can hold
>>> different access rights, with 32 pages at most (hence the maxItems: 32).
>>> That is some information that can be added to the documentation.
>>>
>>> Moreover, when a region is delegated to a non-secure privileged
>>> component, this component can configure the privilege level necessary to
>>> access the region.
>>>
>>> This property gives me the opportunity to get the memory range covered
>>> by the RISAB. "reg" here is used to access the actual RISAB registers
>>> holding the configuration.
>>
>> Looks awfully like memory regions still :/
>>
> 
> IIUC the memory-region property references memory regions within
> a reserved memory. Which is not really what I want to describe
> here as I want to get the boundaries of the whole range. The
> memory-region property would be used by the Trusted Domain / kernel
> to get each regions (or only one that represents the whole range) of the
> internal RAM to apply desired access rights to them / use them.
> 
> Describing the memory range using a reserved memory would make the
> kernel exclude this memory range from the normal usage, no?

In general yes, but also depends on the use case/drivers/purpose. I do
not understand why would you mark some memory for generic use by kernel
(so not reserved for specific purpose) and still configure it somehow
for trusted firmware to allow secure read/write access.

If you mark some part of memory as a meaning for TF for secure access,
you already claim it is not a generic memory. Otherwise TF just writes
all over malloced() pages?

> 
> I think declaring a "boundaries" memory region with no usage for the
> kernel wouldn't make sense. The kernel may not be able to access the
> whole memory range.

I don't understand that. reserved-memory is for cases with "no usage for
the kernel", so it would perfectly make sense.

Look what your description said:

"used to protect internal RAMs by applying access"

and

" a trusted domain, or the domain to whom the page configuration has
been delegated,"

so how it is not a dedicated, special memory delegated to specific
devices and/or TF?

Best regards,
Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Gatien CHEVALLIER]

On 2/17/26 21:06, Krzysztof Kozlowski wrote:
> On 17/02/2026 14:12, Gatien CHEVALLIER wrote:
>>
>>
>> On 2/13/26 16:06, Krzysztof Kozlowski wrote:
>>> On 10/02/2026 10:55, Gatien CHEVALLIER wrote:
>>>>>> +  memory-region:
>>>>>> +    minItems: 1
>>>>>> +    maxItems: 32
>>>>>> +    description:
>>>>>> +      Phandle to nodes describing memory regions to be configured in the RISAB
>>>>>> +      by the trusted domain of at least a RISAB page size.
>>>>>> +      These regions cannot overlap. A zone must be within st,mem-map range and
>>>>>> +      can be represented by one or more pages.
>>>>>> +
>>>>>> +  st,mem-map:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>>> +    description: Memory address range covered by the RISAB.
>>>>>> +    items:
>>>>>> +      - description: Memory range base address
>>>>>> +      - description: Memory range size
>>>>>
>>>>> Why do you need this property if you have memory-region already? This
>>>>> also should be part of <reg>, although this mixing with memory-region is
>>>>> anyway confusing.
>>>>>
>>>>
>>>> The RISAB is a memory firewall peripheral covering internal RAMs. It is
>>>> possible to configure multiple memory regions within these RAMs (done by
>>>> the Trusted Domain) with security, privilege and compartment isolation.
>>>> This peripheral allow 4kBytes page granularity. Each page can hold
>>>> different access rights, with 32 pages at most (hence the maxItems: 32).
>>>> That is some information that can be added to the documentation.
>>>>
>>>> Moreover, when a region is delegated to a non-secure privileged
>>>> component, this component can configure the privilege level necessary to
>>>> access the region.
>>>>
>>>> This property gives me the opportunity to get the memory range covered
>>>> by the RISAB. "reg" here is used to access the actual RISAB registers
>>>> holding the configuration.
>>>
>>> Looks awfully like memory regions still :/
>>>
>>
>> IIUC the memory-region property references memory regions within
>> a reserved memory. Which is not really what I want to describe
>> here as I want to get the boundaries of the whole range. The
>> memory-region property would be used by the Trusted Domain / kernel
>> to get each regions (or only one that represents the whole range) of the
>> internal RAM to apply desired access rights to them / use them.
>>
>> Describing the memory range using a reserved memory would make the
>> kernel exclude this memory range from the normal usage, no?
> 
> In general yes, but also depends on the use case/drivers/purpose. I do
> not understand why would you mark some memory for generic use by kernel
> (so not reserved for specific purpose) and still configure it somehow
> for trusted firmware to allow secure read/write access.
> 
> If you mark some part of memory as a meaning for TF for secure access,
> you already claim it is not a generic memory. Otherwise TF just writes
> all over malloced() pages?
> 

While the Trusted Domain applies the configuration, it is entirely
possible for the Trusted domain to give himself access to, let's say,
the first RISAB page to store whatever data, and give the rest to the
kernel. Actually, this is what we do to store OTP data mirrors
or DDR context and give the rest to the kernel or the co-processor.

Now, using internal RAM for generic use by the kernel is unlikely but
I have in mind the last firewall controller of the stm32mp2x platforms,
which is the RISAF. It has the same purpose as the RISAB but for
external memories. One protects the DDR so I do want DDR regions as
accessible for general use (memory node).

This property allows me to describe the boundaries of what is protected
without having to imply anything from frameworks about the regions as I
have no way of knowing what is accessible and what is not.

>>
>> I think declaring a "boundaries" memory region with no usage for the
>> kernel wouldn't make sense. The kernel may not be able to access the
>> whole memory range.
> 
> I don't understand that. reserved-memory is for cases with "no usage for
> the kernel", so it would perfectly make sense.

> 
> Look what your description said:
> 
> "used to protect internal RAMs by applying access"

Yes, access rights are applied by the Trusted Domain. These firewalls
are very flexible because access rights on secure and privilege levels
along with Compartment ID (SoC is divided into multiple compartments
holding a compartment ID) can be configured. Some bits of the
firewall configuration can also be delegated. e.g: When a memory
region is configured for privileged, non-secure access for the
cortex running Linux; then the kernel could reconfigure the
privilege level (unlikely but feasible).

It would be quite complex to explain the whole mechanism without
pointing to some documentation [1].

Anyway, access rights are applied, but access may very well be given to
the privileged non-secure compartment running the kernel. Meaning that
only the kernel can access such memory. Not the Trusted Domain, not the
user-space, not the co-processor.

So you could give some bits of internal RAM to the kernel for whatever
purpose you'd like (Storing particular data you want to keep in some
low-power mode, etc...).


[1]: https://wiki.st.com/stm32mpu/wiki/Resource_Isolation_Framework_overview

> 
> and
> 
> " a trusted domain, or the domain to whom the page configuration has
> been delegated,"
> 
> so how it is not a dedicated, special memory delegated to specific
> devices and/or TF?
> 

The memory is delegated to some contexts. These can be the processor
running Linux, a co-processor, some initiator ports of peripherals
having DMAs, etc...

> Best regards,
> Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Krzysztof Kozlowski]

On 18/02/2026 11:38, Gatien CHEVALLIER wrote:
> 
> 
> On 2/17/26 21:06, Krzysztof Kozlowski wrote:
>> On 17/02/2026 14:12, Gatien CHEVALLIER wrote:
>>>
>>>
>>> On 2/13/26 16:06, Krzysztof Kozlowski wrote:
>>>> On 10/02/2026 10:55, Gatien CHEVALLIER wrote:
>>>>>>> +  memory-region:
>>>>>>> +    minItems: 1
>>>>>>> +    maxItems: 32
>>>>>>> +    description:
>>>>>>> +      Phandle to nodes describing memory regions to be configured in the RISAB
>>>>>>> +      by the trusted domain of at least a RISAB page size.
>>>>>>> +      These regions cannot overlap. A zone must be within st,mem-map range and
>>>>>>> +      can be represented by one or more pages.
>>>>>>> +
>>>>>>> +  st,mem-map:
>>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>>>> +    description: Memory address range covered by the RISAB.
>>>>>>> +    items:
>>>>>>> +      - description: Memory range base address
>>>>>>> +      - description: Memory range size
>>>>>>
>>>>>> Why do you need this property if you have memory-region already? This
>>>>>> also should be part of <reg>, although this mixing with memory-region is
>>>>>> anyway confusing.
>>>>>>
>>>>>
>>>>> The RISAB is a memory firewall peripheral covering internal RAMs. It is
>>>>> possible to configure multiple memory regions within these RAMs (done by
>>>>> the Trusted Domain) with security, privilege and compartment isolation.
>>>>> This peripheral allow 4kBytes page granularity. Each page can hold
>>>>> different access rights, with 32 pages at most (hence the maxItems: 32).
>>>>> That is some information that can be added to the documentation.
>>>>>
>>>>> Moreover, when a region is delegated to a non-secure privileged
>>>>> component, this component can configure the privilege level necessary to
>>>>> access the region.
>>>>>
>>>>> This property gives me the opportunity to get the memory range covered
>>>>> by the RISAB. "reg" here is used to access the actual RISAB registers
>>>>> holding the configuration.
>>>>
>>>> Looks awfully like memory regions still :/
>>>>
>>>
>>> IIUC the memory-region property references memory regions within
>>> a reserved memory. Which is not really what I want to describe
>>> here as I want to get the boundaries of the whole range. The
>>> memory-region property would be used by the Trusted Domain / kernel
>>> to get each regions (or only one that represents the whole range) of the
>>> internal RAM to apply desired access rights to them / use them.
>>>
>>> Describing the memory range using a reserved memory would make the
>>> kernel exclude this memory range from the normal usage, no?
>>
>> In general yes, but also depends on the use case/drivers/purpose. I do
>> not understand why would you mark some memory for generic use by kernel
>> (so not reserved for specific purpose) and still configure it somehow
>> for trusted firmware to allow secure read/write access.
>>
>> If you mark some part of memory as a meaning for TF for secure access,
>> you already claim it is not a generic memory. Otherwise TF just writes
>> all over malloced() pages?
>>
> 
> While the Trusted Domain applies the configuration, it is entirely
> possible for the Trusted domain to give himself access to, let's say,
> the first RISAB page to store whatever data, and give the rest to the
> kernel. Actually, this is what we do to store OTP data mirrors

And what happens with the rest of that memory? Why the first page cannot
be the reserved region?

> or DDR context and give the rest to the kernel or the co-processor.
> 
> Now, using internal RAM for generic use by the kernel is unlikely but
> I have in mind the last firewall controller of the stm32mp2x platforms,
> which is the RISAF. It has the same purpose as the RISAB but for
> external memories. One protects the DDR so I do want DDR regions as
> accessible for general use (memory node).
> 
> This property allows me to describe the boundaries of what is protected
> without having to imply anything from frameworks about the regions as I
> have no way of knowing what is accessible and what is not.

Frameworks do not matter here - we don't even talk about them yet.

You want to describe boundaries of some dedicated memory region and you
should not have a custom property for that.

> 
>>>
>>> I think declaring a "boundaries" memory region with no usage for the
>>> kernel wouldn't make sense. The kernel may not be able to access the
>>> whole memory range.
>>
>> I don't understand that. reserved-memory is for cases with "no usage for
>> the kernel", so it would perfectly make sense.
> 
>>
>> Look what your description said:
>>
>> "used to protect internal RAMs by applying access"
> 
> Yes, access rights are applied by the Trusted Domain. These firewalls
> are very flexible because access rights on secure and privilege levels
> along with Compartment ID (SoC is divided into multiple compartments
> holding a compartment ID) can be configured. Some bits of the
> firewall configuration can also be delegated. e.g: When a memory
> region is configured for privileged, non-secure access for the
> cortex running Linux; then the kernel could reconfigure the
> privilege level (unlikely but feasible).
> 
> It would be quite complex to explain the whole mechanism without
> pointing to some documentation [1].
> 
> Anyway, access rights are applied, but access may very well be given to
> the privileged non-secure compartment running the kernel. Meaning that
> only the kernel can access such memory. Not the Trusted Domain, not the
> user-space, not the co-processor.

This implies that if you do not reserve such memory that way, then
Trusted Domain or user-space could just poke and use it...

If kernel explicitly has to tell TD to do something with specific region
of memory, this is somehow a reserved memory. It is distinctive,
special, selected, chosen.
> 
> So you could give some bits of internal RAM to the kernel for whatever
> purpose you'd like (Storing particular data you want to keep in some
> low-power mode, etc...).

All RAM is for that purpose...

> 
> 
> [1]: https://wiki.st.com/stm32mpu/wiki/Resource_Isolation_Framework_overview
> 
>>
>> and
>>
>> " a trusted domain, or the domain to whom the page configuration has
>> been delegated,"
>>
>> so how it is not a dedicated, special memory delegated to specific
>> devices and/or TF?
>>
> 
> The memory is delegated to some contexts. These can be the processor
> running Linux, a co-processor, some initiator ports of peripherals
> having DMAs, etc...
> 

So pretty close to what the purpose of reserved-memory is...

Well, we keep discussing and I am really not convinced. You can try to
catch @Rob tomorrow on IRC and maybe get his approval, but for me this
is clearly some sort of reserved memory thus you cannot go with own
bindings. Another way would be to prove me wrong by using the reserved
memory binding and showing how it could not possible work, ever (such
counter examples sometimes help to look at the problem from a new angle).

Best regards,
Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Gatien CHEVALLIER]

Hello Krzysztof,

On 2/18/26 21:03, Krzysztof Kozlowski wrote:
> On 18/02/2026 11:38, Gatien CHEVALLIER wrote:
>>
>>
>> On 2/17/26 21:06, Krzysztof Kozlowski wrote:
>>> On 17/02/2026 14:12, Gatien CHEVALLIER wrote:
>>>>
>>>>
>>>> On 2/13/26 16:06, Krzysztof Kozlowski wrote:
>>>>> On 10/02/2026 10:55, Gatien CHEVALLIER wrote:
>>>>>>>> +  memory-region:
>>>>>>>> +    minItems: 1
>>>>>>>> +    maxItems: 32
>>>>>>>> +    description:
>>>>>>>> +      Phandle to nodes describing memory regions to be configured in the RISAB
>>>>>>>> +      by the trusted domain of at least a RISAB page size.
>>>>>>>> +      These regions cannot overlap. A zone must be within st,mem-map range and
>>>>>>>> +      can be represented by one or more pages.
>>>>>>>> +
>>>>>>>> +  st,mem-map:
>>>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>>>>> +    description: Memory address range covered by the RISAB.
>>>>>>>> +    items:
>>>>>>>> +      - description: Memory range base address
>>>>>>>> +      - description: Memory range size
>>>>>>>
>>>>>>> Why do you need this property if you have memory-region already? This
>>>>>>> also should be part of <reg>, although this mixing with memory-region is
>>>>>>> anyway confusing.
>>>>>>>
>>>>>>
>>>>>> The RISAB is a memory firewall peripheral covering internal RAMs. It is
>>>>>> possible to configure multiple memory regions within these RAMs (done by
>>>>>> the Trusted Domain) with security, privilege and compartment isolation.
>>>>>> This peripheral allow 4kBytes page granularity. Each page can hold
>>>>>> different access rights, with 32 pages at most (hence the maxItems: 32).
>>>>>> That is some information that can be added to the documentation.
>>>>>>
>>>>>> Moreover, when a region is delegated to a non-secure privileged
>>>>>> component, this component can configure the privilege level necessary to
>>>>>> access the region.
>>>>>>
>>>>>> This property gives me the opportunity to get the memory range covered
>>>>>> by the RISAB. "reg" here is used to access the actual RISAB registers
>>>>>> holding the configuration.
>>>>>
>>>>> Looks awfully like memory regions still :/
>>>>>
>>>>
>>>> IIUC the memory-region property references memory regions within
>>>> a reserved memory. Which is not really what I want to describe
>>>> here as I want to get the boundaries of the whole range. The
>>>> memory-region property would be used by the Trusted Domain / kernel
>>>> to get each regions (or only one that represents the whole range) of the
>>>> internal RAM to apply desired access rights to them / use them.
>>>>
>>>> Describing the memory range using a reserved memory would make the
>>>> kernel exclude this memory range from the normal usage, no?
>>>
>>> In general yes, but also depends on the use case/drivers/purpose. I do
>>> not understand why would you mark some memory for generic use by kernel
>>> (so not reserved for specific purpose) and still configure it somehow
>>> for trusted firmware to allow secure read/write access.
>>>
>>> If you mark some part of memory as a meaning for TF for secure access,
>>> you already claim it is not a generic memory. Otherwise TF just writes
>>> all over malloced() pages?
>>>
>>
>> While the Trusted Domain applies the configuration, it is entirely
>> possible for the Trusted domain to give himself access to, let's say,
>> the first RISAB page to store whatever data, and give the rest to the
>> kernel. Actually, this is what we do to store OTP data mirrors
> 
> And what happens with the rest of that memory? Why the first page cannot
> be the reserved region?
> 

First page should be a reserved memory. As the rest should be. Maybe we
have misunderstood each other here.

>> or DDR context and give the rest to the kernel or the co-processor.
>>
>> Now, using internal RAM for generic use by the kernel is unlikely but
>> I have in mind the last firewall controller of the stm32mp2x platforms,
>> which is the RISAF. It has the same purpose as the RISAB but for
>> external memories. One protects the DDR so I do want DDR regions as
>> accessible for general use (memory node).
>>
>> This property allows me to describe the boundaries of what is protected
>> without having to imply anything from frameworks about the regions as I
>> have no way of knowing what is accessible and what is not.
> 
> Frameworks do not matter here - we don't even talk about them yet.
> 
> You want to describe boundaries of some dedicated memory region and you
> should not have a custom property for that.
> 
>>
>>>>
>>>> I think declaring a "boundaries" memory region with no usage for the
>>>> kernel wouldn't make sense. The kernel may not be able to access the
>>>> whole memory range.
>>>
>>> I don't understand that. reserved-memory is for cases with "no usage for
>>> the kernel", so it would perfectly make sense.
>>
>>>
>>> Look what your description said:
>>>
>>> "used to protect internal RAMs by applying access"
>>
>> Yes, access rights are applied by the Trusted Domain. These firewalls
>> are very flexible because access rights on secure and privilege levels
>> along with Compartment ID (SoC is divided into multiple compartments
>> holding a compartment ID) can be configured. Some bits of the
>> firewall configuration can also be delegated. e.g: When a memory
>> region is configured for privileged, non-secure access for the
>> cortex running Linux; then the kernel could reconfigure the
>> privilege level (unlikely but feasible).
>>
>> It would be quite complex to explain the whole mechanism without
>> pointing to some documentation [1].
>>
>> Anyway, access rights are applied, but access may very well be given to
>> the privileged non-secure compartment running the kernel. Meaning that
>> only the kernel can access such memory. Not the Trusted Domain, not the
>> user-space, not the co-processor.
> 
> This implies that if you do not reserve such memory that way, then
> Trusted Domain or user-space could just poke and use it...
> 
> If kernel explicitly has to tell TD to do something with specific region
> of memory, this is somehow a reserved memory. It is distinctive,
> special, selected, chosen.
>>
>> So you could give some bits of internal RAM to the kernel for whatever
>> purpose you'd like (Storing particular data you want to keep in some
>> low-power mode, etc...).
> 
> All RAM is for that purpose...
> 

Not really, some RAMs can be powered off during some low-power modes.

>>
>>
>> [1]: https://wiki.st.com/stm32mpu/wiki/Resource_Isolation_Framework_overview
>>
>>>
>>> and
>>>
>>> " a trusted domain, or the domain to whom the page configuration has
>>> been delegated,"
>>>
>>> so how it is not a dedicated, special memory delegated to specific
>>> devices and/or TF?
>>>
>>
>> The memory is delegated to some contexts. These can be the processor
>> running Linux, a co-processor, some initiator ports of peripherals
>> having DMAs, etc...
>>
> 
> So pretty close to what the purpose of reserved-memory is...
> 
> Well, we keep discussing and I am really not convinced. You can try to
> catch @Rob tomorrow on IRC and maybe get his approval, but for me this
> is clearly some sort of reserved memory thus you cannot go with own
> bindings. Another way would be to prove me wrong by using the reserved
> memory binding and showing how it could not possible work, ever (such
> counter examples sometimes help to look at the problem from a new angle).
> 

Sure, good suggestion, let me state why I think a dedicated property is
preferred for those peripherals. For this part, I will take into account
the RISABs and also the RISAF mentioned previously. The RISAF kind of
works the same but protects external memories such as the DDR.

Just a small reintroduction of the issue:
We need to provide three sets of information to the drivers of RISAx:
- The registers of the RISAx device, handled through property "reg"
- The global range of memory addresses protected by the RISAx devices
(currently through the custom property "st,mem-map")
- Each individual memory range protected, handled through property
"memory-region" that points to children of "/reserved-memory". Memory
regions may not cover the whole range covered by the RISAx.

To replace the custom property, I have explored a few ways:

1) Describe the memory range covered by the memory firewall as a
reserved memory: Cannot be done because, for the memory firewall
covering the DDR, the reserved memory would overlap with the memory
node used to describe the memory available for regular kernel use.
The memory node represents part of the DDR in that case.

	memory@80000000 {
		device_type = "memory";
		reg = <0x0 0x80000000 0x1 0x0>;
	};

	reserved-memory {
		#address-cells = <2>;
		#size-cells = <2>;
		ranges;

		risaf_range: risaf-range@80000000 {
			reg = <0x0 0x80000000 0x0 0x80000000>;
			no-map;
		};
	}

Overlapping is not permitted, nor hierarchies of such regions.

2) Use, as for some Quad/Octo-spi or PCIE drivers, two regs. One for
the peripheral register and one for the memory range covered. Cannot be
done as the reg cannot be out of the SoC range. E.g, on stm32mp2
platforms, the SoC node range is 0x00000000 -> 0x80000000 and the
DDR is 0x80000000 -> 0x<Depends on DDR density>. So the peripheral
would be under the SoC node and the memory it covers (DDR) would be
out of range. It would require an artificial extension of the range
creating potential undesired effects

3) Use the ranges property: cannot be done because of the same SoC
range reason.

Therefore, I still think having a dedicated property is the best
option, but I'm ready to evaluate other suggestions.

Best regards,
Gatien


> Best regards,
> Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Krzysztof Kozlowski]

On 19/02/2026 15:02, Gatien CHEVALLIER wrote:
> Just a small reintroduction of the issue:
> We need to provide three sets of information to the drivers of RISAx:
> - The registers of the RISAx device, handled through property "reg"
> - The global range of memory addresses protected by the RISAx devices
> (currently through the custom property "st,mem-map")
> - Each individual memory range protected, handled through property
> "memory-region" that points to children of "/reserved-memory". Memory
> regions may not cover the whole range covered by the RISAx.
> 
> To replace the custom property, I have explored a few ways:
> 
> 1) Describe the memory range covered by the memory firewall as a
> reserved memory: Cannot be done because, for the memory firewall
> covering the DDR, the reserved memory would overlap with the memory
> node used to describe the memory available for regular kernel use.
> The memory node represents part of the DDR in that case.

But isn't this the entire point of RISAB on main system memory? You want
to mark part of system memory one way or another. And now you say that
overlapping would be a problem.

You do understand you do not have to reserve the memory, right? You are
doing only your specific mapping for that region.

> 
> 	memory@80000000 {
> 		device_type = "memory";
> 		reg = <0x0 0x80000000 0x1 0x0>;
> 	};
> 
> 	reserved-memory {
> 		#address-cells = <2>;
> 		#size-cells = <2>;
> 		ranges;
> 
> 		risaf_range: risaf-range@80000000 {

There is no compatible here...

> 			reg = <0x0 0x80000000 0x0 0x80000000>;
> 			no-map;

And why no-mapping? Isn't the point of the block is to have it as main
system memory?

> 		};
> 	}
> 



Best regards,
Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Gatien CHEVALLIER]

On 2/26/26 19:13, Krzysztof Kozlowski wrote:
> On 19/02/2026 15:02, Gatien CHEVALLIER wrote:
>> Just a small reintroduction of the issue:
>> We need to provide three sets of information to the drivers of RISAx:
>> - The registers of the RISAx device, handled through property "reg"
>> - The global range of memory addresses protected by the RISAx devices
>> (currently through the custom property "st,mem-map")
>> - Each individual memory range protected, handled through property
>> "memory-region" that points to children of "/reserved-memory". Memory
>> regions may not cover the whole range covered by the RISAx.
>>
>> To replace the custom property, I have explored a few ways:
>>
>> 1) Describe the memory range covered by the memory firewall as a
>> reserved memory: Cannot be done because, for the memory firewall
>> covering the DDR, the reserved memory would overlap with the memory
>> node used to describe the memory available for regular kernel use.
>> The memory node represents part of the DDR in that case.
> 
> But isn't this the entire point of RISAB on main system memory? You want
> to mark part of system memory one way or another. And now you say that
> overlapping would be a problem.
> 

Hello Krzysztof,

I explored a bit more the possible usage of a memory region to describe
the range covered by the RISAB/F peripherals.

To describe both the range covered by the memory firewall using a memory
region, I would need to have such node at SoC DT level:

  	reserved-memory {
  		#address-cells = <2>;
		#size-cells = <2>;
		ranges;

		/* Range covered by RISAF/B */
  		ddr: ddr@80000000 {
  			reg = <0x0 0x80000000 0x1 0x00000000>;
  		};
	};

The RISAF/B peripherals need to reference memory regions contained in
the range of the memory it protects in order to apply access rights
to these region's ranges appropriately. Therefore, adding regions like:

		tfm_code: tfm-code@80000000 {
			reg = <0x0 0x80000000 0x0 0x100000>;
			no-map;
		};

		cm33_cube_fw: cm33-cube-fw@80100000 {
			reg = <0x0 0x80100000 0x0 0x800000>;
			no-map;
		};

		tfm_data: tfm-data@80900000 {
			reg = <0x0 0x80900000 0x0 0x100000>;
			no-map;
		};
		...

at board level. These are regions that can or cannot be accessed
by the Linux kernel, depending on the access rights. Proceeding like
this would also force the usage of memory-region-names to be able to
differentiate the Range node from the actual memory regions. The
RISAF/B node would look like:

		risaf4: risaf@420d0000 {
			compatible = "st,stm32mp25-risaf-enc";
			reg = <0x420d0000 0x1000>;
			clocks = <&rcc CK_BUS_RISAF4>;
			memory-region = <&ddr>, <&tfm_code>, <&cm33_cube_fw>, <&tfm_data>
			memory-region-names = "range", "tfm-code", ...
		};

Notice that the tfm_code region here share the same base address
as the node used to describe the range covered. This would result
in the following error from DTC:

xxx.dtsi:109.21-112.5: Warning (unique_unit_address_if_enabled): 
/reserved-memory/ddr@80000000: duplicate unit-address (also used in node 
/reserved-memory/tfm-code@80000000).

In order to use it that way, I would need to force-keep the ddr node
disabled at all time and use it only to extract the reg it describes.
Which feels weird to have a node that can never be enabled.

Also note that, for our ecosystem, these 0x80000000 -> 0x84000000
regions are inaccessible so it was simplified to (I'd prefer to
describe them all BTW):

		fw@80000000 {
			compatible = "shared-dma-pool";
			reg = <0x0 0x80000000 0x0 0x4000000>;
			no-map;
		};

at board level (e.g: arch/arm64/boot/dts/st/stm32mp257f-ev1.dts).
That is completely up to the user to define its memory mapping and its
access rights per-region. One could use the lower DDR for some other
usage.

> You do understand you do not have to reserve the memory, right? You are
> doing only your specific mapping for that region.
> 

Yes, understood.

>>
>> 	memory@80000000 {
>> 		device_type = "memory";
>> 		reg = <0x0 0x80000000 0x1 0x0>;
>> 	};
>>
>> 	reserved-memory {
>> 		#address-cells = <2>;
>> 		#size-cells = <2>;
>> 		ranges;
>>
>> 		risaf_range: risaf-range@80000000 {
> 
> There is no compatible here...

There's no need for a compatible for a reserved memory?

> 
>> 			reg = <0x0 0x80000000 0x0 0x80000000>;
>> 			no-map;
> 
> And why no-mapping? Isn't the point of the block is to have it as main
> system memory?
Main system memory is described using the memory node:

	memory@80000000 {
		device_type = "memory";
		reg = <0x0 0x80000000 0x1 0x0>;
	};

this one is used to describe the possible memory range covered by the
RISAF, which can be superior to the DDR size depending on the choice of
the user for it's DDR, so we shouldn't map this region.

As stated before, I need a way to describe the range covered by the 
RISAB/F, which may not reflect what memory can be used or not by the
current execution context. Hence using a proprietary property to avoid
confusion in the DT and simplifying what is the range covered and what
are the memory region actually configured.

Best regards,
Gatien

> 
>> 		};
>> 	}
>>
> 
> 
> 
> Best regards,
> Krzysztof

Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral

[Gatien CHEVALLIER]

Hello,

I am changing employer so I will not longer be able to work on this
topic. Antonio Borneo (added in To:) will take over this and I fully
authorize him to rework the patches as he wishes while keeping/removing
my signed-off.

I'll make another patch on top of stm32 next branch to update my
email address in the MAINTAINERS file for the rest to keep an eye
on it.

Best regards,
Gatien

On 3/2/26 16:09, Gatien CHEVALLIER wrote:
> 
> 
> On 2/26/26 19:13, Krzysztof Kozlowski wrote:
>> On 19/02/2026 15:02, Gatien CHEVALLIER wrote:
>>> Just a small reintroduction of the issue:
>>> We need to provide three sets of information to the drivers of RISAx:
>>> - The registers of the RISAx device, handled through property "reg"
>>> - The global range of memory addresses protected by the RISAx devices
>>> (currently through the custom property "st,mem-map")
>>> - Each individual memory range protected, handled through property
>>> "memory-region" that points to children of "/reserved-memory". Memory
>>> regions may not cover the whole range covered by the RISAx.
>>>
>>> To replace the custom property, I have explored a few ways:
>>>
>>> 1) Describe the memory range covered by the memory firewall as a
>>> reserved memory: Cannot be done because, for the memory firewall
>>> covering the DDR, the reserved memory would overlap with the memory
>>> node used to describe the memory available for regular kernel use.
>>> The memory node represents part of the DDR in that case.
>>
>> But isn't this the entire point of RISAB on main system memory? You want
>> to mark part of system memory one way or another. And now you say that
>> overlapping would be a problem.
>>
> 
> Hello Krzysztof,
> 
> I explored a bit more the possible usage of a memory region to describe
> the range covered by the RISAB/F peripherals.
> 
> To describe both the range covered by the memory firewall using a memory
> region, I would need to have such node at SoC DT level:
> 
>       reserved-memory {
>           #address-cells = <2>;
>          #size-cells = <2>;
>          ranges;
> 
>          /* Range covered by RISAF/B */
>           ddr: ddr@80000000 {
>               reg = <0x0 0x80000000 0x1 0x00000000>;
>           };
>      };
> 
> The RISAF/B peripherals need to reference memory regions contained in
> the range of the memory it protects in order to apply access rights
> to these region's ranges appropriately. Therefore, adding regions like:
> 
>          tfm_code: tfm-code@80000000 {
>              reg = <0x0 0x80000000 0x0 0x100000>;
>              no-map;
>          };
> 
>          cm33_cube_fw: cm33-cube-fw@80100000 {
>              reg = <0x0 0x80100000 0x0 0x800000>;
>              no-map;
>          };
> 
>          tfm_data: tfm-data@80900000 {
>              reg = <0x0 0x80900000 0x0 0x100000>;
>              no-map;
>          };
>          ...
> 
> at board level. These are regions that can or cannot be accessed
> by the Linux kernel, depending on the access rights. Proceeding like
> this would also force the usage of memory-region-names to be able to
> differentiate the Range node from the actual memory regions. The
> RISAF/B node would look like:
> 
>          risaf4: risaf@420d0000 {
>              compatible = "st,stm32mp25-risaf-enc";
>              reg = <0x420d0000 0x1000>;
>              clocks = <&rcc CK_BUS_RISAF4>;
>              memory-region = <&ddr>, <&tfm_code>, <&cm33_cube_fw>, 
> <&tfm_data>
>              memory-region-names = "range", "tfm-code", ...
>          };
> 
> Notice that the tfm_code region here share the same base address
> as the node used to describe the range covered. This would result
> in the following error from DTC:
> 
> xxx.dtsi:109.21-112.5: Warning (unique_unit_address_if_enabled): / 
> reserved-memory/ddr@80000000: duplicate unit-address (also used in 
> node /reserved-memory/tfm-code@80000000).
> 
> In order to use it that way, I would need to force-keep the ddr node
> disabled at all time and use it only to extract the reg it describes.
> Which feels weird to have a node that can never be enabled.
> 
> Also note that, for our ecosystem, these 0x80000000 -> 0x84000000
> regions are inaccessible so it was simplified to (I'd prefer to
> describe them all BTW):
> 
>          fw@80000000 {
>              compatible = "shared-dma-pool";
>              reg = <0x0 0x80000000 0x0 0x4000000>;
>              no-map;
>          };
> 
> at board level (e.g: arch/arm64/boot/dts/st/stm32mp257f-ev1.dts).
> That is completely up to the user to define its memory mapping and its
> access rights per-region. One could use the lower DDR for some other
> usage.
> 
>> You do understand you do not have to reserve the memory, right? You are
>> doing only your specific mapping for that region.
>>
> 
> Yes, understood.
> 
>>>
>>>     memory@80000000 {
>>>         device_type = "memory";
>>>         reg = <0x0 0x80000000 0x1 0x0>;
>>>     };
>>>
>>>     reserved-memory {
>>>         #address-cells = <2>;
>>>         #size-cells = <2>;
>>>         ranges;
>>>
>>>         risaf_range: risaf-range@80000000 {
>>
>> There is no compatible here...
> 
> There's no need for a compatible for a reserved memory?
> 
>>
>>>             reg = <0x0 0x80000000 0x0 0x80000000>;
>>>             no-map;
>>
>> And why no-mapping? Isn't the point of the block is to have it as main
>> system memory?
> Main system memory is described using the memory node:
> 
>      memory@80000000 {
>          device_type = "memory";
>          reg = <0x0 0x80000000 0x1 0x0>;
>      };
> 
> this one is used to describe the possible memory range covered by the
> RISAF, which can be superior to the DDR size depending on the choice of
> the user for it's DDR, so we shouldn't map this region.
> 
> As stated before, I need a way to describe the range covered by the 
> RISAB/F, which may not reflect what memory can be used or not by the
> current execution context. Hence using a proprietary property to avoid
> confusion in the DT and simplifying what is the range covered and what
> are the memory region actually configured.
> 
> Best regards,
> Gatien
> 
>>
>>>         };
>>>     }
>>>
>>
>>
>>
>> Best regards,
>> Krzysztof
>