[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bd0f97a0705232121j32fcff72hd04b04e37507450e@mail.gmail.com>
Date: Thu, 24 May 2007 00:21:47 -0400
From: "Mike Frysinger" <vapier.adi@...il.com>
To: "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Cc: "Bryan Wu" <Bryan.Wu@...log.com>
Subject: how to allow board writers to customize driver behavior (watchdog here)
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists