All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: Mike Frysinger <vapier.adi@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Bryan Wu <Bryan.Wu@analog.com>
Subject: Re: how to allow board writers to customize driver behavior (watchdog here)
Date: Fri, 25 May 2007 00:23:18 +0900	[thread overview]
Message-ID: <20070524152318.GA4491@linux-sh.org> (raw)
In-Reply-To: <200705240929.51696.rgetz@blackfin.uclinux.org>

On Thu, May 24, 2007 at 09:29:51AM -0400, Robin Getz wrote:
> On Thu 24 May 2007 01:23, Paul Mundt pondered:
> > On Thu, May 24, 2007 at 12:21:47AM -0400, Mike Frysinger wrote:
> > > is this completely bad mojo ?  is there some other mechanism that
> > > provides what i want and i just dont know about it ?  or do i just
> > > make people change the driver to fit their application, thus throwing
> > > out the idea of keeping all board-specific details in just the boards
> > > file ...
> > 
> > It sounds like your constraining your driver based on terminology.
> > Watchdogs on most embedded platforms support either a 'reset' mode or
> > otherwise act as periodic timers, trying to push both of these
> > functionalities in to a watchdog driver is rather pointless.
> > CONFIG_WATCHDOG implies 'reset' mode by definition.
> 
> I understand what you mean - typically - most people think of watchdog == 
> reset.
> 
No, not typically. This is _precisely_ what CONFIG_WATCHDOG means, and
how the entire set of drivers underneath it behave.

> But, calling it a periodic timer, and servicing it with the watchdog user 
> space demon is even more confusing - isn't it?
> 
Calling it a periodic timer when its in periodic timer mode makes sense.
Why you would want to interface that with a userspace watchdog daemon is
beyond me, they're conceptually unrelated.

Please read my original mail on the subject. I'm not advocating hiding a
clocksource somewhere in the depths of CONFIG_WATCHDOG, they're
completely unrelated.

  reply	other threads:[~2007-05-24 15:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-24  4:21 how to allow board writers to customize driver behavior (watchdog here) Mike Frysinger
2007-05-24  5:23 ` Paul Mundt
2007-05-24  8:47   ` Daniel Newby
2007-05-24  9:32     ` Paul Mundt
2007-05-24 15:08     ` Mike Frysinger
2007-05-24 13:29   ` Robin Getz
2007-05-24 15:23     ` Paul Mundt [this message]
2007-05-24 17:32       ` Robin Getz
2007-05-25  4:04         ` Paul Mundt
2007-05-25 10:09           ` Daniel Newby
2007-05-25 17:55             ` Mike Frysinger
2007-05-24 15:12   ` Mike Frysinger
2007-05-24 10:01 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070524152318.GA4491@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=Bryan.Wu@analog.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgetz@blackfin.uclinux.org \
    --cc=vapier.adi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.