USB device driver 2: Root hub daemon 1

Execute PS-A | grep khubd on the terminal, and the khubd process is displayed. This is the hub daemon process. Our device is inserted into the USB interface (whether it is inserted with the hub, after the sub-hub), the daemon detects the issue and then notifies the master controller of the interruption. The master controller then calls the hub detection function to parse the device.

After the hub driver is installed with OK in the previous section, the system will call kthread_run (hub_thread, null, "khubd") to start the daemon. The khubd is the daemon name, this process is almost an endless loop. It exits only when kthread_should_stop is executed, and the process is not always executed. When the Hub does not have a device to insert, the process is in sleep state, only when a device is inserted will the process be awakened for processing.

After the hub notifies the master controller of the discovery of a device insertion, the master controller calls the hub detection function, the Hub detection function starts a device check process (related to HCD, but not familiar with it ). Therefore, a complete process starts with the Hub's probe function hub_probe, and the prerequisite is that the master controller is working properly.

After the master controller discovers the root hub interface, call the hub_probe function to configure the root hub.

1. obtain the current interface descriptor through the interface descriptor, and determine whether it is a hub device by analyzing whether the binterfacesubclass member of the current interface descriptor is a hub class member, whether there is only one port, and whether the port is an interrupt port, if the verification fails, the device is not a hub device and exits.

2. After 1 verification, it can be proved that it is a hub device, and the hub device is allocated control (struct usb_hub), and the hub structure is initialized, that is, struct usb_hub is initialized here.

3. configure the root hub and allocate the cache and DMA address used for urb transmission (the two are associated), hub status space, and hub descriptor space. After the allocation, send a request to the device, obtain the device descriptor, obtain various hub parameters through the descriptor, and use these parameters to configure the usb_device struct in usb_hub.

4. Obtain the pipeline connecting the hub to the host and the size of the pipeline endpoint. The pipeline is interrupted, and the endpoint size cannot be greater than the size of the allocated buffer.

5. Apply for an urb space for preparing to transmit the urb request data.

6. fill the Hub's urb data, including pipelines, caches, cache lengths, and interrupt processing functions. This is the most important thing, when the hub port has an interrupt signal (that is, the device is inserted or pulled out), the configured interrupt function is called to wake up the hub daemon and the process is executed, start to parse the port status-urb is created only when a request is sent. After urb is created and submitted to the host, it is released by the system.

7. Enable the power-on of the hub upstream port through the device interface properties

8. send the requested urb to the host. If everything is normal, the host will periodically ask whether the hub is interrupted. If so, the transmission will be interrupted, the urb request sent is to send various hub data packets to the master controller to let the master controller know.

9. At this point, the hub starts to work normally and waits for the interrupt signal at any time and reports it to the master controller.