Documentation/driver-api/gpio/board.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/gpio/board.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/gpio/board.rst- Extension
.rst- Size
- 10522 bytes
- Lines
- 279
- 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
linux/property.hlinux/gpio/machine.hlinux/gpio/property.h
Detected Declarations
function gpiod_getfunction gpio_foo_register
Annotated Snippet
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPI0", 0, ResourceConsumer) { 15 } // red
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPI0", 0, ResourceConsumer) { 16 } // green
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPI0", 0, ResourceConsumer) { 17 } // blue
GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPI0", 0, ResourceConsumer) { 1 } // power
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"led-gpios",
Package () {
^FOO, 0, 0, 1,
^FOO, 1, 0, 1,
^FOO, 2, 0, 1,
}
},
Package () { "power-gpios", Package () { ^FOO, 3, 0, 0 } },
}
})
}
For more information about the ACPI GPIO bindings see
Documentation/firmware-guide/acpi/gpio-properties.rst.
Software Nodes
--------------
Software nodes allow board-specific code to construct an in-memory,
device-tree-like structure using struct software_node and struct
property_entry. This structure can then be associated with a platform device,
allowing drivers to use the standard device properties API to query
configuration, just as they would on an ACPI or device tree system.
Software-node-backed GPIOs are described using the ``PROPERTY_ENTRY_GPIO()``
macro, which ties a software node representing the GPIO controller with
consumer device. It allows consumers to use regular gpiolib APIs, such as
gpiod_get(), gpiod_get_optional().
The software node representing a GPIO controller must be attached to the
GPIO controller device - either as the primary or the secondary firmware node.
For example, here is how to describe a single GPIO-connected LED. This is an
alternative to using platform_data on legacy systems.
.. code-block:: c
#include <linux/property.h>
#include <linux/gpio/machine.h>
#include <linux/gpio/property.h>
/*
* 1. Define a node for the GPIO controller.
*/
static const struct software_node gpio_controller_node = {
.name = "gpio-foo",
};
/* 2. Define the properties for the LED device. */
static const struct property_entry led_device_props[] = {
PROPERTY_ENTRY_STRING("label", "myboard:green:status"),
PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
PROPERTY_ENTRY_GPIO("gpios", &gpio_controller_node, 42, GPIO_ACTIVE_HIGH),
{ }
};
Annotation
- Immediate include surface: `linux/property.h`, `linux/gpio/machine.h`, `linux/gpio/property.h`.
- Detected declarations: `function gpiod_get`, `function gpio_foo_register`.
- 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.