diff options
-rw-r--r-- | Documentation/driver-model/device.txt | 8 | ||||
-rw-r--r-- | Documentation/driver-model/driver.txt | 51 |
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 | ||
77 | platform_data: Platform data specific to the device. | 77 | platform_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 | |||
79 | current_state: Current power state of the device. | 87 | current_state: Current power state of the device. |
80 | 88 | ||
81 | saved_state: Pointer to saved state of the device. This is usable by | 89 | saved_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. | |||
51 | static struct device_driver eepro100_driver = { | 47 | static struct device_driver eepro100_driver = { |
52 | .name = "eepro100", | 48 | .name = "eepro100", |
53 | .bus = &pci_bus_type, | 49 | .bus = &pci_bus_type, |
54 | .devclass = ðernet_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 = ðernet_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 | ||
169 | probe is called to verify the existence of a certain type of | 163 | The probe() entry is called in task context, with the bus's rwsem locked |
170 | hardware. This is called during the driver binding process, after the | 164 | and the driver partially bound to the device. Drivers commonly use |
171 | bus has verified that the device ID of a device matches one of the | 165 | container_of() to convert "dev" to a bus-specific type, both in probe() |
172 | device IDs supported by the driver. | 166 | and other routines. That type often provides device resource data, such |
173 | 167 | as pci_dev.resource[] or platform_device.resources, which is used in | |
174 | This callback only verifies that there actually is supported hardware | 168 | addition to dev->platform_data to initialize the driver. |
175 | present. It may allocate a driver-specific structure, but it should | 169 | |
176 | not do any initialization of the hardware itself. The device-specific | 170 | This callback holds the driver-specific logic to bind the driver to a |
177 | structure may be stored in the device's driver_data field. | 171 | given device. That includes verifying that the device is present, that |
178 | 172 | it's a version the driver can handle, that driver data structures can | |
179 | int (*init) (struct device * dev); | 173 | be allocated and initialized, and that any hardware can be initialized. |
180 | 174 | Drivers often store a pointer to their state with dev_set_drvdata(). | |
181 | init is called during the binding stage. It is called after probe has | 175 | When the driver has successfully bound itself to that device, then probe() |
182 | successfully returned and the device has been registered with its | 176 | returns zero and the driver model code will finish its part of binding |
183 | class. It is responsible for initializing the hardware. | 177 | the driver to that device. |
178 | |||
179 | A driver's probe() may return a negative errno value to indicate that | ||
180 | the driver did not bind to this device, in which case it should have | ||
181 | released all reasources it allocated. | ||
184 | 182 | ||
185 | int (*remove) (struct device * dev); | 183 | int (*remove) (struct device * dev); |
186 | 184 | ||
187 | remove is called to dissociate a driver with a device. This may be | 185 | remove is called to unbind a driver from a device. This may be |
188 | called if a device is physically removed from the system, if the | 186 | called if a device is physically removed from the system, if the |
189 | driver module is being unloaded, or during a reboot sequence. | 187 | driver module is being unloaded, during a reboot sequence, or |
188 | in other cases. | ||
190 | 189 | ||
191 | It is up to the driver to determine if the device is present or | 190 | It is up to the driver to determine if the device is present or |
192 | not. It should free any resources allocated specifically for the | 191 | not. It should free any resources allocated specifically for the |