[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