[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 at 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 at 80000000 {
>              reg = <0x0 0x80000000 0x0 0x100000>;
>              no-map;
>          };
> 
>          cm33_cube_fw: cm33-cube-fw at 80100000 {
>              reg = <0x0 0x80100000 0x0 0x800000>;
>              no-map;
>          };
> 
>          tfm_data: tfm-data at 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 at 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 at 80000000: duplicate unit-address (also used in 
> node /reserved-memory/tfm-code at 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 at 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 at 80000000 {
>>>         device_type = "memory";
>>>         reg = <0x0 0x80000000 0x1 0x0>;
>>>     };
>>>
>>>     reserved-memory {
>>>         #address-cells = <2>;
>>>         #size-cells = <2>;
>>>         ranges;
>>>
>>>         risaf_range: risaf-range at 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 at 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
>