[PATCH] at91sam9_wdt: Allow watchdog to reset device at early boot

[Timo Kokkonen]

On 05.12.2014 23:39, Guenter Roeck wrote:
> On Fri, Dec 05, 2014 at 10:32:48PM +0200, Timo Kokkonen wrote:
>> On 05.12.2014 21:02, Guenter Roeck wrote:

>>> Not sure about how to name enable-early-reset. I'd prefer to have something
>>> generic, even if only implemented in a single driver for now, but I don't
>>> really know right now what that might/should look like. Maybe just
>>> "enable-early" to indicate that the watchdog should be enabled during init ?
>>
>> Do we need the enable-early or such property at all? Just leave
>> early-timeout-sec to zero and then let it behave just like
>> enable-early would do?
>>
>
> Problem is that the possible conditions are all over the place
> for "early" watchdog handling.
>
> - Disable watchdog
> - Enable watchdog (or keep it enabled), and keep it alive
>    until user space kicks in (ie possibly forever)
> - Enable watchdog or keep it enabled, and keep it alive
>    for a specified period of time.
> - Keep watchdog enabled if it is already enabled, otherwise
>    keep it disabled.
>
> There are probably more conditions which I don't recall right now.
> Which of those conditions would you address with "early-timeout = <0>;" ?
> "enable watchdog early and keep it alive until user space kicks in",
> or "keep watchdog enabled if already running, and set specified early
> timeout" ? One could argue either way which one of the two meanings
> it should be.

Okay, let me elaborate my point of view a bit.

The use case we are concerned about is that we have a device that we 
rather not let freeze up at any point. This is what we use the watchdog 
for. The only missing corner case right now is the point where kernel 
driver initializes the watchdog hardware and pings it on behalf of user 
space until a watchdog daemon opens it and starts kicking. This is kind 
of bad as kernel might lock up or user space might crash before we get 
to the point where the daemon starts taking care of petting the 
watchdog. So this is what we are trying to fix.

Right. Some other hardware behave differently to the one in Atmel. They 
might have watchdog stopped by bootloader or it might not be running at 
all until someone starts it. What do do with such case? If we are still 
concerned about the same use case I described above, I would say the 
reasonable thing to do is to make sure the watchdog is started as early 
as possible and not stopped at any point at all, if possible. If it 
needs to be explicitly enabled, bootloader should do it. If it didn't do 
it, then kernel should do it.

Now that I think of it, what we really are interested in is to defer 
starting of the watchdog to give user space more time to start up. In 
Atmel HW it's more tricky as the driver can't be stopped. And in other 
hardware we could simply disable it altogether until we enable it after 
specific timeout, but we might crash before the timeout expires, in 
which case we would not get a chance to enable it. So the right thing to 
do is to enable the watchdog as early as possible, kick it on behalf of 
the user space until the timeout expires. Special case would be when the 
timeout is zero, when we just ensure watchdog is running but we don't do 
anything to prolong the first expiration.

I can't think of any other use case someone would be interested in, but 
I'm positive that there are plenty of products on the market right now 
that have the requirement for race free guarantee that watchdog never stops.

So given the conditions you listed, what I think is really important to 
fix is "Enable watchdog or keep it enabled, and keep it alive for a 
specified period of time". The only other choice we have right now is 
"Disable watchdog and let user space enabled it later, if ever". Yeah, 
maybe we could cover those other use cases too. Maybe someone is using 
bootloader to decide what to do with watchdog and kernel should somehow 
respect that. I don't know if that makes sense or if it would be 
reasonable assumption..

Any more thoughts?

Thanks,
-Timo