2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* drivers/pci/pci-driver.c
|
|
|
|
*
|
2007-11-28 20:23:18 +00:00
|
|
|
* (C) Copyright 2002-2004, 2007 Greg Kroah-Hartman <greg@kroah.com>
|
|
|
|
* (C) Copyright 2007 Novell Inc.
|
|
|
|
*
|
|
|
|
* Released under the GPL v2 only.
|
|
|
|
*
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/device.h>
|
2005-07-06 17:56:03 +00:00
|
|
|
#include <linux/mempolicy.h>
|
2005-10-30 23:03:48 +00:00
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/slab.h>
|
2005-11-07 08:59:43 +00:00
|
|
|
#include <linux/sched.h>
|
2008-12-31 13:24:56 +00:00
|
|
|
#include <linux/cpu.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "pci.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Dynamic device IDs are disabled for !CONFIG_HOTPLUG
|
|
|
|
*/
|
|
|
|
|
2005-06-30 09:18:12 +00:00
|
|
|
struct pci_dynid {
|
|
|
|
struct list_head node;
|
|
|
|
struct pci_device_id id;
|
|
|
|
};
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-07-06 16:09:38 +00:00
|
|
|
#ifdef CONFIG_HOTPLUG
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2005-10-23 18:57:38 +00:00
|
|
|
* store_new_id - add a new PCI device ID to this driver and re-probe devices
|
|
|
|
* @driver: target device driver
|
|
|
|
* @buf: buffer for scanning device ID data
|
|
|
|
* @count: input size
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Adds a new dynamic pci device ID to this driver,
|
|
|
|
* and causes the driver to probe for all devices again.
|
|
|
|
*/
|
2005-10-29 03:36:51 +00:00
|
|
|
static ssize_t
|
2005-04-16 22:20:36 +00:00
|
|
|
store_new_id(struct device_driver *driver, const char *buf, size_t count)
|
|
|
|
{
|
2005-06-30 09:18:12 +00:00
|
|
|
struct pci_dynid *dynid;
|
2005-04-16 22:20:36 +00:00
|
|
|
struct pci_driver *pdrv = to_pci_driver(driver);
|
2008-08-17 19:06:59 +00:00
|
|
|
const struct pci_device_id *ids = pdrv->id_table;
|
2007-04-07 15:21:28 +00:00
|
|
|
__u32 vendor, device, subvendor=PCI_ANY_ID,
|
2005-04-16 22:20:36 +00:00
|
|
|
subdevice=PCI_ANY_ID, class=0, class_mask=0;
|
|
|
|
unsigned long driver_data=0;
|
|
|
|
int fields=0;
|
2008-11-26 03:36:10 +00:00
|
|
|
int retval=0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-08-17 19:06:59 +00:00
|
|
|
fields = sscanf(buf, "%x %x %x %x %x %x %lx",
|
2005-04-16 22:20:36 +00:00
|
|
|
&vendor, &device, &subvendor, &subdevice,
|
|
|
|
&class, &class_mask, &driver_data);
|
2007-04-07 15:21:28 +00:00
|
|
|
if (fields < 2)
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2008-08-17 19:06:59 +00:00
|
|
|
/* Only accept driver_data values that match an existing id_table
|
|
|
|
entry */
|
2008-11-26 03:36:10 +00:00
|
|
|
if (ids) {
|
|
|
|
retval = -EINVAL;
|
|
|
|
while (ids->vendor || ids->subvendor || ids->class_mask) {
|
|
|
|
if (driver_data == ids->driver_data) {
|
|
|
|
retval = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
ids++;
|
2008-08-17 19:06:59 +00:00
|
|
|
}
|
2008-11-26 03:36:10 +00:00
|
|
|
if (retval) /* No match */
|
|
|
|
return retval;
|
2008-08-17 19:06:59 +00:00
|
|
|
}
|
|
|
|
|
2006-02-28 14:34:49 +00:00
|
|
|
dynid = kzalloc(sizeof(*dynid), GFP_KERNEL);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!dynid)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
dynid->id.vendor = vendor;
|
|
|
|
dynid->id.device = device;
|
|
|
|
dynid->id.subvendor = subvendor;
|
|
|
|
dynid->id.subdevice = subdevice;
|
|
|
|
dynid->id.class = class;
|
|
|
|
dynid->id.class_mask = class_mask;
|
2008-07-10 21:29:37 +00:00
|
|
|
dynid->id.driver_data = driver_data;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
spin_lock(&pdrv->dynids.lock);
|
2007-09-14 05:33:13 +00:00
|
|
|
list_add_tail(&dynid->node, &pdrv->dynids.list);
|
2005-04-16 22:20:36 +00:00
|
|
|
spin_unlock(&pdrv->dynids.lock);
|
|
|
|
|
2005-06-30 09:18:12 +00:00
|
|
|
if (get_driver(&pdrv->driver)) {
|
2006-08-28 18:43:25 +00:00
|
|
|
retval = driver_attach(&pdrv->driver);
|
2005-06-30 09:18:12 +00:00
|
|
|
put_driver(&pdrv->driver);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2006-08-28 18:43:25 +00:00
|
|
|
if (retval)
|
|
|
|
return retval;
|
2005-04-16 22:20:36 +00:00
|
|
|
return count;
|
|
|
|
}
|
|
|
|
static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id);
|
|
|
|
|
|
|
|
static void
|
|
|
|
pci_free_dynids(struct pci_driver *drv)
|
|
|
|
{
|
2005-06-30 09:18:12 +00:00
|
|
|
struct pci_dynid *dynid, *n;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
spin_lock(&drv->dynids.lock);
|
2005-06-30 09:18:12 +00:00
|
|
|
list_for_each_entry_safe(dynid, n, &drv->dynids.list, node) {
|
2005-04-16 22:20:36 +00:00
|
|
|
list_del(&dynid->node);
|
|
|
|
kfree(dynid);
|
|
|
|
}
|
|
|
|
spin_unlock(&drv->dynids.lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
pci_create_newid_file(struct pci_driver *drv)
|
|
|
|
{
|
|
|
|
int error = 0;
|
|
|
|
if (drv->probe != NULL)
|
2007-11-28 20:23:18 +00:00
|
|
|
error = driver_create_file(&drv->driver, &driver_attr_new_id);
|
2005-04-16 22:20:36 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2007-11-28 20:23:18 +00:00
|
|
|
static void pci_remove_newid_file(struct pci_driver *drv)
|
|
|
|
{
|
|
|
|
driver_remove_file(&drv->driver, &driver_attr_new_id);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
#else /* !CONFIG_HOTPLUG */
|
|
|
|
static inline void pci_free_dynids(struct pci_driver *drv) {}
|
|
|
|
static inline int pci_create_newid_file(struct pci_driver *drv)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2007-11-28 20:23:18 +00:00
|
|
|
static inline void pci_remove_newid_file(struct pci_driver *drv) {}
|
2005-04-16 22:20:36 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/**
|
2005-06-30 09:18:12 +00:00
|
|
|
* pci_match_id - See if a pci device matches a given pci_id table
|
2005-04-16 22:20:36 +00:00
|
|
|
* @ids: array of PCI device id structures to search in
|
2005-06-30 09:18:12 +00:00
|
|
|
* @dev: the PCI device structure to match against.
|
|
|
|
*
|
2005-04-16 22:20:36 +00:00
|
|
|
* Used by a driver to check whether a PCI device present in the
|
2005-06-30 09:18:12 +00:00
|
|
|
* system is in its list of supported devices. Returns the matching
|
2005-04-16 22:20:36 +00:00
|
|
|
* pci_device_id structure or %NULL if there is no match.
|
2005-06-30 09:18:12 +00:00
|
|
|
*
|
2007-05-09 05:19:14 +00:00
|
|
|
* Deprecated, don't use this as it will not catch any dynamic ids
|
2005-06-30 09:18:12 +00:00
|
|
|
* that a driver might want to check for.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2005-06-30 09:18:12 +00:00
|
|
|
const struct pci_device_id *pci_match_id(const struct pci_device_id *ids,
|
|
|
|
struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-06-30 09:18:12 +00:00
|
|
|
if (ids) {
|
|
|
|
while (ids->vendor || ids->subvendor || ids->class_mask) {
|
|
|
|
if (pci_match_one_device(ids, dev))
|
|
|
|
return ids;
|
|
|
|
ids++;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2007-01-10 05:41:01 +00:00
|
|
|
* pci_match_device - Tell if a PCI device structure has a matching PCI device id structure
|
2005-06-30 09:18:12 +00:00
|
|
|
* @drv: the PCI driver to match against
|
2006-08-15 08:57:16 +00:00
|
|
|
* @dev: the PCI device structure to match against
|
2005-06-30 09:18:12 +00:00
|
|
|
*
|
|
|
|
* Used by a driver to check whether a PCI device present in the
|
|
|
|
* system is in its list of supported devices. Returns the matching
|
|
|
|
* pci_device_id structure or %NULL if there is no match.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2007-10-24 16:27:18 +00:00
|
|
|
static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
|
|
|
|
struct pci_dev *dev)
|
2005-06-30 09:18:12 +00:00
|
|
|
{
|
|
|
|
struct pci_dynid *dynid;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
PCI: use /sys/bus/pci/drivers/<driver>/new_id first
Unfortunately, the .../new_id feature does not work with the 8250_pci
driver.
The reason for this comes down to the way .../new_id is implemented.
When PCI tries to match a driver to a device, it checks the modules
static device ID tables _before_ checking the dynamic new_id tables.
When a driver is capable of matching by ID, and falls back to matching
by class (as 8250_pci does), this makes it absolutely impossible to
specify a board by ID, and as such the correct driver_data value to
use with it.
Let's say you have a serial board with vendor 0x1234 and device 0x5678.
It's class is set to PCI_CLASS_COMMUNICATION_SERIAL.
On boot, this card is matched to the 8250_pci driver, which tries to
probe it because it matched using the class entry. The driver finds
that it is unable to automatically detect the correct settings to use,
so it returns -ENODEV.
You know that the information the driver needs is to match this card
using a device_data value of '7'. So you echo 1234 5678 0 0 0 0 7
into new_id.
The kernel attempts to re-bind 8250_pci to this device. However,
because it scans the PCI driver tables, it _again_ matches the class
entry which has the wrong device_data. It fails.
End of story. You can't support the card without rebuilding the
kernel (or writing a specific PCI probe module to support it.)
So, can we make new_id override the driver-internal PCI ID tables?
IOW, like this:
From: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-29 21:18:04 +00:00
|
|
|
/* Look at the dynamic ids first, before the static ones */
|
2005-06-30 09:18:12 +00:00
|
|
|
spin_lock(&drv->dynids.lock);
|
|
|
|
list_for_each_entry(dynid, &drv->dynids.list, node) {
|
|
|
|
if (pci_match_one_device(&dynid->id, dev)) {
|
|
|
|
spin_unlock(&drv->dynids.lock);
|
|
|
|
return &dynid->id;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2005-06-30 09:18:12 +00:00
|
|
|
spin_unlock(&drv->dynids.lock);
|
PCI: use /sys/bus/pci/drivers/<driver>/new_id first
Unfortunately, the .../new_id feature does not work with the 8250_pci
driver.
The reason for this comes down to the way .../new_id is implemented.
When PCI tries to match a driver to a device, it checks the modules
static device ID tables _before_ checking the dynamic new_id tables.
When a driver is capable of matching by ID, and falls back to matching
by class (as 8250_pci does), this makes it absolutely impossible to
specify a board by ID, and as such the correct driver_data value to
use with it.
Let's say you have a serial board with vendor 0x1234 and device 0x5678.
It's class is set to PCI_CLASS_COMMUNICATION_SERIAL.
On boot, this card is matched to the 8250_pci driver, which tries to
probe it because it matched using the class entry. The driver finds
that it is unable to automatically detect the correct settings to use,
so it returns -ENODEV.
You know that the information the driver needs is to match this card
using a device_data value of '7'. So you echo 1234 5678 0 0 0 0 7
into new_id.
The kernel attempts to re-bind 8250_pci to this device. However,
because it scans the PCI driver tables, it _again_ matches the class
entry which has the wrong device_data. It fails.
End of story. You can't support the card without rebuilding the
kernel (or writing a specific PCI probe module to support it.)
So, can we make new_id override the driver-internal PCI ID tables?
IOW, like this:
From: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-29 21:18:04 +00:00
|
|
|
|
|
|
|
return pci_match_id(drv->id_table, dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2008-12-31 13:24:56 +00:00
|
|
|
struct drv_dev_and_id {
|
|
|
|
struct pci_driver *drv;
|
|
|
|
struct pci_dev *dev;
|
|
|
|
const struct pci_device_id *id;
|
|
|
|
};
|
|
|
|
|
|
|
|
static long local_pci_probe(void *_ddi)
|
|
|
|
{
|
|
|
|
struct drv_dev_and_id *ddi = _ddi;
|
|
|
|
|
|
|
|
return ddi->drv->probe(ddi->dev, ddi->id);
|
|
|
|
}
|
|
|
|
|
2005-07-06 17:56:03 +00:00
|
|
|
static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev,
|
|
|
|
const struct pci_device_id *id)
|
|
|
|
{
|
2008-12-31 13:24:56 +00:00
|
|
|
int error, node;
|
|
|
|
struct drv_dev_and_id ddi = { drv, dev, id };
|
|
|
|
|
|
|
|
/* Execute driver initialization on node where the device's
|
|
|
|
bus is attached to. This way the driver likely allocates
|
|
|
|
its local memory on the right node without any need to
|
|
|
|
change it. */
|
|
|
|
node = dev_to_node(&dev->dev);
|
2008-04-05 01:11:06 +00:00
|
|
|
if (node >= 0) {
|
2008-12-31 13:24:56 +00:00
|
|
|
int cpu;
|
2008-04-05 01:11:06 +00:00
|
|
|
node_to_cpumask_ptr(nodecpumask, node);
|
2008-12-31 13:24:56 +00:00
|
|
|
|
|
|
|
get_online_cpus();
|
|
|
|
cpu = cpumask_any_and(nodecpumask, cpu_online_mask);
|
|
|
|
if (cpu < nr_cpu_ids)
|
|
|
|
error = work_on_cpu(cpu, local_pci_probe, &ddi);
|
|
|
|
else
|
|
|
|
error = local_pci_probe(&ddi);
|
|
|
|
put_online_cpus();
|
|
|
|
} else
|
|
|
|
error = local_pci_probe(&ddi);
|
2005-07-06 17:56:03 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* __pci_device_probe()
|
2005-10-23 18:57:38 +00:00
|
|
|
* @drv: driver to call to check if it wants the PCI device
|
|
|
|
* @pci_dev: PCI device being probed
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2005-10-23 18:57:38 +00:00
|
|
|
* returns 0 on success, else error.
|
2005-04-16 22:20:36 +00:00
|
|
|
* side-effect: pci_dev->driver is set to drv when drv claims pci_dev.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
__pci_device_probe(struct pci_driver *drv, struct pci_dev *pci_dev)
|
2005-06-30 09:18:12 +00:00
|
|
|
{
|
|
|
|
const struct pci_device_id *id;
|
2005-04-16 22:20:36 +00:00
|
|
|
int error = 0;
|
|
|
|
|
|
|
|
if (!pci_dev->driver && drv->probe) {
|
2005-06-30 09:18:12 +00:00
|
|
|
error = -ENODEV;
|
|
|
|
|
|
|
|
id = pci_match_device(drv, pci_dev);
|
|
|
|
if (id)
|
2005-07-06 17:56:03 +00:00
|
|
|
error = pci_call_probe(drv, pci_dev, id);
|
2005-06-30 09:18:12 +00:00
|
|
|
if (error >= 0) {
|
|
|
|
pci_dev->driver = drv;
|
|
|
|
error = 0;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_device_probe(struct device * dev)
|
|
|
|
{
|
|
|
|
int error = 0;
|
|
|
|
struct pci_driver *drv;
|
|
|
|
struct pci_dev *pci_dev;
|
|
|
|
|
|
|
|
drv = to_pci_driver(dev->driver);
|
|
|
|
pci_dev = to_pci_dev(dev);
|
|
|
|
pci_dev_get(pci_dev);
|
|
|
|
error = __pci_device_probe(drv, pci_dev);
|
|
|
|
if (error)
|
|
|
|
pci_dev_put(pci_dev);
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_device_remove(struct device * dev)
|
|
|
|
{
|
|
|
|
struct pci_dev * pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver * drv = pci_dev->driver;
|
|
|
|
|
|
|
|
if (drv) {
|
|
|
|
if (drv->remove)
|
|
|
|
drv->remove(pci_dev);
|
|
|
|
pci_dev->driver = NULL;
|
|
|
|
}
|
|
|
|
|
2006-10-20 21:45:32 +00:00
|
|
|
/*
|
|
|
|
* If the device is still on, set the power state as "unknown",
|
|
|
|
* since it might change by the next time we load the driver.
|
|
|
|
*/
|
|
|
|
if (pci_dev->current_state == PCI_D0)
|
|
|
|
pci_dev->current_state = PCI_UNKNOWN;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* We would love to complain here if pci_dev->is_enabled is set, that
|
|
|
|
* the driver should have called pci_disable_device(), but the
|
|
|
|
* unfortunate fact is there are too many odd BIOS and bridge setups
|
|
|
|
* that don't like drivers doing that all of the time.
|
|
|
|
* Oh well, we can dream of sane hardware when we sleep, no matter how
|
|
|
|
* horrible the crap we have to deal with is when we are awake...
|
|
|
|
*/
|
|
|
|
|
|
|
|
pci_dev_put(pci_dev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
static void pci_device_shutdown(struct device *dev)
|
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver *drv = pci_dev->driver;
|
|
|
|
|
|
|
|
if (drv && drv->shutdown)
|
|
|
|
drv->shutdown(pci_dev);
|
|
|
|
pci_msi_shutdown(pci_dev);
|
|
|
|
pci_msix_shutdown(pci_dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
2009-01-07 12:03:42 +00:00
|
|
|
/*
|
|
|
|
* Default "suspend" method for devices that have no driver provided suspend,
|
|
|
|
* or not even a driver at all (second part).
|
2008-05-19 22:49:04 +00:00
|
|
|
*/
|
2009-01-07 13:15:17 +00:00
|
|
|
static void pci_pm_set_unknown_state(struct pci_dev *pci_dev)
|
2008-05-19 22:49:04 +00:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* mark its power state as "unknown", since we don't know if
|
|
|
|
* e.g. the BIOS will change its device state when we suspend.
|
|
|
|
*/
|
|
|
|
if (pci_dev->current_state == PCI_D0)
|
|
|
|
pci_dev->current_state = PCI_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
2008-12-07 23:34:57 +00:00
|
|
|
/*
|
|
|
|
* Default "resume" method for devices that have no driver provided resume,
|
|
|
|
* or not even a driver at all (second part).
|
|
|
|
*/
|
2009-01-07 13:15:17 +00:00
|
|
|
static int pci_pm_reenable_device(struct pci_dev *pci_dev)
|
2008-12-07 23:34:57 +00:00
|
|
|
{
|
|
|
|
int retval;
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
/* if the device was enabled before suspend, reenable */
|
|
|
|
retval = pci_reenable_device(pci_dev);
|
|
|
|
/*
|
|
|
|
* if the device was busmaster before the suspend, make it busmaster
|
|
|
|
* again
|
|
|
|
*/
|
|
|
|
if (pci_dev->is_busmaster)
|
|
|
|
pci_set_master(pci_dev);
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_legacy_suspend(struct device *dev, pm_message_t state)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct pci_dev * pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver * drv = pci_dev->driver;
|
2009-03-16 21:39:56 +00:00
|
|
|
int error = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-03-23 09:38:34 +00:00
|
|
|
if (drv && drv->suspend) {
|
2009-02-04 00:59:09 +00:00
|
|
|
pci_power_t prev = pci_dev->current_state;
|
|
|
|
|
2009-01-16 20:54:43 +00:00
|
|
|
pci_dev->state_saved = false;
|
|
|
|
|
2009-03-16 21:39:56 +00:00
|
|
|
error = drv->suspend(pci_dev, state);
|
|
|
|
suspend_report_result(drv->suspend, error);
|
|
|
|
if (error)
|
|
|
|
return error;
|
2009-01-16 20:54:43 +00:00
|
|
|
|
|
|
|
if (pci_dev->state_saved)
|
|
|
|
goto Fixup;
|
|
|
|
|
2009-02-04 00:59:09 +00:00
|
|
|
if (pci_dev->current_state != PCI_D0
|
|
|
|
&& pci_dev->current_state != PCI_UNKNOWN) {
|
|
|
|
WARN_ONCE(pci_dev->current_state != prev,
|
|
|
|
"PCI PM: Device state not saved by %pF\n",
|
|
|
|
drv->suspend);
|
2009-01-16 20:54:43 +00:00
|
|
|
goto Fixup;
|
2009-02-04 00:59:09 +00:00
|
|
|
}
|
2006-03-23 09:38:34 +00:00
|
|
|
}
|
2009-01-07 12:09:37 +00:00
|
|
|
|
2009-01-16 20:54:43 +00:00
|
|
|
pci_save_state(pci_dev);
|
|
|
|
/*
|
|
|
|
* This is for compatibility with existing code with legacy PM support.
|
|
|
|
*/
|
|
|
|
pci_pm_set_unknown_state(pci_dev);
|
|
|
|
|
|
|
|
Fixup:
|
2009-01-07 12:09:37 +00:00
|
|
|
pci_fixup_device(pci_fixup_suspend, pci_dev);
|
|
|
|
|
2009-03-16 21:39:56 +00:00
|
|
|
return error;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
static int pci_legacy_suspend_late(struct device *dev, pm_message_t state)
|
2006-06-24 21:50:29 +00:00
|
|
|
{
|
|
|
|
struct pci_dev * pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver * drv = pci_dev->driver;
|
2009-03-16 21:39:56 +00:00
|
|
|
int error = 0;
|
2006-06-24 21:50:29 +00:00
|
|
|
|
|
|
|
if (drv && drv->suspend_late) {
|
2009-03-16 21:39:56 +00:00
|
|
|
error = drv->suspend_late(pci_dev, state);
|
|
|
|
suspend_report_result(drv->suspend_late, error);
|
2006-06-24 21:50:29 +00:00
|
|
|
}
|
2009-03-16 21:39:56 +00:00
|
|
|
return error;
|
2006-06-24 21:50:29 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
static int pci_legacy_resume_early(struct device *dev)
|
|
|
|
{
|
|
|
|
struct pci_dev * pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver * drv = pci_dev->driver;
|
|
|
|
|
2009-01-16 20:54:43 +00:00
|
|
|
return drv && drv->resume_early ?
|
|
|
|
drv->resume_early(pci_dev) : 0;
|
2009-01-07 12:12:22 +00:00
|
|
|
}
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
static int pci_legacy_resume(struct device *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct pci_dev * pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver * drv = pci_dev->driver;
|
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
pci_fixup_device(pci_fixup_resume, pci_dev);
|
|
|
|
|
2009-01-16 20:54:43 +00:00
|
|
|
return drv && drv->resume ?
|
|
|
|
drv->resume(pci_dev) : pci_pm_reenable_device(pci_dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2009-01-07 12:05:05 +00:00
|
|
|
/* Auxiliary functions used by the new power management framework */
|
|
|
|
|
PCI PM: Avoid touching devices behind bridges in unknown state
It generally is better to avoid accessing devices behind bridges that
may not be in the D0 power state, because in that case the bridges'
secondary buses may not be accessible. For this reason, during the
early phase of resume (ie. with interrupts disabled), before
restoring the standard config registers of a device, check the power
state of the bridge the device is behind and postpone the restoration
of the device's config space, as well as any other operations that
would involve accessing the device, if that state is not D0.
In such cases the restoration of the device's config space will be
retried during the "normal" phase of resume (ie. with interrupts
enabled), so that the bridge can be put into D0 before that happens.
Also, save standard configuration registers of PCI devices during the
"normal" phase of suspend (ie. with interrupts enabled), so that the
bridges the devices are behind can be put into low power states (we
don't put bridges into low power states at the moment, but we may
want to do it in the future and it seems reasonable to design for
that).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-07 12:07:15 +00:00
|
|
|
static void pci_pm_default_resume_noirq(struct pci_dev *pci_dev)
|
|
|
|
{
|
2009-01-16 20:54:43 +00:00
|
|
|
pci_restore_standard_config(pci_dev);
|
2009-01-26 20:43:08 +00:00
|
|
|
pci_dev->state_saved = false;
|
2009-01-16 20:54:43 +00:00
|
|
|
pci_fixup_device(pci_fixup_resume_early, pci_dev);
|
PCI PM: Avoid touching devices behind bridges in unknown state
It generally is better to avoid accessing devices behind bridges that
may not be in the D0 power state, because in that case the bridges'
secondary buses may not be accessible. For this reason, during the
early phase of resume (ie. with interrupts disabled), before
restoring the standard config registers of a device, check the power
state of the bridge the device is behind and postpone the restoration
of the device's config space, as well as any other operations that
would involve accessing the device, if that state is not D0.
In such cases the restoration of the device's config space will be
retried during the "normal" phase of resume (ie. with interrupts
enabled), so that the bridge can be put into D0 before that happens.
Also, save standard configuration registers of PCI devices during the
"normal" phase of suspend (ie. with interrupts enabled), so that the
bridges the devices are behind can be put into low power states (we
don't put bridges into low power states at the moment, but we may
want to do it in the future and it seems reasonable to design for
that).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-07 12:07:15 +00:00
|
|
|
}
|
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
static void pci_pm_default_resume(struct pci_dev *pci_dev)
|
2009-01-07 12:05:05 +00:00
|
|
|
{
|
PCI PM: Avoid touching devices behind bridges in unknown state
It generally is better to avoid accessing devices behind bridges that
may not be in the D0 power state, because in that case the bridges'
secondary buses may not be accessible. For this reason, during the
early phase of resume (ie. with interrupts disabled), before
restoring the standard config registers of a device, check the power
state of the bridge the device is behind and postpone the restoration
of the device's config space, as well as any other operations that
would involve accessing the device, if that state is not D0.
In such cases the restoration of the device's config space will be
retried during the "normal" phase of resume (ie. with interrupts
enabled), so that the bridge can be put into D0 before that happens.
Also, save standard configuration registers of PCI devices during the
"normal" phase of suspend (ie. with interrupts enabled), so that the
bridges the devices are behind can be put into low power states (we
don't put bridges into low power states at the moment, but we may
want to do it in the future and it seems reasonable to design for
that).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-07 12:07:15 +00:00
|
|
|
pci_fixup_device(pci_fixup_resume, pci_dev);
|
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (!pci_is_bridge(pci_dev))
|
|
|
|
pci_enable_wake(pci_dev, PCI_D0, false);
|
2009-01-07 12:05:05 +00:00
|
|
|
}
|
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
static void pci_pm_default_suspend(struct pci_dev *pci_dev)
|
PCI PM: Avoid touching devices behind bridges in unknown state
It generally is better to avoid accessing devices behind bridges that
may not be in the D0 power state, because in that case the bridges'
secondary buses may not be accessible. For this reason, during the
early phase of resume (ie. with interrupts disabled), before
restoring the standard config registers of a device, check the power
state of the bridge the device is behind and postpone the restoration
of the device's config space, as well as any other operations that
would involve accessing the device, if that state is not D0.
In such cases the restoration of the device's config space will be
retried during the "normal" phase of resume (ie. with interrupts
enabled), so that the bridge can be put into D0 before that happens.
Also, save standard configuration registers of PCI devices during the
"normal" phase of suspend (ie. with interrupts enabled), so that the
bridges the devices are behind can be put into low power states (we
don't put bridges into low power states at the moment, but we may
want to do it in the future and it seems reasonable to design for
that).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-07 12:07:15 +00:00
|
|
|
{
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
/* Disable non-bridge devices without PM support */
|
2009-02-04 01:01:15 +00:00
|
|
|
if (!pci_is_bridge(pci_dev))
|
|
|
|
pci_disable_enabled_device(pci_dev);
|
PCI PM: Avoid touching devices behind bridges in unknown state
It generally is better to avoid accessing devices behind bridges that
may not be in the D0 power state, because in that case the bridges'
secondary buses may not be accessible. For this reason, during the
early phase of resume (ie. with interrupts disabled), before
restoring the standard config registers of a device, check the power
state of the bridge the device is behind and postpone the restoration
of the device's config space, as well as any other operations that
would involve accessing the device, if that state is not D0.
In such cases the restoration of the device's config space will be
retried during the "normal" phase of resume (ie. with interrupts
enabled), so that the bridge can be put into D0 before that happens.
Also, save standard configuration registers of PCI devices during the
"normal" phase of suspend (ie. with interrupts enabled), so that the
bridges the devices are behind can be put into low power states (we
don't put bridges into low power states at the moment, but we may
want to do it in the future and it seems reasonable to design for
that).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-07 12:07:15 +00:00
|
|
|
pci_save_state(pci_dev);
|
|
|
|
}
|
|
|
|
|
2009-01-07 12:06:10 +00:00
|
|
|
static bool pci_has_legacy_pm_support(struct pci_dev *pci_dev)
|
|
|
|
{
|
|
|
|
struct pci_driver *drv = pci_dev->driver;
|
2009-01-07 13:15:17 +00:00
|
|
|
bool ret = drv && (drv->suspend || drv->suspend_late || drv->resume
|
2009-01-07 12:06:10 +00:00
|
|
|
|| drv->resume_early);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Legacy PM support is used by default, so warn if the new framework is
|
|
|
|
* supported as well. Drivers are supposed to support either the
|
|
|
|
* former, or the latter, but not both at the same time.
|
|
|
|
*/
|
|
|
|
WARN_ON(ret && drv->driver.pm);
|
|
|
|
|
|
|
|
return ret;
|
2009-01-07 12:06:10 +00:00
|
|
|
}
|
|
|
|
|
2009-01-07 12:05:05 +00:00
|
|
|
/* New power management framework */
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
static int pci_pm_prepare(struct device *dev)
|
|
|
|
{
|
|
|
|
struct device_driver *drv = dev->driver;
|
|
|
|
int error = 0;
|
|
|
|
|
|
|
|
if (drv && drv->pm && drv->pm->prepare)
|
|
|
|
error = drv->pm->prepare(dev);
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pci_pm_complete(struct device *dev)
|
|
|
|
{
|
|
|
|
struct device_driver *drv = dev->driver;
|
|
|
|
|
|
|
|
if (drv && drv->pm && drv->pm->complete)
|
|
|
|
drv->pm->complete(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_SUSPEND
|
|
|
|
|
|
|
|
static int pci_pm_suspend(struct device *dev)
|
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2009-02-04 00:56:14 +00:00
|
|
|
struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
2008-05-19 22:49:04 +00:00
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
|
|
|
return pci_legacy_suspend(dev, PMSG_SUSPEND);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (!pm) {
|
|
|
|
pci_pm_default_suspend(pci_dev);
|
|
|
|
goto Fixup;
|
|
|
|
}
|
|
|
|
|
|
|
|
pci_dev->state_saved = false;
|
|
|
|
|
|
|
|
if (pm->suspend) {
|
|
|
|
pci_power_t prev = pci_dev->current_state;
|
|
|
|
int error;
|
|
|
|
|
2009-02-04 00:56:14 +00:00
|
|
|
error = pm->suspend(dev);
|
|
|
|
suspend_report_result(pm->suspend, error);
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
|
|
|
|
if (pci_dev->state_saved)
|
|
|
|
goto Fixup;
|
|
|
|
|
|
|
|
if (pci_dev->current_state != PCI_D0
|
|
|
|
&& pci_dev->current_state != PCI_UNKNOWN) {
|
|
|
|
WARN_ONCE(pci_dev->current_state != prev,
|
|
|
|
"PCI PM: State of device not saved by %pF\n",
|
|
|
|
pm->suspend);
|
|
|
|
goto Fixup;
|
|
|
|
}
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
2009-01-07 12:03:42 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (!pci_dev->state_saved) {
|
|
|
|
pci_save_state(pci_dev);
|
|
|
|
if (!pci_is_bridge(pci_dev))
|
|
|
|
pci_prepare_to_sleep(pci_dev);
|
|
|
|
}
|
2008-05-19 22:49:04 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
Fixup:
|
|
|
|
pci_fixup_device(pci_fixup_suspend, pci_dev);
|
|
|
|
|
|
|
|
return 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_pm_suspend_noirq(struct device *dev)
|
2005-04-08 05:53:31 +00:00
|
|
|
{
|
2008-12-07 23:34:57 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2008-10-06 20:46:05 +00:00
|
|
|
struct device_driver *drv = dev->driver;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
2005-04-08 05:53:31 +00:00
|
|
|
|
2009-01-07 13:15:17 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
|
|
|
return pci_legacy_suspend_late(dev, PMSG_SUSPEND);
|
|
|
|
|
2009-01-07 12:11:28 +00:00
|
|
|
if (drv && drv->pm && drv->pm->suspend_noirq) {
|
|
|
|
error = drv->pm->suspend_noirq(dev);
|
|
|
|
suspend_report_result(drv->pm->suspend_noirq, error);
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
2009-01-07 12:11:28 +00:00
|
|
|
if (!error)
|
|
|
|
pci_pm_set_unknown_state(pci_dev);
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
return error;
|
2005-04-08 05:53:31 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
static int pci_pm_resume_noirq(struct device *dev)
|
2008-05-19 22:49:04 +00:00
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct device_driver *drv = dev->driver;
|
2008-12-07 23:34:57 +00:00
|
|
|
int error = 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
|
2009-01-16 20:54:43 +00:00
|
|
|
pci_pm_default_resume_noirq(pci_dev);
|
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
2009-01-07 12:12:22 +00:00
|
|
|
return pci_legacy_resume_early(dev);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
if (drv && drv->pm && drv->pm->resume_noirq)
|
|
|
|
error = drv->pm->resume_noirq(dev);
|
2008-05-19 22:49:04 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
static int pci_pm_resume(struct device *dev)
|
2008-05-19 22:49:04 +00:00
|
|
|
{
|
2008-12-07 23:34:57 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2009-01-26 20:43:08 +00:00
|
|
|
/*
|
|
|
|
* This is necessary for the suspend error path in which resume is
|
|
|
|
* called without restoring the standard config registers of the device.
|
|
|
|
*/
|
|
|
|
if (pci_dev->state_saved)
|
|
|
|
pci_restore_standard_config(pci_dev);
|
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
2009-01-07 12:12:22 +00:00
|
|
|
return pci_legacy_resume(dev);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
pci_pm_default_resume(pci_dev);
|
PCI PM: Avoid touching devices behind bridges in unknown state
It generally is better to avoid accessing devices behind bridges that
may not be in the D0 power state, because in that case the bridges'
secondary buses may not be accessible. For this reason, during the
early phase of resume (ie. with interrupts disabled), before
restoring the standard config registers of a device, check the power
state of the bridge the device is behind and postpone the restoration
of the device's config space, as well as any other operations that
would involve accessing the device, if that state is not D0.
In such cases the restoration of the device's config space will be
retried during the "normal" phase of resume (ie. with interrupts
enabled), so that the bridge can be put into D0 before that happens.
Also, save standard configuration registers of PCI devices during the
"normal" phase of suspend (ie. with interrupts enabled), so that the
bridges the devices are behind can be put into low power states (we
don't put bridges into low power states at the moment, but we may
want to do it in the future and it seems reasonable to design for
that).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-07 12:07:15 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (pm) {
|
|
|
|
if (pm->resume)
|
|
|
|
error = pm->resume(dev);
|
|
|
|
} else {
|
|
|
|
pci_pm_reenable_device(pci_dev);
|
|
|
|
}
|
2008-05-19 22:49:04 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
return 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#else /* !CONFIG_SUSPEND */
|
|
|
|
|
|
|
|
#define pci_pm_suspend NULL
|
|
|
|
#define pci_pm_suspend_noirq NULL
|
|
|
|
#define pci_pm_resume NULL
|
|
|
|
#define pci_pm_resume_noirq NULL
|
|
|
|
|
|
|
|
#endif /* !CONFIG_SUSPEND */
|
|
|
|
|
|
|
|
#ifdef CONFIG_HIBERNATION
|
|
|
|
|
|
|
|
static int pci_pm_freeze(struct device *dev)
|
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
2008-05-19 22:49:04 +00:00
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
|
|
|
return pci_legacy_suspend(dev, PMSG_FREEZE);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (!pm) {
|
|
|
|
pci_pm_default_suspend(pci_dev);
|
|
|
|
return 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
pci_dev->state_saved = false;
|
2009-01-07 12:11:28 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (pm->freeze) {
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = pm->freeze(dev);
|
|
|
|
suspend_report_result(pm->freeze, error);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!pci_dev->state_saved)
|
|
|
|
pci_save_state(pci_dev);
|
|
|
|
|
|
|
|
return 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_pm_freeze_noirq(struct device *dev)
|
|
|
|
{
|
2008-12-07 23:34:57 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2008-10-06 20:46:05 +00:00
|
|
|
struct device_driver *drv = dev->driver;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2009-01-07 13:15:17 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
|
|
|
return pci_legacy_suspend_late(dev, PMSG_FREEZE);
|
|
|
|
|
2009-01-07 12:11:28 +00:00
|
|
|
if (drv && drv->pm && drv->pm->freeze_noirq) {
|
|
|
|
error = drv->pm->freeze_noirq(dev);
|
|
|
|
suspend_report_result(drv->pm->freeze_noirq, error);
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
2009-01-07 12:11:28 +00:00
|
|
|
if (!error)
|
|
|
|
pci_pm_set_unknown_state(pci_dev);
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
static int pci_pm_thaw_noirq(struct device *dev)
|
2008-05-19 22:49:04 +00:00
|
|
|
{
|
2008-12-07 23:34:57 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2008-05-19 22:49:04 +00:00
|
|
|
struct device_driver *drv = dev->driver;
|
|
|
|
int error = 0;
|
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
2009-01-07 12:12:22 +00:00
|
|
|
return pci_legacy_resume_early(dev);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
pci_update_current_state(pci_dev, PCI_D0);
|
2009-01-07 12:11:28 +00:00
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
if (drv && drv->pm && drv->pm->thaw_noirq)
|
|
|
|
error = drv->pm->thaw_noirq(dev);
|
2008-05-19 22:49:04 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
static int pci_pm_thaw(struct device *dev)
|
2008-05-19 22:49:04 +00:00
|
|
|
{
|
2008-12-07 23:34:57 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
2009-01-07 12:12:22 +00:00
|
|
|
return pci_legacy_resume(dev);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (pm) {
|
|
|
|
if (pm->thaw)
|
|
|
|
error = pm->thaw(dev);
|
|
|
|
} else {
|
|
|
|
pci_pm_reenable_device(pci_dev);
|
|
|
|
}
|
2008-05-19 22:49:04 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_pm_poweroff(struct device *dev)
|
|
|
|
{
|
2008-12-07 23:34:57 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2009-02-04 00:56:14 +00:00
|
|
|
struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
|
|
|
return pci_legacy_suspend(dev, PMSG_HIBERNATE);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (!pm) {
|
|
|
|
pci_pm_default_suspend(pci_dev);
|
|
|
|
goto Fixup;
|
|
|
|
}
|
|
|
|
|
|
|
|
pci_dev->state_saved = false;
|
|
|
|
|
|
|
|
if (pm->poweroff) {
|
2009-02-04 00:56:14 +00:00
|
|
|
error = pm->poweroff(dev);
|
|
|
|
suspend_report_result(pm->poweroff, error);
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (!pci_dev->state_saved && !pci_is_bridge(pci_dev))
|
|
|
|
pci_prepare_to_sleep(pci_dev);
|
|
|
|
|
|
|
|
Fixup:
|
|
|
|
pci_fixup_device(pci_fixup_suspend, pci_dev);
|
2009-01-07 12:02:36 +00:00
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_pm_poweroff_noirq(struct device *dev)
|
|
|
|
{
|
2008-10-06 20:46:05 +00:00
|
|
|
struct device_driver *drv = dev->driver;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2009-01-07 13:15:17 +00:00
|
|
|
if (pci_has_legacy_pm_support(to_pci_dev(dev)))
|
|
|
|
return pci_legacy_suspend_late(dev, PMSG_HIBERNATE);
|
|
|
|
|
2009-01-07 12:11:28 +00:00
|
|
|
if (drv && drv->pm && drv->pm->poweroff_noirq) {
|
|
|
|
error = drv->pm->poweroff_noirq(dev);
|
|
|
|
suspend_report_result(drv->pm->poweroff_noirq, error);
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
static int pci_pm_restore_noirq(struct device *dev)
|
2008-05-19 22:49:04 +00:00
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct device_driver *drv = dev->driver;
|
2008-12-07 23:34:57 +00:00
|
|
|
int error = 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
|
2009-01-16 20:54:43 +00:00
|
|
|
pci_pm_default_resume_noirq(pci_dev);
|
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
2009-01-07 12:12:22 +00:00
|
|
|
return pci_legacy_resume_early(dev);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
if (drv && drv->pm && drv->pm->restore_noirq)
|
|
|
|
error = drv->pm->restore_noirq(dev);
|
2008-05-19 22:49:04 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2009-01-07 12:12:22 +00:00
|
|
|
static int pci_pm_restore(struct device *dev)
|
2008-05-19 22:49:04 +00:00
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2009-01-26 20:43:08 +00:00
|
|
|
/*
|
|
|
|
* This is necessary for the hibernation error path in which restore is
|
|
|
|
* called without restoring the standard config registers of the device.
|
|
|
|
*/
|
|
|
|
if (pci_dev->state_saved)
|
|
|
|
pci_restore_standard_config(pci_dev);
|
|
|
|
|
2009-01-07 12:09:37 +00:00
|
|
|
if (pci_has_legacy_pm_support(pci_dev))
|
2009-01-07 12:12:22 +00:00
|
|
|
return pci_legacy_resume(dev);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
pci_pm_default_resume(pci_dev);
|
PCI PM: Avoid touching devices behind bridges in unknown state
It generally is better to avoid accessing devices behind bridges that
may not be in the D0 power state, because in that case the bridges'
secondary buses may not be accessible. For this reason, during the
early phase of resume (ie. with interrupts disabled), before
restoring the standard config registers of a device, check the power
state of the bridge the device is behind and postpone the restoration
of the device's config space, as well as any other operations that
would involve accessing the device, if that state is not D0.
In such cases the restoration of the device's config space will be
retried during the "normal" phase of resume (ie. with interrupts
enabled), so that the bridge can be put into D0 before that happens.
Also, save standard configuration registers of PCI devices during the
"normal" phase of suspend (ie. with interrupts enabled), so that the
bridges the devices are behind can be put into low power states (we
don't put bridges into low power states at the moment, but we may
want to do it in the future and it seems reasonable to design for
that).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-01-07 12:07:15 +00:00
|
|
|
|
PCI PM: make the PM core more careful with drivers using the new PM framework
Currently, the PM core always attempts to manage devices with drivers
that use the new PM framework. In particular, it attempts to disable
the devices (which is unnecessary), to save their state (which may be
undesirable if the driver has done that already) and to put them into
low power states (again, this may be undesirable if the driver has
already put the device into a low power state). That need not be
the right thing to do, so make the core be more careful in this
respect.
Generally, there are the following categories of devices to consider:
* bridge devices without drivers
* non-bridge devices without drivers
* bridge devices with drivers
* non-bridge devices with drivers
and each of them should be handled differently.
For bridge devices without drivers the PCI PM core will save their
state on suspend and restore it (early) during resume, after putting
them into D0 if necessary. It will not attempt to do anything else
to these devices.
For non-bridge devices without drivers the PCI PM core will disable
them and save their state on suspend. During resume, it will put
them into D0, if necessary, restore their state (early) and reenable
them.
For bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already.
Still, the core will restore their state (early) during resume,
after putting them into D0, if necessary.
For non-bridge devices with drivers the PCI PM core will only save
their state on suspend if the driver hasn't done that already. Also,
if the state of the device hasn't been saved by the driver, the core
will attempt to put the device into a low power state. During
resume the core will restore the state of the device (early), after
putting it into D0, if necessary.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-02-04 01:09:07 +00:00
|
|
|
if (pm) {
|
|
|
|
if (pm->restore)
|
|
|
|
error = pm->restore(dev);
|
|
|
|
} else {
|
|
|
|
pci_pm_reenable_device(pci_dev);
|
|
|
|
}
|
2008-05-19 22:49:04 +00:00
|
|
|
|
|
|
|
return error;
|
2005-04-08 05:53:31 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
#else /* !CONFIG_HIBERNATION */
|
|
|
|
|
|
|
|
#define pci_pm_freeze NULL
|
|
|
|
#define pci_pm_freeze_noirq NULL
|
|
|
|
#define pci_pm_thaw NULL
|
|
|
|
#define pci_pm_thaw_noirq NULL
|
|
|
|
#define pci_pm_poweroff NULL
|
|
|
|
#define pci_pm_poweroff_noirq NULL
|
|
|
|
#define pci_pm_restore NULL
|
|
|
|
#define pci_pm_restore_noirq NULL
|
|
|
|
|
|
|
|
#endif /* !CONFIG_HIBERNATION */
|
|
|
|
|
2008-10-06 20:46:05 +00:00
|
|
|
struct dev_pm_ops pci_dev_pm_ops = {
|
|
|
|
.prepare = pci_pm_prepare,
|
|
|
|
.complete = pci_pm_complete,
|
|
|
|
.suspend = pci_pm_suspend,
|
|
|
|
.resume = pci_pm_resume,
|
|
|
|
.freeze = pci_pm_freeze,
|
|
|
|
.thaw = pci_pm_thaw,
|
|
|
|
.poweroff = pci_pm_poweroff,
|
|
|
|
.restore = pci_pm_restore,
|
2008-05-19 22:49:04 +00:00
|
|
|
.suspend_noirq = pci_pm_suspend_noirq,
|
|
|
|
.resume_noirq = pci_pm_resume_noirq,
|
|
|
|
.freeze_noirq = pci_pm_freeze_noirq,
|
|
|
|
.thaw_noirq = pci_pm_thaw_noirq,
|
|
|
|
.poweroff_noirq = pci_pm_poweroff_noirq,
|
|
|
|
.restore_noirq = pci_pm_restore_noirq,
|
|
|
|
};
|
|
|
|
|
2008-10-06 20:46:05 +00:00
|
|
|
#define PCI_PM_OPS_PTR (&pci_dev_pm_ops)
|
2008-05-19 22:49:04 +00:00
|
|
|
|
|
|
|
#else /* !CONFIG_PM_SLEEP */
|
|
|
|
|
|
|
|
#define PCI_PM_OPS_PTR NULL
|
|
|
|
|
|
|
|
#endif /* !CONFIG_PM_SLEEP */
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2005-10-27 21:12:54 +00:00
|
|
|
* __pci_register_driver - register a new pci driver
|
2005-04-16 22:20:36 +00:00
|
|
|
* @drv: the driver structure to register
|
2005-10-27 21:12:54 +00:00
|
|
|
* @owner: owner module of drv
|
2007-02-10 22:41:56 +00:00
|
|
|
* @mod_name: module name string
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Adds the driver structure to the list of registered drivers.
|
|
|
|
* Returns a negative value on error, otherwise 0.
|
2005-05-04 00:38:30 +00:00
|
|
|
* If no error occurred, the driver remains registered even if
|
2005-04-16 22:20:36 +00:00
|
|
|
* no device was claimed during registration.
|
|
|
|
*/
|
2007-01-15 19:50:02 +00:00
|
|
|
int __pci_register_driver(struct pci_driver *drv, struct module *owner,
|
|
|
|
const char *mod_name)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
/* initialize common driver fields */
|
|
|
|
drv->driver.name = drv->name;
|
|
|
|
drv->driver.bus = &pci_bus_type;
|
2005-10-27 21:12:54 +00:00
|
|
|
drv->driver.owner = owner;
|
2007-01-15 19:50:02 +00:00
|
|
|
drv->driver.mod_name = mod_name;
|
2006-08-16 16:42:18 +00:00
|
|
|
|
2005-06-30 09:18:12 +00:00
|
|
|
spin_lock_init(&drv->dynids.lock);
|
|
|
|
INIT_LIST_HEAD(&drv->dynids.list);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* register with core */
|
|
|
|
error = driver_register(&drv->driver);
|
2006-11-09 03:53:59 +00:00
|
|
|
if (error)
|
|
|
|
return error;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-11-09 03:53:59 +00:00
|
|
|
error = pci_create_newid_file(drv);
|
|
|
|
if (error)
|
|
|
|
driver_unregister(&drv->driver);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_unregister_driver - unregister a pci driver
|
|
|
|
* @drv: the driver structure to unregister
|
|
|
|
*
|
|
|
|
* Deletes the driver structure from the list of registered PCI drivers,
|
|
|
|
* gives it a chance to clean up by calling its remove() function for
|
|
|
|
* each device it was responsible for, and marks those devices as
|
|
|
|
* driverless.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void
|
|
|
|
pci_unregister_driver(struct pci_driver *drv)
|
|
|
|
{
|
2007-11-28 20:23:18 +00:00
|
|
|
pci_remove_newid_file(drv);
|
2005-04-16 22:20:36 +00:00
|
|
|
driver_unregister(&drv->driver);
|
|
|
|
pci_free_dynids(drv);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct pci_driver pci_compat_driver = {
|
|
|
|
.name = "compat"
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_dev_driver - get the pci_driver of a device
|
|
|
|
* @dev: the device to query
|
|
|
|
*
|
|
|
|
* Returns the appropriate pci_driver structure or %NULL if there is no
|
|
|
|
* registered driver for the device.
|
|
|
|
*/
|
|
|
|
struct pci_driver *
|
|
|
|
pci_dev_driver(const struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (dev->driver)
|
|
|
|
return dev->driver;
|
|
|
|
else {
|
|
|
|
int i;
|
|
|
|
for(i=0; i<=PCI_ROM_RESOURCE; i++)
|
|
|
|
if (dev->resource[i].flags & IORESOURCE_BUSY)
|
|
|
|
return &pci_compat_driver;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_bus_match - Tell if a PCI device structure has a matching PCI device id structure
|
|
|
|
* @dev: the PCI device structure to match against
|
2005-10-23 18:57:38 +00:00
|
|
|
* @drv: the device driver to search for matching PCI device id structures
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Used by a driver to check whether a PCI device present in the
|
2005-10-23 18:57:38 +00:00
|
|
|
* system is in its list of supported devices. Returns the matching
|
2005-04-16 22:20:36 +00:00
|
|
|
* pci_device_id structure or %NULL if there is no match.
|
|
|
|
*/
|
2005-06-30 09:18:12 +00:00
|
|
|
static int pci_bus_match(struct device *dev, struct device_driver *drv)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-06-30 09:18:12 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver *pci_drv = to_pci_driver(drv);
|
2005-04-16 22:20:36 +00:00
|
|
|
const struct pci_device_id *found_id;
|
|
|
|
|
2005-06-30 09:18:12 +00:00
|
|
|
found_id = pci_match_device(pci_drv, pci_dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (found_id)
|
|
|
|
return 1;
|
|
|
|
|
2005-06-30 09:18:12 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_dev_get - increments the reference count of the pci device structure
|
|
|
|
* @dev: the device being referenced
|
|
|
|
*
|
|
|
|
* Each live reference to a device should be refcounted.
|
|
|
|
*
|
|
|
|
* Drivers for PCI devices should normally record such references in
|
|
|
|
* their probe() methods, when they bind to a device, and release
|
|
|
|
* them by calling pci_dev_put(), in their disconnect() methods.
|
|
|
|
*
|
|
|
|
* A pointer to the device with the incremented reference counter is returned.
|
|
|
|
*/
|
|
|
|
struct pci_dev *pci_dev_get(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (dev)
|
|
|
|
get_device(&dev->dev);
|
|
|
|
return dev;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_dev_put - release a use of the pci device structure
|
|
|
|
* @dev: device that's been disconnected
|
|
|
|
*
|
|
|
|
* Must be called when a user of a device is finished with it. When the last
|
|
|
|
* user of the device calls this function, the memory of the device is freed.
|
|
|
|
*/
|
|
|
|
void pci_dev_put(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (dev)
|
|
|
|
put_device(&dev->dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef CONFIG_HOTPLUG
|
2007-08-14 13:15:12 +00:00
|
|
|
int pci_uevent(struct device *dev, struct kobj_uevent_env *env)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
struct bus_type pci_bus_type = {
|
|
|
|
.name = "pci",
|
|
|
|
.match = pci_bus_match,
|
2005-11-16 08:00:00 +00:00
|
|
|
.uevent = pci_uevent,
|
2006-01-05 14:30:22 +00:00
|
|
|
.probe = pci_device_probe,
|
|
|
|
.remove = pci_device_remove,
|
2006-06-24 21:50:29 +00:00
|
|
|
.shutdown = pci_device_shutdown,
|
2005-04-16 22:20:36 +00:00
|
|
|
.dev_attrs = pci_dev_attrs,
|
2008-05-19 22:49:04 +00:00
|
|
|
.pm = PCI_PM_OPS_PTR,
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static int __init pci_driver_init(void)
|
|
|
|
{
|
|
|
|
return bus_register(&pci_bus_type);
|
|
|
|
}
|
|
|
|
|
|
|
|
postcore_initcall(pci_driver_init);
|
|
|
|
|
2005-06-30 09:18:12 +00:00
|
|
|
EXPORT_SYMBOL(pci_match_id);
|
2005-10-27 21:12:54 +00:00
|
|
|
EXPORT_SYMBOL(__pci_register_driver);
|
2005-04-16 22:20:36 +00:00
|
|
|
EXPORT_SYMBOL(pci_unregister_driver);
|
|
|
|
EXPORT_SYMBOL(pci_dev_driver);
|
|
|
|
EXPORT_SYMBOL(pci_bus_type);
|
|
|
|
EXPORT_SYMBOL(pci_dev_get);
|
|
|
|
EXPORT_SYMBOL(pci_dev_put);
|