drivers/watchdog/Kconfig
Source file repositories/reference/linux-study-clean/drivers/watchdog/Kconfig
File Facts
- System
- Linux kernel
- Corpus path
drivers/watchdog/Kconfig- Extension
[no extension]- Size
- 75539 bytes
- Lines
- 2356
- Domain
- Driver Families
- Bucket
- drivers/watchdog
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: GPL-2.0-only
#
# Watchdog device configuration
#
menuconfig WATCHDOG
bool "Watchdog Timer Support"
help
If you say Y here (and to one of the following options) and create a
character special file /dev/watchdog with major number 10 and minor
number 130 using mknod ("man mknod"), you will get a watchdog, i.e.:
subsequently opening the file and then failing to write to it for
longer than 1 minute will result in rebooting the machine. This
could be useful for a networked machine that needs to come back
on-line as fast as possible after a lock-up. There's both a watchdog
implementation entirely in software (which can sometimes fail to
reboot the machine) and a driver for hardware watchdog boards, which
are more robust and can also keep track of the temperature inside
your computer. For details, read
<file:Documentation/watchdog/watchdog-api.rst> in the kernel source.
The watchdog is usually used together with the watchdog daemon
which is available from
<https://ibiblio.org/pub/Linux/system/daemons/watchdog/>. This daemon
can also monitor NFS connections and can reboot the machine when the
process table is full.
If unsure, say N.
if WATCHDOG
config WATCHDOG_CORE
tristate "WatchDog Timer Driver Core"
help
Say Y here if you want to use the new watchdog timer driver core.
This driver provides a framework for all watchdog timer drivers
and gives them the /dev/watchdog interface (and later also the
sysfs interface).
config WATCHDOG_NOWAYOUT
bool "Disable watchdog shutdown on close"
help
The default watchdog behaviour (which you get if you say N here) is
to stop the timer if the process managing it closes the file
/dev/watchdog. It's always remotely possible that this process might
get killed. If you say Y here, the watchdog cannot be stopped once
it has been started.
config WATCHDOG_HANDLE_BOOT_ENABLED
bool "Update boot-enabled watchdog until userspace takes over"
default y
help
The default watchdog behaviour (which you get if you say Y here) is
to ping watchdog devices that were enabled before the driver has
been loaded until control is taken over from userspace using the
/dev/watchdog file. If you say N here, the kernel will not update
the watchdog on its own. Thus if your userspace does not start fast
enough your device will reboot.
config WATCHDOG_OPEN_TIMEOUT
int "Timeout value for opening watchdog device"
default 0
help
The maximum time, in seconds, for which the watchdog framework takes
care of pinging a hardware watchdog. A value of 0 means infinite. The
value set here can be overridden by the commandline parameter
"watchdog.open_timeout".
config WATCHDOG_SYSFS
Annotation
- Atlas domain: Driver Families / drivers/watchdog.
- Implementation status: integration implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.