diff options
author | Wim Van Sebroeck <wim@iguana.be> | 2011-07-22 14:55:18 -0400 |
---|---|---|
committer | Wim Van Sebroeck <wim@iguana.be> | 2011-07-28 04:01:04 -0400 |
commit | 43316044d4f64da008d6aca7d4b60771b9a24eb8 (patch) | |
tree | 66d0d023a8713119d973e3c367efa21fb5a1908f /Documentation/watchdog/watchdog-kernel-api.txt | |
parent | 5efc7a6222f6408d29d6beb1142a302f31dc9eac (diff) |
watchdog: WatchDog Timer Driver Core - Add basic framework
The WatchDog Timer Driver Core is a framework
that contains the common code for all watchdog-driver's.
It also introduces a watchdog device structure and the
operations that go with it.
This is the introduction of this framework. This part
supports the minimal watchdog userspace API (or with
other words: the functionality to use /dev/watchdog's
open, release and write functionality as defined in
the simplest watchdog API). Extra functionality will
follow in the next set of patches.
Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Diffstat (limited to 'Documentation/watchdog/watchdog-kernel-api.txt')
-rw-r--r-- | Documentation/watchdog/watchdog-kernel-api.txt | 119 |
1 files changed, 119 insertions, 0 deletions
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt new file mode 100644 index 000000000000..3db67e74b80e --- /dev/null +++ b/Documentation/watchdog/watchdog-kernel-api.txt | |||
@@ -0,0 +1,119 @@ | |||
1 | The Linux WatchDog Timer Driver Core kernel API. | ||
2 | =============================================== | ||
3 | Last reviewed: 22-Jul-2011 | ||
4 | |||
5 | Wim Van Sebroeck <wim@iguana.be> | ||
6 | |||
7 | Introduction | ||
8 | ------------ | ||
9 | This document does not describe what a WatchDog Timer (WDT) Driver or Device is. | ||
10 | It also does not describe the API which can be used by user space to communicate | ||
11 | with a WatchDog Timer. If you want to know this then please read the following | ||
12 | file: Documentation/watchdog/watchdog-api.txt . | ||
13 | |||
14 | So what does this document describe? It describes the API that can be used by | ||
15 | WatchDog Timer Drivers that want to use the WatchDog Timer Driver Core | ||
16 | Framework. This framework provides all interfacing towards user space so that | ||
17 | the same code does not have to be reproduced each time. This also means that | ||
18 | a watchdog timer driver then only needs to provide the different routines | ||
19 | (operations) that control the watchdog timer (WDT). | ||
20 | |||
21 | The API | ||
22 | ------- | ||
23 | Each watchdog timer driver that wants to use the WatchDog Timer Driver Core | ||
24 | must #include <linux/watchdog.h> (you would have to do this anyway when | ||
25 | writing a watchdog device driver). This include file contains following | ||
26 | register/unregister routines: | ||
27 | |||
28 | extern int watchdog_register_device(struct watchdog_device *); | ||
29 | extern void watchdog_unregister_device(struct watchdog_device *); | ||
30 | |||
31 | The watchdog_register_device routine registers a watchdog timer device. | ||
32 | The parameter of this routine is a pointer to a watchdog_device structure. | ||
33 | This routine returns zero on success and a negative errno code for failure. | ||
34 | |||
35 | The watchdog_unregister_device routine deregisters a registered watchdog timer | ||
36 | device. The parameter of this routine is the pointer to the registered | ||
37 | watchdog_device structure. | ||
38 | |||
39 | The watchdog device structure looks like this: | ||
40 | |||
41 | struct watchdog_device { | ||
42 | const struct watchdog_info *info; | ||
43 | const struct watchdog_ops *ops; | ||
44 | void *driver_data; | ||
45 | unsigned long status; | ||
46 | }; | ||
47 | |||
48 | It contains following fields: | ||
49 | * info: a pointer to a watchdog_info structure. This structure gives some | ||
50 | additional information about the watchdog timer itself. (Like it's unique name) | ||
51 | * ops: a pointer to the list of watchdog operations that the watchdog supports. | ||
52 | * driver_data: a pointer to the drivers private data of a watchdog device. | ||
53 | This data should only be accessed via the watchdog_set_drvadata and | ||
54 | watchdog_get_drvdata routines. | ||
55 | * status: this field contains a number of status bits that give extra | ||
56 | information about the status of the device (Like: is the device opened via | ||
57 | the /dev/watchdog interface or not, ...). | ||
58 | |||
59 | The list of watchdog operations is defined as: | ||
60 | |||
61 | struct watchdog_ops { | ||
62 | struct module *owner; | ||
63 | /* mandatory operations */ | ||
64 | int (*start)(struct watchdog_device *); | ||
65 | int (*stop)(struct watchdog_device *); | ||
66 | /* optional operations */ | ||
67 | int (*ping)(struct watchdog_device *); | ||
68 | }; | ||
69 | |||
70 | It is important that you first define the module owner of the watchdog timer | ||
71 | driver's operations. This module owner will be used to lock the module when | ||
72 | the watchdog is active. (This to avoid a system crash when you unload the | ||
73 | module and /dev/watchdog is still open). | ||
74 | Some operations are mandatory and some are optional. The mandatory operations | ||
75 | are: | ||
76 | * start: this is a pointer to the routine that starts the watchdog timer | ||
77 | device. | ||
78 | The routine needs a pointer to the watchdog timer device structure as a | ||
79 | parameter. It returns zero on success or a negative errno code for failure. | ||
80 | * stop: with this routine the watchdog timer device is being stopped. | ||
81 | The routine needs a pointer to the watchdog timer device structure as a | ||
82 | parameter. It returns zero on success or a negative errno code for failure. | ||
83 | Some watchdog timer hardware can only be started and not be stopped. The | ||
84 | driver supporting this hardware needs to make sure that a start and stop | ||
85 | routine is being provided. This can be done by using a timer in the driver | ||
86 | that regularly sends a keepalive ping to the watchdog timer hardware. | ||
87 | |||
88 | Not all watchdog timer hardware supports the same functionality. That's why | ||
89 | all other routines/operations are optional. They only need to be provided if | ||
90 | they are supported. These optional routines/operations are: | ||
91 | * ping: this is the routine that sends a keepalive ping to the watchdog timer | ||
92 | hardware. | ||
93 | The routine needs a pointer to the watchdog timer device structure as a | ||
94 | parameter. It returns zero on success or a negative errno code for failure. | ||
95 | Most hardware that does not support this as a separate function uses the | ||
96 | start function to restart the watchdog timer hardware. And that's also what | ||
97 | the watchdog timer driver core does: to send a keepalive ping to the watchdog | ||
98 | timer hardware it will either use the ping operation (when available) or the | ||
99 | start operation (when the ping operation is not available). | ||
100 | |||
101 | The status bits should (preferably) be set with the set_bit and clear_bit alike | ||
102 | bit-operations. The status bits that are defined are: | ||
103 | * WDOG_DEV_OPEN: this status bit shows whether or not the watchdog device | ||
104 | was opened via /dev/watchdog. | ||
105 | (This bit should only be used by the WatchDog Timer Driver Core). | ||
106 | |||
107 | To get or set driver specific data the following two helper functions should be | ||
108 | used: | ||
109 | |||
110 | static inline void watchdog_set_drvdata(struct watchdog_device *wdd, void *data) | ||
111 | static inline void *watchdog_get_drvdata(struct watchdog_device *wdd) | ||
112 | |||
113 | The watchdog_set_drvdata function allows you to add driver specific data. The | ||
114 | arguments of this function are the watchdog device where you want to add the | ||
115 | driver specific data to and a pointer to the data itself. | ||
116 | |||
117 | The watchdog_get_drvdata function allows you to retrieve driver specific data. | ||
118 | The argument of this function is the watchdog device where you want to retrieve | ||
119 | data from. The function retruns the pointer to the driver specific data. | ||