mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
@ 2026-09-07  9:14 Mateusz Nowicki
  2026-09-08  8:52 ` [Linux-stm32] [PATCH] arm64: dts: st: fix arm, smc-id " Antonio Borneo
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Mateusz Nowicki @ 2026-09-07  9:14 UTC (permalink / raw)
  To: alexandre.torgue, mcoquelin.stm32
  Cc: robh, krzk+dt, conor+dt, lionel.debieve, amelie.delaunay,
	patrice.chotard, devicetree, linux-stm32, linux-arm-kernel,
	linux-kernel

OP-TEE implements the STM32MP2 watchdog SMC service with function ID
0xbc000000 (CFG_WDT_SM_HANDLER_ID), not 0xb200005a. With the current
value the arm_smc_wdt probe fails with -EIO and the IWDG started by the
bootloader is never refreshed.

Fixes: 89fca38168c9 ("arm64: dts: st: add arm-wdt node for watchdog support on stm32mp251")
Fixes: e9b03ef21386 ("arm64: dts: st: introduce stm32mp23 SoCs family")
Signed-off-by: Mateusz Nowicki <mateusz.nowicki@posteo.net>
---
 arch/arm64/boot/dts/st/stm32mp231.dtsi | 2 +-
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/st/stm32mp231.dtsi b/arch/arm64/boot/dts/st/stm32mp231.dtsi
index 9e1d240888ff..35e247af957c 100644
--- a/arch/arm64/boot/dts/st/stm32mp231.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp231.dtsi
@@ -35,7 +35,7 @@ arm-pmu {
 
 	arm_wdt: watchdog {
 		compatible = "arm,smc-wdt";
-		arm,smc-id = <0xb200005a>;
+		arm,smc-id = <0xbc000000>;
 		status = "disabled";
 	};
 
diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 9c63fdb5a885..2dcbba65e298 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -36,7 +36,7 @@ arm-pmu {
 
 	arm_wdt: watchdog {
 		compatible = "arm,smc-wdt";
-		arm,smc-id = <0xb200005a>;
+		arm,smc-id = <0xbc000000>;
 		status = "disabled";
 	};
 
-- 
2.55.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Linux-stm32] [PATCH] arm64: dts: st: fix arm, smc-id of the SMC watchdog on stm32mp2
  2026-09-07  9:14 [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2 Mateusz Nowicki
@ 2026-09-08  8:52 ` Antonio Borneo
  2026-09-23 11:52 ` [PATCH] arm64: dts: st: fix arm,smc-id " Mateusz Nowicki
  2026-09-28  8:45 ` Alexandre TORGUE
  2 siblings, 0 replies; 9+ messages in thread
From: Antonio Borneo @ 2026-09-08  8:52 UTC (permalink / raw)
  To: Mateusz Nowicki, alexandre.torgue, mcoquelin.stm32
  Cc: robh, conor+dt, devicetree, linux-stm32, linux-kernel, krzk+dt,
	linux-arm-kernel

On Mon, 2026-09-07 at 09:14 +0000, Mateusz Nowicki wrote:
> OP-TEE implements the STM32MP2 watchdog SMC service with function ID
> 0xbc000000 (CFG_WDT_SM_HANDLER_ID), not 0xb200005a. With the current
> value the arm_smc_wdt probe fails with -EIO and the IWDG started by the
> bootloader is never refreshed.
> 
> Fixes: 89fca38168c9 ("arm64: dts: st: add arm-wdt node for watchdog support on stm32mp251")
> Fixes: e9b03ef21386 ("arm64: dts: st: introduce stm32mp23 SoCs family")
> Signed-off-by: Mateusz Nowicki <mateusz.nowicki@posteo.net>

Reviewed-by: Antonio Borneo <antonio.borneo@foss.st.com>

Thanks,
Antonio

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
  2026-09-07  9:14 [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2 Mateusz Nowicki
  2026-09-08  8:52 ` [Linux-stm32] [PATCH] arm64: dts: st: fix arm, smc-id " Antonio Borneo
@ 2026-09-23 11:52 ` Mateusz Nowicki
  2026-09-28  8:45 ` Alexandre TORGUE
  2 siblings, 0 replies; 9+ messages in thread
From: Mateusz Nowicki @ 2026-09-23 11:52 UTC (permalink / raw)
  To: alexandre.torgue, mcoquelin.stm32
  Cc: antonio.borneo, robh, krzk+dt, conor+dt, lionel.debieve,
	amelie.delaunay, patrice.chotard, devicetree, linux-stm32,
	linux-arm-kernel, linux-kernel

Hi Alexandre,

Gentle ping on this fix, Antonio gave his Reviewed-by on Sep 8.

On current stm32-next the SMC watchdog still fails to probe on the
STM32MP257F-DK:

    arm_smc_wdt watchdog: probe with driver arm_smc_wdt failed with error -5

Could you take it for v7.4?

Thanks,
Mateusz

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
  2026-09-07  9:14 [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2 Mateusz Nowicki
  2026-09-08  8:52 ` [Linux-stm32] [PATCH] arm64: dts: st: fix arm, smc-id " Antonio Borneo
  2026-09-23 11:52 ` [PATCH] arm64: dts: st: fix arm,smc-id " Mateusz Nowicki
@ 2026-09-28  8:45 ` Alexandre TORGUE
  2026-10-31  5:59   ` Marek Vasut
  2 siblings, 1 reply; 9+ messages in thread
From: Alexandre TORGUE @ 2026-09-28  8:45 UTC (permalink / raw)
  To: Mateusz Nowicki, mcoquelin.stm32
  Cc: robh, krzk+dt, conor+dt, lionel.debieve, amelie.delaunay,
	patrice.chotard, devicetree, linux-stm32, linux-arm-kernel,
	linux-kernel

Hi Mateusz

On 9/7/26 11:14, Mateusz Nowicki wrote:
> OP-TEE implements the STM32MP2 watchdog SMC service with function ID
> 0xbc000000 (CFG_WDT_SM_HANDLER_ID), not 0xb200005a. With the current
> value the arm_smc_wdt probe fails with -EIO and the IWDG started by the
> bootloader is never refreshed.
> 
> Fixes: 89fca38168c9 ("arm64: dts: st: add arm-wdt node for watchdog support on stm32mp251")
> Fixes: e9b03ef21386 ("arm64: dts: st: introduce stm32mp23 SoCs family")
> Signed-off-by: Mateusz Nowicki <mateusz.nowicki@posteo.net>
> ---
>   arch/arm64/boot/dts/st/stm32mp231.dtsi | 2 +-
>   arch/arm64/boot/dts/st/stm32mp251.dtsi | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/st/stm32mp231.dtsi b/arch/arm64/boot/dts/st/stm32mp231.dtsi
> index 9e1d240888ff..35e247af957c 100644
> --- a/arch/arm64/boot/dts/st/stm32mp231.dtsi
> +++ b/arch/arm64/boot/dts/st/stm32mp231.dtsi
> @@ -35,7 +35,7 @@ arm-pmu {
>   
>   	arm_wdt: watchdog {
>   		compatible = "arm,smc-wdt";
> -		arm,smc-id = <0xb200005a>;
> +		arm,smc-id = <0xbc000000>;
>   		status = "disabled";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
> index 9c63fdb5a885..2dcbba65e298 100644
> --- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
> +++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
> @@ -36,7 +36,7 @@ arm-pmu {
>   
>   	arm_wdt: watchdog {
>   		compatible = "arm,smc-wdt";
> -		arm,smc-id = <0xb200005a>;
> +		arm,smc-id = <0xbc000000>;
>   		status = "disabled";
>   	};
>   

Applied on stm32-next.

Thanks
Alex

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
  2026-09-28  8:45 ` Alexandre TORGUE
@ 2026-10-31  5:59   ` Marek Vasut
  2026-10-31  8:45     ` Arnd Bergmann
  0 siblings, 1 reply; 9+ messages in thread
From: Marek Vasut @ 2026-10-31  5:59 UTC (permalink / raw)
  To: Alexandre TORGUE, Mateusz Nowicki, mcoquelin.stm32, Thomas BOURGOIN
  Cc: robh, krzk+dt, conor+dt, lionel.debieve, amelie.delaunay,
	patrice.chotard, devicetree, linux-stm32, linux-arm-kernel,
	linux-kernel, kernel, Geert Uytterhoeven, Laurent Pinchart,
	Fabrice Gasnier, Stefano Babic, Etienne Carriere, Arnd Bergmann

On 9/28/26 10:45 AM, Alexandre TORGUE wrote:

Hello all,

> On 9/7/26 11:14, Mateusz Nowicki wrote:
>> OP-TEE implements the STM32MP2 watchdog SMC service with function ID
>> 0xbc000000 (CFG_WDT_SM_HANDLER_ID), not 0xb200005a. With the current
>> value the arm_smc_wdt probe fails with -EIO and the IWDG started by the
>> bootloader is never refreshed.
>>
>> Fixes: 89fca38168c9 ("arm64: dts: st: add arm-wdt node for watchdog 
>> support on stm32mp251")
>> Fixes: e9b03ef21386 ("arm64: dts: st: introduce stm32mp23 SoCs family")
>> Signed-off-by: Mateusz Nowicki <mateusz.nowicki@posteo.net>
>> ---
>>   arch/arm64/boot/dts/st/stm32mp231.dtsi | 2 +-
>>   arch/arm64/boot/dts/st/stm32mp251.dtsi | 2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/st/stm32mp231.dtsi b/arch/arm64/boot/ 
>> dts/st/stm32mp231.dtsi
>> index 9e1d240888ff..35e247af957c 100644
>> --- a/arch/arm64/boot/dts/st/stm32mp231.dtsi
>> +++ b/arch/arm64/boot/dts/st/stm32mp231.dtsi
>> @@ -35,7 +35,7 @@ arm-pmu {
>>       arm_wdt: watchdog {
>>           compatible = "arm,smc-wdt";
>> -        arm,smc-id = <0xb200005a>;
>> +        arm,smc-id = <0xbc000000>;
>>           status = "disabled";
>>       };
>> diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/ 
>> dts/st/stm32mp251.dtsi
>> index 9c63fdb5a885..2dcbba65e298 100644
>> --- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
>> +++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
>> @@ -36,7 +36,7 @@ arm-pmu {
>>       arm_wdt: watchdog {
>>           compatible = "arm,smc-wdt";
>> -        arm,smc-id = <0xb200005a>;
>> +        arm,smc-id = <0xbc000000>;
>>           status = "disabled";
>>       };
> 
> Applied on stm32-next.
Since this change, my STM32MP255C board started rebooting after 32 
seconds. It turns out, this is caused by an ABI break.

Here is the thing -- old ST downstream fork of OP-TEE OS did expect ARM 
SMC WDT ID 0xb200005a (that was the ST ecosystem v5), the OP-TEE OS 
4.0.0 fork seems to have handled both, and the new 4.8.0 fork expects 
0xbc000000 ID only and does not handle 0xb200005a .

At this point, with Linux 6.18 the kernel is trying to trigger the WDT 
using SMC ID 0xb200005a , which on my machine works (older OP-TEE OS). 
When I boot linux-next , it is using ID 0xbc000000 and my system reboots 
after 32 seconds. (not even mainline Linux versions are consistent here 
now, sigh)

I actually found this behavior the other way around -- while forward 
porting a system to the new OP-TEE OS 4.8.0 port, which I installed, 
then booted Linux 6.18.y, machine started rebooting (SMC ID mismatch, 
new OP-TEE expects 0xbc000000 and linux-stable sends 0xb200005a), so I 
booted recovery, and ... recovery is also Linux 6.18.y, so I could not 
recover the machine that way anymore.

Currently, I added [1] to OP-TEE OS as a mitigation of this ABI break, 
but I don't think everyone can still update their bootloader stack in 
this way. And with this patch in place (and inconsistency between Linux 
stable 6.18.y and upcoming 7.4.y) the ABI break will cause some serious 
mess.

How shall we deal with this ?

Thank you for your help !

[1] 
https://github.com/STMicroelectronics/optee_os/commit/8450f25923c0c98465decc975f25efed19f82ba0

-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
  2026-10-31  5:59   ` Marek Vasut
@ 2026-10-31  8:45     ` Arnd Bergmann
  2026-10-31 12:00       ` mateusz.nowicki
  0 siblings, 1 reply; 9+ messages in thread
From: Arnd Bergmann @ 2026-10-31  8:45 UTC (permalink / raw)
  To: Marek Vasut, Alexandre Torgue, Mateusz Nowicki, Maxime Coquelin,
	Thomas BOURGOIN
  Cc: Rob Herring, krzk+dt, Conor Dooley, Lionel DEBIEVE,
	Amelie DELAUNAY, Patrice Chotard, devicetree, linux-stm32,
	linux-arm-kernel, linux-kernel, kernel, Geert Uytterhoeven,
	laurent.pinchart, Fabrice GASNIER, Stefano Babic,
	Etienne Carriere

On Sat, Oct 31, 2026, at 06:59, Marek Vasut wrote:
> On 9/28/26 10:45 AM, Alexandre TORGUE wrote:
>> On 9/7/26 11:14, Mateusz Nowicki wrote:

> At this point, with Linux 6.18 the kernel is trying to trigger the WDT 
> using SMC ID 0xb200005a , which on my machine works (older OP-TEE OS). 
> When I boot linux-next , it is using ID 0xbc000000 and my system reboots 
> after 32 seconds. (not even mainline Linux versions are consistent here 
> now, sigh)
>
> I actually found this behavior the other way around -- while forward 
> porting a system to the new OP-TEE OS 4.8.0 port, which I installed, 
> then booted Linux 6.18.y, machine started rebooting (SMC ID mismatch, 
> new OP-TEE expects 0xbc000000 and linux-stable sends 0xb200005a), so I 
> booted recovery, and ... recovery is also Linux 6.18.y, so I could not 
> recover the machine that way anymore.
>
> Currently, I added [1] to OP-TEE OS as a mitigation of this ABI break, 
> but I don't think everyone can still update their bootloader stack in 
> this way. And with this patch in place (and inconsistency between Linux 
> stable 6.18.y and upcoming 7.4.y) the ABI break will cause some serious 
> mess.
>
> How shall we deal with this ?

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?

Newer boards can override this if they always supported the
new ABI.

For the firmware change, I can see multiple ways forward, depending
on what the original reason for the change was:

- (obviously) revert to accepting both values forever on boards
  that ever had the old ABI in the past.

- For boards that can have either firmware, use separate dtb
  files that match whatever the firmware is. This only makes
  sense if the firmware is fundamentally incompatible for
  reasons other than this constant. I think we did this for
  firmware with and without op-tee.

- Add a workaround in u-boot to patch the dtb at boot time to
  match whatever op-tee version is being used. This would be
  the cleanest but requires extra work.

     Arnd

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
  2026-10-31  8:45     ` Arnd Bergmann
@ 2026-10-31 12:00       ` mateusz.nowicki
  2026-10-31 13:35         ` Marek Vasut
  0 siblings, 1 reply; 9+ messages in thread
From: mateusz.nowicki @ 2026-10-31 12:00 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Marek Vasut, Alexandre Torgue, Maxime Coquelin, Thomas BOURGOIN,
	Rob Herring, krzk+dt, Conor Dooley, Lionel DEBIEVE,
	Amelie DELAUNAY, Patrice Chotard, devicetree, linux-stm32,
	linux-arm-kernel, linux-kernel, kernel, Geert Uytterhoeven,
	laurent.pinchart, Fabrice GASNIER, Stefano Babic,
	Etienne Carriere

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
  2026-10-31 12:00       ` mateusz.nowicki
@ 2026-10-31 13:35         ` Marek Vasut
  2026-10-31 20:59           ` mateusz.nowicki
  0 siblings, 1 reply; 9+ messages in thread
From: Marek Vasut @ 2026-10-31 13:35 UTC (permalink / raw)
  To: mateusz.nowicki, Arnd Bergmann
  Cc: Alexandre Torgue, Maxime Coquelin, Thomas BOURGOIN, Rob Herring,
	krzk+dt, Conor Dooley, Lionel DEBIEVE, Amelie DELAUNAY,
	Patrice Chotard, devicetree, linux-stm32, linux-arm-kernel,
	linux-kernel, kernel, Geert Uytterhoeven, laurent.pinchart,
	Fabrice GASNIER, Stefano Babic, Etienne Carriere

On 10/31/26 1:00 PM, mateusz.nowicki@posteo.net wrote:

Hello Mateusz,

> 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.

I do not think revert of this patch is the right approach here. I also 
do not think patching the arm,smc-id in board DT is the right approach. 
Both of those, because we do not know which SMC ID is the correct one 
(we do not know which firmware is running and how it is configured, see 
the OP-TEE OS CFG_WDT_SM_HANDLER_ID which is user configurable, and as 
far as I can tell, the SMC ID is not discoverable, or is it?).

But maybe there is some way to probe for the correct ARM SMC WDT ID ? (I 
do not think we can infer the ID from e.g. OP-TEE OS version, because of 
the CFG_WDT_SM_HANDLER_ID user configuration).

In case of this SoC, we can mostly assume that the SMC IDs will be one 
of the two, 0xb200005a or 0xbc000000, so maybe we can extend the SMC WDT 
driver to support some sort of fallback -- if the primary SMC ID fails 
as not supported, try the secondary one ?

As for the DHCOS boards, those are evalboards, their bootloader can be 
easily updated, and they are running recent software more often than 
not, there this topic is mostly a non-issue. There is however hardware 
which does have downstream DTs which pull in upstream DTSIs .

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2
  2026-10-31 13:35         ` Marek Vasut
@ 2026-10-31 20:59           ` mateusz.nowicki
  0 siblings, 0 replies; 9+ messages in thread
From: mateusz.nowicki @ 2026-10-31 20:59 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Arnd Bergmann, Alexandre Torgue, Maxime Coquelin,
	Thomas BOURGOIN, Rob Herring, krzk+dt, Conor Dooley,
	Lionel DEBIEVE, Amelie DELAUNAY, Patrice Chotard, devicetree,
	linux-stm32, linux-arm-kernel, linux-kernel, kernel,
	Geert Uytterhoeven, laurent.pinchart, Fabrice GASNIER,
	Stefano Babic, Etienne Carriere

Hi Marek,

> But maybe there is some way to probe for the correct ARM SMC WDT ID ?

I agree, the ID is not discoverable. A revert or a board override
would not help firmware built with a custom CFG_WDT_SM_HANDLER_ID
either. Sorry for the trouble on your board.

I like the fallback idea. My suggestion:

- arm,smc-id becomes a list of IDs.
- The driver tries them in order until SMCWD_INIT succeeds.
- The SoC dtsi lists <0xbc000000 0xb200005a>.
- Boards with a custom ID override the list.
- Older kernels read only the first cell, so nothing breaks there.

Trying a wrong ID is harmless. Old and new firmware both just return
an error for an ID they do not know, as your two cases and my DK show.

One catch: OP-TEE answers an unknown call with 0xFFFFFFFF in w0, and
smcwd_call() compares a0 with PSCI_RET_NOT_SUPPORTED as a 64-bit
value. The driver gets -EIO, not -ENODEV, so the fallback should move
to the next ID on any error.

If you and the watchdog maintainers are fine with this, I can send
the binding and driver patches.

Best regards,
Mateusz

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2026-10-31 20:59 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-07  9:14 [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2 Mateusz Nowicki
2026-09-08  8:52 ` [Linux-stm32] [PATCH] arm64: dts: st: fix arm, smc-id " Antonio Borneo
2026-09-23 11:52 ` [PATCH] arm64: dts: st: fix arm,smc-id " Mateusz Nowicki
2026-09-28  8:45 ` Alexandre TORGUE
2026-10-31  5:59   ` Marek Vasut
2026-10-31  8:45     ` Arnd Bergmann
2026-10-31 12:00       ` mateusz.nowicki
2026-10-31 13:35         ` Marek Vasut
2026-10-31 20:59           ` mateusz.nowicki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®