Documentation/devicetree/bindings/input/input-reset.txt
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/input/input-reset.txt
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/input/input-reset.txt- Extension
.txt- Size
- 1060 bytes
- Lines
- 34
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
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
Input: sysrq reset sequence
A simple binding to represent a set of keys as described in
include/uapi/linux/input.h. This is to communicate a sequence of keys to the
sysrq driver. Upon holding the keys for a specified amount of time (if
specified) the system is sync'ed and reset.
Key sequences are global to the system but all the keys in a set must be coming
from the same input device.
The /chosen node should contain a 'linux,sysrq-reset-seq' child node to define
a set of keys.
Required property:
keyset: array of Linux keycodes, one keycode per cell.
Optional property:
timeout-ms: duration keys must be pressed together in milliseconds before
generating a sysrq. If omitted the system is rebooted immediately when a valid
sequence has been recognized.
Example:
chosen {
linux,sysrq-reset-seq {
keyset = <0x03
0x04
0x0a>;
timeout-ms = <3000>;
};
};
Would represent KEY_2, KEY_3 and KEY_9.
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
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.