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