Commit 4109aca0 authored by David Brownell's avatar David Brownell Committed by Greg Kroah-Hartman

[PATCH] Driver Core: driver model doc update

This updates some driver data documentation:

 - removes references to some fields that haven't been there for a
   long time now, e.g. pre-kobject or even older;

 - giving more information about the probe() method;

 - adding an example of how platform_data is used
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
parent 4b45099b
...@@ -76,6 +76,14 @@ driver_data: Driver-specific data. ...@@ -76,6 +76,14 @@ driver_data: Driver-specific data.
platform_data: Platform data specific to the device. platform_data: Platform data specific to the device.
Example: for devices on custom boards, as typical of embedded
and SOC based hardware, Linux often uses platform_data to point
to board-specific structures describing devices and how they
are wired. That can include what ports are available, chip
variants, which GPIO pins act in what additional roles, and so
on. This shrinks the "Board Support Packages" (BSPs) and
minimizes board-specific #ifdefs in drivers.
current_state: Current power state of the device. current_state: Current power state of the device.
saved_state: Pointer to saved state of the device. This is usable by saved_state: Pointer to saved state of the device. This is usable by
......
...@@ -5,21 +5,17 @@ struct device_driver { ...@@ -5,21 +5,17 @@ struct device_driver {
char * name; char * name;
struct bus_type * bus; struct bus_type * bus;
rwlock_t lock; struct completion unloaded;
atomic_t refcount; struct kobject kobj;
list_t bus_list;
list_t devices; list_t devices;
struct driver_dir_entry dir; struct module *owner;
int (*probe) (struct device * dev); int (*probe) (struct device * dev);
int (*remove) (struct device * dev); int (*remove) (struct device * dev);
int (*suspend) (struct device * dev, pm_message_t state, u32 level); int (*suspend) (struct device * dev, pm_message_t state, u32 level);
int (*resume) (struct device * dev, u32 level); int (*resume) (struct device * dev, u32 level);
void (*release) (struct device_driver * drv);
}; };
...@@ -51,7 +47,6 @@ being converted completely to the new model. ...@@ -51,7 +47,6 @@ being converted completely to the new model.
static struct device_driver eepro100_driver = { static struct device_driver eepro100_driver = {
.name = "eepro100", .name = "eepro100",
.bus = &pci_bus_type, .bus = &pci_bus_type,
.devclass = &ethernet_devclass, /* when it's implemented */
.probe = eepro100_probe, .probe = eepro100_probe,
.remove = eepro100_remove, .remove = eepro100_remove,
...@@ -85,7 +80,6 @@ static struct pci_driver eepro100_driver = { ...@@ -85,7 +80,6 @@ static struct pci_driver eepro100_driver = {
.driver = { .driver = {
.name = "eepro100", .name = "eepro100",
.bus = &pci_bus_type, .bus = &pci_bus_type,
.devclass = &ethernet_devclass, /* when it's implemented */
.probe = eepro100_probe, .probe = eepro100_probe,
.remove = eepro100_remove, .remove = eepro100_remove,
.suspend = eepro100_suspend, .suspend = eepro100_suspend,
...@@ -166,27 +160,32 @@ Callbacks ...@@ -166,27 +160,32 @@ Callbacks
int (*probe) (struct device * dev); int (*probe) (struct device * dev);
probe is called to verify the existence of a certain type of The probe() entry is called in task context, with the bus's rwsem locked
hardware. This is called during the driver binding process, after the and the driver partially bound to the device. Drivers commonly use
bus has verified that the device ID of a device matches one of the container_of() to convert "dev" to a bus-specific type, both in probe()
device IDs supported by the driver. and other routines. That type often provides device resource data, such
as pci_dev.resource[] or platform_device.resources, which is used in
This callback only verifies that there actually is supported hardware addition to dev->platform_data to initialize the driver.
present. It may allocate a driver-specific structure, but it should
not do any initialization of the hardware itself. The device-specific This callback holds the driver-specific logic to bind the driver to a
structure may be stored in the device's driver_data field. given device. That includes verifying that the device is present, that
it's a version the driver can handle, that driver data structures can
int (*init) (struct device * dev); be allocated and initialized, and that any hardware can be initialized.
Drivers often store a pointer to their state with dev_set_drvdata().
init is called during the binding stage. It is called after probe has When the driver has successfully bound itself to that device, then probe()
successfully returned and the device has been registered with its returns zero and the driver model code will finish its part of binding
class. It is responsible for initializing the hardware. the driver to that device.
A driver's probe() may return a negative errno value to indicate that
the driver did not bind to this device, in which case it should have
released all reasources it allocated.
int (*remove) (struct device * dev); int (*remove) (struct device * dev);
remove is called to dissociate a driver with a device. This may be remove is called to unbind a driver from a device. This may be
called if a device is physically removed from the system, if the called if a device is physically removed from the system, if the
driver module is being unloaded, or during a reboot sequence. driver module is being unloaded, during a reboot sequence, or
in other cases.
It is up to the driver to determine if the device is present or It is up to the driver to determine if the device is present or
not. It should free any resources allocated specifically for the not. It should free any resources allocated specifically for the
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment