[Linux-stm32] [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.