driver-api/driver-model/driver.rst

11 be multiple devices in a system that a driver supports, struct
12 device_driver represents the driver as a whole (not a particular
18 The driver must initialize at least the name and bus fields. It should
28 driver. This declaration is hypothetical only; it relies on the driver
45 The most common example of this are device ID structures. A driver
52 the definition of the bus-specific driver. Like this::
56          struct device_driver	  driver;
60 (using the eepro100 driver again)::
64          .driver	       = {
84 The driver registers the structure on startup. For drivers that have
85 no bus-specific fields (i.e. don't have a bus-specific driver
92 It is important that drivers register their driver structure as early as
96 used by the device model core or the bus driver.
109 information in the driver, the drivers must be modified anyway. Since
124 the driver. The LDM core provides a helper function to operate on all
125 the devices a driver controls. This helper locks the driver on each
133 When a driver is registered, a sysfs directory is created in its
134 bus's directory. In this directory, the driver can export an interface
135 to userspace to control operation of the driver on a global basis;
136 e.g. toggling debugging output in the driver.
152 and the driver partially bound to the device.  Drivers commonly use
156 addition to dev->platform_data to initialize the driver.
158 This callback holds the driver-specific logic to bind the driver to a
160 it's a version the driver can handle, that driver data structures can
163 When the driver has successfully bound itself to that device, then probe()
164 returns zero and the driver model code will finish its part of binding
165 the driver to that device.
167 A driver's probe() may return a negative errno value to indicate that
168 the driver did not bind to this device, in which case it should have
171 Optionally, probe() may return -EPROBE_DEFER if the driver depends on
172 resources that are not yet available (e.g., supplied by a driver that
173 hasn't initialized yet).  The driver core will put the device onto the
174 deferred probe list and will try to call it again later. If a driver
184       .probe() calls to the same driver.
206 device probe successfully. If during the reattempt, the driver core finds that
213 driver might need to keep the device in the boot configuration until all the
215 probed, the device's driver can synchronize the hardware state of the device to
233 remove is called to unbind a driver from a device. This may be
235 driver module is being unloaded, during a reboot sequence, or
238 It is up to the driver to determine if the device is present or
265           ssize_t (*show)(struct device_driver *driver, char *buf);
283 driver's directory using::