On 10/6/20 4:56 AM, Guenter Roeck wrote:
> 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 ?
> 

After having another couple hours of sleep and a coffee, I wonder if
this is already done, and the reboot just fails _because_ the imx2_wdt
is _not_ loaded. Is that the case ?

If so, it looks like you want the reset functionality of the imx_wdt driver
but not its watchdog functionality. And the above would be a suggestion
to add a "generic" restart functionality into the watchdog subsystem,
one that uses a watchdog with minimum timeout to reset the system,
even if its driver doesn't explicitly register a restart handler.
Is that what you are trying to suggest ?

Thanks,
Guenter

>> (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
>>
> 
>