Lines Matching refs:driver
11 Please refer to Documentation/driver-model/*.txt for definitions of
12 various driver types and concepts.
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
23 The generic objects must be registered with the driver model core. By
35 Step 1: Registering the bus driver.
38 - Define a struct bus_type for the bus driver.
57 The bus type may be unregistered (if the bus driver may be compiled
126 bus driver should initialize the generic device. The most important
134 the bus driver sets this field correctly.
136 The driver model maintains an ordered list of devices that it uses
151 Optionally, the bus driver may set the device's name and release
158 The release field is a callback that the driver model core calls
166 with the driver model core by doing:
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
228 struct device_driver is a simple driver structure that contains a set
229 of operations that the driver model core may call.
232 - Embed a struct device_driver in the bus-specific driver.
238 struct device_driver 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
253 driver_register(&drv->driver);
255 to register the driver with the core.
257 When the driver is unregistered from the bus, unregister it from the
260 driver_unregister(&drv->driver);
262 Note that this will block until all references to the driver have
268 Drivers are exported via sysfs in their bus's 'driver's directory.
281 struct device_driver defines a set of operations that the driver model
286 It would be difficult and tedious to force every driver on a bus to
288 bus driver should define single instances of the generic methods that
295 struct pci_driver * drv = pci_dev->driver;
300 pci_dev->driver = NULL;
306 The generic driver should be initialized with these methods before it
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;
318 driver_register(&drv->driver);
326 Step 5: Support generic driver binding.
328 The model assumes that a device or driver can be dynamically
330 devices must be bound to a driver, or drivers must be bound to all
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.
343 match should return '1' if the driver supports the device, and '0'
349 When a driver is registered, the bus's list of devices is iterated
351 claimed by a driver.
353 When a device is successfully bound to a driver, device->driver is
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
375 Whenever a device is registered with the driver model core, the
380 The driver model core passes several arguments to userspace via
386 A bus driver may also supply additional parameters for userspace to
396 Step 7: Cleaning up the bus driver.
398 The generic bus, device, and driver structures provide several fields
399 that can replace those defined privately to the bus driver.
417 it. An internal list of drivers that the bus driver maintains may
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
437 - Device and driver fields.