From: "Mike Frysinger" <vapier.adi@gmail.com>
To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Cc: "Bryan Wu" <Bryan.Wu@analog.com>
Subject: how to allow board writers to customize driver behavior (watchdog here)
Date: Thu, 24 May 2007 00:21:47 -0400 [thread overview]
Message-ID: <8bd0f97a0705232121j32fcff72hd04b04e37507450e@mail.gmail.com> (raw)
the Blackfin on-chip watchdog has controllable behavior ... it can be
configured to reset the processor (like a normal watchdog), or it can
be configured to simply generate an interrupt.
i can see embedded systems where simply resetting the system is not
desirable ... perhaps it's the control system for some machinery and
resetting the system will force it to reinitialize itself which could
cause problems if a guy is servicing the insides at the time ;)
the Blackfin watchdog driver has a module parameter, "action" ... the
default will have the watchdog act like every other watchdog out there
-- it reboots after a timeout. however, by setting the action param
appropriately, the watchdog goes into simple interrupt generation.
the question then becomes, how do people developing their
board-specific version customize what happens when the timeout occurs
and the interrupt is fired ? making every customer who wishes to
customize the watchdog behavior edit the watchdog driver is
troublesome as they're now blurring the distinct parts: the
watchdog-specific piece and their board-specific piece.
what i'm doing now is weak symbols:
...
extern irqreturn_t bfin_board_watchdog_interrupt(void) __attribute__((weak));
static irqreturn_t bfin_wdt_interrupt(int irq, void *dev_id)
{
if (bfin_board_watchdog_interrupt) {
return bfin_board_watchdog_interrupt();
} else {
bfin_wdt_stop();
bfin_wdt_keepalive();
bfin_wdt_start();
return IRQ_HANDLED;
}
}
...
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 ...
-mike
next reply other threads:[~2007-05-24 4:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-24 4:21 Mike Frysinger [this message]
2007-05-24 5:23 ` how to allow board writers to customize driver behavior (watchdog here) 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
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=8bd0f97a0705232121j32fcff72hd04b04e37507450e@mail.gmail.com \
--to=vapier.adi@gmail.com \
--cc=Bryan.Wu@analog.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox