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>
|
2010-02-17 22:44:58 +00:00
|
|
|
#include <linux/pm_runtime.h>
|
2011-07-06 08:51:40 +00:00
|
|
|
#include <linux/suspend.h>
|
2013-11-27 22:19:25 +00:00
|
|
|
#include <linux/kexec.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "pci.h"
|
|
|
|
|
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
|
|
|
|
2009-09-03 06:26:36 +00:00
|
|
|
/**
|
|
|
|
* pci_add_dynid - add a new PCI device ID to this driver and re-probe devices
|
|
|
|
* @drv: target pci driver
|
|
|
|
* @vendor: PCI vendor ID
|
|
|
|
* @device: PCI device ID
|
|
|
|
* @subvendor: PCI subvendor ID
|
|
|
|
* @subdevice: PCI subdevice ID
|
|
|
|
* @class: PCI class
|
|
|
|
* @class_mask: PCI class mask
|
|
|
|
* @driver_data: private driver data
|
|
|
|
*
|
|
|
|
* Adds a new dynamic pci device ID to this driver and causes the
|
|
|
|
* driver to probe for all devices again. @drv must have been
|
|
|
|
* registered prior to calling this function.
|
|
|
|
*
|
|
|
|
* CONTEXT:
|
|
|
|
* Does GFP_KERNEL allocation.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* 0 on success, -errno on failure.
|
|
|
|
*/
|
|
|
|
int pci_add_dynid(struct pci_driver *drv,
|
|
|
|
unsigned int vendor, unsigned int device,
|
|
|
|
unsigned int subvendor, unsigned int subdevice,
|
|
|
|
unsigned int class, unsigned int class_mask,
|
|
|
|
unsigned long driver_data)
|
|
|
|
{
|
|
|
|
struct pci_dynid *dynid;
|
|
|
|
int retval;
|
|
|
|
|
|
|
|
dynid = kzalloc(sizeof(*dynid), GFP_KERNEL);
|
|
|
|
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;
|
|
|
|
dynid->id.driver_data = driver_data;
|
2005-07-06 16:09:38 +00:00
|
|
|
|
2009-09-03 06:26:36 +00:00
|
|
|
spin_lock(&drv->dynids.lock);
|
|
|
|
list_add_tail(&dynid->node, &drv->dynids.list);
|
|
|
|
spin_unlock(&drv->dynids.lock);
|
|
|
|
|
|
|
|
retval = driver_attach(&drv->driver);
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_add_dynid);
|
2009-09-03 06:26:36 +00:00
|
|
|
|
|
|
|
static void pci_free_dynids(struct pci_driver *drv)
|
|
|
|
{
|
|
|
|
struct pci_dynid *dynid, *n;
|
2005-07-06 16:09:38 +00:00
|
|
|
|
2009-09-03 06:26:36 +00:00
|
|
|
spin_lock(&drv->dynids.lock);
|
|
|
|
list_for_each_entry_safe(dynid, n, &drv->dynids.list, node) {
|
|
|
|
list_del(&dynid->node);
|
|
|
|
kfree(dynid);
|
|
|
|
}
|
|
|
|
spin_unlock(&drv->dynids.lock);
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2009-09-03 06:26:36 +00:00
|
|
|
* store_new_id - sysfs frontend to pci_add_dynid()
|
2005-10-23 18:57:38 +00:00
|
|
|
* @driver: target device driver
|
|
|
|
* @buf: buffer for scanning device ID data
|
|
|
|
* @count: input size
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2009-09-03 06:26:36 +00:00
|
|
|
* Allow PCI IDs to be added to an existing driver via sysfs.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
static ssize_t store_new_id(struct device_driver *driver, const char *buf,
|
|
|
|
size_t count)
|
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;
|
2014-04-19 00:13:49 +00:00
|
|
|
__u32 vendor, device, subvendor = PCI_ANY_ID,
|
|
|
|
subdevice = PCI_ANY_ID, class = 0, class_mask = 0;
|
|
|
|
unsigned long driver_data = 0;
|
|
|
|
int fields = 0;
|
2014-04-02 01:32:59 +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;
|
|
|
|
|
2014-04-02 01:32:59 +00:00
|
|
|
if (fields != 7) {
|
|
|
|
struct pci_dev *pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
|
|
|
|
if (!pdev)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
pdev->vendor = vendor;
|
|
|
|
pdev->device = device;
|
|
|
|
pdev->subsystem_vendor = subvendor;
|
|
|
|
pdev->subsystem_device = subdevice;
|
|
|
|
pdev->class = class;
|
|
|
|
|
|
|
|
if (pci_match_id(pdrv->id_table, pdev))
|
|
|
|
retval = -EEXIST;
|
|
|
|
|
|
|
|
kfree(pdev);
|
|
|
|
|
|
|
|
if (retval)
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2009-09-03 06:26:36 +00:00
|
|
|
retval = pci_add_dynid(pdrv, vendor, device, subvendor, subdevice,
|
|
|
|
class, class_mask, driver_data);
|
2006-08-28 18:43:25 +00:00
|
|
|
if (retval)
|
|
|
|
return retval;
|
2005-04-16 22:20:36 +00:00
|
|
|
return count;
|
|
|
|
}
|
2013-10-07 20:51:20 +00:00
|
|
|
static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-02-24 05:52:23 +00:00
|
|
|
/**
|
|
|
|
* store_remove_id - remove a PCI device ID from this driver
|
|
|
|
* @driver: target device driver
|
|
|
|
* @buf: buffer for scanning device ID data
|
|
|
|
* @count: input size
|
|
|
|
*
|
|
|
|
* Removes a dynamic pci device ID to this driver.
|
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
static ssize_t store_remove_id(struct device_driver *driver, const char *buf,
|
|
|
|
size_t count)
|
2009-02-24 05:52:23 +00:00
|
|
|
{
|
|
|
|
struct pci_dynid *dynid, *n;
|
|
|
|
struct pci_driver *pdrv = to_pci_driver(driver);
|
|
|
|
__u32 vendor, device, subvendor = PCI_ANY_ID,
|
|
|
|
subdevice = PCI_ANY_ID, class = 0, class_mask = 0;
|
|
|
|
int fields = 0;
|
|
|
|
int retval = -ENODEV;
|
|
|
|
|
|
|
|
fields = sscanf(buf, "%x %x %x %x %x %x",
|
|
|
|
&vendor, &device, &subvendor, &subdevice,
|
|
|
|
&class, &class_mask);
|
|
|
|
if (fields < 2)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
spin_lock(&pdrv->dynids.lock);
|
|
|
|
list_for_each_entry_safe(dynid, n, &pdrv->dynids.list, node) {
|
|
|
|
struct pci_device_id *id = &dynid->id;
|
|
|
|
if ((id->vendor == vendor) &&
|
|
|
|
(id->device == device) &&
|
|
|
|
(subvendor == PCI_ANY_ID || id->subvendor == subvendor) &&
|
|
|
|
(subdevice == PCI_ANY_ID || id->subdevice == subdevice) &&
|
|
|
|
!((id->class ^ class) & class_mask)) {
|
|
|
|
list_del(&dynid->node);
|
|
|
|
kfree(dynid);
|
|
|
|
retval = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock(&pdrv->dynids.lock);
|
|
|
|
|
|
|
|
if (retval)
|
|
|
|
return retval;
|
|
|
|
return count;
|
|
|
|
}
|
2013-10-07 20:51:20 +00:00
|
|
|
static DRIVER_ATTR(remove_id, S_IWUSR, NULL, store_remove_id);
|
2009-02-24 05:52:23 +00:00
|
|
|
|
2013-10-07 20:51:20 +00:00
|
|
|
static struct attribute *pci_drv_attrs[] = {
|
|
|
|
&driver_attr_new_id.attr,
|
|
|
|
&driver_attr_remove_id.attr,
|
|
|
|
NULL,
|
2012-08-08 10:47:51 +00:00
|
|
|
};
|
2013-10-07 20:51:20 +00:00
|
|
|
ATTRIBUTE_GROUPS(pci_drv);
|
2009-02-24 05:52:23 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
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;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_match_id);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
PCI: Introduce new device binding path using pci_dev.driver_override
The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive match of the
device. This shortcuts the existing process of looking up the vendor and
device ID, adding them to the driver new_id, binding the device, then
removing the ID, but it also provides a couple advantages.
First, the above existing process allows the driver to bind to any device
matching the new_id for the window where it's enabled. This is often not
desired, such as the case of trying to bind a single device to a meta
driver like pci-stub or vfio-pci. Using driver_override we can do this
deterministically using:
echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
Previously we could not invoke drivers_probe after adding a device to
new_id for a driver as we get non-deterministic behavior whether the driver
we intend or the standard driver will claim the device. Now it becomes a
deterministic process, only the driver matching driver_override will probe
the device.
To return the device to the standard driver, we simply clear the
driver_override and reprobe the device:
echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
Another advantage to this approach is that we can specify a driver override
to force a specific binding or prevent any binding. For instance when an
IOMMU group is exposed to userspace through VFIO we require that all
devices within that group are owned by VFIO. However, devices can be
hot-added into an IOMMU group, in which case we want to prevent the device
from binding to any driver (override driver = "none") or perhaps have it
automatically bind to vfio-pci. With driver_override it's a simple matter
for this field to be set internally when the device is first discovered to
prevent driver matches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 14:53:21 +00:00
|
|
|
static const struct pci_device_id pci_device_id_any = {
|
|
|
|
.vendor = PCI_ANY_ID,
|
|
|
|
.device = PCI_ANY_ID,
|
|
|
|
.subvendor = PCI_ANY_ID,
|
|
|
|
.subdevice = PCI_ANY_ID,
|
|
|
|
};
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
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;
|
PCI: Introduce new device binding path using pci_dev.driver_override
The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive match of the
device. This shortcuts the existing process of looking up the vendor and
device ID, adding them to the driver new_id, binding the device, then
removing the ID, but it also provides a couple advantages.
First, the above existing process allows the driver to bind to any device
matching the new_id for the window where it's enabled. This is often not
desired, such as the case of trying to bind a single device to a meta
driver like pci-stub or vfio-pci. Using driver_override we can do this
deterministically using:
echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
Previously we could not invoke drivers_probe after adding a device to
new_id for a driver as we get non-deterministic behavior whether the driver
we intend or the standard driver will claim the device. Now it becomes a
deterministic process, only the driver matching driver_override will probe
the device.
To return the device to the standard driver, we simply clear the
driver_override and reprobe the device:
echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
Another advantage to this approach is that we can specify a driver override
to force a specific binding or prevent any binding. For instance when an
IOMMU group is exposed to userspace through VFIO we require that all
devices within that group are owned by VFIO. However, devices can be
hot-added into an IOMMU group, in which case we want to prevent the device
from binding to any driver (override driver = "none") or perhaps have it
automatically bind to vfio-pci. With driver_override it's a simple matter
for this field to be set internally when the device is first discovered to
prevent driver matches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 14:53:21 +00:00
|
|
|
const struct pci_device_id *found_id = NULL;
|
|
|
|
|
|
|
|
/* When driver_override is set, only bind to the matching driver */
|
|
|
|
if (dev->driver_override && strcmp(dev->driver_override, drv->name))
|
|
|
|
return NULL;
|
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)) {
|
PCI: Introduce new device binding path using pci_dev.driver_override
The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive match of the
device. This shortcuts the existing process of looking up the vendor and
device ID, adding them to the driver new_id, binding the device, then
removing the ID, but it also provides a couple advantages.
First, the above existing process allows the driver to bind to any device
matching the new_id for the window where it's enabled. This is often not
desired, such as the case of trying to bind a single device to a meta
driver like pci-stub or vfio-pci. Using driver_override we can do this
deterministically using:
echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
Previously we could not invoke drivers_probe after adding a device to
new_id for a driver as we get non-deterministic behavior whether the driver
we intend or the standard driver will claim the device. Now it becomes a
deterministic process, only the driver matching driver_override will probe
the device.
To return the device to the standard driver, we simply clear the
driver_override and reprobe the device:
echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
Another advantage to this approach is that we can specify a driver override
to force a specific binding or prevent any binding. For instance when an
IOMMU group is exposed to userspace through VFIO we require that all
devices within that group are owned by VFIO. However, devices can be
hot-added into an IOMMU group, in which case we want to prevent the device
from binding to any driver (override driver = "none") or perhaps have it
automatically bind to vfio-pci. With driver_override it's a simple matter
for this field to be set internally when the device is first discovered to
prevent driver matches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 14:53:21 +00:00
|
|
|
found_id = &dynid->id;
|
|
|
|
break;
|
2005-06-30 09:18:12 +00:00
|
|
|
}
|
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
|
|
|
|
PCI: Introduce new device binding path using pci_dev.driver_override
The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive match of the
device. This shortcuts the existing process of looking up the vendor and
device ID, adding them to the driver new_id, binding the device, then
removing the ID, but it also provides a couple advantages.
First, the above existing process allows the driver to bind to any device
matching the new_id for the window where it's enabled. This is often not
desired, such as the case of trying to bind a single device to a meta
driver like pci-stub or vfio-pci. Using driver_override we can do this
deterministically using:
echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
Previously we could not invoke drivers_probe after adding a device to
new_id for a driver as we get non-deterministic behavior whether the driver
we intend or the standard driver will claim the device. Now it becomes a
deterministic process, only the driver matching driver_override will probe
the device.
To return the device to the standard driver, we simply clear the
driver_override and reprobe the device:
echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
Another advantage to this approach is that we can specify a driver override
to force a specific binding or prevent any binding. For instance when an
IOMMU group is exposed to userspace through VFIO we require that all
devices within that group are owned by VFIO. However, devices can be
hot-added into an IOMMU group, in which case we want to prevent the device
from binding to any driver (override driver = "none") or perhaps have it
automatically bind to vfio-pci. With driver_override it's a simple matter
for this field to be set internally when the device is first discovered to
prevent driver matches.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 14:53:21 +00:00
|
|
|
if (!found_id)
|
|
|
|
found_id = pci_match_id(drv->id_table, dev);
|
|
|
|
|
|
|
|
/* driver_override will always match, send a dummy id */
|
|
|
|
if (!found_id && dev->driver_override)
|
|
|
|
found_id = &pci_device_id_any;
|
|
|
|
|
|
|
|
return found_id;
|
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;
|
2012-11-20 08:08:22 +00:00
|
|
|
struct pci_dev *pci_dev = ddi->dev;
|
|
|
|
struct pci_driver *pci_drv = ddi->drv;
|
|
|
|
struct device *dev = &pci_dev->dev;
|
2010-06-08 19:23:51 +00:00
|
|
|
int rc;
|
|
|
|
|
2012-11-20 08:08:22 +00:00
|
|
|
/*
|
|
|
|
* Unbound PCI devices are always put in D0, regardless of
|
|
|
|
* runtime PM status. During probe, the device is set to
|
|
|
|
* active and the usage count is incremented. If the driver
|
|
|
|
* supports runtime PM, it should call pm_runtime_put_noidle()
|
|
|
|
* in its probe routine and pm_runtime_get_noresume() in its
|
|
|
|
* remove routine.
|
2010-06-08 19:23:51 +00:00
|
|
|
*/
|
2012-11-20 08:08:22 +00:00
|
|
|
pm_runtime_get_sync(dev);
|
|
|
|
pci_dev->driver = pci_drv;
|
|
|
|
rc = pci_drv->probe(pci_dev, ddi->id);
|
2013-11-01 19:34:55 +00:00
|
|
|
if (!rc)
|
|
|
|
return rc;
|
|
|
|
if (rc < 0) {
|
2012-11-20 08:08:22 +00:00
|
|
|
pci_dev->driver = NULL;
|
|
|
|
pm_runtime_put_sync(dev);
|
2013-11-01 19:34:55 +00:00
|
|
|
return rc;
|
2010-06-08 19:23:51 +00:00
|
|
|
}
|
2013-11-01 19:34:55 +00:00
|
|
|
/*
|
|
|
|
* Probe function should return < 0 for failure, 0 for success
|
|
|
|
* Treat values > 0 as success, but warn.
|
|
|
|
*/
|
|
|
|
dev_warn(dev, "Driver probe function unexpectedly returned %d\n", rc);
|
|
|
|
return 0;
|
2008-12-31 13:24:56 +00:00
|
|
|
}
|
|
|
|
|
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 };
|
|
|
|
|
2013-11-18 17:59:59 +00:00
|
|
|
/*
|
|
|
|
* Execute driver initialization on node where the device is
|
|
|
|
* attached. This way the driver likely allocates its local memory
|
|
|
|
* on the right node.
|
|
|
|
*/
|
2008-12-31 13:24:56 +00:00
|
|
|
node = dev_to_node(&dev->dev);
|
2013-11-18 17:59:59 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* On NUMA systems, we are likely to call a PF probe function using
|
|
|
|
* work_on_cpu(). If that probe calls pci_enable_sriov() (which
|
|
|
|
* adds the VF devices via pci_bus_add_device()), we may re-enter
|
|
|
|
* this function to call the VF probe function. Calling
|
|
|
|
* work_on_cpu() again will cause a lockdep warning. Since VFs are
|
|
|
|
* always on the same node as the PF, we can work around this by
|
|
|
|
* avoiding work_on_cpu() when we're already on the correct node.
|
|
|
|
*
|
|
|
|
* Preemption is enabled, so it's theoretically unsafe to use
|
|
|
|
* numa_node_id(), but even if we run the probe function on the
|
|
|
|
* wrong node, it should be functionally correct.
|
|
|
|
*/
|
|
|
|
if (node >= 0 && node != numa_node_id()) {
|
2008-12-31 13:24:56 +00:00
|
|
|
int cpu;
|
|
|
|
|
|
|
|
get_online_cpus();
|
2009-03-13 04:19:46 +00:00
|
|
|
cpu = cpumask_any_and(cpumask_of_node(node), cpu_online_mask);
|
2008-12-31 13:24:56 +00:00
|
|
|
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);
|
2013-11-18 17:59:59 +00:00
|
|
|
|
2005-07-06 17:56:03 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2010-11-18 23:02:31 +00:00
|
|
|
* __pci_device_probe - check if a driver wants to claim a specific PCI device
|
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
|
2013-11-14 18:28:18 +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.
|
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
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);
|
2012-11-20 08:08:22 +00:00
|
|
|
if (error >= 0)
|
2005-06-30 09:18:12 +00:00
|
|
|
error = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2014-04-19 00:13:49 +00:00
|
|
|
static int pci_device_probe(struct device *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2014-04-19 00:13:49 +00:00
|
|
|
static int pci_device_remove(struct device *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-04-19 00:13:49 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver *drv = pci_dev->driver;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (drv) {
|
2010-06-08 19:23:51 +00:00
|
|
|
if (drv->remove) {
|
|
|
|
pm_runtime_get_sync(dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
drv->remove(pci_dev);
|
2010-06-08 19:23:51 +00:00
|
|
|
pm_runtime_put_noidle(dev);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
pci_dev->driver = NULL;
|
|
|
|
}
|
|
|
|
|
2010-06-08 19:23:51 +00:00
|
|
|
/* Undo the runtime PM settings in local_pci_probe() */
|
2012-11-20 08:08:22 +00:00
|
|
|
pm_runtime_put_sync(dev);
|
2010-06-08 19:23:51 +00:00
|
|
|
|
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
|
2013-11-14 18:28:18 +00:00
|
|
|
* that don't like drivers doing that all of the time.
|
2005-04-16 22:20:36 +00:00
|
|
|
* 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;
|
|
|
|
|
2012-10-24 06:54:14 +00:00
|
|
|
pm_runtime_resume(dev);
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
if (drv && drv->shutdown)
|
|
|
|
drv->shutdown(pci_dev);
|
|
|
|
pci_msi_shutdown(pci_dev);
|
|
|
|
pci_msix_shutdown(pci_dev);
|
2012-02-06 23:50:35 +00:00
|
|
|
|
2013-11-27 22:19:25 +00:00
|
|
|
#ifdef CONFIG_KEXEC
|
2012-04-27 19:00:33 +00:00
|
|
|
/*
|
2013-11-27 22:19:25 +00:00
|
|
|
* If this is a kexec reboot, turn off Bus Master bit on the
|
|
|
|
* device to tell it to not continue to do DMA. Don't touch
|
|
|
|
* devices in D3cold or unknown states.
|
|
|
|
* If it is not a kexec reboot, firmware will hit the PCI
|
|
|
|
* devices with big hammer and stop their DMA any way.
|
2012-04-27 19:00:33 +00:00
|
|
|
*/
|
2013-11-27 22:19:25 +00:00
|
|
|
if (kexec_in_progress && (pci_dev->current_state <= PCI_D3hot))
|
2013-03-14 14:49:37 +00:00
|
|
|
pci_clear_master(pci_dev);
|
2013-11-27 22:19:25 +00:00
|
|
|
#endif
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
2011-02-10 23:06:54 +00:00
|
|
|
#ifdef CONFIG_PM
|
2010-02-17 22:44:58 +00:00
|
|
|
|
|
|
|
/* Auxiliary functions used for system resume and run-time resume. */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_restore_standard_config - restore standard config registers of PCI device
|
|
|
|
* @pci_dev: PCI device to handle
|
|
|
|
*/
|
|
|
|
static int pci_restore_standard_config(struct pci_dev *pci_dev)
|
|
|
|
{
|
|
|
|
pci_update_current_state(pci_dev, PCI_UNKNOWN);
|
|
|
|
|
|
|
|
if (pci_dev->current_state != PCI_D0) {
|
|
|
|
int error = pci_set_power_state(pci_dev, PCI_D0);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2010-11-30 23:43:26 +00:00
|
|
|
pci_restore_state(pci_dev);
|
|
|
|
return 0;
|
2010-02-17 22:44:58 +00:00
|
|
|
}
|
|
|
|
|
PCI / PM: restore the original behavior of pci_set_power_state()
Commit cc2893b6 (PCI: Ensure we re-enable devices on resume)
addressed the problem with USB not being powered after resume on
recent Lenovo machines, but it did that in a suboptimal way.
Namely, it should have changed the relevant code paths only,
which are pci_pm_resume_noirq() and pci_pm_restore_noirq() supposed
to restore the device's power and standard configuration registers
after system resume from suspend or hibernation. Instead, however,
it modified pci_set_power_state() which is executed in several
other situations too. That resulted in some undesirable effects,
like attempting to change a device's power state in the same way
multiple times in a row (up to as many as 4 times in a row in the
snd_hda_intel driver).
Fix the bug addressed by commit cc2893b6 in an alternative way,
by forcibly powering up all devices in pci_pm_default_resume_early(),
which is called by pci_pm_resume_noirq() and pci_pm_restore_noirq()
to restore the device's power and standard configuration registers,
and modifying pci_pm_runtime_resume() to avoid the forcible power-up
if not necessary. Then, revert the changes made by commit cc2893b6
to make the confusion introduced by it go away.
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-07-05 21:20:00 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
static void pci_pm_default_resume_early(struct pci_dev *pci_dev)
|
|
|
|
{
|
PCI / PM: restore the original behavior of pci_set_power_state()
Commit cc2893b6 (PCI: Ensure we re-enable devices on resume)
addressed the problem with USB not being powered after resume on
recent Lenovo machines, but it did that in a suboptimal way.
Namely, it should have changed the relevant code paths only,
which are pci_pm_resume_noirq() and pci_pm_restore_noirq() supposed
to restore the device's power and standard configuration registers
after system resume from suspend or hibernation. Instead, however,
it modified pci_set_power_state() which is executed in several
other situations too. That resulted in some undesirable effects,
like attempting to change a device's power state in the same way
multiple times in a row (up to as many as 4 times in a row in the
snd_hda_intel driver).
Fix the bug addressed by commit cc2893b6 in an alternative way,
by forcibly powering up all devices in pci_pm_default_resume_early(),
which is called by pci_pm_resume_noirq() and pci_pm_restore_noirq()
to restore the device's power and standard configuration registers,
and modifying pci_pm_runtime_resume() to avoid the forcible power-up
if not necessary. Then, revert the changes made by commit cc2893b6
to make the confusion introduced by it go away.
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-07-05 21:20:00 +00:00
|
|
|
pci_power_up(pci_dev);
|
|
|
|
pci_restore_state(pci_dev);
|
2010-02-17 22:44:58 +00:00
|
|
|
pci_fixup_device(pci_fixup_resume_early, pci_dev);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2014-04-19 00:13:49 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver *drv = pci_dev->driver;
|
2009-03-16 21:40:26 +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-03-16 21:40:26 +00:00
|
|
|
int error;
|
2009-01-16 20:54:43 +00:00
|
|
|
|
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
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
if (!pci_dev->state_saved && pci_dev->current_state != PCI_D0
|
2009-02-04 00:59:09 +00:00
|
|
|
&& pci_dev->current_state != PCI_UNKNOWN) {
|
|
|
|
WARN_ONCE(pci_dev->current_state != prev,
|
|
|
|
"PCI PM: Device state not saved by %pF\n",
|
|
|
|
drv->suspend);
|
|
|
|
}
|
2006-03-23 09:38:34 +00:00
|
|
|
}
|
2009-01-07 12:09:37 +00:00
|
|
|
|
|
|
|
pci_fixup_device(pci_fixup_suspend, pci_dev);
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
return 0;
|
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
|
|
|
{
|
2014-04-19 00:13:49 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver *drv = pci_dev->driver;
|
2006-06-24 21:50:29 +00:00
|
|
|
|
|
|
|
if (drv && drv->suspend_late) {
|
2009-03-16 21:40:26 +00:00
|
|
|
pci_power_t prev = pci_dev->current_state;
|
|
|
|
int error;
|
|
|
|
|
2009-03-16 21:39:56 +00:00
|
|
|
error = drv->suspend_late(pci_dev, state);
|
|
|
|
suspend_report_result(drv->suspend_late, error);
|
2009-03-16 21:40:26 +00:00
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
|
|
|
|
if (!pci_dev->state_saved && 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_late);
|
2014-06-03 20:04:09 +00:00
|
|
|
goto Fixup;
|
2009-03-16 21:40:26 +00:00
|
|
|
}
|
2006-06-24 21:50:29 +00:00
|
|
|
}
|
2009-03-16 21:40:26 +00:00
|
|
|
|
|
|
|
if (!pci_dev->state_saved)
|
|
|
|
pci_save_state(pci_dev);
|
|
|
|
|
|
|
|
pci_pm_set_unknown_state(pci_dev);
|
|
|
|
|
2014-06-03 20:04:09 +00:00
|
|
|
Fixup:
|
|
|
|
pci_fixup_device(pci_fixup_suspend_late, pci_dev);
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
return 0;
|
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)
|
|
|
|
{
|
2014-04-19 00:13:49 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver *drv = pci_dev->driver;
|
2009-01-07 12:12:22 +00:00
|
|
|
|
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
|
|
|
{
|
2014-04-19 00:13:49 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
struct pci_driver *drv = pci_dev->driver;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
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: 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);
|
|
|
|
|
2014-05-04 04:23:36 +00:00
|
|
|
if (!pci_has_subordinate(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
|
|
|
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 */
|
2014-05-04 04:23:36 +00:00
|
|
|
if (!pci_has_subordinate(pci_dev))
|
2009-02-04 01:01:15 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*/
|
2011-11-20 21:29:46 +00:00
|
|
|
WARN(ret && drv->driver.pm, "driver %s device %04x:%04x\n",
|
|
|
|
drv->name, pci_dev->vendor, pci_dev->device);
|
2009-01-07 13:15:17 +00:00
|
|
|
|
|
|
|
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;
|
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
/*
|
PCI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
pci_pm_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-26 00:00:30 +00:00
|
|
|
* Devices having power.ignore_children set may still be necessary for
|
|
|
|
* suspending their children in the next phase of device suspend.
|
2010-02-17 22:44:58 +00:00
|
|
|
*/
|
PCI / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
pci_pm_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-26 00:00:30 +00:00
|
|
|
if (dev->power.ignore_children)
|
|
|
|
pm_runtime_resume(dev);
|
2010-02-17 22:44:58 +00:00
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
if (drv && drv->pm && drv->pm->prepare)
|
|
|
|
error = drv->pm->prepare(dev);
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
#else /* !CONFIG_PM_SLEEP */
|
|
|
|
|
|
|
|
#define pci_pm_prepare NULL
|
|
|
|
|
|
|
|
#endif /* !CONFIG_PM_SLEEP */
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
#ifdef CONFIG_SUSPEND
|
|
|
|
|
|
|
|
static int pci_pm_suspend(struct device *dev)
|
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2009-07-25 05:11:32 +00:00
|
|
|
const 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 / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
pci_pm_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-26 00:00:30 +00:00
|
|
|
/*
|
|
|
|
* PCI devices suspended at run time need to be resumed at this point,
|
|
|
|
* because in general it is necessary to reconfigure them for system
|
|
|
|
* suspend. Namely, if the device is supposed to wake up the system
|
|
|
|
* from the sleep state, we may need to reconfigure it for this purpose.
|
|
|
|
* In turn, if the device is not supposed to wake up the system from the
|
|
|
|
* sleep state, we'll have to prevent it from signaling wake-up.
|
|
|
|
*/
|
|
|
|
pm_runtime_resume(dev);
|
|
|
|
|
2013-02-04 11:56:05 +00:00
|
|
|
pci_dev->state_saved = false;
|
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->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;
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
if (!pci_dev->state_saved && pci_dev->current_state != PCI_D0
|
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->current_state != PCI_UNKNOWN) {
|
|
|
|
WARN_ONCE(pci_dev->current_state != prev,
|
|
|
|
"PCI PM: State of device not saved by %pF\n",
|
|
|
|
pm->suspend);
|
|
|
|
}
|
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
|
|
|
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);
|
2009-07-25 05:11:32 +00:00
|
|
|
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
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-03-16 21:40:50 +00:00
|
|
|
if (!pm) {
|
|
|
|
pci_save_state(pci_dev);
|
2014-06-03 20:04:09 +00:00
|
|
|
goto Fixup;
|
2009-03-16 21:40:50 +00:00
|
|
|
}
|
2009-03-16 21:40:26 +00:00
|
|
|
|
|
|
|
if (pm->suspend_noirq) {
|
|
|
|
pci_power_t prev = pci_dev->current_state;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = pm->suspend_noirq(dev);
|
|
|
|
suspend_report_result(pm->suspend_noirq, error);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
|
|
|
|
if (!pci_dev->state_saved && 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_noirq);
|
2014-06-03 20:04:09 +00:00
|
|
|
goto Fixup;
|
2009-03-16 21:40:26 +00:00
|
|
|
}
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
if (!pci_dev->state_saved) {
|
|
|
|
pci_save_state(pci_dev);
|
2014-05-04 04:23:36 +00:00
|
|
|
if (!pci_has_subordinate(pci_dev))
|
2009-03-16 21:40:26 +00:00
|
|
|
pci_prepare_to_sleep(pci_dev);
|
|
|
|
}
|
2009-01-07 12:11:28 +00:00
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
pci_pm_set_unknown_state(pci_dev);
|
|
|
|
|
PCI: EHCI: fix crash during suspend on ASUS computers
Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend. It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.
It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working. Consequently
commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add
NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.
Now we know the actual cause of the problem. Thanks to AceLan Kao for
tracking it down.
According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows. When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS. Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state. If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so. This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3. The end result is
a system hang or memory corruption.
Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend. This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.
In theory we could do this for every PCI device. However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.
Finally the affected systems can suspend with USB wakeup working
properly.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Dâniel Fraga <fragabr@gmail.com>
Tested-by: Javier Marcet <jmarcet@gmail.com>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Cc: stable <stable@vger.kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-09 15:09:21 +00:00
|
|
|
/*
|
|
|
|
* Some BIOSes from ASUS have a bug: If a USB EHCI host controller's
|
|
|
|
* PCI COMMAND register isn't 0, the BIOS assumes that the controller
|
|
|
|
* hasn't been quiesced and tries to turn it off. If the controller
|
|
|
|
* is already in D3, this can hang or cause memory corruption.
|
|
|
|
*
|
|
|
|
* Since the value of the COMMAND register doesn't matter once the
|
|
|
|
* device has been suspended, we can safely set it to 0 here.
|
|
|
|
*/
|
|
|
|
if (pci_dev->class == PCI_CLASS_SERIAL_USB_EHCI)
|
|
|
|
pci_write_config_word(pci_dev, PCI_COMMAND, 0);
|
|
|
|
|
2014-06-03 20:04:09 +00:00
|
|
|
Fixup:
|
|
|
|
pci_fixup_device(pci_fixup_suspend_late, pci_dev);
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
return 0;
|
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
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
pci_pm_default_resume_early(pci_dev);
|
2009-01-16 20:54:43 +00:00
|
|
|
|
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);
|
2009-07-25 05:11:32 +00:00
|
|
|
const 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
|
|
|
|
2009-09-09 21:51:27 +00:00
|
|
|
return error;
|
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 */
|
|
|
|
|
2011-04-11 20:54:42 +00:00
|
|
|
#ifdef CONFIG_HIBERNATE_CALLBACKS
|
2008-05-19 22:49:04 +00:00
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pcibios_pm_ops - provide arch-specific hooks when a PCI device is doing
|
|
|
|
* a hibernate transition
|
|
|
|
*/
|
|
|
|
struct dev_pm_ops __weak pcibios_pm_ops;
|
|
|
|
|
2008-05-19 22:49:04 +00:00
|
|
|
static int pci_pm_freeze(struct device *dev)
|
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2009-07-25 05:11:32 +00:00
|
|
|
const 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: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
pci_pm_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-26 00:00:30 +00:00
|
|
|
/*
|
|
|
|
* This used to be done in pci_pm_prepare() for all devices and some
|
|
|
|
* drivers may depend on it, so do it here. Ideally, runtime-suspended
|
|
|
|
* devices should not be touched during freeze/thaw transitions,
|
|
|
|
* however.
|
|
|
|
*/
|
|
|
|
pm_runtime_resume(dev);
|
|
|
|
|
2013-02-04 11:56:05 +00:00
|
|
|
pci_dev->state_saved = false;
|
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;
|
|
|
|
}
|
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
if (pcibios_pm_ops.freeze)
|
|
|
|
return pcibios_pm_ops.freeze(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
|
|
|
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
|
|
|
|
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) {
|
2009-03-16 21:40:26 +00:00
|
|
|
int error;
|
|
|
|
|
2009-01-07 12:11:28 +00:00
|
|
|
error = drv->pm->freeze_noirq(dev);
|
|
|
|
suspend_report_result(drv->pm->freeze_noirq, error);
|
2009-03-16 21:40:26 +00:00
|
|
|
if (error)
|
|
|
|
return error;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
if (!pci_dev->state_saved)
|
|
|
|
pci_save_state(pci_dev);
|
2009-01-07 12:11:28 +00:00
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
pci_pm_set_unknown_state(pci_dev);
|
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
if (pcibios_pm_ops.freeze_noirq)
|
|
|
|
return pcibios_pm_ops.freeze_noirq(dev);
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
return 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
if (pcibios_pm_ops.thaw_noirq) {
|
|
|
|
error = pcibios_pm_ops.thaw_noirq(dev);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
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);
|
2009-07-25 05:11:32 +00:00
|
|
|
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
if (pcibios_pm_ops.thaw) {
|
|
|
|
error = pcibios_pm_ops.thaw(dev);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2009-09-09 21:49:59 +00:00
|
|
|
pci_dev->state_saved = false;
|
|
|
|
|
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-07-25 05:11:32 +00:00
|
|
|
const 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_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 / PM: Resume runtime-suspended devices later during system suspend
Runtime-suspended devices are resumed during system suspend by
pci_pm_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended. That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.
For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set. The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-26 00:00:30 +00:00
|
|
|
/* The reason to do that is the same as in pci_pm_suspend(). */
|
|
|
|
pm_runtime_resume(dev);
|
|
|
|
|
2013-02-04 11:56:05 +00:00
|
|
|
pci_dev->state_saved = false;
|
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->poweroff) {
|
2009-03-16 21:40:26 +00:00
|
|
|
int error;
|
|
|
|
|
2009-02-04 00:56:14 +00:00
|
|
|
error = pm->poweroff(dev);
|
|
|
|
suspend_report_result(pm->poweroff, error);
|
2009-03-16 21:40:26 +00:00
|
|
|
if (error)
|
|
|
|
return 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
|
|
|
Fixup:
|
|
|
|
pci_fixup_device(pci_fixup_suspend, pci_dev);
|
2009-01-07 12:02:36 +00:00
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
if (pcibios_pm_ops.poweroff)
|
|
|
|
return pcibios_pm_ops.poweroff(dev);
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
return 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_pm_poweroff_noirq(struct device *dev)
|
|
|
|
{
|
2009-03-16 21:40:26 +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
|
|
|
|
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);
|
|
|
|
|
2014-06-03 20:04:09 +00:00
|
|
|
if (!drv || !drv->pm) {
|
|
|
|
pci_fixup_device(pci_fixup_suspend_late, pci_dev);
|
2009-03-16 21:40:26 +00:00
|
|
|
return 0;
|
2014-06-03 20:04:09 +00:00
|
|
|
}
|
2009-03-16 21:40:26 +00:00
|
|
|
|
|
|
|
if (drv->pm->poweroff_noirq) {
|
|
|
|
int error;
|
|
|
|
|
2009-01-07 12:11:28 +00:00
|
|
|
error = drv->pm->poweroff_noirq(dev);
|
|
|
|
suspend_report_result(drv->pm->poweroff_noirq, error);
|
2009-03-16 21:40:26 +00:00
|
|
|
if (error)
|
|
|
|
return error;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
2014-05-04 04:23:36 +00:00
|
|
|
if (!pci_dev->state_saved && !pci_has_subordinate(pci_dev))
|
2009-03-16 21:40:26 +00:00
|
|
|
pci_prepare_to_sleep(pci_dev);
|
|
|
|
|
2012-08-12 21:26:07 +00:00
|
|
|
/*
|
|
|
|
* The reason for doing this here is the same as for the analogous code
|
|
|
|
* in pci_pm_suspend_noirq().
|
|
|
|
*/
|
|
|
|
if (pci_dev->class == PCI_CLASS_SERIAL_USB_EHCI)
|
|
|
|
pci_write_config_word(pci_dev, PCI_COMMAND, 0);
|
|
|
|
|
2014-06-03 20:04:09 +00:00
|
|
|
pci_fixup_device(pci_fixup_suspend_late, pci_dev);
|
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
if (pcibios_pm_ops.poweroff_noirq)
|
|
|
|
return pcibios_pm_ops.poweroff_noirq(dev);
|
|
|
|
|
2009-03-16 21:40:26 +00:00
|
|
|
return 0;
|
2008-05-19 22:49:04 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
if (pcibios_pm_ops.restore_noirq) {
|
|
|
|
error = pcibios_pm_ops.restore_noirq(dev);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
pci_pm_default_resume_early(pci_dev);
|
2009-01-16 20:54:43 +00:00
|
|
|
|
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);
|
2009-07-25 05:11:32 +00:00
|
|
|
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
2008-05-19 22:49:04 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2013-08-20 14:41:02 +00:00
|
|
|
if (pcibios_pm_ops.restore) {
|
|
|
|
error = pcibios_pm_ops.restore(dev);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2011-04-11 20:54:42 +00:00
|
|
|
#else /* !CONFIG_HIBERNATE_CALLBACKS */
|
2008-05-19 22:49:04 +00:00
|
|
|
|
|
|
|
#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
|
|
|
|
|
2011-04-11 20:54:42 +00:00
|
|
|
#endif /* !CONFIG_HIBERNATE_CALLBACKS */
|
2008-05-19 22:49:04 +00:00
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
#ifdef CONFIG_PM_RUNTIME
|
|
|
|
|
|
|
|
static int pci_pm_runtime_suspend(struct device *dev)
|
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
|
|
|
pci_power_t prev = pci_dev->current_state;
|
|
|
|
int error;
|
|
|
|
|
2012-11-20 08:08:22 +00:00
|
|
|
/*
|
|
|
|
* If pci_dev->driver is not set (unbound), the device should
|
|
|
|
* always remain in D0 regardless of the runtime PM status
|
|
|
|
*/
|
|
|
|
if (!pci_dev->driver)
|
|
|
|
return 0;
|
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
if (!pm || !pm->runtime_suspend)
|
|
|
|
return -ENOSYS;
|
|
|
|
|
2013-02-04 11:56:05 +00:00
|
|
|
pci_dev->state_saved = false;
|
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 02:23:51 +00:00
|
|
|
pci_dev->no_d3cold = false;
|
2010-02-17 22:44:58 +00:00
|
|
|
error = pm->runtime_suspend(dev);
|
|
|
|
suspend_report_result(pm->runtime_suspend, error);
|
|
|
|
if (error)
|
|
|
|
return error;
|
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 02:23:51 +00:00
|
|
|
if (!pci_dev->d3cold_allowed)
|
|
|
|
pci_dev->no_d3cold = true;
|
2010-02-17 22:44:58 +00:00
|
|
|
|
|
|
|
pci_fixup_device(pci_fixup_suspend, pci_dev);
|
|
|
|
|
|
|
|
if (!pci_dev->state_saved && 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->runtime_suspend);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-10-29 23:26:54 +00:00
|
|
|
if (!pci_dev->state_saved) {
|
2010-02-17 22:44:58 +00:00
|
|
|
pci_save_state(pci_dev);
|
2012-10-29 23:26:54 +00:00
|
|
|
pci_finish_runtime_suspend(pci_dev);
|
|
|
|
}
|
2010-02-17 22:44:58 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_pm_runtime_resume(struct device *dev)
|
|
|
|
{
|
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 02:23:51 +00:00
|
|
|
int rc;
|
2010-02-17 22:44:58 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
|
|
|
|
2012-11-20 08:08:22 +00:00
|
|
|
/*
|
|
|
|
* If pci_dev->driver is not set (unbound), the device should
|
|
|
|
* always remain in D0 regardless of the runtime PM status
|
|
|
|
*/
|
|
|
|
if (!pci_dev->driver)
|
|
|
|
return 0;
|
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
if (!pm || !pm->runtime_resume)
|
|
|
|
return -ENOSYS;
|
|
|
|
|
PCI / PM: restore the original behavior of pci_set_power_state()
Commit cc2893b6 (PCI: Ensure we re-enable devices on resume)
addressed the problem with USB not being powered after resume on
recent Lenovo machines, but it did that in a suboptimal way.
Namely, it should have changed the relevant code paths only,
which are pci_pm_resume_noirq() and pci_pm_restore_noirq() supposed
to restore the device's power and standard configuration registers
after system resume from suspend or hibernation. Instead, however,
it modified pci_set_power_state() which is executed in several
other situations too. That resulted in some undesirable effects,
like attempting to change a device's power state in the same way
multiple times in a row (up to as many as 4 times in a row in the
snd_hda_intel driver).
Fix the bug addressed by commit cc2893b6 in an alternative way,
by forcibly powering up all devices in pci_pm_default_resume_early(),
which is called by pci_pm_resume_noirq() and pci_pm_restore_noirq()
to restore the device's power and standard configuration registers,
and modifying pci_pm_runtime_resume() to avoid the forcible power-up
if not necessary. Then, revert the changes made by commit cc2893b6
to make the confusion introduced by it go away.
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-07-05 21:20:00 +00:00
|
|
|
pci_restore_standard_config(pci_dev);
|
|
|
|
pci_fixup_device(pci_fixup_resume_early, pci_dev);
|
2010-02-17 22:44:58 +00:00
|
|
|
__pci_enable_wake(pci_dev, PCI_D0, true, false);
|
|
|
|
pci_fixup_device(pci_fixup_resume, pci_dev);
|
|
|
|
|
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 02:23:51 +00:00
|
|
|
rc = pm->runtime_resume(dev);
|
|
|
|
|
|
|
|
pci_dev->runtime_d3cold = false;
|
|
|
|
|
|
|
|
return rc;
|
2010-02-17 22:44:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_pm_runtime_idle(struct device *dev)
|
|
|
|
{
|
2012-11-20 08:08:22 +00:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2010-02-17 22:44:58 +00:00
|
|
|
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
|
PM / Runtime: Rework the "runtime idle" helper routine
The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0. If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.
Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.
To reduce overall code bloat, make the changes described above.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2013-06-03 19:49:52 +00:00
|
|
|
int ret = 0;
|
2010-02-17 22:44:58 +00:00
|
|
|
|
2012-11-20 08:08:22 +00:00
|
|
|
/*
|
|
|
|
* If pci_dev->driver is not set (unbound), the device should
|
|
|
|
* always remain in D0 regardless of the runtime PM status
|
|
|
|
*/
|
|
|
|
if (!pci_dev->driver)
|
PM / Runtime: Rework the "runtime idle" helper routine
The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0. If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.
Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.
To reduce overall code bloat, make the changes described above.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2013-06-03 19:49:52 +00:00
|
|
|
return 0;
|
2012-11-20 08:08:22 +00:00
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
if (!pm)
|
|
|
|
return -ENOSYS;
|
|
|
|
|
PM / Runtime: Rework the "runtime idle" helper routine
The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0. If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.
Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.
To reduce overall code bloat, make the changes described above.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2013-06-03 19:49:52 +00:00
|
|
|
if (pm->runtime_idle)
|
|
|
|
ret = pm->runtime_idle(dev);
|
2010-02-17 22:44:58 +00:00
|
|
|
|
PM / Runtime: Rework the "runtime idle" helper routine
The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0. If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.
Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.
To reduce overall code bloat, make the changes described above.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2013-06-03 19:49:52 +00:00
|
|
|
return ret;
|
2010-02-17 22:44:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#else /* !CONFIG_PM_RUNTIME */
|
|
|
|
|
|
|
|
#define pci_pm_runtime_suspend NULL
|
|
|
|
#define pci_pm_runtime_resume NULL
|
|
|
|
#define pci_pm_runtime_idle NULL
|
|
|
|
|
|
|
|
#endif /* !CONFIG_PM_RUNTIME */
|
|
|
|
|
2011-02-10 23:06:54 +00:00
|
|
|
#ifdef CONFIG_PM
|
2010-02-17 22:44:58 +00:00
|
|
|
|
2013-10-04 18:04:44 +00:00
|
|
|
static const struct dev_pm_ops pci_dev_pm_ops = {
|
2008-10-06 20:46:05 +00:00
|
|
|
.prepare = pci_pm_prepare,
|
|
|
|
.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,
|
2010-02-17 22:44:58 +00:00
|
|
|
.runtime_suspend = pci_pm_runtime_suspend,
|
|
|
|
.runtime_resume = pci_pm_runtime_resume,
|
|
|
|
.runtime_idle = pci_pm_runtime_idle,
|
2008-05-19 22:49:04 +00:00
|
|
|
};
|
|
|
|
|
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
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
#else /* !COMFIG_PM_OPS */
|
2008-05-19 22:49:04 +00:00
|
|
|
|
|
|
|
#define PCI_PM_OPS_PTR NULL
|
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
#endif /* !COMFIG_PM_OPS */
|
2008-05-19 22:49:04 +00:00
|
|
|
|
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
|
2013-11-14 18:28:18 +00:00
|
|
|
*
|
2005-04-16 22:20:36 +00:00
|
|
|
* Adds the driver structure to the list of registered drivers.
|
2013-11-14 18:28:18 +00:00
|
|
|
* Returns a negative value on error, otherwise 0.
|
|
|
|
* 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
|
|
|
{
|
|
|
|
/* 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 */
|
2012-08-08 10:47:51 +00:00
|
|
|
return driver_register(&drv->driver);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(__pci_register_driver);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_unregister_driver - unregister a pci driver
|
|
|
|
* @drv: the driver structure to unregister
|
2013-11-14 18:28:18 +00:00
|
|
|
*
|
2005-04-16 22:20:36 +00:00
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2014-04-19 00:13:49 +00:00
|
|
|
void pci_unregister_driver(struct pci_driver *drv)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
driver_unregister(&drv->driver);
|
|
|
|
pci_free_dynids(drv);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_unregister_driver);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
static struct pci_driver pci_compat_driver = {
|
|
|
|
.name = "compat"
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_dev_driver - get the pci_driver of a device
|
|
|
|
* @dev: the device to query
|
|
|
|
*
|
2013-11-14 18:28:18 +00:00
|
|
|
* Returns the appropriate pci_driver structure or %NULL if there is no
|
2005-04-16 22:20:36 +00:00
|
|
|
* registered driver for the device.
|
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
struct pci_driver *pci_dev_driver(const struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
if (dev->driver)
|
|
|
|
return dev->driver;
|
|
|
|
else {
|
|
|
|
int i;
|
2014-04-19 00:13:49 +00:00
|
|
|
for (i = 0; i <= PCI_ROM_RESOURCE; i++)
|
2005-04-16 22:20:36 +00:00
|
|
|
if (dev->resource[i].flags & IORESOURCE_BUSY)
|
|
|
|
return &pci_compat_driver;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_dev_driver);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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
|
2013-11-14 18:28:18 +00:00
|
|
|
*
|
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);
|
2013-01-21 21:20:51 +00:00
|
|
|
struct pci_driver *pci_drv;
|
2005-04-16 22:20:36 +00:00
|
|
|
const struct pci_device_id *found_id;
|
|
|
|
|
2013-01-21 21:20:51 +00:00
|
|
|
if (!pci_dev->match_driver)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
pci_drv = to_pci_driver(drv);
|
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;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_dev_get);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_dev_put);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-11-21 20:34:58 +00:00
|
|
|
static int pci_uevent(struct device *dev, struct kobj_uevent_env *env)
|
|
|
|
{
|
|
|
|
struct pci_dev *pdev;
|
|
|
|
|
|
|
|
if (!dev)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
pdev = to_pci_dev(dev);
|
|
|
|
|
|
|
|
if (add_uevent_var(env, "PCI_CLASS=%04X", pdev->class))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (add_uevent_var(env, "PCI_ID=%04X:%04X", pdev->vendor, pdev->device))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (add_uevent_var(env, "PCI_SUBSYS_ID=%04X:%04X", pdev->subsystem_vendor,
|
|
|
|
pdev->subsystem_device))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (add_uevent_var(env, "PCI_SLOT_NAME=%s", pci_name(pdev)))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (add_uevent_var(env, "MODALIAS=pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x",
|
|
|
|
pdev->vendor, pdev->device,
|
|
|
|
pdev->subsystem_vendor, pdev->subsystem_device,
|
|
|
|
(u8)(pdev->class >> 16), (u8)(pdev->class >> 8),
|
|
|
|
(u8)(pdev->class)))
|
|
|
|
return -ENOMEM;
|
2014-04-05 21:08:22 +00:00
|
|
|
|
2012-11-21 20:34:58 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
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,
|
2013-10-07 06:55:40 +00:00
|
|
|
.dev_groups = pci_dev_groups,
|
2013-10-07 20:51:02 +00:00
|
|
|
.bus_groups = pci_bus_groups,
|
2013-10-07 20:51:20 +00:00
|
|
|
.drv_groups = pci_drv_groups,
|
2008-05-19 22:49:04 +00:00
|
|
|
.pm = PCI_PM_OPS_PTR,
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_bus_type);
|
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);
|