aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--Documentation/driver-model/device.txt8
-rw-r--r--Documentation/driver-model/driver.txt51
2 files changed, 33 insertions, 26 deletions
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt
index 58cc5dc8fd3e..a05ec50f8004 100644
--- a/Documentation/driver-model/device.txt
+++ b/Documentation/driver-model/device.txt
@@ -76,6 +76,14 @@ driver_data: Driver-specific data.
76 76
77platform_data: Platform data specific to the device. 77platform_data: Platform data specific to the device.
78 78
79 Example: for devices on custom boards, as typical of embedded
80 and SOC based hardware, Linux often uses platform_data to point
81 to board-specific structures describing devices and how they
82 are wired. That can include what ports are available, chip
83 variants, which GPIO pins act in what additional roles, and so
84 on. This shrinks the "Board Support Packages" (BSPs) and
85 minimizes board-specific #ifdefs in drivers.
86
79current_state: Current power state of the device. 87current_state: Current power state of the device.
80 88
81saved_state: Pointer to saved state of the device. This is usable by 89saved_state: Pointer to saved state of the device. This is usable by
diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt
index 6031a68dd3f5..fabaca1ab1b0 100644
--- a/Documentation/driver-model/driver.txt
+++ b/Documentation/driver-model/driver.txt
@@ -5,21 +5,17 @@ struct device_driver {
5 char * name; 5 char * name;
6 struct bus_type * bus; 6 struct bus_type * bus;
7 7
8 rwlock_t lock; 8 struct completion unloaded;
9 atomic_t refcount; 9 struct kobject kobj;
10
11 list_t bus_list;
12 list_t devices; 10 list_t devices;
13 11
14 struct driver_dir_entry dir; 12 struct module *owner;
15 13
16 int (*probe) (struct device * dev); 14 int (*probe) (struct device * dev);
17 int (*remove) (struct device * dev); 15 int (*remove) (struct device * dev);
18 16
19 int (*suspend) (struct device * dev, pm_message_t state, u32 level); 17 int (*suspend) (struct device * dev, pm_message_t state, u32 level);
20 int (*resume) (struct device * dev, u32 level); 18 int (*resume) (struct device * dev, u32 level);
21
22 void (*release) (struct device_driver * drv);
23}; 19};
24 20
25 21
@@ -51,7 +47,6 @@ being converted completely to the new model.
51static struct device_driver eepro100_driver = { 47static struct device_driver eepro100_driver = {
52 .name = "eepro100", 48 .name = "eepro100",
53 .bus = &pci_bus_type, 49 .bus = &pci_bus_type,
54 .devclass = &ethernet_devclass, /* when it's implemented */
55 50
56 .probe = eepro100_probe, 51 .probe = eepro100_probe,
57 .remove = eepro100_remove, 52 .remove = eepro100_remove,
@@ -85,7 +80,6 @@ static struct pci_driver eepro100_driver = {
85 .driver = { 80 .driver = {
86 .name = "eepro100", 81 .name = "eepro100",
87 .bus = &pci_bus_type, 82 .bus = &pci_bus_type,
88 .devclass = &ethernet_devclass, /* when it's implemented */
89 .probe = eepro100_probe, 83 .probe = eepro100_probe,
90 .remove = eepro100_remove, 84 .remove = eepro100_remove,
91 .suspend = eepro100_suspend, 85 .suspend = eepro100_suspend,
@@ -166,27 +160,32 @@ Callbacks
166 160
167 int (*probe) (struct device * dev); 161 int (*probe) (struct device * dev);
168 162
169probe is called to verify the existence of a certain type of 163The probe() entry is called in task context, with the bus's rwsem locked
170hardware. This is called during the driver binding process, after the 164and the driver partially bound to the device. Drivers commonly use
171bus has verified that the device ID of a device matches one of the 165container_of() to convert "dev" to a bus-specific type, both in probe()
172device IDs supported by the driver. 166and other routines. That type often provides device resource data, such
173 167as pci_dev.resource[] or platform_device.resources, which is used in
174This callback only verifies that there actually is supported hardware 168addition to dev->platform_data to initialize the driver.
175present. It may allocate a driver-specific structure, but it should 169
176not do any initialization of the hardware itself. The device-specific 170This callback holds the driver-specific logic to bind the driver to a
177structure may be stored in the device's driver_data field. 171given device. That includes verifying that the device is present, that
178 172it's a version the driver can handle, that driver data structures can
179 int (*init) (struct device * dev); 173be allocated and initialized, and that any hardware can be initialized.
180 174Drivers often store a pointer to their state with dev_set_drvdata().
181init is called during the binding stage. It is called after probe has 175When the driver has successfully bound itself to that device, then probe()
182successfully returned and the device has been registered with its 176returns zero and the driver model code will finish its part of binding
183class. It is responsible for initializing the hardware. 177the driver to that device.
178
179A driver's probe() may return a negative errno value to indicate that
180the driver did not bind to this device, in which case it should have
181released all reasources it allocated.
184 182
185 int (*remove) (struct device * dev); 183 int (*remove) (struct device * dev);
186 184
187remove is called to dissociate a driver with a device. This may be 185remove is called to unbind a driver from a device. This may be
188called if a device is physically removed from the system, if the 186called if a device is physically removed from the system, if the
189driver module is being unloaded, or during a reboot sequence. 187driver module is being unloaded, during a reboot sequence, or
188in other cases.
190 189
191It is up to the driver to determine if the device is present or 190It is up to the driver to determine if the device is present or
192not. It should free any resources allocated specifically for the 191not. It should free any resources allocated specifically for the