Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "the workflow of the USB driver in the Linux system". In the operation of the actual case, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1.USB host

In the Linux driver, the USB driver at the bottom is the USB host controller hardware, on which runs the USB host controller driver. Above the host controller is the USB core layer, and then the upper layer is the USB device driver layer (plugged into the U disk, mouse, USB to serial port and other device drivers on the host).

Therefore, in the hierarchical structure of the host side, the USB drivers to be implemented include two types: the USB host controller driver and the USB device driver, the former controls the USB device inserted into it, and the latter controls how the USB device communicates with the host. The USB core of Linux kernel is responsible for the main work of USB driver management and protocol processing. The USB core between host controller driver and device driver is very important, its functions include: by defining some data structures, macros and function functions, it provides programming interface for device driver up and down for USB host controller driver; maintains USB device information of the whole system through global variables; completes device hot plug control, bus data transmission control and so on.

2.USB equipment

The USB device side driver in Linux kernel is divided into three levels: UDC driver, Gadget API driver and Gadget driver. The UDC driver accesses the hardware directly, controls the bottom communication between the USB device and the host, and provides the callback function of the hardware-related operation to the upper layer. The current Gadget API is a simple wrapper around the callback function of the UDC driver. The Gadget driver specifically controls the realization of the function of the USB device, so that the device shows the characteristics of "network connection", "printer" or "USB Mass Storage". It uses Gadget API to control UDC to achieve the above functions. Gadget API separates the UDC driver of the lower layer from the Gadget driver of the upper layer, which makes it possible to separate the implementation of the function from the underlying communication when writing the USB device side driver in the Linux system.

3. Layers

In the organizational structure of USB equipment, it is divided into four levels: device (device), configuration (config), interface (interface) and endpoint (endpoint) from top to bottom. The USB device program is bound to the interface.

A brief description of these four levels is as follows:

(1) the device usually has one or more configurations

(2) configurations often have one or more interfaces

(3) the interface does not have or has more than one endpoint

4. End point

The most basic form of USB communication is through endpoints (USB endpoints are divided into interrupt (Interrupt), batch (Bulk), isochronous (ISO), and control (Control), each for different purposes. USB endpoints can only transmit data to one direction, from host to device or from device to host, endpoints can be regarded as one-way pipes (pipe). The driver registers the driver object with the USB subsystem and later uses the manufacturer and device ID to determine whether the hardware has been installed. The USB core uses a list (a structure containing the manufacturer's ID and the device number ID) to determine which driver to use for a device, and the hotplug script uses it to determine which driver's Probe should be executed automatically when a particular device is plugged into the system.

5. Data structure

(1) USB device: corresponding data structure struct usb_device

(2) configuration: struct usb_host_config (only one configuration can take effect at any one time)

(3) USB interface: struct usb_interface (USB core transfers it to USB device driver, and USB device driver is responsible for subsequent control. An USB interface represents a basic function, and each USB driver controls an interface. So a physical hardware device may require more than one driver. )

(4) Endpoint: struct usb_host_endpoint, which contains real endpoint information in another structure: struct usb_endpoint_descriptor (endpoint descriptor, which contains all USB-specific data).

6. USB endpoint classification

The most basic form of USB communication is through something called an endpoint. A USB endpoint can transfer data in only one direction (from the host to the device (called the output endpoint) or from the device to the host (called the input endpoint). The endpoint can be thought of as an one-way pipe.

There are four different types of USB endpoints, each with different data transfer modes:

The control endpoint is used to control access to different parts of the USB device. It is commonly used to configure a device, obtain device information, send commands to a device, or obtain a device status report. These endpoints are usually small. Each USB device has a control endpoint called Endpoint 0, which is used by the USB core to configure the device when plugged in. The USB protocol ensures that there is always enough bandwidth for the control endpoint to transmit data to the device.

(2) interrupt INTERRUPT

Whenever the USB host requests data from the device, the interrupt endpoint transmits a small amount of data at a fixed rate. This is the main data transfer method for USB keyboard and mouse. It is also used to transfer data to the USB device to control the device. Not usually used to transmit large amounts of data. The USB protocol ensures that there is always enough bandwidth for the interrupt endpoint to transmit data to the device.

Batch endpoints are used to transmit large amounts of data. These endpoints are usually much larger than interrupt endpoints. They are commonly used in situations where there can be no data loss. The USB protocol does not guarantee that the transmission will be completed within a specific time frame. If there is not enough space on the bus to send the entire BULK packet, it is divided into multiple packets for transmission. These endpoints are commonly used on printers, USB Mass Storage, and USB network devices.

Isochronous endpoints also send large amounts of data in bulk, but this data is not guaranteed to be delivered. These endpoints are used in devices that can handle data loss and rely more on maintaining a continuous data stream. Such as audio and video equipment and so on.

Control and batch endpoints are used for asynchronous data transfer, while interrupts and isochronous endpoints are periodic. This means that these endpoints are set to transmit data continuously at a fixed time, and the USB core reserves the corresponding bandwidth for them.

7. Endpoint

Copy the content to the clipboard with Candlestick + Code

Struct usb_host_endpoint {

Struct usb_endpoint_descriptor desc;// endpoint descriptor

Struct list_head urb_list;// URB alignment of this endpoint, maintained by the USB core

Void * hcpriv

Struct ep_device * ep_dev; / * For sysfs info * /

Unsigned char*extra;/* Extra descriptors * /

Int extralen

Int enabled

}

When the USB device driver calls usb_submit_urb to submit the urb request, int usb_hcd_link_urb_to_ep (struct usb_hcd * hcd, struct urb * urb) is called to add the urb to the tail of the urb_list. (hcd: Host Controller Driver, corresponding to the data structure struct usb_hcd)

8. Urb

All USB communications are in request-> response mode, and USB devices do not actively send data to Host. Write data: the USB device driver sends a urb request to the USB device, and the USB device does not need to return data. Read data: the USB device driver sends a urb request to the USB device, and the USB device needs to return data.

The USB device driver communicates with all USB devices through urb. Urb uses struct urb structure description (include/linux/usb.h).

Urb sends or receives data asynchronously to a specific endpoint of a particular USB device. A USB device driver can assign multiple urb to one endpoint or reuse a single urb to multiple different endpoints according to the needs of the driver. Each endpoint in the device processes a urb queue, so multiple urb can be sent to the same endpoint before the queue is emptied.

The typical life cycle of a urb is as follows:

(1) created

(2) specific endpoints assigned to a particular USB device

(3) submitted to the USB core

(4) specific USB host controller drivers submitted to specific devices by the USB core

(5) be driven and processed by USB host controller and transmitted to the device

(6) after the above operations are completed, the USB host controller driver notifies the USB device driver.

Urb can also be submitted to its driver to cancel at any time; if the device is removed, urb can be cancelled by the USB core. Urb is created dynamically and contains an internal reference count so that they can be automatically released when the last user releases them.

8.1 submit urb

Once the urb is properly created and initialized, it can be submitted to the USB core for sending to the USB device. This is achieved by calling the function sb_submit_urb.

Int usb_submit_urb (struct urb * urb, gfp_t mem_flags)

Parameters:

Struct urb * urb: pointer to the submitted urb

Gfp_t mem_flags: use the same parameters passed to kmalloc to tell the USB core how to allocate memory buffers in a timely manner

Because the function usb_submit_urb can be called at any time (including from an interrupt context), the mem_flags variable must be set correctly. Based on the time when usb_submit_urb was called, only three valid values are available:

GFP_ATOMIC

This value should be used as long as the following conditions are met:

1) the caller is in a urb end routine, interrupt routine, bottom half, tasklet or a timer callback function.

2) the caller holds a spin lock or a read-write lock. Note that if you are holding a semaphore, this value is not necessary.

3) current- > state is not TASK_RUNNING. Unless the driver has changed the current state itself, the state should always be TASK_RUNNING.

GFP_NOIO

The driver is in the process of block Imax O processing. It should also be used in error handling for all storage types.

GFP_KERNEL

All other cases that are not mentioned earlier.

After the urb is successfully submitted to the USB core, no member of the urb structure can be accessed until the end handler function is called

If usb_submit_urb is successfully called and control of urb is passed to the USB core, the function returns 0; otherwise, a negative error code is returned. If the function call is successful, the closing routine will be called once when the urb is terminated. When this function is called, the USB core completes the urb and returns its control to the device driver.

There are only three cases in which the urb ends and the end processing routine is called:

(1) the urb is successfully sent to the device and the device returns a correct acknowledgment. If so, the status variable in urb is set to 0. 0.

(2) an error occurs and the error value is recorded in the status variable in the urb structure.

This happens either when the driver calls usb_unlink_urb or usb_kill_urb to tell the USB core to cancel a submitted urb, or when a urb has been submitted to it, the device is removed from the system.

9. Detect and disconnect

In the struct usb_driver structure, there are two functions that the USB core calls when appropriate:

(1) when the device is plugged in, if the USB core thinks that the driver can be processed (the USB core uses a list (a structure containing the manufacturer ID and the device number ID) to determine which driver should be used for a device, then call the probe function, which checks the device information passed to it, and determines whether the driver is really suitable for the device.

(2) for some reason, when the device is removed or the driver no longer controls the device, the disconnect function is called to do the appropriate cleaning.

Both the probe and disconnect callback functions are called in the context of the kernel thread in the USB hub, so they hibernate legally. In order to shorten the USB detection time, most of the work is done when the device is turned on as much as possible. This is because the USB core handles the addition and removal of USB devices in a single thread, so any slow device driver can make USB device detection time longer.

In order to communicate with the device, the USB driver usually probes the endpoint address and buffer size of the device.

Knowledge supplement of PS:Linux USB driver related details

1. The callback function needs to be specified in usb_fill_bulk_urb,usb_fill_int_urb,usb_fill_control_urb. When the URB request is completed, the usb core callback uses this function.

Note: the urb callback function runs in the interrupt context, so it should not do any memory allocation, hold any semaphores, or anything that can cause the process to sleep. If you commit urb from the callback and need to allocate a new memory block, use the GFP_ATOMIC flag to tell the USB core not to sleep.

2. Urb encapsulates the function:

(1) int usb_bulk_msg (struct usb_device * usb_dev,unsigned int pipe,void*data, int len, int*actual_length,int timeout)

Function: create a batch urb and send it to the specified device, then wait for completion before returning.

Parameters:

Struct usb_device * usb_dev: target USB device pointer

Unsigned int pipe: a specific endpoint of the target USB device. Must be created with a specific macro.

Void * data: in the case of an OUT endpoint, a pointer to the data to be sent to the device. In the case of an IN endpoint, this is the buffer pointer to the data read from the device.

Int len: the length of the buffer pointed to by the data parameter

Int * actual_length: a pointer to a function that places the real number of bytes that are either sent to or read from the device, depending on the direction of the endpoint.

Int timeout: the clock ticks, the time it should wait. If 0, the function always waits for the operation to complete.

Return value: successfully returned 0 the number of bytes transferred or read from the device.

(2) int usb_control_msg (struct usb_device*dev, unsigned int pipe, _ _ U8 request,__u8 requesttype, _ _ U16 value, _ _ U16 index,void * data, _ _ U16 size,int timeout)

Function: create a control urb and send it to the specified device, then wait for completion before returning.

Parameters:

Struct usb_device * usb_dev: target USB device pointer

Unsigned int pipe: a specific endpoint of the target USB device. Must be created with a specific macro.

_ U8 request: the USB request value of the control message.

_ _ U8 requesttype: controls the USB request type of the message.

_ U16 value: the USB message value of the control message.

_ U16 index: the USB message index value of the control message.

Void * data: in the case of an OUT endpoint, a pointer to the data to be sent to the device. In the case of an IN endpoint, this is the buffer pointer to the data read from the device.

_ _ U16 size: the length of the buffer pointed to by the data parameter

Int timeout: the clock ticks, the time it should wait. If 0, the function always waits for the operation to complete.

Return value: successfully returns the number of bytes transferred to or read from the device. Otherwise, a negative error value is returned.

(3) int usb_interrupt_msg (struct usb_device*usb_dev, unsigned int pipe,void * data,int len, int * actual_length,int timeout)

Function: create an interrupt urb and send it to the specified device, then wait for completion before returning. In fact, it is the packaging of usb_bulk_msg, and all parameters are used in the same way as usb_bulk_msg

This is the end of the work flow of USB driver in Linux system. Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.