|author||Hans de Goede <email@example.com>||2011-09-12 11:56:59 +0200|
|committer||Wim Van Sebroeck <firstname.lastname@example.org>||2012-03-27 20:07:43 +0200|
watchdog: watchdog_dev: Let the driver update the timeout field on set_timeout success
When a set_timeout operation succeeds this does not necessarily mean that the exact timeout requested has been achieved, because the watchdog does not necessarily have a 1 second resolution. So rather then have the core set the timeout member of the watchdog_device struct to the exact requested value, instead the driver should set it to the actually achieved timeout value. Signed-off-by: Hans de Goede <email@example.com> Signed-off-by: Wim Van Sebroeck <firstname.lastname@example.org>
Diffstat (limited to 'Documentation/watchdog')
1 files changed, 4 insertions, 3 deletions
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
index 9e162465b0c..7d9d1da762b 100644
@@ -117,9 +117,10 @@ they are supported. These optional routines/operations are:
status of the device is reported with watchdog WDIOF_* status flags/bits.
* set_timeout: this routine checks and changes the timeout of the watchdog
timer device. It returns 0 on success, -EINVAL for "parameter out of range"
- and -EIO for "could not write value to the watchdog". On success the timeout
- value of the watchdog_device will be changed to the value that was just used
- to re-program the watchdog timer device.
+ and -EIO for "could not write value to the watchdog". On success this
+ routine should set the timeout value of the watchdog_device to the
+ achieved timeout value (which may be different from the requested one
+ because the watchdog does not necessarily has a 1 second resolution).
(Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
watchdog's info structure).
* ioctl: if this routine is present then it will be called first before we do