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
