Lines Matching refs:the
2 Porting Drivers to the New Driver Model
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
19 In a nutshell, the driver model consists of a set of objects that can
21 objects can replace fields in the bus-specific objects.
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
35 Step 1: Registering the bus driver.
38 - Define a struct bus_type for the bus driver.
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.
57 The bus type may be unregistered (if the bus driver may be compiled
63 - Export the bus type for others to use.
65 Other code may wish to reference the bus type, so declare it in a
66 shared header file and export the symbol.
73 From file the above code appears in:
79 - This will cause the bus to show up in /sys/bus/pci/ with two
92 describing the relationship the device has to other entities.
95 - Embed a struct device in the bus-specific device type.
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.
119 This allows the compiler to verify type-safety of the operations
123 - Initialize the device on registration.
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.
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
133 parent is the physical parent of the device. It is important that
134 the bus driver sets this field correctly.
139 The order of this list is determined by the parent of registered
142 Also, the location of the device's sysfs directory depends on a
144 the device hierarchy. Accurately setting the parent guarantees that
145 sysfs will accurately represent the hierarchy.
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
151 Optionally, the bus driver may set the device's name and release
154 The name field is an ASCII string describing the device, like
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
163 - Register the device.
165 Once the generic device has been initialized, it can be registered
166 with the driver model core by doing:
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
183 When the device is registered, a directory in sysfs is created.
206 Also, symlinks are created in the bus's 'devices' directory
207 that point to the device's directory in the physical hierarchy.
229 of operations that the driver model core may call.
232 - Embed a struct device_driver in the bus-specific driver.
242 - Initialize the generic driver structure.
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
249 - Register the driver.
251 After the generic driver has been initialized, call
255 to register the driver with the core.
257 When the driver is unregistered from the bus, unregister it from the
262 Note that this will block until all references to the driver have
281 struct device_driver defines a set of operations that the driver model
283 operations the bus already defines for drivers, but taking different
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:
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
329 registered with the bus at any time. When registration happens,
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.
338 Instead, a bus may supply a method in struct bus_type that does the
343 match should return '1' if the driver supports the device, and '0'
346 When a device is registered, the bus's list of drivers is iterated
349 When a driver is registered, the bus's list of devices is iterated
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
369 This driver binding should replace the existing driver binding
370 mechanism the bus currently uses.
375 Whenever a device is registered with the driver model core, the
384 - DEVPATH: set to the device's physical path in sysfs.
387 consume. To do this, a bus must implement the 'hotplug' method in
396 Step 7: Cleaning up the bus driver.
399 that can replace those defined privately to the bus driver.
403 struct bus_type contains a list of all devices registered with the bus
405 An internal list that the bus uses may be removed, in favor of using
417 it. An internal list of drivers that the bus driver maintains may
418 be removed in favor of using the generic one.
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.
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