Lines Matching refs:watchdog
12 file: Documentation/watchdog/watchdog-api.txt .
18 a watchdog timer driver then only needs to provide the different routines
19 (operations) that control the watchdog timer (WDT).
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
31 The watchdog_register_device routine registers a watchdog timer device.
35 The watchdog_unregister_device routine deregisters a registered watchdog timer
39 The watchdog device structure looks like this:
60 /dev/watchdog miscdev. The id is set automatically when calling
62 * cdev: cdev for the dynamic /dev/watchdog<id> device nodes. This
64 * dev: device under the watchdog class (created by watchdog_register_device).
68 additional information about the watchdog timer itself. (Like it's unique name)
69 * ops: a pointer to the list of watchdog operations that the watchdog supports.
70 * timeout: the watchdog timer's timeout value (in seconds).
71 * min_timeout: the watchdog timer's minimum timeout value (in seconds).
72 * max_timeout: the watchdog timer's maximum timeout value (in seconds).
73 * bootstatus: status of the device after booting (reported with watchdog
75 * driver_data: a pointer to the drivers private data of a watchdog device.
80 information about the status of the device (Like: is the watchdog timer
82 the /dev/watchdog interface or not, ...).
84 The list of watchdog operations is defined as:
101 It is important that you first define the module owner of the watchdog timer
103 the watchdog is active. (This to avoid a system crash when you unload the
104 module and /dev/watchdog is still open).
122 * start: this is a pointer to the routine that starts the watchdog timer
124 The routine needs a pointer to the watchdog timer device structure as a
126 * stop: with this routine the watchdog timer device is being stopped.
127 The routine needs a pointer to the watchdog timer device structure as a
129 Some watchdog timer hardware can only be started and not be stopped. The
132 that regularly sends a keepalive ping to the watchdog timer hardware.
134 Not all watchdog timer hardware supports the same functionality. That's why
137 * ping: this is the routine that sends a keepalive ping to the watchdog timer
139 The routine needs a pointer to the watchdog timer device structure as a
142 start function to restart the watchdog timer hardware. And that's also what
143 the watchdog timer driver core does: to send a keepalive ping to the watchdog
147 WDIOF_KEEPALIVEPING bit has been set in the option field on the watchdog's
149 * status: this routine checks the status of the watchdog timer device. The
150 status of the device is reported with watchdog WDIOF_* status flags/bits.
151 * set_timeout: this routine checks and changes the timeout of the watchdog
153 and -EIO for "could not write value to the watchdog". On success this
156 because the watchdog does not necessarily has a 1 second resolution).
158 watchdog's info structure).
171 * WDOG_ACTIVE: this status bit indicates whether or not a watchdog timer device
172 is active or not. When the watchdog is active after booting, then you should
173 set this status bit (Note: when you register the watchdog timer device with
174 this bit set, then opening /dev/watchdog will skip the start operation)
175 * WDOG_DEV_OPEN: this status bit shows whether or not the watchdog device
176 was opened via /dev/watchdog.
181 * WDOG_NO_WAY_OUT: this bit stores the nowayout setting for the watchdog.
182 If this bit is set then the watchdog timer will not be able to stop.
187 reference to /dev/watchdog
189 To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog
199 WDIOF_MAGICCLOSE bit in the options field of the watchdog's info structure.
209 arguments of this function are the watchdog device where you want to add the
213 The argument of this function is the watchdog device where you want to retrieve