On 10/6/20 3:29 AM, Uwe Kleine-König wrote:
> 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."
>
Some systems have more than one means to reset it, which is why
restart handlers have a priority. This in turn suggests that we should
maybe have a means to set that priority dynamically for the imx2_wdt driver
(or for watchdog drivers in general) instead of having it fixed at 128.
That would also solve your problem, assuming there is a different
(currently lower priority) means to reset the hardware in your system.
Alternatively, can't you just blacklist the imx2-wdt driver ?
> (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.)
>
Hmm - that suggests that the reset may fail because the reset code
in imx2_wdt doesn't work, not because it isn't wired.
If so, the driver code handling the reset may be buggy or incomplete.
Have you tried setting (or not setting) the fsl,ext-reset-output
property ?
> 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.
The intent of the callback was to handle situations where the watchdog
hardware also generates the system reset. The secondary use was for systems
which don't have a means to reset the system other than what you describe
above.
Guenter
>
> 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
>
Attachment:
signature.asc
Description: OpenPGP digital signature
