Documentation/driver-api/usb/gadget.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/usb/gadget.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/usb/gadget.rst- Extension
.rst- Size
- 25105 bytes
- Lines
- 511
- 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
========================
USB Gadget API for Linux
========================
:Author: David Brownell
:Date: 20 August 2004
Introduction
============
This document presents a Linux-USB "Gadget" kernel mode API, for use
within peripherals and other USB devices that embed Linux. It provides
an overview of the API structure, and shows how that fits into a system
development project. This is the first such API released on Linux to
address a number of important problems, including:
- Supports USB 2.0, for high speed devices which can stream data at
several dozen megabytes per second.
- Handles devices with dozens of endpoints just as well as ones with
just two fixed-function ones. Gadget drivers can be written so
they're easy to port to new hardware.
- Flexible enough to expose more complex USB device capabilities such
as multiple configurations, multiple interfaces, composite devices,
and alternate interface settings.
- USB "On-The-Go" (OTG) support, in conjunction with updates to the
Linux-USB host side.
- Sharing data structures and API models with the Linux-USB host side
API. This helps the OTG support, and looks forward to more-symmetric
frameworks (where the same I/O model is used by both host and device
side drivers).
- Minimalist, so it's easier to support new device controller hardware.
I/O processing doesn't imply large demands for memory or CPU
resources.
Most Linux developers will not be able to use this API, since they have
USB ``host`` hardware in a PC, workstation, or server. Linux users with
embedded systems are more likely to have USB peripheral hardware. To
distinguish drivers running inside such hardware from the more familiar
Linux "USB device drivers", which are host side proxies for the real USB
devices, a different term is used: the drivers inside the peripherals
are "USB gadget drivers". In USB protocol interactions, the device
driver is the master (or "client driver") and the gadget driver is the
slave (or "function driver").
The gadget API resembles the host side Linux-USB API in that both use
queues of request objects to package I/O buffers, and those requests may
be submitted or canceled. They share common definitions for the standard
USB *Chapter 9* messages, structures, and constants. Also, both APIs
bind and unbind drivers to devices. The APIs differ in detail, since the
host side's current URB framework exposes a number of implementation
details and assumptions that are inappropriate for a gadget API. While
the model for control transfers and configuration management is
necessarily different (one side is a hardware-neutral master, the other
is a hardware-aware slave), the endpoint I/0 API used here should also
be usable for an overhead-reduced host side API.
Structure of Gadget Drivers
===========================
A system running inside a USB peripheral normally has at least three
layers inside the kernel to handle USB protocol processing, and may have
additional layers in user space code. The ``gadget`` API is used by the
middle layer to interact with the lowest level (which directly handles
hardware).
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.