Re: [PATCH] arm64: dts: st: fix arm,smc-id of the SMC watchdog on stm32mp2

[Arnd Bergmann]

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