diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/driver-model/binding.txt |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'Documentation/driver-model/binding.txt')
-rw-r--r-- | Documentation/driver-model/binding.txt | 102 |
1 files changed, 102 insertions, 0 deletions
diff --git a/Documentation/driver-model/binding.txt b/Documentation/driver-model/binding.txt new file mode 100644 index 000000000000..f7ec9d625bfc --- /dev/null +++ b/Documentation/driver-model/binding.txt | |||
@@ -0,0 +1,102 @@ | |||
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 | |||