Hello,
I have an i.MX25 system here with an external watchdog (using the
gpio_wdt driver). So the internal watchdog (imx2_wdt) is unused.
The problem with the unused imx2_wdt is that this usually provides the
restart handler and now a reboot ends with
reboot: Restarting system
Reboot failed -- System halted
until eventually the watchdog bites and resets the machine.
I imagine that this is a common enough issue to warrant a generic
solution. My suggestion is to formalize and implement something like:
watchdog {
compatible = "linux,wdt-gpio";
...
provide-system-reset;
}
with the sematic of: "This is the dedicated mechanism to reset this
machine."
(OK, I could enable the imx2_wdt driver and make sure with some udev
magic that the gpio watchdog is the one being fed by userspace. But
having two watchdogs fills me with some trepidation.)
Having said that, I wonder what the typical restart callback does
different from setting the timeout to a minimal value, start it and then
maybe call delay() to not return until the watchdog triggers. At least
that's what I would do for a watchdog that doesn't provide an explicit
.restart handler but has the provide-system-reset property.
In my eyes this is somewhat of a hardware property, but I can imagine
that others don't agree and argue this shouldn't go into the device
tree. @Rob: What is your position here?
Does this sound sane? Do we also need a property like
"no-provide-system-reset" to better maintain backward compatibility?
(which then would result in not registering the watchdog as reset
trigger even if the driver provides a .restart.)
Does someone know a better name for the property?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
