Documentation/leds/uleds.rst
Source file repositories/reference/linux-study-clean/Documentation/leds/uleds.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/leds/uleds.rst- Extension
.rst- Size
- 1188 bytes
- Lines
- 38
- 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.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct uleds_user_dev
Annotated Snippet
struct uleds_user_dev {
char name[LED_MAX_NAME_SIZE];
};
A new LED class device will be created with the name given. The name can be
any valid sysfs device node name, but consider using the LED class naming
convention of "devicename:color:function".
The current brightness is found by reading a single byte from the character
device. Values are unsigned: 0 to 255. Reading will block until the brightness
changes. The device node can also be polled to notify when the brightness value
changes.
The LED class device will be removed when the open file handle to /dev/uleds
is closed.
Multiple LED class devices are created by opening additional file handles to
/dev/uleds.
See tools/leds/uledmon.c for an example userspace program.Annotation
- Detected declarations: `struct uleds_user_dev`.
- 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.