From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH 2/4] ARM: sm: fix repeated call to of_add_reserve_entry on every fixup
Date: Wed, 21 Jan 2026 12:36:47 +0100 [thread overview]
Message-ID: <20260121113738.1485637-2-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20260121113738.1485637-1-a.fatoum@pengutronix.de>
A fixup can be applied arbitrarily often through boot fallback, dry runs
or of_diff command runs.
There's no need to add the reserve entry at fixup time, so just add it
in sm_init.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
arch/arm/cpu/sm.c | 36 +++++++++++-------------------------
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/arch/arm/cpu/sm.c b/arch/arm/cpu/sm.c
index 53f5142b63f9..a7edd9f565c2 100644
--- a/arch/arm/cpu/sm.c
+++ b/arch/arm/cpu/sm.c
@@ -185,30 +185,6 @@ int armv7_secure_monitor_install(void)
return 0;
}
-/*
- * of_secure_monitor_fixup - reserve memory region for secure monitor
- *
- * We currently do not support putting the secure monitor into onchip RAM,
- * hence it runs in SDRAM and we must reserve the memory region so that we
- * won't get overwritten from the Kernel.
- * Beware: despite the name this is not secure in any way. The Kernel obeys
- * the reserve map, but only because it's nice. It could always overwrite the
- * secure monitor and hijack secure mode.
- */
-static int of_secure_monitor_fixup(struct device_node *root, void *unused)
-{
- unsigned long res_start, res_end;
-
- res_start = (unsigned long)_stext;
- res_end = (unsigned long)__bss_stop;
-
- of_add_reserve_entry(res_start, res_end);
-
- pr_debug("Reserved memory range from 0x%08lx to 0x%08lx\n", res_start, res_end);
-
- return 0;
-}
-
static enum arm_security_state bootm_secure_state;
static const char * const bootm_secure_state_names[] = {
@@ -229,7 +205,17 @@ const char *bootm_arm_security_state_name(enum arm_security_state state)
static int sm_init(void)
{
- of_register_fixup(of_secure_monitor_fixup, NULL);
+ /*
+ * Reserve memory region for secure monitor
+ *
+ * We currently do not support putting the secure monitor into onchip RAM,
+ * hence it runs in SDRAM and we must reserve the memory region so that we
+ * won't get overwritten from the Kernel.
+ * Beware: despite the name this is not secure in any way. The Kernel obeys
+ * the reserve map, but only because it's nice. It could always overwrite the
+ * secure monitor and hijack secure mode.
+ */
+ of_add_reserve_entry((ulong)_stext, (ulong)__bss_stop);
globalvar_add_simple_enum("bootm.secure_state",
(unsigned int *)&bootm_secure_state,
--
2.47.3
next prev parent reply other threads:[~2026-01-21 11:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 11:36 [PATCH 1/4] of: fdt: implement of_del_reserve_entry Ahmad Fatoum
2026-01-21 11:36 ` Ahmad Fatoum [this message]
2026-01-21 11:36 ` [PATCH 3/4] bootm: delete initrd reserve entry on bootm_boot return Ahmad Fatoum
2026-01-21 11:36 ` [PATCH 4/4] video: stmfb: add screen base only once Ahmad Fatoum
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=20260121113738.1485637-2-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.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