Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | |
2 | Porting Drivers to the New Driver Model | |
3 | ||
4 | Patrick Mochel | |
5 | ||
6 | 7 January 2003 | |
7 | ||
8 | ||
9 | Overview | |
10 | ||
11 | Please refer to Documentation/driver-model/*.txt for definitions of | |
12 | various driver types and concepts. | |
13 | ||
14 | Most of the work of porting devices drivers to the new model happens | |
15 | at the bus driver layer. This was intentional, to minimize the | |
16 | negative effect on kernel drivers, and to allow a gradual transition | |
17 | of bus drivers. | |
18 | ||
19 | In a nutshell, the driver model consists of a set of objects that can | |
20 | be embedded in larger, bus-specific objects. Fields in these generic | |
21 | objects can replace fields in the bus-specific objects. | |
22 | ||
23 | The generic objects must be registered with the driver model core. By | |
24 | doing so, they will exported via the sysfs filesystem. sysfs can be | |
25 | mounted by doing | |
26 | ||
27 | # mount -t sysfs sysfs /sys | |
28 | ||
29 | ||
30 | ||
31 | The Process | |
32 | ||
33 | Step 0: Read include/linux/device.h for object and function definitions. | |
34 | ||
35 | Step 1: Registering the bus driver. | |
36 | ||
37 | ||
38 | - Define a struct bus_type for the bus driver. | |
39 | ||
40 | struct bus_type pci_bus_type = { | |
41 | .name = "pci", | |
42 | }; | |
43 | ||
44 | ||
45 | - Register the bus type. | |
46 | This should be done in the initialization function for the bus type, | |
47 | which is usually the module_init(), or equivalent, function. | |
48 | ||
49 | static int __init pci_driver_init(void) | |
50 | { | |
51 | return bus_register(&pci_bus_type); | |
52 | } | |
53 | ||
54 | subsys_initcall(pci_driver_init); | |
55 | ||
56 | ||
57 | The bus type may be unregistered (if the bus driver may be compiled | |
58 | as a module) by doing: | |
59 | ||
60 | bus_unregister(&pci_bus_type); | |
61 | ||
62 | ||
63 | - Export the bus type for others to use. | |
64 | ||
65 | Other code may wish to reference the bus type, so declare it in a | |
66 | shared header file and export the symbol. | |
67 | ||
68 | From include/linux/pci.h: | |
69 | ||
70 | extern struct bus_type pci_bus_type; | |
71 | ||
72 | ||
73 | From file the above code appears in: | |
74 | ||
75 | EXPORT_SYMBOL(pci_bus_type); | |
76 | ||
77 | ||
78 | ||
79 | - This will cause the bus to show up in /sys/bus/pci/ with two | |
80 | subdirectories: 'devices' and 'drivers'. | |
81 | ||
82 | # tree -d /sys/bus/pci/ | |
83 | /sys/bus/pci/ | |
84 | |-- devices | |
85 | `-- drivers | |
86 | ||
87 | ||
88 | ||
89 | Step 2: Registering Devices. | |
90 | ||
91 | struct device represents a single device. It mainly contains metadata | |
92 | describing the relationship the device has to other entities. | |
93 | ||
94 | ||
5d3f083d | 95 | - Embed a struct device in the bus-specific device type. |
1da177e4 LT |
96 | |
97 | ||
98 | struct pci_dev { | |
99 | ... | |
100 | struct device dev; /* Generic device interface */ | |
101 | ... | |
102 | }; | |
103 | ||
104 | It is recommended that the generic device not be the first item in | |
105 | the struct to discourage programmers from doing mindless casts | |
106 | between the object types. Instead macros, or inline functions, | |
107 | should be created to convert from the generic object type. | |
108 | ||
109 | ||
110 | #define to_pci_dev(n) container_of(n, struct pci_dev, dev) | |
111 | ||
112 | or | |
113 | ||
114 | static inline struct pci_dev * to_pci_dev(struct kobject * kobj) | |
115 | { | |
116 | return container_of(n, struct pci_dev, dev); | |
117 | } | |
118 | ||
119 | This allows the compiler to verify type-safety of the operations | |
120 | that are performed (which is Good). | |
121 | ||
122 | ||
123 | - Initialize the device on registration. | |
124 | ||
125 | When devices are discovered or registered with the bus type, the | |
126 | bus driver should initialize the generic device. The most important | |
127 | things to initialize are the bus_id, parent, and bus fields. | |
128 | ||
129 | The bus_id is an ASCII string that contains the device's address on | |
130 | the bus. The format of this string is bus-specific. This is | |
131 | necessary for representing devices in sysfs. | |
132 | ||
133 | parent is the physical parent of the device. It is important that | |
134 | the bus driver sets this field correctly. | |
135 | ||
136 | The driver model maintains an ordered list of devices that it uses | |
137 | for power management. This list must be in order to guarantee that | |
138 | devices are shutdown before their physical parents, and vice versa. | |
139 | The order of this list is determined by the parent of registered | |
140 | devices. | |
141 | ||
142 | Also, the location of the device's sysfs directory depends on a | |
143 | device's parent. sysfs exports a directory structure that mirrors | |
144 | the device hierarchy. Accurately setting the parent guarantees that | |
145 | sysfs will accurately represent the hierarchy. | |
146 | ||
147 | The device's bus field is a pointer to the bus type the device | |
148 | belongs to. This should be set to the bus_type that was declared | |
149 | and initialized before. | |
150 | ||
151 | Optionally, the bus driver may set the device's name and release | |
152 | fields. | |
153 | ||
154 | The name field is an ASCII string describing the device, like | |
155 | ||
156 | "ATI Technologies Inc Radeon QD" | |
157 | ||
158 | The release field is a callback that the driver model core calls | |
159 | when the device has been removed, and all references to it have | |
160 | been released. More on this in a moment. | |
161 | ||
162 | ||
163 | - Register the device. | |
164 | ||
165 | Once the generic device has been initialized, it can be registered | |
166 | with the driver model core by doing: | |
167 | ||
168 | device_register(&dev->dev); | |
169 | ||
170 | It can later be unregistered by doing: | |
171 | ||
172 | device_unregister(&dev->dev); | |
173 | ||
174 | This should happen on buses that support hotpluggable devices. | |
175 | If a bus driver unregisters a device, it should not immediately free | |
176 | it. It should instead wait for the driver model core to call the | |
177 | device's release method, then free the bus-specific object. | |
178 | (There may be other code that is currently referencing the device | |
179 | structure, and it would be rude to free the device while that is | |
180 | happening). | |
181 | ||
182 | ||
183 | When the device is registered, a directory in sysfs is created. | |
184 | The PCI tree in sysfs looks like: | |
185 | ||
186 | /sys/devices/pci0/ | |
187 | |-- 00:00.0 | |
188 | |-- 00:01.0 | |
189 | | `-- 01:00.0 | |
190 | |-- 00:02.0 | |
191 | | `-- 02:1f.0 | |
192 | | `-- 03:00.0 | |
193 | |-- 00:1e.0 | |
194 | | `-- 04:04.0 | |
195 | |-- 00:1f.0 | |
196 | |-- 00:1f.1 | |
197 | | |-- ide0 | |
198 | | | |-- 0.0 | |
199 | | | `-- 0.1 | |
200 | | `-- ide1 | |
201 | | `-- 1.0 | |
202 | |-- 00:1f.2 | |
203 | |-- 00:1f.3 | |
204 | `-- 00:1f.5 | |
205 | ||
206 | Also, symlinks are created in the bus's 'devices' directory | |
207 | that point to the device's directory in the physical hierarchy. | |
208 | ||
209 | /sys/bus/pci/devices/ | |
210 | |-- 00:00.0 -> ../../../devices/pci0/00:00.0 | |
211 | |-- 00:01.0 -> ../../../devices/pci0/00:01.0 | |
212 | |-- 00:02.0 -> ../../../devices/pci0/00:02.0 | |
213 | |-- 00:1e.0 -> ../../../devices/pci0/00:1e.0 | |
214 | |-- 00:1f.0 -> ../../../devices/pci0/00:1f.0 | |
215 | |-- 00:1f.1 -> ../../../devices/pci0/00:1f.1 | |
216 | |-- 00:1f.2 -> ../../../devices/pci0/00:1f.2 | |
217 | |-- 00:1f.3 -> ../../../devices/pci0/00:1f.3 | |
218 | |-- 00:1f.5 -> ../../../devices/pci0/00:1f.5 | |
219 | |-- 01:00.0 -> ../../../devices/pci0/00:01.0/01:00.0 | |
220 | |-- 02:1f.0 -> ../../../devices/pci0/00:02.0/02:1f.0 | |
221 | |-- 03:00.0 -> ../../../devices/pci0/00:02.0/02:1f.0/03:00.0 | |
222 | `-- 04:04.0 -> ../../../devices/pci0/00:1e.0/04:04.0 | |
223 | ||
224 | ||
225 | ||
226 | Step 3: Registering Drivers. | |
227 | ||
228 | struct device_driver is a simple driver structure that contains a set | |
229 | of operations that the driver model core may call. | |
230 | ||
231 | ||
232 | - Embed a struct device_driver in the bus-specific driver. | |
233 | ||
234 | Just like with devices, do something like: | |
235 | ||
236 | struct pci_driver { | |
237 | ... | |
238 | struct device_driver driver; | |
239 | }; | |
240 | ||
241 | ||
242 | - Initialize the generic driver structure. | |
243 | ||
244 | When the driver registers with the bus (e.g. doing pci_register_driver()), | |
245 | initialize the necessary fields of the driver: the name and bus | |
246 | fields. | |
247 | ||
248 | ||
249 | - Register the driver. | |
250 | ||
251 | After the generic driver has been initialized, call | |
252 | ||
253 | driver_register(&drv->driver); | |
254 | ||
255 | to register the driver with the core. | |
256 | ||
257 | When the driver is unregistered from the bus, unregister it from the | |
258 | core by doing: | |
259 | ||
260 | driver_unregister(&drv->driver); | |
261 | ||
262 | Note that this will block until all references to the driver have | |
263 | gone away. Normally, there will not be any. | |
264 | ||
265 | ||
266 | - Sysfs representation. | |
267 | ||
268 | Drivers are exported via sysfs in their bus's 'driver's directory. | |
269 | For example: | |
270 | ||
271 | /sys/bus/pci/drivers/ | |
272 | |-- 3c59x | |
273 | |-- Ensoniq AudioPCI | |
274 | |-- agpgart-amdk7 | |
275 | |-- e100 | |
276 | `-- serial | |
277 | ||
278 | ||
279 | Step 4: Define Generic Methods for Drivers. | |
280 | ||
281 | struct device_driver defines a set of operations that the driver model | |
282 | core calls. Most of these operations are probably similar to | |
283 | operations the bus already defines for drivers, but taking different | |
284 | parameters. | |
285 | ||
286 | It would be difficult and tedious to force every driver on a bus to | |
287 | simultaneously convert their drivers to generic format. Instead, the | |
288 | bus driver should define single instances of the generic methods that | |
289 | forward call to the bus-specific drivers. For instance: | |
290 | ||
291 | ||
292 | static int pci_device_remove(struct device * dev) | |
293 | { | |
294 | struct pci_dev * pci_dev = to_pci_dev(dev); | |
295 | struct pci_driver * drv = pci_dev->driver; | |
296 | ||
297 | if (drv) { | |
298 | if (drv->remove) | |
299 | drv->remove(pci_dev); | |
300 | pci_dev->driver = NULL; | |
301 | } | |
302 | return 0; | |
303 | } | |
304 | ||
305 | ||
306 | The generic driver should be initialized with these methods before it | |
307 | is registered. | |
308 | ||
309 | /* initialize common driver fields */ | |
310 | drv->driver.name = drv->name; | |
311 | drv->driver.bus = &pci_bus_type; | |
312 | drv->driver.probe = pci_device_probe; | |
313 | drv->driver.resume = pci_device_resume; | |
314 | drv->driver.suspend = pci_device_suspend; | |
315 | drv->driver.remove = pci_device_remove; | |
316 | ||
317 | /* register with core */ | |
318 | driver_register(&drv->driver); | |
319 | ||
320 | ||
321 | Ideally, the bus should only initialize the fields if they are not | |
322 | already set. This allows the drivers to implement their own generic | |
323 | methods. | |
324 | ||
325 | ||
326 | Step 5: Support generic driver binding. | |
327 | ||
328 | The model assumes that a device or driver can be dynamically | |
329 | registered with the bus at any time. When registration happens, | |
330 | devices must be bound to a driver, or drivers must be bound to all | |
331 | devices that it supports. | |
332 | ||
333 | A driver typically contains a list of device IDs that it supports. The | |
334 | bus driver compares these IDs to the IDs of devices registered with it. | |
335 | The format of the device IDs, and the semantics for comparing them are | |
336 | bus-specific, so the generic model does attempt to generalize them. | |
337 | ||
338 | Instead, a bus may supply a method in struct bus_type that does the | |
339 | comparison: | |
340 | ||
341 | int (*match)(struct device * dev, struct device_driver * drv); | |
342 | ||
343 | match should return '1' if the driver supports the device, and '0' | |
344 | otherwise. | |
345 | ||
346 | When a device is registered, the bus's list of drivers is iterated | |
347 | over. bus->match() is called for each one until a match is found. | |
348 | ||
349 | When a driver is registered, the bus's list of devices is iterated | |
350 | over. bus->match() is called for each device that is not already | |
351 | claimed by a driver. | |
352 | ||
2a7ff1fe | 353 | When a device is successfully bound to a driver, device->driver is |
1da177e4 LT |
354 | set, the device is added to a per-driver list of devices, and a |
355 | symlink is created in the driver's sysfs directory that points to the | |
356 | device's physical directory: | |
357 | ||
358 | /sys/bus/pci/drivers/ | |
359 | |-- 3c59x | |
360 | | `-- 00:0b.0 -> ../../../../devices/pci0/00:0b.0 | |
361 | |-- Ensoniq AudioPCI | |
362 | |-- agpgart-amdk7 | |
363 | | `-- 00:00.0 -> ../../../../devices/pci0/00:00.0 | |
364 | |-- e100 | |
365 | | `-- 00:0c.0 -> ../../../../devices/pci0/00:0c.0 | |
366 | `-- serial | |
367 | ||
368 | ||
369 | This driver binding should replace the existing driver binding | |
370 | mechanism the bus currently uses. | |
371 | ||
372 | ||
373 | Step 6: Supply a hotplug callback. | |
374 | ||
375 | Whenever a device is registered with the driver model core, the | |
376 | userspace program /sbin/hotplug is called to notify userspace. | |
377 | Users can define actions to perform when a device is inserted or | |
378 | removed. | |
379 | ||
380 | The driver model core passes several arguments to userspace via | |
381 | environment variables, including | |
382 | ||
383 | - ACTION: set to 'add' or 'remove' | |
384 | - DEVPATH: set to the device's physical path in sysfs. | |
385 | ||
386 | A bus driver may also supply additional parameters for userspace to | |
387 | consume. To do this, a bus must implement the 'hotplug' method in | |
388 | struct bus_type: | |
389 | ||
390 | int (*hotplug) (struct device *dev, char **envp, | |
391 | int num_envp, char *buffer, int buffer_size); | |
392 | ||
393 | This is called immediately before /sbin/hotplug is executed. | |
394 | ||
395 | ||
396 | Step 7: Cleaning up the bus driver. | |
397 | ||
398 | The generic bus, device, and driver structures provide several fields | |
399 | that can replace those defined privately to the bus driver. | |
400 | ||
401 | - Device list. | |
402 | ||
403 | struct bus_type contains a list of all devices registered with the bus | |
404 | type. This includes all devices on all instances of that bus type. | |
405 | An internal list that the bus uses may be removed, in favor of using | |
406 | this one. | |
407 | ||
408 | The core provides an iterator to access these devices. | |
409 | ||
410 | int bus_for_each_dev(struct bus_type * bus, struct device * start, | |
411 | void * data, int (*fn)(struct device *, void *)); | |
412 | ||
413 | ||
414 | - Driver list. | |
415 | ||
416 | struct bus_type also contains a list of all drivers registered with | |
417 | it. An internal list of drivers that the bus driver maintains may | |
418 | be removed in favor of using the generic one. | |
419 | ||
420 | The drivers may be iterated over, like devices: | |
421 | ||
422 | int bus_for_each_drv(struct bus_type * bus, struct device_driver * start, | |
423 | void * data, int (*fn)(struct device_driver *, void *)); | |
424 | ||
425 | ||
426 | Please see drivers/base/bus.c for more information. | |
427 | ||
428 | ||
429 | - rwsem | |
430 | ||
431 | struct bus_type contains an rwsem that protects all core accesses to | |
432 | the device and driver lists. This can be used by the bus driver | |
433 | internally, and should be used when accessing the device or driver | |
434 | lists the bus maintains. | |
435 | ||
436 | ||
437 | - Device and driver fields. | |
438 | ||
439 | Some of the fields in struct device and struct device_driver duplicate | |
440 | fields in the bus-specific representations of these objects. Feel free | |
441 | to remove the bus-specific ones and favor the generic ones. Note | |
442 | though, that this will likely mean fixing up all the drivers that | |
443 | reference the bus-specific fields (though those should all be 1-line | |
444 | changes). | |
445 |