Re: [RFC PATCH 0/3] watchdog: arm_smc_wdt: allow a list of SMC function ids

[Marek Vasut]

On 11/4/26 5:39 PM, Guenter Roeck wrote:
> On 11/4/26 08:16, Mateusz Nowicki wrote:
> > Hi all,
> >
> > this follows up on Marek's report about the stm32mp2 watchdog [1].
> >
> > A quick recap: the arm,smc-wdt driver talks to the firmware through one
> > SMC function id that it reads from the device tree, and there is no way
> > to ask the firmware which id it uses. On the STM32MP2 SoCs that id
> > changed over time. ST's OP-TEE from ecosystem v5 expects 0xb200005a,
> > their 4.0.0 fork accepts both, and the 4.8.0 fork as well as upstream
> > OP-TEE only accept 0xbc000000.
> >
> > My earlier patch, commit ae4d08bbe3f4 ("arm64: dts: st: fix arm,smc-id
> > of the SMC watchdog on stm32mp2"), switched the dtsi to 0xbc000000. That
> > made the watchdog work with current OP-TEE, but it broke boards that run
> > the older firmware. So today 6.18.y uses one id and 7.4 the other. When
> > the kernel and the firmware disagree, nobody pets the watchdog that the
> > bootloader started, and the board resets after 32 seconds. Marek hit
> > this even with a recovery kernel, which is about the worst place for it.
>
> So the DT on the board is updated to use the new ID but the firmware itself
> isn't ? That seems a bit odd; I would have assumed that the DT on a board
> is kept in sync with its firmware. Is that not the case here ?

That is not necessarily the case, no. Consider a scenario where the 
firmware is old, kernel is new. Bootloader is not always updated in 
devices deployed in field.

> > The idea from that thread: let arm,smc-id be a list. The driver tries
> > the ids one by one and keeps the first one the firmware accepts. Older
> > kernels only read the first cell, so they behave exactly as they do
> > now. For stm32mp2 the list is <0xbc000000 0xb200005a>. Calling an id
> > that belongs to some other firmware service would be bad, so the
> > binding says the list may only hold ids known to be this watchdog.
>
> Would it possibly make sense to check keep a list of known IDs in the
> driver ? It already checks 0x82003D06, so it might as well check a 
> sequence.
I am unsure whether there are any standardized IDs, but yes, this would 
be good.