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

[mateusz . nowicki]

On 11/5/26 Julius Werner wrote:
> What happens if you simply define two watchdog nodes in your DTS, one
> for each SMC ID? Both of them would independently try to probe, one of
> them would die from getting an SMC_UNK, and the other would continue
> working to pet your watchdog?

I thought about that, but there is firmware where both of them probe.
ST's 4.0.0 OP-TEE fork accepts both IDs, so you end up with watchdog0
and watchdog1 on the same IWDG. The bootloader has already started it,
so both register with WDOG_HW_RUNNING. Userspace opens one of them and
the watchdog core keeps pinging the other one forever (open_timeout is
0 by default). If userspace hangs, the board never resets.

> I would be fine
> with the array solution but I don't know about the validation checker
> and whether people care about reusing the same prop name with
> different types. (FWIW, in the device tree a 32-bit integer is
> basically a 1-element array anyway, so we might just say it's always
> an array and for SCMI only one element is allowed.)

I tried that. With arm,smc-id as a uint32-array with maxItems: 1 in
arm,scmi.yaml the "multiple incompatible types" error is gone.
dt_binding_check is clean, and so is dtbs_check on stm32mp257f-dk,
stm32mp235f-dk and a few boards that use SCMI over SMC (imx8ulp-evk,
rk3528-armsom-sige1, amlogic-c3, blaize-blzp1600). The SCMI driver
reads the property with of_property_read_u32(), so nothing changes
there.

Guenter, you suggested keeping the IDs in the driver and I have a v2
like that ready (st,stm32mp25-smc-wdt with the IDs as match data).
Julius would rather keep them in DT. I'm fine with either, just tell me
which one you'd take. If it's the array, v2 is the RFC plus the
arm,scmi.yaml change, and maxItems: 2 as Marek asked.

Thanks,
Mateusz