Commit | Line | Data |
---|---|---|
4489f161 | 1 | ============== |
1da177e4 | 2 | Driver Binding |
4489f161 | 3 | ============== |
1da177e4 LT |
4 | |
5 | Driver binding is the process of associating a device with a device | |
6 | driver that can control it. Bus drivers have typically handled this | |
7 | because there have been bus-specific structures to represent the | |
8 | devices and the drivers. With generic device and device driver | |
9 | structures, most of the binding can take place using common code. | |
10 | ||
11 | ||
12 | Bus | |
13 | ~~~ | |
14 | ||
15 | The bus type structure contains a list of all devices that are on that bus | |
16 | type in the system. When device_register is called for a device, it is | |
17 | inserted into the end of this list. The bus object also contains a | |
18 | list of all drivers of that bus type. When driver_register is called | |
19 | for a driver, it is inserted at the end of this list. These are the | |
20 | two events which trigger driver binding. | |
21 | ||
22 | ||
23 | device_register | |
24 | ~~~~~~~~~~~~~~~ | |
25 | ||
26 | When a new device is added, the bus's list of drivers is iterated over | |
27 | to find one that supports it. In order to determine that, the device | |
28 | ID of the device must match one of the device IDs that the driver | |
4489f161 | 29 | supports. The format and semantics for comparing IDs is bus-specific. |
1da177e4 LT |
30 | Instead of trying to derive a complex state machine and matching |
31 | algorithm, it is up to the bus driver to provide a callback to compare | |
32 | a device against the IDs of a driver. The bus returns 1 if a match was | |
33 | found; 0 otherwise. | |
34 | ||
35 | int match(struct device * dev, struct device_driver * drv); | |
36 | ||
37 | If a match is found, the device's driver field is set to the driver | |
38 | and the driver's probe callback is called. This gives the driver a | |
39 | chance to verify that it really does support the hardware, and that | |
4489f161 | 40 | it's in a working state. |
1da177e4 LT |
41 | |
42 | Device Class | |
43 | ~~~~~~~~~~~~ | |
44 | ||
45 | Upon the successful completion of probe, the device is registered with | |
46 | the class to which it belongs. Device drivers belong to one and only one | |
4489f161 | 47 | class, and that is set in the driver's devclass field. |
1da177e4 LT |
48 | devclass_add_device is called to enumerate the device within the class |
49 | and actually register it with the class, which happens with the | |
50 | class's register_dev callback. | |
51 | ||
1da177e4 LT |
52 | |
53 | Driver | |
54 | ~~~~~~ | |
55 | ||
56 | When a driver is attached to a device, the device is inserted into the | |
4489f161 | 57 | driver's list of devices. |
1da177e4 LT |
58 | |
59 | ||
60 | sysfs | |
61 | ~~~~~ | |
62 | ||
63 | A symlink is created in the bus's 'devices' directory that points to | |
64 | the device's directory in the physical hierarchy. | |
65 | ||
66 | A symlink is created in the driver's 'devices' directory that points | |
67 | to the device's directory in the physical hierarchy. | |
68 | ||
69 | A directory for the device is created in the class's directory. A | |
70 | symlink is created in that directory that points to the device's | |
4489f161 | 71 | physical location in the sysfs tree. |
1da177e4 LT |
72 | |
73 | A symlink can be created (though this isn't done yet) in the device's | |
74 | physical directory to either its class directory, or the class's | |
75 | top-level directory. One can also be created to point to its driver's | |
4489f161 | 76 | directory also. |
1da177e4 LT |
77 | |
78 | ||
79 | driver_register | |
80 | ~~~~~~~~~~~~~~~ | |
81 | ||
4489f161 | 82 | The process is almost identical for when a new driver is added. |
1da177e4 LT |
83 | The bus's list of devices is iterated over to find a match. Devices |
84 | that already have a driver are skipped. All the devices are iterated | |
85 | over, to bind as many devices as possible to the driver. | |
86 | ||
87 | ||
88 | Removal | |
89 | ~~~~~~~ | |
90 | ||
91 | When a device is removed, the reference count for it will eventually | |
92 | go to 0. When it does, the remove callback of the driver is called. It | |
93 | is removed from the driver's list of devices and the reference count | |
94 | of the driver is decremented. All symlinks between the two are removed. | |
95 | ||
96 | When a driver is removed, the list of devices that it supports is | |
97 | iterated over, and the driver's remove callback is called for each | |
4489f161 | 98 | one. The device is removed from that list and the symlinks removed. |