On 12/06/2014 02:11 AM, Timo Kokkonen wrote:
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?
To make progress, can you update the patch using early-timeout-sec as discussed
?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
