Re: how to allow board writers to customize driver behavior (watchdog here)

[Paul Mundt <lethal@linux-sh.org>]

On Thu, May 24, 2007 at 01:32:30PM -0400, Robin Getz wrote:
> On Thu 24 May 2007 11:23, Paul Mundt pondered:
> > 
> > Calling it a periodic timer when its in periodic timer mode makes sense.
> 
> No disagreements - but I don't think that a watchdog that doesn't cause a 
> reset is a periodic timer.
> 
I'm not sure what else you think it is? On most platforms, when it's not
in reset mode, it works as a free-running timer with an IRQ generated on
overflow. I've certainly used the watchdog as a system timer before on
boards where all of the timer channels are tied up for other uses.

> > Why you would want to interface that with a userspace watchdog daemon is
> > beyond me, they're conceptually unrelated.
> 
> Agreed again - periodic timers have nothing to do with watchdogs. This is 
> where I am confused about why you are saying that the only event a watchdog 
> can have is a hard reset.
> 
No, what I said was that the only event that _matters_ to CONFIG_WATCHDOG
is a hard reset. So far no one has suggested anything outside of hard
reset, periodic timer, or softlockup detection that would be useful to
extend CONFIG_WATCHDOG for.

If you're talking about specific events, clockevents are still a much
better way to go than trying to hammer something in to CONFIG_WATCHDOG
that it was never designed for. If you have some 'special' events for
your watchdog that would be of use to others, tying these in as
additional flags for clockevents would be far more beneficial anyways.

> > I'm not advocating hiding a clocksource somewhere in the depths of
> > CONFIG_WATCHDOG, they're completely unrelated.
> 
> I (and many others) consider a "watchdog" a clock sink - something that needs 
> to be poked within certain limits (too fast can indicate a failures just as 
> too slow is a failure).
> 
Currently there's nothing in the kernel that cares about clearing 'too fast'.
I can't imagine why this _should_ be treated as a failure, but feel free
to code up a solution if you feel it will be useful.

> The event or how something is notified of the failure of the watchdog to be 
> serviced shouldn't determine what the name is.
> 
If all you want is a timer that you occasionally have to poke and then
take some notification when it expires, you can just use a regular
one-shot timer anyways and bank off of the system timer, the 'watchdog'
is certainly not doing anything useful at this point.

So far the only example anyone has provided outside of periodic timers or
hardware reset has been dumping the stack when something gets stuck.
Softlockup does this already today, using a timer.

If your system is completely dead, you won't have any way to trigger or
see the stack dump anyways, so the watchdog doesn't buy you anything
there, either.

What many watchdogs do today is simply to have split timer for userspace
and the actual hardware (where userspace has to poke the timer every now
and then, or the kernel will allow the overflow). This is pretty common
for watchdogs with very fast overflow periods.

There's certainly nothing wrong with having a timer that runs out and
kicks a notifier chain if there's something special you want to do, but
tying up the watchdog hardware for that is silly. There are many other
things one has to use the watchdog hardware for anyways (reset, periodic
timing, frequency scaling -- waiting for PLL stabilization, etc.). Tying
down a hardware block where a struct timer_list will do the same work
makes no sense.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/