Linux subsystem series-USB

I recently investigated a problem with Musb. I simply sorted out the frame of USB, and I made a record this time. I can outline it.

/*************************************** **************************/

Directory

0, Background

1. USB subsystem structure

2. Implementation of the USB subsystem

0, Background

When we first got in touch with the USB flash drive, we had to manually find the new hardware and install the driver before we could access it. Later, the USB flash drive could be used as soon as it was plugged in. At that time, it was very lazy, I don't think much about the principle, so I think it's amazing ......

In the future, I will deal with this kind of things to find that not only USB, but all other bus that support the plug-and-play function will be interrupted (it can be regarded as a hardware Specification) and some driver programming specifications.

The hardware specification can be applied to any device as long as it meets some simple interface design requirements (the rest is handed over to the driver ), this is also the design principle of computer loader (various operating systems can be started.

No rules, not a square view!

No specification, no driver !!

The USB specification manual describes a bus that can be connected to many devices (mass storage, keyboards, mice, etc .), multiple devices can communicate with the host stably.

Based on this specification, the Linux Kernel provides a USB subsystem driver.

Note that the USB sub-system in Linux only provides drivers for devices of the predefined category. For those exceptions, a specific device driver is required.

1. USB subsystem structure

Recall that the data structure was not well learned in college. At that time, I felt that I didn't know what to do, and I couldn't relate to the actual things, so my interests would go down and go ...... this is a prefix. It's not displayed yet.

Here we will start by describing how a USB device works when it is plugged into the host, to understand its general framework:

USB flash drives are inserted into the computer. According to the hardware specifications of the USB bus, an interruption is generated to the CPU,

The CPU calls the related interrupt function based on the interrupt number sent by the interrupt manager. If it is a shared number, the interrupt function checks the registers that share the hardware, check whether there is any interruption, and then call to complete the work to be done by each hardware device. All hardware is designed according to some specifications, and the collaboration between them becomes so beautiful... for example, if there are no rules between people and society, it will become messy, and the interrupt function called by USB device insertion will issue an event, this event will be sent to user space udevd (or mdevd, if you use busybox ), udevd inserts the corresponding module based on some data in the event and mounts the driver of the device ...... this process is briefly described as follows: although, so far, I have always thought that it is very complicated to use software to abstract the description of the USB bus and USB devices. On the one hand, it is caused by the Protocol, on the one hand, they are used too widely and there are too many situations to consider in abstraction. Fortunately, the kernel USB subsystem abstracted by kernel developers hides a lot of complexity (a group of people who love and hate us :)). In this way, we will naturally be interested in the software implementation ideas and layers. Here we will give a brief overview:

To understand what a USB sub-system is, we need to explain the following: a) the USB driver is a kubernetes sub-system, because the USB device is finally presented to us through the blcock or char device, we can see that there is another layer above the USB driver. B) the USB driver uses the APIS provided by the USB core to easily and elegantly complete the driver work. Here, the USB core abstracts the complicated USB protocol. C) The host controller driver is located at the bottom of the USB software and provides the abstraction of the host controller hardware to hide hardware details, under the host controller is a physical USB and all USB devices connected to it. The host controller driver is only associated with the USB core. The USB core maps user requests to the relevant host controller driver, so that you do not need to access the host controller. D) USB core and USB Host Controller drivers constitute our USB subsystem. USB core is responsible for implementing some core functions, such as protocols, provides an interface for accessing and controlling USB hardware, so that the device driver does not need to consider which host controller is currently used by the system. With the USB subsystem, when writing a USB driver, you only need to call the USB core export interface to complete almost all the work. 2. the USB sub-system implements 2.1 initialization first, wondering how the USB device is abstracted: a) a USB will be composed of one or more configurations. B) A configuration is composed of one or more interfaces. c) an interface is composed of one or more setting interfaces. d) an Interface contains 0 or multiple endpointusb devices and the communication channel of the host is called endpoint: control, interrupt, bulk, and isochronousinterface.

A usb driver is bound to the interface of a USB device.

In the USB subsystem, the USB _ device_id data structure is used to match the USB device and the corresponding driver. For ease of use, USB core provides some macros to help establish this data structure. According to the conventions, this table will be export in the driver (using the module_device_table macro). During the Build stage, this table will be written to the module database and used by udev later. Any driver must be registered at the beginning. In the USB subsystem, the driver is registered by the usb_register function using the usb_drivr data structure. The probe function is called when the USB core determines that it has found a driver for the interface of a device. The probe function performs many important tasks, such as allocating space for interface-related data and registering other kernel subsystems (Block, Char, net, tty, etc) based on interface features) 2.2 communication in most cases, USB device communication works on the software layer using USB request blocks (urb. Urb uses an Asynchronous Method to send or receive data at the endpoint. After each urb is initialized and assigned a value, it is submitted to the USB core for subsequent work. Using urb for communication involves the use of many USB core APIs. Sometimes users want to simplify their usage, such as lazy people like me. The cute kernel developer provides us with some interfaces, we can easily complete the communication of the USB endpoint without the urb operation (in fact, the urb operation is encapsulated)