Lines Matching +full:timer +full:- +full:watchdog
2 The Linux WatchDog Timer Driver Core kernel API
5 Last reviewed: 12-Feb-2013
10 ------------
11 This document does not describe what a WatchDog Timer (WDT) Driver or Device is.
13 with a WatchDog Timer. If you want to know this then please read the following
14 file: Documentation/watchdog/watchdog-api.rst .
17 WatchDog Timer Drivers that want to use the WatchDog Timer Driver Core
20 a watchdog timer driver then only needs to provide the different routines
21 (operations) that control the watchdog timer (WDT).
24 -------
25 Each watchdog timer driver that wants to use the WatchDog Timer Driver Core
26 must #include <linux/watchdog.h> (you would have to do this anyway when
27 writing a watchdog device driver). This include file contains following
33 The watchdog_register_device routine registers a watchdog timer device.
37 The watchdog_unregister_device routine deregisters a registered watchdog timer
41 The watchdog subsystem includes an registration deferral mechanism,
42 which allows you to register an watchdog as early as you wish during
45 The watchdog device structure looks like this::
73 /dev/watchdog miscdev. The id is set automatically when calling
77 * groups: List of sysfs attribute groups to create when creating the watchdog
80 additional information about the watchdog timer itself. (Like its unique name)
81 * ops: a pointer to the list of watchdog operations that the watchdog supports.
82 * gov: a pointer to the assigned watchdog device pretimeout governor or NULL.
83 * timeout: the watchdog timer's timeout value (in seconds).
86 * pretimeout: the watchdog timer's pretimeout value (in seconds).
87 * min_timeout: the watchdog timer's minimum timeout value (in seconds).
89 * max_timeout: the watchdog timer's maximum timeout value (in seconds),
91 'timeout'. Not used if max_hw_heartbeat_ms is non-zero.
93 in milli-seconds. This value is normally 0; it should only be provided
95 * max_hw_heartbeat_ms: Maximum hardware heartbeat, in milli-seconds.
96 If set, the infrastructure will send heartbeats to the watchdog driver
102 internal use only. If the driver calls watchdog_stop_on_reboot, watchdog core
103 will stop the watchdog on such notifications.
105 internal use only. If a watchdog is capable of restarting the machine, it
106 should define ops->restart. Priority can be changed through
108 * bootstatus: status of the device after booting (reported with watchdog
110 * driver_data: a pointer to the drivers private data of a watchdog device.
113 * wd_data: a pointer to watchdog core internal data.
115 information about the status of the device (Like: is the watchdog timer
120 The list of watchdog operations is defined as::
137 It is important that you first define the module owner of the watchdog timer
139 the watchdog is active. (This to avoid a system crash when you unload the
140 module and /dev/watchdog is still open).
145 * start: this is a pointer to the routine that starts the watchdog timer
147 The routine needs a pointer to the watchdog timer device structure as a
150 Not all watchdog timer hardware supports the same functionality. That's why
154 * stop: with this routine the watchdog timer device is being stopped.
156 The routine needs a pointer to the watchdog timer device structure as a
158 Some watchdog timer hardware can only be started and not be stopped. A
161 If a driver has no stop function, the watchdog core will set WDOG_HW_RUNNING
162 and start calling the driver's keepalive pings function after the watchdog
165 If a watchdog driver does not implement the stop function, it must set
167 * ping: this is the routine that sends a keepalive ping to the watchdog timer
170 The routine needs a pointer to the watchdog timer device structure as a
174 start function to restart the watchdog timer hardware. And that's also what
175 the watchdog timer driver core does: to send a keepalive ping to the watchdog
176 timer hardware it will either use the ping operation (when available) or the
180 WDIOF_KEEPALIVEPING bit has been set in the option field on the watchdog's
182 * status: this routine checks the status of the watchdog timer device. The
183 status of the device is reported with watchdog WDIOF_* status flags/bits.
185 WDIOF_MAGICCLOSE and WDIOF_KEEPALIVEPING are reported by the watchdog core;
187 function is provided by the driver, the watchdog core reports the status bits
190 * set_timeout: this routine checks and changes the timeout of the watchdog
191 timer device. It returns 0 on success, -EINVAL for "parameter out of range"
192 and -EIO for "could not write value to the watchdog". On success this
195 because the watchdog does not necessarily have a 1 second resolution).
197 Drivers implementing max_hw_heartbeat_ms set the hardware watchdog heartbeat
202 watchdog's info structure).
204 If the watchdog driver does not have to perform any action but setting the
207 If set_timeout is not provided but, WDIOF_SETTIMEOUT is set, the watchdog
212 also take care of checking if pretimeout is still valid and set up the timer
216 the watchdog. It is optional because not all watchdogs support pretimeout
219 -EINVAL for "parameter out of range" and -EIO for "could not write value to
220 the watchdog". A value of 0 disables pretimeout notification.
223 watchdog's info structure).
225 If the watchdog driver does not have to perform any action but setting the
227 set_pretimeout is not provided but WDIOF_PRETIMEOUT is set, the watchdog
235 our own internal ioctl call handling. This routine should return -ENOIOCTLCMD
240 bit-operations. The status bits that are defined are:
242 * WDOG_ACTIVE: this status bit indicates whether or not a watchdog timer device
245 * WDOG_NO_WAY_OUT: this bit stores the nowayout setting for the watchdog.
246 If this bit is set then the watchdog timer will not be able to stop.
247 * WDOG_HW_RUNNING: Set by the watchdog driver if the hardware watchdog is
248 running. The bit must be set if the watchdog timer hardware can not be
249 stopped. The bit may also be set if the watchdog timer is running after
250 booting, before the watchdog device is opened. If set, the watchdog
251 infrastructure will send keepalives to the watchdog hardware while
253 Note: when you register the watchdog timer device with this bit set,
254 then opening /dev/watchdog will skip the start operation but send a keepalive
257 To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog
258 timer device) you can either:
271 The WatchDog Timer Driver Core supports the magic close feature and
273 WDIOF_MAGICCLOSE bit in the options field of the watchdog's info structure.
285 arguments of this function are the watchdog device where you want to add the
289 The argument of this function is the watchdog device where you want to retrieve
299 using the module timeout parameter or by retrieving the timeout-sec property from
305 To disable the watchdog on reboot, the user must call the following helper::
309 To disable the watchdog when unregistering the watchdog, the user must call
310 the following helper. Note that this will only stop the watchdog if the
333 The function can be called in the interrupt context. If watchdog pretimeout
336 the watchdog device. If watchdog pretimeout governor framework is not
340 To set the last known HW keepalive time for a watchdog, the following function
346 This function must be called immediately after watchdog registration. It
348 current time. Calling this is only needed if the watchdog is already running
349 when probe is called, and the watchdog can only be pinged after the