The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Gatien CHEVALLIER <gatien.chevallier@foss.st.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral
Date: Thu, 26 Feb 2026 19:13:19 +0100	[thread overview]
Message-ID: <ae9962a4-b611-46e0-b124-5910e8708a20@kernel.org> (raw)
In-Reply-To: <b535dfd6-e4a6-4831-a868-c152574144c8@foss.st.com>

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

  reply	other threads:[~2026-02-26 18:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-09 14:59 [PATCH 0/7] soc: st: add RISAB dump debug driver Gatien Chevallier
2026-02-09 14:59 ` [PATCH 1/7] dt-bindings: soc: st: document the RISAB firewall peripheral Gatien Chevallier
2026-02-10  7:57   ` Krzysztof Kozlowski
2026-02-10  9:55     ` Gatien CHEVALLIER
2026-02-13 15:06       ` Krzysztof Kozlowski
2026-02-17 13:12         ` Gatien CHEVALLIER
2026-02-17 20:06           ` Krzysztof Kozlowski
2026-02-18 10:38             ` Gatien CHEVALLIER
2026-02-18 20:03               ` Krzysztof Kozlowski
2026-02-19 14:02                 ` Gatien CHEVALLIER
2026-02-26 18:13                   ` Krzysztof Kozlowski [this message]
2026-03-02 15:09                     ` Gatien CHEVALLIER
2026-03-06  8:33                       ` Gatien CHEVALLIER
2026-02-09 14:59 ` [PATCH 2/7] soc: st: add RISAB dump debug driver Gatien Chevallier
2026-02-10  7:50   ` Krzysztof Kozlowski
2026-02-10  9:57     ` Gatien CHEVALLIER
2026-02-09 14:59 ` [PATCH 3/7] arm64: dts: st: add RISAB1/2/3/4/5/6 nodes to stm32mp251.dtsi Gatien Chevallier
2026-02-10  7:51   ` Krzysztof Kozlowski
2026-02-10  9:58     ` Gatien CHEVALLIER
2026-02-09 14:59 ` [PATCH 4/7] arm64: dts: st: add RISAB1/2/3/4/5/6 nodes to stm32mp231.dtsi Gatien Chevallier
2026-02-09 14:59 ` [PATCH 5/7] arm64: dts: st: enable all RISAB instances on the stm32mp257f-ev1 board Gatien Chevallier
2026-02-09 14:59 ` [PATCH 6/7] arm64: dts: st: enable all RISAB instances on the stm32mp257f-dk board Gatien Chevallier
2026-02-09 14:59 ` [PATCH 7/7] arm64: dts: st: enable all RISAB instances on the stm32mp235f-dk board Gatien Chevallier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae9962a4-b611-46e0-b124-5910e8708a20@kernel.org \
    --to=krzk@kernel.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gatien.chevallier@foss.st.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox