Linux USB Gadget (USB device-side Driver Analysis)

Linux-USB Gadget

Overview
The Linux-USB Gadget driver framework (hereinafter referred to as gadget) provides software functions for devices defined by the USB protocol.
Compared with the Linux USB host driver, the gadget driver appears later than 2.4.23.
The Gadget Framework proposes a set of standard APIs, which are driven by the underlying USB device controller (UDC ).
To implement this set of APIS, different UDC (usually part of the SOC) require different drivers, or even based on the same UDC
You also need to modify the code. This layer is called a platform-related layer.
Based on the API, the gadget driver implements a set of hardware-independent functions, which can basically correspond to various USB classes in the USB protocol,
There are also USB Gadget generic serial drivers with no corresponding class. Of course, the gadget driver is still limited by the underlying
For example, some classes require USB isochronous endpoints, so we cannot support this class.
A general gadget driver only implements one function (for example, a U disk or a USB Nic ). The composite device supports multiple functions, which will be carefully studied later
The implementation of the composite device. Devices such as smartphones and PDAs support a wide range of hardware endpoints and DMA buffers, providing software support for Compound
Basic functions.
There are two points worth noting: the first is that the USB gaget driver framework does not have the concept of USB core on the USB host, and the USB host may support
It makes sense to abstract general functions into hundreds of types of peripherals. USB device usually does not have this requirement. Some general functions are abstracted in some helper
Function. The second is the OTG concept proposed in USB 2.0, which can support the host and device functions on the same interface.
OTG is a complicated specification and will be studied later.

Driving Structure Analysis
A Linux USB driver consists of two parts. Some are USB device controller (UDC) drivers,
The other part is the hardware-independent function driver-the gadget Driver (such as the mouse, USB flash drive, USB serial port, USB network, etc.). It can also be divided into three layers, respectively
Yes: controller drivers, Gadget drivers, and upper layers.

I. Controller (USB device controller, UDC) Driver

The Gadget Framework proposes a set of standard APIs. At the underlying layer, the USB device controller driver implements this set of APIs. Different UDC requires different drivers and even
Code modifications are also required for different boards based on the same UDC. This layer is related to hardware.

The Linux standard kernel supports various mainstream soc udc drivers, such as S3C2410 and PXA270. You can directly configure the support through the kernel. You can also
Modify them to improve efficiency. For example, the DMA function of the controller is not used in s3c2410_uda.c. You can modify it as needed.

Common USB devices include USB drive, USB mouse, keyboard, USB bluetooth module, USB card reader, and so on. These devices are relatively simple and usually do not run Linux.
Running Linux gadget is usually a SoC (System-on-chip) that integrates CPU and many peripheral interfaces. the CPU is usually a 32-bit CPU,
UDC is also part of the SOC (along with DMA channels and FIFO ).

The Linux standard kernel supports mainstream soc udc drivers. Make menuconfig and you can see the specific list. It is worth mentioning that dummy_hcd,
It is a software-simulated UDC that is very helpful when developing a new gadget driver.

The controller driver processes a small number of USB control requests (mainly the hardware is responsible ). All other control requests, such as the return descriptor, are configured with the current configuration.
Complete. A major responsibility of the controller driver is to manage the I/O queues of various endpoints and transmit data (usually through DMA) between the buffer of the gadget driver and the hardware buffer ).

We mentioned earlier that the upper-layer gadget driver depends on the hardware conditions provided by the underlying layer to implement any functions. For example, a composite device requires at least five endpoints. These hardware features
Implemented through a set of gadget_is _ * () Functions

Ii. Gadget driver
Important drivers include:
Gadget zero: similar to dummy HCD, which is used to test the UDC driver. It will help you test through a USB-IF.

Ethernet Over USB: This driver simulates an Ethernet network port and supports multiple operating modes:

CDC Ethernet: communication device Class "Ethernet model" Protocol specified by USB specifications.

CDC subset: a method that has the lowest hardware requirements. It is mainly supported by Linux Hosts.

Rndis: Microsoft's implementation of the CDC Ethernet variant.

File-backed storage gadget is the most common U disk function implementation.

Serial gadget implementation, including:

Generic serial implementation (only the bulk-in/bulk-out endpoint + ep0 is required)

Cdc acm specification implementation.

The Gadget filesystem exposes the gadget API to the application layer to implement the user mode driver at the application layer.

MIDI: exposes the Alsa interface and provides recording and playback functions.

Reference: Baidu encyclopedia http://baike.baidu.com/view/319313.htm.
Liu Hongtao's column http://blog.csdn.net/hongtao_liu/article/details/4566548