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