[lkml]   [2007]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: how to allow board writers to customize driver behavior (watchdog here)
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-25 06:09    [W:0.024 / U:14.412 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site