[PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
mateusz.nowicki at posteo.net
mateusz.nowicki at posteo.net
Sat Oct 31 05:00:27 PDT 2026
Hi Arnd, Marek,
On Sat, Oct 31, 2026, Arnd Bergmann wrote:
> I think for the kernel it's pretty clear, we have to revert it
> to avoid the regression on old firmware, at least for boards
> that have ever shipped with that version. I count eight boards
> for stm32mp2 in upstream Linux, do we know how many of them
> are affected by the ABI break?
As the author of the patch, I looked at where both IDs come from.
0xb200005a only ever matched ST's *downstream* OP-TEE 3.19.0-stm32mp,
the base of the first OpenSTLinux releases for stm32mp25 (last update
2024-11-25). No *upstream* OP-TEE release ever used it on stm32mp2.
0xbc000000 is used by:
- ST's downstream OP-TEE since 4.0.0-stm32mp-r1 (2024-11-04), the base
of the current OpenSTLinux releases, up to 4.8.0-stm32mp-r1
(2026-10-27)
- upstream OP-TEE since 4.8.0 (2025-10-24), commit 11d68b6754
("plat-stm32mp2: enable watchdog SMC service"). Before 4.8.0
upstream OP-TEE has no watchdog SMC service on stm32mp2 at all.
On the Linux side:
- 89fca38168c9 (v6.7, 2023-09) added the node with 0xb200005a, which
matched the 3.19 based firmware of that time.
- 7a57b1bb1afb and e9b03ef21386 (v6.15, 2025-03) added stm32mp21 with
0xbc000000 and stm32mp23 with 0xb200005a on the same day.
- ae4d08bbe3f4 (v7.4 merge window) moved stm32mp23 and stm32mp25 to
0xbc000000.
So from v6.7 to v7.3 the watchdog never worked with upstream OP-TEE,
nor with ST's own firmware since November 2024: arm_smc_wdt fails to
probe with -EIO and an IWDG started by the boot loader is never
refreshed. That is how I found it on a STM32MP257F-DK with upstream
OP-TEE 4.10.
A revert would move the breakage to everybody running current
firmware. For stm32mp23 there is nothing to restore: ST's OP-TEE
supports stm32mp21 and stm32mp23 only since 4.0.0-stm32mp, so
0xb200005a never matched any stm32mp23 firmware.
About the boards: arm_wdt is enabled on all eight.
- stm32mp215f-dk is not affected, stm32mp211.dtsi always had
0xbc000000.
- stm32mp235f-dk and stm32mp23xx-dhcos-bb can only run firmware with
0xbc000000.
- That leaves the stm32mp25 boards: stm32mp257f-dk, stm32mp257f-ev1,
stm32mp257d-engicam-microgea-rmm, stm32mp255c-dhcos-dhsbc and
stm32mp25xx-dhcos-bb. Only those still shipping a 3.19 based OP-TEE
need the old ID.
So I would suggest the opposite direction: keep 0xbc000000 in the SoC
dtsi, which matches upstream OP-TEE and current ST firmware, and let
the boards that shipped with the old firmware override it in their
board dts:
&arm_wdt {
arm,smc-id = <0xb200005a>;
};
Marek, would that work for the DHCOS boards? I can send the patch if
you tell me which of them ship the old OP-TEE. Your OP-TEE change to
accept both IDs is a good mitigation on top of it for anybody who
updates the firmware.
Best regards,
Mateusz
More information about the linux-arm-kernel
mailing list