summaryrefslogtreecommitdiffstats
path: root/Documentation/watchdog
diff options
context:
space:
mode:
authorRasmus Villemoes <rasmus.villemoes@prevas.dk>2019-06-05 14:06:41 +0000
committerWim Van Sebroeck <wim@linux-watchdog.org>2019-07-08 20:04:13 +0200
commit4d1c6a0ec2d98e51f950127bf9299531caac53e1 (patch)
treef0d20f2efbe881941a54ebb6efa62bceb7089ad5 /Documentation/watchdog
parent8c21ead3ea5d896946fb5d85b52b0be757e9bef4 (diff)
downloadlinux-stable-4d1c6a0ec2d98e51f950127bf9299531caac53e1.tar.gz
linux-stable-4d1c6a0ec2d98e51f950127bf9299531caac53e1.tar.bz2
linux-stable-4d1c6a0ec2d98e51f950127bf9299531caac53e1.zip
watchdog: introduce watchdog.open_timeout commandline parameter
The watchdog framework takes care of feeding a hardware watchdog until userspace opens /dev/watchdogN. If that never happens for some reason (buggy init script, corrupt root filesystem or whatnot) but the kernel itself is fine, the machine stays up indefinitely. This patch allows setting an upper limit for how long the kernel will take care of the watchdog, thus ensuring that the watchdog will eventually reset the machine. A value of 0 (the default) means infinite timeout, preserving the current behaviour. This is particularly useful for embedded devices where some fallback logic is implemented in the bootloader (e.g., use a different root partition, boot from network, ...). There is already handle_boot_enabled serving a similar purpose. However, such a binary choice is unsuitable if the hardware watchdog cannot be programmed by the bootloader to provide a timeout long enough for userspace to get up and running. Many of the embedded devices we see use external (gpio-triggered) watchdogs with a fixed timeout of the order of 1-2 seconds. The open timeout only applies for the first open from userspace. Should userspace need to close the watchdog device, with the intention of re-opening it shortly, the application can emulate the open timeout feature by combining the nowayout feature with an appropriate WDIOC_SETTIMEOUT immediately prior to closing the device. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Diffstat (limited to 'Documentation/watchdog')
-rw-r--r--Documentation/watchdog/watchdog-parameters.txt8
1 files changed, 8 insertions, 0 deletions
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 0b88e333f9e1..32d3606caa65 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -8,6 +8,14 @@ See Documentation/admin-guide/kernel-parameters.rst for information on
providing kernel parameters for builtin drivers versus loadable
modules.
+The watchdog core parameter watchdog.open_timeout is the maximum time,
+in seconds, for which the watchdog framework will take care of pinging
+a running hardware watchdog until userspace opens the corresponding
+/dev/watchdogN device. A value of 0 (the default) means an infinite
+timeout. Setting this to a non-zero value can be useful to ensure that
+either userspace comes up properly, or the board gets reset and allows
+fallback logic in the bootloader to try something else.
+
-------------------------------------------------
acquirewdt: