Hi Juuso,
On 8/18/26 9:43 AM, Juuso Rinta wrote:
This series provides a fix for the wdt_start() function, which can
print incorrect timeout values in cases where the function is
called with a timeout value greater than the hardware-supported
maximum. The current implementation prints the requested value, so,
for example, the console may show that the watchdog timeout is set to
60 seconds when it is in practice clamped to 10 seconds by the device.
The series introduces the max_timeout_ms value into the per-device
uclass-plat data. By default, this value is initialized to 0, and
drivers should write the hardware-limited max_timeout_ms value into
the plat-data typically during probing.
If the driver has reported a max_timeout_ms value, wdt_start() clamps
the requested timeout_ms value before calling ops->start(). The default
value 0 is considered "limitless", i.e. on drivers that do not set the
value, the prints and the functionality are unaffected by this series.
I have two remarks.
1. Is it really appropriate to have a timeout smaller than requested?
Maybe the answer is that we should fail if the user requests an
unsupported timeout?
2. I'm not sure it is enough to clamp the max. The Rockchip RK806 PMIC
has a watchdog with only a few possible values as timeout: 50ms, 100ms,
500ms, 2s, 10s, 1min and 10min. Experimentally, they are not even that
(though I don't remember exactly the actual values I found, and I don't
have access to my notes as I'm currently traveling). So, I'm wondering
if we shouldn't update the API such that the driver reports what the
actual timeout is, as it may differ from the requested timeout (if we do
clamping or rounding, even with non-max values). wdt_ops->start()
returns 0 on success, but it could return the actual timeout for
example. I would wait on Stefan to chime in though, that is a much more
involved rework and if Stefan doesn't like it, wasted time and effort ;)
Cheers,
Quentin
