Root/Documentation/driver-model/binding.txt

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

Archive Download this file



interactive