Device model bus, driver, device basic tutorial

Kobject, kset is the basic structure of the device model. The device model uses these two structures to complete the hierarchical relationship of the device. However, in the actual device driver writing, we basically do not use kobject, kset these structures. Because these structures are embedded in larger structures, because kobject and kset structures can only represent the hierarchical relationship of devices, but the driving of a device is not a simple hierarchical relationship. Therefore, it must Kobject, kset structure needs to be embedded into a larger structure, kobject, kset is used to represent the hierarchical relationship, and other members are used to represent the specific functions of the device driver.

In the device model, we will see that the device driver is mainly composed of three parts: bus, driver and device. Through these three standard components, all kinds of complicated devices are brought back to reach The purpose of simplifying device driver writing, that is, the device driver we wrote, is actually only a small part of these three parts.

The device driver we wrote must be a driver that belongs to a bus first, such as the USB bus, or belongs to the PCI bus, or belongs to the I2C bus, etc., because we have written Device driver, when registering and installing to the system, the system will first check which bus the driver belongs to (the device driver has been defined when it is written), and will add the driver to the kset of the corresponding bus, that is, the kobject of the current device driver. Join the kset of the corresponding bus to form a hierarchical association. When the system detects that a device exists (hardware), it also first determines which bus the device belongs to (hardware connection), then traverses all device drivers under the current bus, and finds whether there is a device driver through the probe function of the own bus. Program matching can drive the current device (generally by obtaining the device's PID, VID, compared with the driver's PID, VID, to see if it matches), if there is a driver to drive the device, then the current device is also added to In the kset of the bus, if there is no driver for the driveable device, it can only exist in the device list of the bus, and if the device cannot match through the bus, there is no way to exist in the device list of the bus. Since one bus manages all the drivers on the bus and manages the devices on the bus, it needs to separate all the devices and all the drivers, and set up a device kset and a device driver kset to manage all the devices. And the device driver, so, the bus kset actually contains two ksets (device kset, device driver kset), the device kset contains all the kops of the current bus device, the device driver kset contains all the devices of the current bus The kobject is driven; and all the buses form the kset of the bus, which comes down to form the hierarchical relationship of the following figure:
bus-dirver-device

Each device is hooked up to different On the bus, when the device is hooked up to the corresponding bus, the corresponding bus type is determined, and when the device is hooked up to the bus, the bus first scans the device to see if the device is suitable for the bus. If it is appropriate, then scan the device driver list on the entire bus to find out if there is a driver that can manage the device. If found, then the device is terminated. The corresponding pointer member in the body points to the corresponding driver. If the corresponding device driver is not found temporarily, the pointer to the driver in the device structure is temporarily empty, indicating that there is no device driver yet, and it is also in the device queue of the bus. Waiting; if the device can't pass the bus check, it will not appear on the bus device list, naturally it will not scan the device driver list to find the matching driver.

And each device driver is installed on the corresponding bus, whether it is manual installation or automatic installation. The so-called installation is to mount the driver to the corresponding bus driver list. Mounting to the corresponding bus driver list, first of all to meet the bus matching requirements, only suitable for the requirements, can be mounted to the bus driver list, and only when this step is reached, the system will scan the entire bus device list to find Is there a device that needs this driver to manage? If the device is found, the device management list in the driver will record the address of the device to achieve the purpose of managing the device.

After the above device is inserted, or the driver is installed, only the device will appear in the system, and there will be no device driver. Only the device driver and the corresponding device will be present. At this time, The device or device driver will temporarily wait in its own queue. Once a driver is installed, or a new device is inserted, it will automatically scan the corresponding linked list to detect the possibility of pairing.

To combine the above three relationships, as shown in the figure:
bus-dirver-device

Linux device model bus type - bus_typebus_type

Related data structure:
Each bus type supported by the kernel is represented by a bus_type object. A subsystem-subsys is embedded in bus_type. The bus_subsys subsystem in the system aggregates the subsys in all bus_types together. Bus_subsys corresponds to the /sys/bus directory in sysfs.

In addition, there are two embedded kset objects in bus_type: devices and drivers. Represents the device and driver on the bus.

The functions bus_for_each_dev() and bus_for_each_drv() are used to traverse all the elements in the devices and drivers list on the bus, respectively.