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