Documentation/admin-guide/gpio/gpio-virtuser.rst
Source file repositories/reference/linux-study-clean/Documentation/admin-guide/gpio/gpio-virtuser.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/admin-guide/gpio/gpio-virtuser.rst- Extension
.rst- Size
- 7177 bytes
- Lines
- 178
- 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
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0-only
Virtual GPIO Consumer
=====================
The virtual GPIO Consumer module allows users to instantiate virtual devices
that request GPIOs and then control their behavior over debugfs. Virtual
consumer devices can be instantiated from device-tree or over configfs.
A virtual consumer uses the driver-facing GPIO APIs and allows to cover it with
automated tests driven by user-space. The GPIOs are requested using
``gpiod_get_array()`` and so we support multiple GPIOs per connector ID.
Creating GPIO consumers
-----------------------
The gpio-consumer module registers a configfs subsystem called
``'gpio-virtuser'``. For details of the configfs filesystem, please refer to
the configfs documentation.
The user can create a hierarchy of configfs groups and items as well as modify
values of exposed attributes. Once the consumer is instantiated, this hierarchy
will be translated to appropriate device properties. The general structure is:
**Group:** ``/config/gpio-virtuser``
This is the top directory of the gpio-consumer configfs tree.
**Group:** ``/config/gpio-consumer/example-name``
**Attribute:** ``/config/gpio-consumer/example-name/live``
**Attribute:** ``/config/gpio-consumer/example-name/dev_name``
This is a directory representing a GPIO consumer device.
The read-only ``dev_name`` attribute exposes the name of the device as it will
appear in the system on the platform bus. This is useful for locating the
associated debugfs directory under
``/sys/kernel/debug/gpio-virtuser/$dev_name``.
The ``'live'`` attribute allows to trigger the actual creation of the device
once it's fully configured. The accepted values are: ``'1'`` to enable the
virtual device and ``'0'`` to disable and tear it down.
Creating GPIO lookup tables
---------------------------
Users can create a number of configfs groups under the device group:
**Group:** ``/config/gpio-consumer/example-name/con_id``
The ``'con_id'`` directory represents a single GPIO lookup and its value maps
to the ``'con_id'`` argument of the ``gpiod_get()`` function. For example:
``con_id`` == ``'reset'`` maps to the ``reset-gpios`` device property.
Users can assign a number of GPIOs to each lookup. Each GPIO is a sub-directory
with a user-defined name under the ``'con_id'`` group.
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/key``
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/offset``
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/drive``
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/pull``
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/active_low``
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/transitory``
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.