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

[Gatien CHEVALLIER <gatien.chevallier@foss.st.com>]

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