2018-01-26 17:45:16 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2018-03-09 22:36:33 +00:00
|
|
|
* PCI Bus Services, see include/linux/pci.h for further explanation.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2018-03-09 22:36:33 +00:00
|
|
|
* Copyright 1993 -- 1997 Drew Eckhardt, Frederic Potter,
|
|
|
|
* David Mosberger-Tang
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2018-03-09 22:36:33 +00:00
|
|
|
* Copyright 1997 -- 2000 Martin Mares <mj@ucw.cz>
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
|
2016-06-10 20:36:26 +00:00
|
|
|
#include <linux/acpi.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/delay.h>
|
2016-06-02 08:17:12 +00:00
|
|
|
#include <linux/dmi.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/init.h>
|
2014-12-28 01:19:12 +00:00
|
|
|
#include <linux/of.h>
|
|
|
|
#include <linux/of_pci.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/pci.h>
|
2007-04-26 07:12:06 +00:00
|
|
|
#include <linux/pm.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/spinlock.h>
|
2005-10-30 23:03:48 +00:00
|
|
|
#include <linux/string.h>
|
2007-08-13 12:53:14 +00:00
|
|
|
#include <linux/log2.h>
|
2018-03-14 18:15:53 +00:00
|
|
|
#include <linux/logic_pio.h>
|
2008-07-10 00:16:44 +00:00
|
|
|
#include <linux/pm_wakeup.h>
|
2008-10-21 09:38:25 +00:00
|
|
|
#include <linux/interrupt.h>
|
2009-03-16 08:13:39 +00:00
|
|
|
#include <linux/device.h>
|
2010-02-17 22:44:09 +00:00
|
|
|
#include <linux/pm_runtime.h>
|
2013-08-08 20:09:43 +00:00
|
|
|
#include <linux/pci_hotplug.h>
|
2016-06-10 19:55:11 +00:00
|
|
|
#include <linux/vmalloc.h>
|
2017-05-30 16:25:49 +00:00
|
|
|
#include <linux/pci-ats.h>
|
2009-03-16 08:13:39 +00:00
|
|
|
#include <asm/setup.h>
|
2016-06-17 15:05:13 +00:00
|
|
|
#include <asm/dma.h>
|
2015-09-17 15:09:37 +00:00
|
|
|
#include <linux/aer.h>
|
2005-04-08 05:53:31 +00:00
|
|
|
#include "pci.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-09-20 16:27:11 +00:00
|
|
|
DEFINE_MUTEX(pci_slot_mutex);
|
|
|
|
|
2009-04-27 17:33:16 +00:00
|
|
|
const char *pci_power_names[] = {
|
|
|
|
"error", "D0", "D1", "D2", "D3hot", "D3cold", "unknown",
|
|
|
|
};
|
|
|
|
EXPORT_SYMBOL_GPL(pci_power_names);
|
|
|
|
|
2010-01-02 21:57:24 +00:00
|
|
|
int isa_dma_bridge_buggy;
|
|
|
|
EXPORT_SYMBOL(isa_dma_bridge_buggy);
|
|
|
|
|
|
|
|
int pci_pci_problems;
|
|
|
|
EXPORT_SYMBOL(pci_pci_problems);
|
|
|
|
|
2009-12-31 11:15:54 +00:00
|
|
|
unsigned int pci_pm_d3_delay;
|
|
|
|
|
2010-10-04 18:22:29 +00:00
|
|
|
static void pci_pme_list_scan(struct work_struct *work);
|
|
|
|
|
|
|
|
static LIST_HEAD(pci_pme_list);
|
|
|
|
static DEFINE_MUTEX(pci_pme_list_mutex);
|
|
|
|
static DECLARE_DELAYED_WORK(pci_pme_work, pci_pme_list_scan);
|
|
|
|
|
|
|
|
struct pci_pme_device {
|
|
|
|
struct list_head list;
|
|
|
|
struct pci_dev *dev;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define PME_TIMEOUT 1000 /* How long between PME checks */
|
|
|
|
|
2009-12-31 11:15:54 +00:00
|
|
|
static void pci_dev_d3_sleep(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
unsigned int delay = dev->d3_delay;
|
|
|
|
|
|
|
|
if (delay < pci_pm_d3_delay)
|
|
|
|
delay = pci_pm_d3_delay;
|
|
|
|
|
2017-03-14 13:21:58 +00:00
|
|
|
if (delay)
|
|
|
|
msleep(delay);
|
2009-12-31 11:15:54 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-10-11 20:57:27 +00:00
|
|
|
#ifdef CONFIG_PCI_DOMAINS
|
|
|
|
int pci_domains_supported = 1;
|
|
|
|
#endif
|
|
|
|
|
2007-02-06 00:36:06 +00:00
|
|
|
#define DEFAULT_CARDBUS_IO_SIZE (256)
|
|
|
|
#define DEFAULT_CARDBUS_MEM_SIZE (64*1024*1024)
|
|
|
|
/* pci=cbmemsize=nnM,cbiosize=nn can override this */
|
|
|
|
unsigned long pci_cardbus_io_size = DEFAULT_CARDBUS_IO_SIZE;
|
|
|
|
unsigned long pci_cardbus_mem_size = DEFAULT_CARDBUS_MEM_SIZE;
|
|
|
|
|
2009-09-09 21:09:24 +00:00
|
|
|
#define DEFAULT_HOTPLUG_IO_SIZE (256)
|
|
|
|
#define DEFAULT_HOTPLUG_MEM_SIZE (2*1024*1024)
|
|
|
|
/* pci=hpmemsize=nnM,hpiosize=nn can override this */
|
|
|
|
unsigned long pci_hotplug_io_size = DEFAULT_HOTPLUG_IO_SIZE;
|
|
|
|
unsigned long pci_hotplug_mem_size = DEFAULT_HOTPLUG_MEM_SIZE;
|
|
|
|
|
2016-07-22 03:40:28 +00:00
|
|
|
#define DEFAULT_HOTPLUG_BUS_SIZE 1
|
|
|
|
unsigned long pci_hotplug_bus_size = DEFAULT_HOTPLUG_BUS_SIZE;
|
|
|
|
|
PCI: Set MPS to match upstream bridge
Firmware typically configures the PCIe fabric with a consistent Max Payload
Size setting based on the devices present at boot. A hot-added device
typically has the power-on default MPS setting (128 bytes), which may not
match the fabric.
The previous Linux default, in the absence of any "pci=pcie_bus_*" options,
was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added
devices.
Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every
device's MPS setting matches the upstream bridge. This makes it more
likely that a hot-added device will work in a system with optimized MPS
configuration.
Note that if we hot-add a device that only supports 128-byte MPS, it still
likely won't work because we don't reconfigure the rest of the fabric.
Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it
sets MPS to 128 for everything.
[bhelgaas: changelog, new default, rework for pci_configure_device() path]
Tested-by: Keith Busch <keith.busch@intel.com>
Tested-by: Jordan Hargrave <jharg93@gmail.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2015-08-24 13:48:16 +00:00
|
|
|
enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_DEFAULT;
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
|
2009-10-26 20:20:44 +00:00
|
|
|
/*
|
|
|
|
* The default CLS is used if arch didn't set CLS explicitly and not
|
|
|
|
* all pci devices agree on the same value. Arch can override either
|
|
|
|
* the dfl or actual value as it sees fit. Don't forget this is
|
|
|
|
* measured in 32-bit words, not bytes.
|
|
|
|
*/
|
2012-11-21 20:35:00 +00:00
|
|
|
u8 pci_dfl_cache_line_size = L1_CACHE_BYTES >> 2;
|
2009-10-26 20:20:44 +00:00
|
|
|
u8 pci_cache_line_size;
|
|
|
|
|
2011-10-28 21:48:38 +00:00
|
|
|
/*
|
|
|
|
* If we set up a device for bus mastering, we need to check the latency
|
|
|
|
* timer as certain BIOSes forget to set it properly.
|
|
|
|
*/
|
|
|
|
unsigned int pcibios_max_latency = 255;
|
|
|
|
|
2012-02-29 23:06:33 +00:00
|
|
|
/* If set, the PCIe ARI capability will not be used. */
|
|
|
|
static bool pcie_ari_disabled;
|
|
|
|
|
2018-05-10 22:56:02 +00:00
|
|
|
/* If set, the PCIe ATS capability will not be used. */
|
|
|
|
static bool pcie_ats_disabled;
|
|
|
|
|
2018-06-05 02:16:09 +00:00
|
|
|
/* If set, the PCI config space of each device is printed during boot. */
|
|
|
|
bool pci_early_dump;
|
|
|
|
|
2018-05-10 22:56:02 +00:00
|
|
|
bool pci_ats_disabled(void)
|
|
|
|
{
|
|
|
|
return pcie_ats_disabled;
|
|
|
|
}
|
|
|
|
|
2016-06-02 08:17:12 +00:00
|
|
|
/* Disable bridge_d3 for all PCIe ports */
|
|
|
|
static bool pci_bridge_d3_disable;
|
|
|
|
/* Force bridge_d3 for all PCIe ports */
|
|
|
|
static bool pci_bridge_d3_force;
|
|
|
|
|
|
|
|
static int __init pcie_port_pm_setup(char *str)
|
|
|
|
{
|
|
|
|
if (!strcmp(str, "off"))
|
|
|
|
pci_bridge_d3_disable = true;
|
|
|
|
else if (!strcmp(str, "force"))
|
|
|
|
pci_bridge_d3_force = true;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("pcie_port_pm=", pcie_port_pm_setup);
|
|
|
|
|
2018-02-27 20:14:10 +00:00
|
|
|
/* Time to wait after a reset for device to become responsive */
|
|
|
|
#define PCIE_RESET_READY_POLL_MS 60000
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* pci_bus_max_busnr - returns maximum PCI bus number of given bus' children
|
|
|
|
* @bus: pointer to PCI bus structure to search
|
|
|
|
*
|
|
|
|
* Given a PCI bus, returns the highest PCI bus number present in the set
|
|
|
|
* including the given PCI bus and its list of child PCI buses.
|
|
|
|
*/
|
2014-04-11 05:01:53 +00:00
|
|
|
unsigned char pci_bus_max_busnr(struct pci_bus *bus)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-02-13 13:14:03 +00:00
|
|
|
struct pci_bus *tmp;
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned char max, n;
|
|
|
|
|
2012-05-18 01:51:11 +00:00
|
|
|
max = bus->busn_res.end;
|
2014-02-13 13:14:03 +00:00
|
|
|
list_for_each_entry(tmp, &bus->children, node) {
|
|
|
|
n = pci_bus_max_busnr(tmp);
|
2014-04-19 00:13:49 +00:00
|
|
|
if (n > max)
|
2005-04-16 22:20:36 +00:00
|
|
|
max = n;
|
|
|
|
}
|
|
|
|
return max;
|
|
|
|
}
|
2006-01-18 00:56:56 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_bus_max_busnr);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-12-01 22:30:30 +00:00
|
|
|
#ifdef CONFIG_HAS_IOMEM
|
|
|
|
void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar)
|
|
|
|
{
|
2015-03-12 17:30:11 +00:00
|
|
|
struct resource *res = &pdev->resource[bar];
|
|
|
|
|
2008-12-01 22:30:30 +00:00
|
|
|
/*
|
|
|
|
* Make sure the BAR is actually a memory resource, not an IO resource
|
|
|
|
*/
|
2015-03-12 17:30:15 +00:00
|
|
|
if (res->flags & IORESOURCE_UNSET || !(res->flags & IORESOURCE_MEM)) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_warn(pdev, "can't ioremap BAR %d: %pR\n", bar, res);
|
2008-12-01 22:30:30 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
2015-03-12 17:30:11 +00:00
|
|
|
return ioremap_nocache(res->start, resource_size(res));
|
2008-12-01 22:30:30 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
|
2015-08-24 19:13:23 +00:00
|
|
|
|
|
|
|
void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Make sure the BAR is actually a memory resource, not an IO resource
|
|
|
|
*/
|
|
|
|
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
|
|
|
|
WARN_ON(1);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return ioremap_wc(pci_resource_start(pdev, bar),
|
|
|
|
pci_resource_len(pdev, bar));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
|
2008-12-01 22:30:30 +00:00
|
|
|
#endif
|
|
|
|
|
2018-07-30 16:18:38 +00:00
|
|
|
/**
|
|
|
|
* pci_dev_str_match_path - test if a path string matches a device
|
2019-01-09 20:14:42 +00:00
|
|
|
* @dev: the PCI device to test
|
|
|
|
* @path: string to match the device against
|
2018-07-30 16:18:38 +00:00
|
|
|
* @endptr: pointer to the string after the match
|
|
|
|
*
|
|
|
|
* Test if a string (typically from a kernel parameter) formatted as a
|
|
|
|
* path of device/function addresses matches a PCI device. The string must
|
|
|
|
* be of the form:
|
|
|
|
*
|
|
|
|
* [<domain>:]<bus>:<device>.<func>[/<device>.<func>]*
|
|
|
|
*
|
|
|
|
* A path for a device can be obtained using 'lspci -t'. Using a path
|
|
|
|
* is more robust against bus renumbering than using only a single bus,
|
|
|
|
* device and function address.
|
|
|
|
*
|
|
|
|
* Returns 1 if the string matches the device, 0 if it does not and
|
|
|
|
* a negative error code if it fails to parse the string.
|
|
|
|
*/
|
|
|
|
static int pci_dev_str_match_path(struct pci_dev *dev, const char *path,
|
|
|
|
const char **endptr)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
int seg, bus, slot, func;
|
|
|
|
char *wpath, *p;
|
|
|
|
char end;
|
|
|
|
|
|
|
|
*endptr = strchrnul(path, ';');
|
|
|
|
|
|
|
|
wpath = kmemdup_nul(path, *endptr - path, GFP_KERNEL);
|
|
|
|
if (!wpath)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
p = strrchr(wpath, '/');
|
|
|
|
if (!p)
|
|
|
|
break;
|
|
|
|
ret = sscanf(p, "/%x.%x%c", &slot, &func, &end);
|
|
|
|
if (ret != 2) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto free_and_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dev->devfn != PCI_DEVFN(slot, func)) {
|
|
|
|
ret = 0;
|
|
|
|
goto free_and_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: we don't need to get a reference to the upstream
|
|
|
|
* bridge because we hold a reference to the top level
|
|
|
|
* device which should hold a reference to the bridge,
|
|
|
|
* and so on.
|
|
|
|
*/
|
|
|
|
dev = pci_upstream_bridge(dev);
|
|
|
|
if (!dev) {
|
|
|
|
ret = 0;
|
|
|
|
goto free_and_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
*p = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = sscanf(wpath, "%x:%x:%x.%x%c", &seg, &bus, &slot,
|
|
|
|
&func, &end);
|
|
|
|
if (ret != 4) {
|
|
|
|
seg = 0;
|
|
|
|
ret = sscanf(wpath, "%x:%x.%x%c", &bus, &slot, &func, &end);
|
|
|
|
if (ret != 3) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto free_and_exit;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = (seg == pci_domain_nr(dev->bus) &&
|
|
|
|
bus == dev->bus->number &&
|
|
|
|
dev->devfn == PCI_DEVFN(slot, func));
|
|
|
|
|
|
|
|
free_and_exit:
|
|
|
|
kfree(wpath);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-07-30 16:18:37 +00:00
|
|
|
/**
|
|
|
|
* pci_dev_str_match - test if a string matches a device
|
2019-01-09 20:14:42 +00:00
|
|
|
* @dev: the PCI device to test
|
|
|
|
* @p: string to match the device against
|
2018-07-30 16:18:37 +00:00
|
|
|
* @endptr: pointer to the string after the match
|
|
|
|
*
|
|
|
|
* Test if a string (typically from a kernel parameter) matches a specified
|
|
|
|
* PCI device. The string may be of one of the following formats:
|
|
|
|
*
|
2018-07-30 16:18:38 +00:00
|
|
|
* [<domain>:]<bus>:<device>.<func>[/<device>.<func>]*
|
2018-07-30 16:18:37 +00:00
|
|
|
* pci:<vendor>:<device>[:<subvendor>:<subdevice>]
|
|
|
|
*
|
|
|
|
* The first format specifies a PCI bus/device/function address which
|
|
|
|
* may change if new hardware is inserted, if motherboard firmware changes,
|
|
|
|
* or due to changes caused in kernel parameters. If the domain is
|
2018-07-30 16:18:38 +00:00
|
|
|
* left unspecified, it is taken to be 0. In order to be robust against
|
|
|
|
* bus renumbering issues, a path of PCI device/function numbers may be used
|
|
|
|
* to address the specific device. The path for a device can be determined
|
|
|
|
* through the use of 'lspci -t'.
|
2018-07-30 16:18:37 +00:00
|
|
|
*
|
|
|
|
* The second format matches devices using IDs in the configuration
|
|
|
|
* space which may match multiple devices in the system. A value of 0
|
|
|
|
* for any field will match all devices. (Note: this differs from
|
|
|
|
* in-kernel code that uses PCI_ANY_ID which is ~0; this is for
|
|
|
|
* legacy reasons and convenience so users don't have to specify
|
|
|
|
* FFFFFFFFs on the command line.)
|
|
|
|
*
|
|
|
|
* Returns 1 if the string matches the device, 0 if it does not and
|
|
|
|
* a negative error code if the string cannot be parsed.
|
|
|
|
*/
|
|
|
|
static int pci_dev_str_match(struct pci_dev *dev, const char *p,
|
|
|
|
const char **endptr)
|
|
|
|
{
|
|
|
|
int ret;
|
2018-07-30 16:18:38 +00:00
|
|
|
int count;
|
2018-07-30 16:18:37 +00:00
|
|
|
unsigned short vendor, device, subsystem_vendor, subsystem_device;
|
|
|
|
|
|
|
|
if (strncmp(p, "pci:", 4) == 0) {
|
|
|
|
/* PCI vendor/device (subvendor/subdevice) IDs are specified */
|
|
|
|
p += 4;
|
|
|
|
ret = sscanf(p, "%hx:%hx:%hx:%hx%n", &vendor, &device,
|
|
|
|
&subsystem_vendor, &subsystem_device, &count);
|
|
|
|
if (ret != 4) {
|
|
|
|
ret = sscanf(p, "%hx:%hx%n", &vendor, &device, &count);
|
|
|
|
if (ret != 2)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
subsystem_vendor = 0;
|
|
|
|
subsystem_device = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
p += count;
|
|
|
|
|
|
|
|
if ((!vendor || vendor == dev->vendor) &&
|
|
|
|
(!device || device == dev->device) &&
|
|
|
|
(!subsystem_vendor ||
|
|
|
|
subsystem_vendor == dev->subsystem_vendor) &&
|
|
|
|
(!subsystem_device ||
|
|
|
|
subsystem_device == dev->subsystem_device))
|
|
|
|
goto found;
|
|
|
|
} else {
|
2018-07-30 16:18:38 +00:00
|
|
|
/*
|
|
|
|
* PCI Bus, Device, Function IDs are specified
|
2019-01-09 20:14:42 +00:00
|
|
|
* (optionally, may include a path of devfns following it)
|
2018-07-30 16:18:38 +00:00
|
|
|
*/
|
|
|
|
ret = pci_dev_str_match_path(dev, p, &p);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
else if (ret)
|
2018-07-30 16:18:37 +00:00
|
|
|
goto found;
|
|
|
|
}
|
|
|
|
|
|
|
|
*endptr = p;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
found:
|
|
|
|
*endptr = p;
|
|
|
|
return 1;
|
|
|
|
}
|
2006-11-22 07:26:18 +00:00
|
|
|
|
|
|
|
static int __pci_find_next_cap_ttl(struct pci_bus *bus, unsigned int devfn,
|
|
|
|
u8 pos, int cap, int *ttl)
|
[PATCH] PCI: add pci_find_next_capability()
Some devices have more than one capability of the same type. For
example, the PCI header for the PathScale InfiniPath looks like:
04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
Subsystem: Unknown device 1fc1:000d
Flags: bus master, fast devsel, latency 0, IRQ 193
Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [c0] HyperTransport: Slave or Primary Interface
Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
There are _two_ HyperTransport capabilities, and the PathScale driver
wants to look at both of them.
The current pci_find_capability() API doesn't work for this, since it
only allows us to get to the first capability of a given type. The
patch below introduces a new pci_find_next_capability(), which can be
used in a loop like
for (pos = pci_find_capability(pdev, <ID>);
pos;
pos = pci_find_next_capability(pdev, pos, <ID>)) {
/* ... */
}
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-29 00:35:34 +00:00
|
|
|
{
|
|
|
|
u8 id;
|
2015-04-02 21:10:19 +00:00
|
|
|
u16 ent;
|
|
|
|
|
|
|
|
pci_bus_read_config_byte(bus, devfn, pos, &pos);
|
[PATCH] PCI: add pci_find_next_capability()
Some devices have more than one capability of the same type. For
example, the PCI header for the PathScale InfiniPath looks like:
04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
Subsystem: Unknown device 1fc1:000d
Flags: bus master, fast devsel, latency 0, IRQ 193
Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [c0] HyperTransport: Slave or Primary Interface
Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
There are _two_ HyperTransport capabilities, and the PathScale driver
wants to look at both of them.
The current pci_find_capability() API doesn't work for this, since it
only allows us to get to the first capability of a given type. The
patch below introduces a new pci_find_next_capability(), which can be
used in a loop like
for (pos = pci_find_capability(pdev, <ID>);
pos;
pos = pci_find_next_capability(pdev, pos, <ID>)) {
/* ... */
}
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-29 00:35:34 +00:00
|
|
|
|
2006-11-22 07:26:18 +00:00
|
|
|
while ((*ttl)--) {
|
[PATCH] PCI: add pci_find_next_capability()
Some devices have more than one capability of the same type. For
example, the PCI header for the PathScale InfiniPath looks like:
04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
Subsystem: Unknown device 1fc1:000d
Flags: bus master, fast devsel, latency 0, IRQ 193
Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [c0] HyperTransport: Slave or Primary Interface
Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
There are _two_ HyperTransport capabilities, and the PathScale driver
wants to look at both of them.
The current pci_find_capability() API doesn't work for this, since it
only allows us to get to the first capability of a given type. The
patch below introduces a new pci_find_next_capability(), which can be
used in a loop like
for (pos = pci_find_capability(pdev, <ID>);
pos;
pos = pci_find_next_capability(pdev, pos, <ID>)) {
/* ... */
}
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-29 00:35:34 +00:00
|
|
|
if (pos < 0x40)
|
|
|
|
break;
|
|
|
|
pos &= ~3;
|
2015-04-02 21:10:19 +00:00
|
|
|
pci_bus_read_config_word(bus, devfn, pos, &ent);
|
|
|
|
|
|
|
|
id = ent & 0xff;
|
[PATCH] PCI: add pci_find_next_capability()
Some devices have more than one capability of the same type. For
example, the PCI header for the PathScale InfiniPath looks like:
04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
Subsystem: Unknown device 1fc1:000d
Flags: bus master, fast devsel, latency 0, IRQ 193
Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [c0] HyperTransport: Slave or Primary Interface
Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
There are _two_ HyperTransport capabilities, and the PathScale driver
wants to look at both of them.
The current pci_find_capability() API doesn't work for this, since it
only allows us to get to the first capability of a given type. The
patch below introduces a new pci_find_next_capability(), which can be
used in a loop like
for (pos = pci_find_capability(pdev, <ID>);
pos;
pos = pci_find_next_capability(pdev, pos, <ID>)) {
/* ... */
}
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-29 00:35:34 +00:00
|
|
|
if (id == 0xff)
|
|
|
|
break;
|
|
|
|
if (id == cap)
|
|
|
|
return pos;
|
2015-04-02 21:10:19 +00:00
|
|
|
pos = (ent >> 8);
|
[PATCH] PCI: add pci_find_next_capability()
Some devices have more than one capability of the same type. For
example, the PCI header for the PathScale InfiniPath looks like:
04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
Subsystem: Unknown device 1fc1:000d
Flags: bus master, fast devsel, latency 0, IRQ 193
Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [c0] HyperTransport: Slave or Primary Interface
Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
There are _two_ HyperTransport capabilities, and the PathScale driver
wants to look at both of them.
The current pci_find_capability() API doesn't work for this, since it
only allows us to get to the first capability of a given type. The
patch below introduces a new pci_find_next_capability(), which can be
used in a loop like
for (pos = pci_find_capability(pdev, <ID>);
pos;
pos = pci_find_next_capability(pdev, pos, <ID>)) {
/* ... */
}
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-29 00:35:34 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-11-22 07:26:18 +00:00
|
|
|
static int __pci_find_next_cap(struct pci_bus *bus, unsigned int devfn,
|
|
|
|
u8 pos, int cap)
|
|
|
|
{
|
|
|
|
int ttl = PCI_FIND_CAP_TTL;
|
|
|
|
|
|
|
|
return __pci_find_next_cap_ttl(bus, devfn, pos, cap, &ttl);
|
|
|
|
}
|
|
|
|
|
[PATCH] PCI: add pci_find_next_capability()
Some devices have more than one capability of the same type. For
example, the PCI header for the PathScale InfiniPath looks like:
04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
Subsystem: Unknown device 1fc1:000d
Flags: bus master, fast devsel, latency 0, IRQ 193
Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [c0] HyperTransport: Slave or Primary Interface
Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
There are _two_ HyperTransport capabilities, and the PathScale driver
wants to look at both of them.
The current pci_find_capability() API doesn't work for this, since it
only allows us to get to the first capability of a given type. The
patch below introduces a new pci_find_next_capability(), which can be
used in a loop like
for (pos = pci_find_capability(pdev, <ID>);
pos;
pos = pci_find_next_capability(pdev, pos, <ID>)) {
/* ... */
}
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-29 00:35:34 +00:00
|
|
|
int pci_find_next_capability(struct pci_dev *dev, u8 pos, int cap)
|
|
|
|
{
|
|
|
|
return __pci_find_next_cap(dev->bus, dev->devfn,
|
|
|
|
pos + PCI_CAP_LIST_NEXT, cap);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_find_next_capability);
|
|
|
|
|
2006-11-22 07:26:16 +00:00
|
|
|
static int __pci_bus_find_cap_start(struct pci_bus *bus,
|
|
|
|
unsigned int devfn, u8 hdr_type)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
u16 status;
|
|
|
|
|
|
|
|
pci_bus_read_config_word(bus, devfn, PCI_STATUS, &status);
|
|
|
|
if (!(status & PCI_STATUS_CAP_LIST))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
switch (hdr_type) {
|
|
|
|
case PCI_HEADER_TYPE_NORMAL:
|
|
|
|
case PCI_HEADER_TYPE_BRIDGE:
|
2006-11-22 07:26:16 +00:00
|
|
|
return PCI_CAPABILITY_LIST;
|
2005-04-16 22:20:36 +00:00
|
|
|
case PCI_HEADER_TYPE_CARDBUS:
|
2006-11-22 07:26:16 +00:00
|
|
|
return PCI_CB_CAPABILITY_LIST;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2006-11-22 07:26:16 +00:00
|
|
|
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2013-11-14 18:28:18 +00:00
|
|
|
* pci_find_capability - query for devices' capabilities
|
2005-04-16 22:20:36 +00:00
|
|
|
* @dev: PCI device to query
|
|
|
|
* @cap: capability code
|
|
|
|
*
|
|
|
|
* Tell if a device supports a given PCI capability.
|
|
|
|
* Returns the address of the requested capability structure within the
|
|
|
|
* device's PCI configuration space or 0 in case the device does not
|
2019-01-09 20:14:42 +00:00
|
|
|
* support it. Possible values for @cap include:
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2013-11-14 18:28:18 +00:00
|
|
|
* %PCI_CAP_ID_PM Power Management
|
|
|
|
* %PCI_CAP_ID_AGP Accelerated Graphics Port
|
|
|
|
* %PCI_CAP_ID_VPD Vital Product Data
|
|
|
|
* %PCI_CAP_ID_SLOTID Slot Identification
|
2005-04-16 22:20:36 +00:00
|
|
|
* %PCI_CAP_ID_MSI Message Signalled Interrupts
|
2013-11-14 18:28:18 +00:00
|
|
|
* %PCI_CAP_ID_CHSWP CompactPCI HotSwap
|
2005-04-16 22:20:36 +00:00
|
|
|
* %PCI_CAP_ID_PCIX PCI-X
|
|
|
|
* %PCI_CAP_ID_EXP PCI Express
|
|
|
|
*/
|
|
|
|
int pci_find_capability(struct pci_dev *dev, int cap)
|
|
|
|
{
|
2006-11-22 07:26:16 +00:00
|
|
|
int pos;
|
|
|
|
|
|
|
|
pos = __pci_bus_find_cap_start(dev->bus, dev->devfn, dev->hdr_type);
|
|
|
|
if (pos)
|
|
|
|
pos = __pci_find_next_cap(dev->bus, dev->devfn, pos, cap);
|
|
|
|
|
|
|
|
return pos;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_find_capability);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
2013-11-14 18:28:18 +00:00
|
|
|
* pci_bus_find_capability - query for devices' capabilities
|
2019-01-09 20:14:42 +00:00
|
|
|
* @bus: the PCI bus to query
|
2005-04-16 22:20:36 +00:00
|
|
|
* @devfn: PCI device to query
|
2019-01-09 20:14:42 +00:00
|
|
|
* @cap: capability code
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Like pci_find_capability() but works for PCI devices that do not have a
|
2013-11-14 18:28:18 +00:00
|
|
|
* pci_dev structure set up yet.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Returns the address of the requested capability structure within the
|
|
|
|
* device's PCI configuration space or 0 in case the device does not
|
|
|
|
* support it.
|
|
|
|
*/
|
|
|
|
int pci_bus_find_capability(struct pci_bus *bus, unsigned int devfn, int cap)
|
|
|
|
{
|
2006-11-22 07:26:16 +00:00
|
|
|
int pos;
|
2005-04-16 22:20:36 +00:00
|
|
|
u8 hdr_type;
|
|
|
|
|
|
|
|
pci_bus_read_config_byte(bus, devfn, PCI_HEADER_TYPE, &hdr_type);
|
|
|
|
|
2006-11-22 07:26:16 +00:00
|
|
|
pos = __pci_bus_find_cap_start(bus, devfn, hdr_type & 0x7f);
|
|
|
|
if (pos)
|
|
|
|
pos = __pci_find_next_cap(bus, devfn, pos, cap);
|
|
|
|
|
|
|
|
return pos;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_bus_find_capability);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
2012-07-13 20:24:59 +00:00
|
|
|
* pci_find_next_ext_capability - Find an extended capability
|
2005-04-16 22:20:36 +00:00
|
|
|
* @dev: PCI device to query
|
2012-07-13 20:24:59 +00:00
|
|
|
* @start: address at which to start looking (0 to start at beginning of list)
|
2005-04-16 22:20:36 +00:00
|
|
|
* @cap: capability code
|
|
|
|
*
|
2012-07-13 20:24:59 +00:00
|
|
|
* Returns the address of the next matching extended capability structure
|
2005-04-16 22:20:36 +00:00
|
|
|
* within the device's PCI configuration space or 0 if the device does
|
2012-07-13 20:24:59 +00:00
|
|
|
* not support it. Some capabilities can occur several times, e.g., the
|
|
|
|
* vendor-specific capability, and this provides a way to find them all.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2012-07-13 20:24:59 +00:00
|
|
|
int pci_find_next_ext_capability(struct pci_dev *dev, int start, int cap)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
u32 header;
|
2008-10-13 11:18:07 +00:00
|
|
|
int ttl;
|
|
|
|
int pos = PCI_CFG_SPACE_SIZE;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-10-13 11:18:07 +00:00
|
|
|
/* minimum 8 bytes per capability */
|
|
|
|
ttl = (PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) / 8;
|
|
|
|
|
|
|
|
if (dev->cfg_size <= PCI_CFG_SPACE_SIZE)
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
|
2012-07-13 20:24:59 +00:00
|
|
|
if (start)
|
|
|
|
pos = start;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (pci_read_config_dword(dev, pos, &header) != PCIBIOS_SUCCESSFUL)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have no capabilities, this is indicated by cap ID,
|
|
|
|
* cap version and next pointer all being 0.
|
|
|
|
*/
|
|
|
|
if (header == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
while (ttl-- > 0) {
|
2012-07-13 20:24:59 +00:00
|
|
|
if (PCI_EXT_CAP_ID(header) == cap && pos != start)
|
2005-04-16 22:20:36 +00:00
|
|
|
return pos;
|
|
|
|
|
|
|
|
pos = PCI_EXT_CAP_NEXT(header);
|
2008-10-13 11:18:07 +00:00
|
|
|
if (pos < PCI_CFG_SPACE_SIZE)
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
if (pci_read_config_dword(dev, pos, &header) != PCIBIOS_SUCCESSFUL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2012-07-13 20:24:59 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_find_next_ext_capability);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_find_ext_capability - Find an extended capability
|
|
|
|
* @dev: PCI device to query
|
|
|
|
* @cap: capability code
|
|
|
|
*
|
|
|
|
* Returns the address of the requested extended capability structure
|
|
|
|
* within the device's PCI configuration space or 0 if the device does
|
2019-01-09 20:14:42 +00:00
|
|
|
* not support it. Possible values for @cap include:
|
2012-07-13 20:24:59 +00:00
|
|
|
*
|
|
|
|
* %PCI_EXT_CAP_ID_ERR Advanced Error Reporting
|
|
|
|
* %PCI_EXT_CAP_ID_VC Virtual Channel
|
|
|
|
* %PCI_EXT_CAP_ID_DSN Device Serial Number
|
|
|
|
* %PCI_EXT_CAP_ID_PWR Power Budgeting
|
|
|
|
*/
|
|
|
|
int pci_find_ext_capability(struct pci_dev *dev, int cap)
|
|
|
|
{
|
|
|
|
return pci_find_next_ext_capability(dev, 0, cap);
|
|
|
|
}
|
2006-05-23 10:10:01 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_find_ext_capability);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-11-22 07:26:18 +00:00
|
|
|
static int __pci_find_next_ht_cap(struct pci_dev *dev, int pos, int ht_cap)
|
|
|
|
{
|
|
|
|
int rc, ttl = PCI_FIND_CAP_TTL;
|
|
|
|
u8 cap, mask;
|
|
|
|
|
|
|
|
if (ht_cap == HT_CAPTYPE_SLAVE || ht_cap == HT_CAPTYPE_HOST)
|
|
|
|
mask = HT_3BIT_CAP_MASK;
|
|
|
|
else
|
|
|
|
mask = HT_5BIT_CAP_MASK;
|
|
|
|
|
|
|
|
pos = __pci_find_next_cap_ttl(dev->bus, dev->devfn, pos,
|
|
|
|
PCI_CAP_ID_HT, &ttl);
|
|
|
|
while (pos) {
|
|
|
|
rc = pci_read_config_byte(dev, pos + 3, &cap);
|
|
|
|
if (rc != PCIBIOS_SUCCESSFUL)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if ((cap & mask) == ht_cap)
|
|
|
|
return pos;
|
|
|
|
|
2007-01-11 07:15:29 +00:00
|
|
|
pos = __pci_find_next_cap_ttl(dev->bus, dev->devfn,
|
|
|
|
pos + PCI_CAP_LIST_NEXT,
|
2006-11-22 07:26:18 +00:00
|
|
|
PCI_CAP_ID_HT, &ttl);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/**
|
|
|
|
* pci_find_next_ht_capability - query a device's Hypertransport capabilities
|
|
|
|
* @dev: PCI device to query
|
|
|
|
* @pos: Position from which to continue searching
|
|
|
|
* @ht_cap: Hypertransport capability code
|
|
|
|
*
|
|
|
|
* To be used in conjunction with pci_find_ht_capability() to search for
|
|
|
|
* all capabilities matching @ht_cap. @pos should always be a value returned
|
|
|
|
* from pci_find_ht_capability().
|
|
|
|
*
|
|
|
|
* NB. To be 100% safe against broken PCI devices, the caller should take
|
|
|
|
* steps to avoid an infinite loop.
|
|
|
|
*/
|
|
|
|
int pci_find_next_ht_capability(struct pci_dev *dev, int pos, int ht_cap)
|
|
|
|
{
|
|
|
|
return __pci_find_next_ht_cap(dev, pos + PCI_CAP_LIST_NEXT, ht_cap);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_find_next_ht_capability);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_find_ht_capability - query a device's Hypertransport capabilities
|
|
|
|
* @dev: PCI device to query
|
|
|
|
* @ht_cap: Hypertransport capability code
|
|
|
|
*
|
|
|
|
* Tell if a device supports a given Hypertransport capability.
|
|
|
|
* Returns an address within the device's PCI configuration space
|
|
|
|
* or 0 in case the device does not support the request capability.
|
|
|
|
* The address points to the PCI capability, of type PCI_CAP_ID_HT,
|
|
|
|
* which has a Hypertransport capability matching @ht_cap.
|
|
|
|
*/
|
|
|
|
int pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
|
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
|
|
|
|
pos = __pci_bus_find_cap_start(dev->bus, dev->devfn, dev->hdr_type);
|
|
|
|
if (pos)
|
|
|
|
pos = __pci_find_next_ht_cap(dev, pos, ht_cap);
|
|
|
|
|
|
|
|
return pos;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_find_ht_capability);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_find_parent_resource - return resource region of parent bus of given
|
|
|
|
* region
|
2005-04-16 22:20:36 +00:00
|
|
|
* @dev: PCI device structure contains resources to be searched
|
|
|
|
* @res: child resource record for which parent is sought
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* For given resource region of given device, return the resource region of
|
|
|
|
* parent bus the given region is contained in.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
struct resource *pci_find_parent_resource(const struct pci_dev *dev,
|
|
|
|
struct resource *res)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
const struct pci_bus *bus = dev->bus;
|
2014-02-26 18:25:58 +00:00
|
|
|
struct resource *r;
|
2005-04-16 22:20:36 +00:00
|
|
|
int i;
|
|
|
|
|
2010-02-23 17:24:31 +00:00
|
|
|
pci_bus_for_each_resource(bus, r, i) {
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!r)
|
|
|
|
continue;
|
2017-04-11 16:33:12 +00:00
|
|
|
if (resource_contains(r, res)) {
|
2014-02-26 18:25:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the window is prefetchable but the BAR is
|
|
|
|
* not, the allocator made a mistake.
|
|
|
|
*/
|
|
|
|
if (r->flags & IORESOURCE_PREFETCH &&
|
|
|
|
!(res->flags & IORESOURCE_PREFETCH))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're below a transparent bridge, there may
|
|
|
|
* be both a positively-decoded aperture and a
|
|
|
|
* subtractively-decoded region that contain the BAR.
|
|
|
|
* We want the positively-decoded one, so this depends
|
|
|
|
* on pci_bus_for_each_resource() giving us those
|
|
|
|
* first.
|
|
|
|
*/
|
|
|
|
return r;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-02-26 18:25:58 +00:00
|
|
|
return NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_find_parent_resource);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-09-15 08:07:03 +00:00
|
|
|
/**
|
|
|
|
* pci_find_resource - Return matching PCI device resource
|
|
|
|
* @dev: PCI device to query
|
|
|
|
* @res: Resource to look for
|
|
|
|
*
|
|
|
|
* Goes over standard PCI resources (BARs) and checks if the given resource
|
|
|
|
* is partially or fully contained in any of them. In that case the
|
|
|
|
* matching resource is returned, %NULL otherwise.
|
|
|
|
*/
|
|
|
|
struct resource *pci_find_resource(struct pci_dev *dev, struct resource *res)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < PCI_ROM_RESOURCE; i++) {
|
|
|
|
struct resource *r = &dev->resource[i];
|
|
|
|
|
|
|
|
if (r->start && resource_contains(r, res))
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pci_find_resource);
|
|
|
|
|
PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum
The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or
Unexpected Completion errors in some systems, which may cause device access
timeouts.
Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values
for the Attribute as were supplied in the header of the corresponding
Request, except as explicitly allowed when IDO is used."
Instead of copying the Attributes from the Request to the Completion, the
T5 always generates Completions with zero Attributes. The receiver of a
Completion whose Attributes don't match the Request may accept it (which
itself seems non-compliant based on sec 2.3.2), or it may handle it as a
Malformed TLP or an Unexpected Completion, which will probably lead to a
device access timeout.
Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root
Port so it always generate Requests with zero Attributes.
This does affect all other devices which are downstream of that Root Port,
but these are performance optimizations that should not make a functional
difference.
Note that Configuration Space accesses are never supposed to have TLP
Attributes, so we're safe waiting till after any Configuration Space
accesses to do the Root Port "fixup".
Based on original work by Casey Leedom <leedom@chelsio.com>
[bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework
to use pci_upstream_bridge() and check for Root Port device type, edit
diagnostics to clarify intent and devices affected]
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2015-10-18 14:25:04 +00:00
|
|
|
/**
|
|
|
|
* pci_find_pcie_root_port - return PCIe Root Port
|
|
|
|
* @dev: PCI device to query
|
|
|
|
*
|
|
|
|
* Traverse up the parent chain and return the PCIe Root Port PCI Device
|
|
|
|
* for a given PCI Device.
|
|
|
|
*/
|
|
|
|
struct pci_dev *pci_find_pcie_root_port(struct pci_dev *dev)
|
|
|
|
{
|
2017-08-17 11:06:14 +00:00
|
|
|
struct pci_dev *bridge, *highest_pcie_bridge = dev;
|
PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum
The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or
Unexpected Completion errors in some systems, which may cause device access
timeouts.
Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values
for the Attribute as were supplied in the header of the corresponding
Request, except as explicitly allowed when IDO is used."
Instead of copying the Attributes from the Request to the Completion, the
T5 always generates Completions with zero Attributes. The receiver of a
Completion whose Attributes don't match the Request may accept it (which
itself seems non-compliant based on sec 2.3.2), or it may handle it as a
Malformed TLP or an Unexpected Completion, which will probably lead to a
device access timeout.
Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root
Port so it always generate Requests with zero Attributes.
This does affect all other devices which are downstream of that Root Port,
but these are performance optimizations that should not make a functional
difference.
Note that Configuration Space accesses are never supposed to have TLP
Attributes, so we're safe waiting till after any Configuration Space
accesses to do the Root Port "fixup".
Based on original work by Casey Leedom <leedom@chelsio.com>
[bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework
to use pci_upstream_bridge() and check for Root Port device type, edit
diagnostics to clarify intent and devices affected]
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2015-10-18 14:25:04 +00:00
|
|
|
|
|
|
|
bridge = pci_upstream_bridge(dev);
|
|
|
|
while (bridge && pci_is_pcie(bridge)) {
|
|
|
|
highest_pcie_bridge = bridge;
|
|
|
|
bridge = pci_upstream_bridge(bridge);
|
|
|
|
}
|
|
|
|
|
2017-08-17 11:06:14 +00:00
|
|
|
if (pci_pcie_type(highest_pcie_bridge) != PCI_EXP_TYPE_ROOT_PORT)
|
|
|
|
return NULL;
|
PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum
The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or
Unexpected Completion errors in some systems, which may cause device access
timeouts.
Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values
for the Attribute as were supplied in the header of the corresponding
Request, except as explicitly allowed when IDO is used."
Instead of copying the Attributes from the Request to the Completion, the
T5 always generates Completions with zero Attributes. The receiver of a
Completion whose Attributes don't match the Request may accept it (which
itself seems non-compliant based on sec 2.3.2), or it may handle it as a
Malformed TLP or an Unexpected Completion, which will probably lead to a
device access timeout.
Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root
Port so it always generate Requests with zero Attributes.
This does affect all other devices which are downstream of that Root Port,
but these are performance optimizations that should not make a functional
difference.
Note that Configuration Space accesses are never supposed to have TLP
Attributes, so we're safe waiting till after any Configuration Space
accesses to do the Root Port "fixup".
Based on original work by Casey Leedom <leedom@chelsio.com>
[bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework
to use pci_upstream_bridge() and check for Root Port device type, edit
diagnostics to clarify intent and devices affected]
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2015-10-18 14:25:04 +00:00
|
|
|
|
2017-08-17 11:06:14 +00:00
|
|
|
return highest_pcie_bridge;
|
PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum
The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or
Unexpected Completion errors in some systems, which may cause device access
timeouts.
Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values
for the Attribute as were supplied in the header of the corresponding
Request, except as explicitly allowed when IDO is used."
Instead of copying the Attributes from the Request to the Completion, the
T5 always generates Completions with zero Attributes. The receiver of a
Completion whose Attributes don't match the Request may accept it (which
itself seems non-compliant based on sec 2.3.2), or it may handle it as a
Malformed TLP or an Unexpected Completion, which will probably lead to a
device access timeout.
Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root
Port so it always generate Requests with zero Attributes.
This does affect all other devices which are downstream of that Root Port,
but these are performance optimizations that should not make a functional
difference.
Note that Configuration Space accesses are never supposed to have TLP
Attributes, so we're safe waiting till after any Configuration Space
accesses to do the Root Port "fixup".
Based on original work by Casey Leedom <leedom@chelsio.com>
[bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework
to use pci_upstream_bridge() and check for Root Port device type, edit
diagnostics to clarify intent and devices affected]
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2015-10-18 14:25:04 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pci_find_pcie_root_port);
|
|
|
|
|
2013-12-17 23:43:39 +00:00
|
|
|
/**
|
|
|
|
* pci_wait_for_pending - wait for @mask bit(s) to clear in status word @pos
|
|
|
|
* @dev: the PCI device to operate on
|
|
|
|
* @pos: config space offset of status word
|
|
|
|
* @mask: mask of bit(s) to care about in status word
|
|
|
|
*
|
|
|
|
* Return 1 when mask bit(s) in status word clear, 0 otherwise.
|
|
|
|
*/
|
|
|
|
int pci_wait_for_pending(struct pci_dev *dev, int pos, u16 mask)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Wait for Transaction Pending bit clean */
|
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
u16 status;
|
|
|
|
if (i)
|
|
|
|
msleep((1 << (i - 1)) * 100);
|
|
|
|
|
|
|
|
pci_read_config_word(dev, pos, &status);
|
|
|
|
if (!(status & mask))
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-07-27 14:19:44 +00:00
|
|
|
/**
|
2015-07-29 08:52:58 +00:00
|
|
|
* pci_restore_bars - restore a device's BAR values (e.g. after wake-up)
|
2005-07-27 14:19:44 +00:00
|
|
|
* @dev: PCI device to have its BARs restored
|
|
|
|
*
|
|
|
|
* Restore the BAR values for a given device, so as to make it
|
|
|
|
* accessible by its driver.
|
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
static void pci_restore_bars(struct pci_dev *dev)
|
2005-07-27 14:19:44 +00:00
|
|
|
{
|
2008-11-21 18:40:00 +00:00
|
|
|
int i;
|
2005-07-27 14:19:44 +00:00
|
|
|
|
2008-11-21 18:40:00 +00:00
|
|
|
for (i = 0; i < PCI_BRIDGE_RESOURCES; i++)
|
2008-11-21 18:38:52 +00:00
|
|
|
pci_update_resource(dev, i);
|
2005-07-27 14:19:44 +00:00
|
|
|
}
|
|
|
|
|
2015-12-06 16:33:45 +00:00
|
|
|
static const struct pci_platform_pm_ops *pci_platform_pm;
|
2008-07-07 01:32:02 +00:00
|
|
|
|
2015-12-06 16:33:45 +00:00
|
|
|
int pci_set_platform_pm(const struct pci_platform_pm_ops *ops)
|
2008-07-07 01:32:02 +00:00
|
|
|
{
|
2016-09-18 03:39:20 +00:00
|
|
|
if (!ops->is_manageable || !ops->set_state || !ops->get_state ||
|
2017-06-23 23:57:35 +00:00
|
|
|
!ops->choose_state || !ops->set_wakeup || !ops->need_resume)
|
2008-07-07 01:32:02 +00:00
|
|
|
return -EINVAL;
|
|
|
|
pci_platform_pm = ops;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool platform_pci_power_manageable(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
return pci_platform_pm ? pci_platform_pm->is_manageable(dev) : false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int platform_pci_set_power_state(struct pci_dev *dev,
|
2014-04-19 00:13:49 +00:00
|
|
|
pci_power_t t)
|
2008-07-07 01:32:02 +00:00
|
|
|
{
|
|
|
|
return pci_platform_pm ? pci_platform_pm->set_state(dev, t) : -ENOSYS;
|
|
|
|
}
|
|
|
|
|
2016-09-18 03:39:20 +00:00
|
|
|
static inline pci_power_t platform_pci_get_power_state(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
return pci_platform_pm ? pci_platform_pm->get_state(dev) : PCI_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
2019-06-25 12:09:12 +00:00
|
|
|
static inline void platform_pci_refresh_power_state(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (pci_platform_pm && pci_platform_pm->refresh_state)
|
|
|
|
pci_platform_pm->refresh_state(dev);
|
|
|
|
}
|
|
|
|
|
2008-07-07 01:32:02 +00:00
|
|
|
static inline pci_power_t platform_pci_choose_state(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
return pci_platform_pm ?
|
|
|
|
pci_platform_pm->choose_state(dev) : PCI_POWER_ERROR;
|
|
|
|
}
|
2005-10-23 18:57:38 +00:00
|
|
|
|
2017-06-23 23:57:35 +00:00
|
|
|
static inline int platform_pci_set_wakeup(struct pci_dev *dev, bool enable)
|
2008-07-07 01:34:48 +00:00
|
|
|
{
|
|
|
|
return pci_platform_pm ?
|
2017-06-23 23:57:35 +00:00
|
|
|
pci_platform_pm->set_wakeup(dev, enable) : -ENODEV;
|
2010-02-17 22:44:09 +00:00
|
|
|
}
|
|
|
|
|
2015-01-21 01:17:42 +00:00
|
|
|
static inline bool platform_pci_need_resume(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
return pci_platform_pm ? pci_platform_pm->need_resume(dev) : false;
|
|
|
|
}
|
|
|
|
|
2018-09-27 21:57:14 +00:00
|
|
|
static inline bool platform_pci_bridge_d3(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
return pci_platform_pm ? pci_platform_pm->bridge_d3(dev) : false;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2008-07-07 01:32:52 +00:00
|
|
|
* pci_raw_set_power_state - Use PCI PM registers to set the power state of
|
2019-01-09 20:14:42 +00:00
|
|
|
* given PCI device
|
2008-07-07 01:32:52 +00:00
|
|
|
* @dev: PCI device to handle.
|
|
|
|
* @state: PCI power state (D0, D1, D2, D3hot) to put the device into.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2008-07-07 01:32:52 +00:00
|
|
|
* RETURN VALUE:
|
|
|
|
* -EINVAL if the requested state is invalid.
|
|
|
|
* -EIO if device does not support PCI PM or its PM capabilities register has a
|
|
|
|
* wrong version, or device doesn't support the requested state.
|
|
|
|
* 0 if device already is in the requested state.
|
|
|
|
* 0 if device's power state has been successfully changed.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2009-03-16 21:40:08 +00:00
|
|
|
static int pci_raw_set_power_state(struct pci_dev *dev, pci_power_t state)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-07-07 01:36:24 +00:00
|
|
|
u16 pmcsr;
|
2008-07-07 01:32:52 +00:00
|
|
|
bool need_restore = false;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-03-16 21:40:36 +00:00
|
|
|
/* Check if we're already there */
|
|
|
|
if (dev->current_state == state)
|
|
|
|
return 0;
|
|
|
|
|
2008-07-07 01:36:24 +00:00
|
|
|
if (!dev->pm_cap)
|
2007-07-09 18:55:58 +00:00
|
|
|
return -EIO;
|
|
|
|
|
2008-07-07 01:32:52 +00:00
|
|
|
if (state < PCI_D0 || state > PCI_D3hot)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-01-09 20:14:42 +00:00
|
|
|
/*
|
|
|
|
* Validate current state:
|
2013-11-14 18:28:18 +00:00
|
|
|
* Can enter D0 from any state, but if we can only go deeper
|
2005-04-16 22:20:36 +00:00
|
|
|
* to sleep if we're already in a low power state
|
|
|
|
*/
|
2009-03-16 21:40:36 +00:00
|
|
|
if (state != PCI_D0 && dev->current_state <= PCI_D3cold
|
2008-07-07 01:32:52 +00:00
|
|
|
&& dev->current_state > state) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "invalid power transition (from state %d to %d)\n",
|
2014-04-19 00:13:50 +00:00
|
|
|
dev->current_state, state);
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
2008-07-07 01:32:52 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-01-09 20:14:42 +00:00
|
|
|
/* Check if this device supports the desired state */
|
2008-07-07 01:36:24 +00:00
|
|
|
if ((state == PCI_D1 && !dev->d1_support)
|
|
|
|
|| (state == PCI_D2 && !dev->d2_support))
|
2005-08-17 22:32:19 +00:00
|
|
|
return -EIO;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-07-07 01:36:24 +00:00
|
|
|
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
|
2005-07-27 14:19:44 +00:00
|
|
|
|
2019-01-09 20:14:42 +00:00
|
|
|
/*
|
|
|
|
* If we're (effectively) in D3, force entire word to 0.
|
2005-04-16 22:20:36 +00:00
|
|
|
* This doesn't affect PME_Status, disables PME_En, and
|
|
|
|
* sets PowerState to 0.
|
|
|
|
*/
|
2005-09-14 13:52:42 +00:00
|
|
|
switch (dev->current_state) {
|
2005-09-28 21:50:51 +00:00
|
|
|
case PCI_D0:
|
|
|
|
case PCI_D1:
|
|
|
|
case PCI_D2:
|
|
|
|
pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
|
|
|
|
pmcsr |= state;
|
|
|
|
break;
|
2009-05-18 20:51:12 +00:00
|
|
|
case PCI_D3hot:
|
|
|
|
case PCI_D3cold:
|
2005-09-14 13:52:42 +00:00
|
|
|
case PCI_UNKNOWN: /* Boot-up */
|
|
|
|
if ((pmcsr & PCI_PM_CTRL_STATE_MASK) == PCI_D3hot
|
2009-03-16 21:40:08 +00:00
|
|
|
&& !(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET))
|
2008-07-07 01:32:52 +00:00
|
|
|
need_restore = true;
|
2019-01-14 20:41:36 +00:00
|
|
|
/* Fall-through - force to D0 */
|
2005-09-14 13:52:42 +00:00
|
|
|
default:
|
2005-09-28 21:50:51 +00:00
|
|
|
pmcsr = 0;
|
2005-09-14 13:52:42 +00:00
|
|
|
break;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2019-01-09 20:14:42 +00:00
|
|
|
/* Enter specified state */
|
2008-07-07 01:36:24 +00:00
|
|
|
pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-01-09 20:14:42 +00:00
|
|
|
/*
|
|
|
|
* Mandatory power management transition delays; see PCI PM 1.1
|
|
|
|
* 5.6.1 table 18
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
if (state == PCI_D3hot || dev->current_state == PCI_D3hot)
|
2009-12-31 11:15:54 +00:00
|
|
|
pci_dev_d3_sleep(dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
else if (state == PCI_D2 || dev->current_state == PCI_D2)
|
2009-01-16 20:54:43 +00:00
|
|
|
udelay(PCI_PM_D2_DELAY);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-10-04 22:48:40 +00:00
|
|
|
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
|
|
|
|
dev->current_state = (pmcsr & PCI_PM_CTRL_STATE_MASK);
|
|
|
|
if (dev->current_state != state && printk_ratelimit())
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_info(dev, "Refused to change power state, currently in D%d\n",
|
2014-04-19 00:13:50 +00:00
|
|
|
dev->current_state);
|
2005-07-27 14:19:44 +00:00
|
|
|
|
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
|
|
|
/*
|
|
|
|
* According to section 5.4.1 of the "PCI BUS POWER MANAGEMENT
|
2005-07-27 14:19:44 +00:00
|
|
|
* INTERFACE SPECIFICATION, REV. 1.2", a device transitioning
|
|
|
|
* from D3hot to D0 _may_ perform an internal reset, thereby
|
|
|
|
* going to "D0 Uninitialized" rather than "D0 Initialized".
|
|
|
|
* For example, at least some versions of the 3c905B and the
|
|
|
|
* 3c556B exhibit this behaviour.
|
|
|
|
*
|
|
|
|
* At least some laptop BIOSen (e.g. the Thinkpad T21) leave
|
|
|
|
* devices in a D3hot state at boot. Consequently, we need to
|
|
|
|
* restore at least the BARs so that the device will be
|
|
|
|
* accessible to its driver.
|
|
|
|
*/
|
|
|
|
if (need_restore)
|
|
|
|
pci_restore_bars(dev);
|
|
|
|
|
2009-03-16 21:40:08 +00:00
|
|
|
if (dev->bus->self)
|
PCI: add PCI Express ASPM support
PCI Express ASPM defines a protocol for PCI Express components in the D0
state to reduce Link power by placing their Links into a low power state
and instructing the other end of the Link to do likewise. This
capability allows hardware-autonomous, dynamic Link power reduction
beyond what is achievable by software-only controlled power management.
However, The device should be configured by software appropriately.
Enabling ASPM will save power, but will introduce device latency.
This patch adds ASPM support in Linux. It introduces a global policy for
ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control
it. The interface can be used as a boot option too. Currently we have
below setting:
-default, BIOS default setting
-powersave, highest power saving mode, enable all available ASPM
state and clock power management
-performance, highest performance, disable ASPM and clock power
management
By default, the 'default' policy is used currently.
In my test, power difference between powersave mode and performance mode
is about 1.3w in a system with 3 PCIE links.
Note: some devices might not work well with aspm, either because chipset
issue or device issue. The patch provide API (pci_disable_link_state),
driver can disable ASPM for specific device.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-02-25 01:46:41 +00:00
|
|
|
pcie_aspm_pm_state_change(dev->bus->self);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-07-07 01:32:52 +00:00
|
|
|
/**
|
PCI: Recognize D3cold in pci_update_current_state()
Whenever a device is resumed or its power state is changed using the
platform, its new power state is read from the PM Control & Status Register
and cached in pci_dev->current_state by calling pci_update_current_state().
If the device is in D3cold, reading from config space typically results in
a fabricated "all ones" response. But if it's in D3hot, the two bits
representing the power state in the PMCSR are *also* set to 1. Thus D3hot
and D3cold are not discernible by just reading the PMCSR.
To account for this, pci_update_current_state() uses two workarounds:
- When transitioning to D3cold using pci_platform_power_transition(), the
new power state is set blindly by pci_update_current_state(), i.e.
without verifying that the device actually *is* in D3cold. This is
achieved by setting the "state" argument to PCI_D3cold. The "state"
argument was originally intended to convey the new state in case the
device doesn't have the PM capability. It is *also* used to convey the
device state if the PM capability is present and the new state is D3cold,
but this was never explained in the kerneldoc.
- Once the current_state is set to D3cold, further invocations of
pci_update_current_state() will blindly assume that the device is still
in D3cold and leave the current_state unmodified. To get out of this
impasse, the current_state has to be set directly, typically by calling
pci_raw_set_power_state() or pci_enable_device().
It would be desirable if pci_update_current_state() could reliably detect
D3cold by itself. That would allow us to do away with these workarounds,
and it would allow for a smarter, more energy conserving runtime resume
strategy after system sleep: Currently devices which utilize
direct_complete are mandatorily runtime resumed in their ->complete stage.
This can be avoided if their power state after system sleep is the same as
before, but it requires a mechanism to detect the power state reliably.
We've just gained the ability to query the platform firmware for its
opinion on the device's power state. On platforms conforming to ACPI 4.0
or newer, this allows recognition of D3cold. Pre-4.0 platforms lack _PR3
and therefore the deepest power state that will ever be reported is D3hot,
even though the device may actually be in D3cold. To detect D3cold in
those cases, accessibility of the vendor ID in config space is probed using
pci_device_is_present(). This also works for devices which are not
platform-power-manageable at all, but can be suspended to D3cold using a
nonstandard mechanism (e.g. some hybrid graphics laptops or Thunderbolt on
the Mac).
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-18 03:39:20 +00:00
|
|
|
* pci_update_current_state - Read power state of given device and cache it
|
2008-07-07 01:32:52 +00:00
|
|
|
* @dev: PCI device to handle.
|
2008-12-27 15:30:52 +00:00
|
|
|
* @state: State to cache in case the device doesn't have the PM capability
|
PCI: Recognize D3cold in pci_update_current_state()
Whenever a device is resumed or its power state is changed using the
platform, its new power state is read from the PM Control & Status Register
and cached in pci_dev->current_state by calling pci_update_current_state().
If the device is in D3cold, reading from config space typically results in
a fabricated "all ones" response. But if it's in D3hot, the two bits
representing the power state in the PMCSR are *also* set to 1. Thus D3hot
and D3cold are not discernible by just reading the PMCSR.
To account for this, pci_update_current_state() uses two workarounds:
- When transitioning to D3cold using pci_platform_power_transition(), the
new power state is set blindly by pci_update_current_state(), i.e.
without verifying that the device actually *is* in D3cold. This is
achieved by setting the "state" argument to PCI_D3cold. The "state"
argument was originally intended to convey the new state in case the
device doesn't have the PM capability. It is *also* used to convey the
device state if the PM capability is present and the new state is D3cold,
but this was never explained in the kerneldoc.
- Once the current_state is set to D3cold, further invocations of
pci_update_current_state() will blindly assume that the device is still
in D3cold and leave the current_state unmodified. To get out of this
impasse, the current_state has to be set directly, typically by calling
pci_raw_set_power_state() or pci_enable_device().
It would be desirable if pci_update_current_state() could reliably detect
D3cold by itself. That would allow us to do away with these workarounds,
and it would allow for a smarter, more energy conserving runtime resume
strategy after system sleep: Currently devices which utilize
direct_complete are mandatorily runtime resumed in their ->complete stage.
This can be avoided if their power state after system sleep is the same as
before, but it requires a mechanism to detect the power state reliably.
We've just gained the ability to query the platform firmware for its
opinion on the device's power state. On platforms conforming to ACPI 4.0
or newer, this allows recognition of D3cold. Pre-4.0 platforms lack _PR3
and therefore the deepest power state that will ever be reported is D3hot,
even though the device may actually be in D3cold. To detect D3cold in
those cases, accessibility of the vendor ID in config space is probed using
pci_device_is_present(). This also works for devices which are not
platform-power-manageable at all, but can be suspended to D3cold using a
nonstandard mechanism (e.g. some hybrid graphics laptops or Thunderbolt on
the Mac).
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-18 03:39:20 +00:00
|
|
|
*
|
|
|
|
* The power state is read from the PMCSR register, which however is
|
|
|
|
* inaccessible in D3cold. The platform firmware is therefore queried first
|
|
|
|
* to detect accessibility of the register. In case the platform firmware
|
|
|
|
* reports an incorrect state or the device isn't power manageable by the
|
|
|
|
* platform at all, we try to detect D3cold by testing accessibility of the
|
|
|
|
* vendor ID in config space.
|
2008-07-07 01:32:52 +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
|
|
|
void pci_update_current_state(struct pci_dev *dev, pci_power_t state)
|
2008-07-07 01:32:52 +00:00
|
|
|
{
|
PCI: Recognize D3cold in pci_update_current_state()
Whenever a device is resumed or its power state is changed using the
platform, its new power state is read from the PM Control & Status Register
and cached in pci_dev->current_state by calling pci_update_current_state().
If the device is in D3cold, reading from config space typically results in
a fabricated "all ones" response. But if it's in D3hot, the two bits
representing the power state in the PMCSR are *also* set to 1. Thus D3hot
and D3cold are not discernible by just reading the PMCSR.
To account for this, pci_update_current_state() uses two workarounds:
- When transitioning to D3cold using pci_platform_power_transition(), the
new power state is set blindly by pci_update_current_state(), i.e.
without verifying that the device actually *is* in D3cold. This is
achieved by setting the "state" argument to PCI_D3cold. The "state"
argument was originally intended to convey the new state in case the
device doesn't have the PM capability. It is *also* used to convey the
device state if the PM capability is present and the new state is D3cold,
but this was never explained in the kerneldoc.
- Once the current_state is set to D3cold, further invocations of
pci_update_current_state() will blindly assume that the device is still
in D3cold and leave the current_state unmodified. To get out of this
impasse, the current_state has to be set directly, typically by calling
pci_raw_set_power_state() or pci_enable_device().
It would be desirable if pci_update_current_state() could reliably detect
D3cold by itself. That would allow us to do away with these workarounds,
and it would allow for a smarter, more energy conserving runtime resume
strategy after system sleep: Currently devices which utilize
direct_complete are mandatorily runtime resumed in their ->complete stage.
This can be avoided if their power state after system sleep is the same as
before, but it requires a mechanism to detect the power state reliably.
We've just gained the ability to query the platform firmware for its
opinion on the device's power state. On platforms conforming to ACPI 4.0
or newer, this allows recognition of D3cold. Pre-4.0 platforms lack _PR3
and therefore the deepest power state that will ever be reported is D3hot,
even though the device may actually be in D3cold. To detect D3cold in
those cases, accessibility of the vendor ID in config space is probed using
pci_device_is_present(). This also works for devices which are not
platform-power-manageable at all, but can be suspended to D3cold using a
nonstandard mechanism (e.g. some hybrid graphics laptops or Thunderbolt on
the Mac).
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-18 03:39:20 +00:00
|
|
|
if (platform_pci_get_power_state(dev) == PCI_D3cold ||
|
|
|
|
!pci_device_is_present(dev)) {
|
|
|
|
dev->current_state = PCI_D3cold;
|
|
|
|
} else if (dev->pm_cap) {
|
2008-07-07 01:32:52 +00:00
|
|
|
u16 pmcsr;
|
|
|
|
|
2008-07-07 01:36:24 +00:00
|
|
|
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
|
2008-07-07 01:32:52 +00:00
|
|
|
dev->current_state = (pmcsr & PCI_PM_CTRL_STATE_MASK);
|
2008-12-27 15:30:52 +00:00
|
|
|
} else {
|
|
|
|
dev->current_state = state;
|
2008-07-07 01:32:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-25 12:09:12 +00:00
|
|
|
/**
|
|
|
|
* pci_refresh_power_state - Refresh the given device's power state data
|
|
|
|
* @dev: Target PCI device.
|
|
|
|
*
|
|
|
|
* Ask the platform to refresh the devices power state information and invoke
|
|
|
|
* pci_update_current_state() to update its current PCI power state.
|
|
|
|
*/
|
|
|
|
void pci_refresh_power_state(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (platform_pci_power_manageable(dev))
|
|
|
|
platform_pci_refresh_power_state(dev);
|
|
|
|
|
|
|
|
pci_update_current_state(dev, dev->current_state);
|
|
|
|
}
|
|
|
|
|
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 - Put the given device into D0 forcibly
|
|
|
|
* @dev: PCI device to power up
|
|
|
|
*/
|
|
|
|
void pci_power_up(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (platform_pci_power_manageable(dev))
|
|
|
|
platform_pci_set_power_state(dev, PCI_D0);
|
|
|
|
|
|
|
|
pci_raw_set_power_state(dev, PCI_D0);
|
|
|
|
pci_update_current_state(dev, PCI_D0);
|
|
|
|
}
|
|
|
|
|
2009-03-26 21:51:40 +00:00
|
|
|
/**
|
|
|
|
* pci_platform_power_transition - Use platform to change device power state
|
|
|
|
* @dev: PCI device to handle.
|
|
|
|
* @state: State to put the device into.
|
|
|
|
*/
|
|
|
|
static int pci_platform_power_transition(struct pci_dev *dev, pci_power_t state)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (platform_pci_power_manageable(dev)) {
|
|
|
|
error = platform_pci_set_power_state(dev, state);
|
|
|
|
if (!error)
|
|
|
|
pci_update_current_state(dev, state);
|
2013-04-12 13:58:17 +00:00
|
|
|
} else
|
2009-03-26 21:51:40 +00:00
|
|
|
error = -ENODEV;
|
2013-04-12 13:58:17 +00:00
|
|
|
|
|
|
|
if (error && !dev->pm_cap) /* Fall back to PCI_D0 */
|
|
|
|
dev->current_state = PCI_D0;
|
2009-03-26 21:51:40 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2014-01-11 00:14:48 +00:00
|
|
|
/**
|
|
|
|
* pci_wakeup - Wake up a PCI device
|
|
|
|
* @pci_dev: Device to handle.
|
|
|
|
* @ign: ignored parameter
|
|
|
|
*/
|
|
|
|
static int pci_wakeup(struct pci_dev *pci_dev, void *ign)
|
|
|
|
{
|
|
|
|
pci_wakeup_event(pci_dev);
|
|
|
|
pm_request_resume(&pci_dev->dev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_wakeup_bus - Walk given bus and wake up devices on it
|
|
|
|
* @bus: Top bus of the subtree to walk.
|
|
|
|
*/
|
2018-03-03 09:53:24 +00:00
|
|
|
void pci_wakeup_bus(struct pci_bus *bus)
|
2014-01-11 00:14:48 +00:00
|
|
|
{
|
|
|
|
if (bus)
|
|
|
|
pci_walk_bus(bus, pci_wakeup, NULL);
|
|
|
|
}
|
|
|
|
|
2009-03-26 21:51:40 +00:00
|
|
|
/**
|
|
|
|
* __pci_start_power_transition - Start power transition of a PCI device
|
|
|
|
* @dev: PCI device to handle.
|
|
|
|
* @state: State to put the device into.
|
|
|
|
*/
|
|
|
|
static void __pci_start_power_transition(struct pci_dev *dev, pci_power_t state)
|
|
|
|
{
|
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 (state == PCI_D0) {
|
2009-03-26 21:51:40 +00:00
|
|
|
pci_platform_power_transition(dev, PCI_D0);
|
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: Add missing link delays required by the PCIe spec
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that
consists of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
+-01.0-[04-36]-- DS hotplug port
+-02.0-[37]----00.0 xHCI controller
\-04.0-[38-6b]-- DS hotplug port
The root port (1b.0) and the PCIe switch downstream ports are all PCIe
gen3 so they support 8GT/s link speeds.
We wait for the PCIe hierarchy to enter D3cold (runtime):
pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the
PCIe switch is put to reset and its power is re-applied. This means that
we must follow the rules in PCIe 4.0 section 6.6.1.
For the PCIe gen3 ports we are dealing with here, the following applies:
With a Downstream Port that supports Link speeds greater than 5.0
GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port. Software can determine when Link training
completes by polling the Data Link Layer Link Active bit or by setting
up an associated interrupt (see Section 6.7.3.3).
Translating this into the above topology we would need to do this (DLLLA
stands for Data Link Layer Link Active):
pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0
pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0
I've instrumented the kernel with additional logging so we can see the
actual delays the kernel performs:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
pcieport 0000:00:1b.0: waking up bus
pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:00:1b.0: PME# disabled
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:01:00.0: PME# disabled
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:00.0: PME# disabled
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:01.0: PME# disabled
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: PME# disabled
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:04.0: PME# disabled
pcieport 0000:02:01.0: PME# enabled
pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:04.0: PME# enabled
pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
...
thunderbolt 0000:03:00.0: PME# disabled
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
xhci_hcd 0000:37:00.0: PME# disabled
For the switch upstream port (01:00.0) we wait for 100ms but not taking
into account the DLLLA requirement. We then wait 10ms for D3hot -> D0
transition of the root port and the two downstream hotplug ports. This
means that we deviate from what the spec requires.
Performing the same check for system sleep (s2idle) transitions we can
see following when resuming from s2idle:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0)
pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001)
pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702)
pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001)
pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00)
pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400)
pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151)
pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00)
pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161)
pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402)
pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802)
pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302)
pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
This is even worse. None of the mandatory delays are performed. If this
would be S3 instead of s2idle then according to PCI FW spec 3.2 section
4.6.8. there is a specific _DSM that allows the OS to skip the delays
but this platform does not provide the _DSM and does not go to S3 anyway
so no firmware is involved that could already handle these delays.
In this particular Intel Coffee Lake platform these delays are not
actually needed because there is an additional delay as part of the ACPI
power resource that is used to turn on power to the hierarchy but since
that additional delay is not required by any of standards (PCIe, ACPI)
it is not present in the Intel Ice Lake, for example where missing the
mandatory delays causes pciehp to start tearing down the stack too early
(links are not yet trained).
For this reason, change the PCIe portdrv PM resume hooks so that they
perform the mandatory delays before the downstream component gets
resumed. We perform the delays before port services are resumed because
otherwise pciehp might find that the link is not up (even if it is just
training) and tears-down the hierarchy.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-12 10:57:38 +00:00
|
|
|
* Mandatory power management transition delays are
|
|
|
|
* handled in the PCIe portdrv resume hooks.
|
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 (dev->runtime_d3cold) {
|
|
|
|
/*
|
|
|
|
* When powering on a bridge from D3cold, the
|
|
|
|
* whole hierarchy may be powered on into
|
|
|
|
* D0uninitialized state, resume them to give
|
|
|
|
* them a chance to suspend again
|
|
|
|
*/
|
|
|
|
pci_wakeup_bus(dev->subordinate);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __pci_dev_set_current_state - Set current state of a PCI device
|
|
|
|
* @dev: Device to handle
|
|
|
|
* @data: pointer to state to be set
|
|
|
|
*/
|
|
|
|
static int __pci_dev_set_current_state(struct pci_dev *dev, void *data)
|
|
|
|
{
|
|
|
|
pci_power_t state = *(pci_power_t *)data;
|
|
|
|
|
|
|
|
dev->current_state = state;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2018-03-03 09:53:24 +00:00
|
|
|
* pci_bus_set_current_state - Walk given bus and set current state of devices
|
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
|
|
|
* @bus: Top bus of the subtree to walk.
|
|
|
|
* @state: state to be set
|
|
|
|
*/
|
2018-03-03 09:53:24 +00:00
|
|
|
void pci_bus_set_current_state(struct pci_bus *bus, pci_power_t state)
|
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 (bus)
|
|
|
|
pci_walk_bus(bus, __pci_dev_set_current_state, &state);
|
2009-03-26 21:51:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __pci_complete_power_transition - Complete power transition of a PCI device
|
|
|
|
* @dev: PCI device to handle.
|
|
|
|
* @state: State to put the device into.
|
|
|
|
*
|
|
|
|
* This function should not be called directly by device drivers.
|
|
|
|
*/
|
|
|
|
int __pci_complete_power_transition(struct pci_dev *dev, pci_power_t state)
|
|
|
|
{
|
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 ret;
|
|
|
|
|
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
|
|
|
if (state <= PCI_D0)
|
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
|
|
|
return -EINVAL;
|
|
|
|
ret = pci_platform_power_transition(dev, state);
|
|
|
|
/* Power off the bridge may power off the whole hierarchy */
|
|
|
|
if (!ret && state == PCI_D3cold)
|
2018-03-03 09:53:24 +00:00
|
|
|
pci_bus_set_current_state(dev->subordinate, PCI_D3cold);
|
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
|
|
|
return ret;
|
2009-03-26 21:51:40 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__pci_complete_power_transition);
|
|
|
|
|
2008-07-07 01:32:52 +00:00
|
|
|
/**
|
|
|
|
* pci_set_power_state - Set the power state of a PCI device
|
|
|
|
* @dev: PCI device to handle.
|
|
|
|
* @state: PCI power state (D0, D1, D2, D3hot) to put the device into.
|
|
|
|
*
|
2009-01-26 10:06:57 +00:00
|
|
|
* Transition a device to a new power state, using the platform firmware and/or
|
2008-07-07 01:32:52 +00:00
|
|
|
* the device's PCI PM registers.
|
|
|
|
*
|
|
|
|
* RETURN VALUE:
|
|
|
|
* -EINVAL if the requested state is invalid.
|
|
|
|
* -EIO if device does not support PCI PM or its PM capabilities register has a
|
|
|
|
* wrong version, or device doesn't support the requested state.
|
2017-08-02 19:42:18 +00:00
|
|
|
* 0 if the transition is to D1 or D2 but D1 and D2 are not supported.
|
2008-07-07 01:32:52 +00:00
|
|
|
* 0 if device already is in the requested state.
|
2017-08-02 19:42:18 +00:00
|
|
|
* 0 if the transition is to D3 but D3 is not supported.
|
2008-07-07 01:32:52 +00:00
|
|
|
* 0 if device's power state has been successfully changed.
|
|
|
|
*/
|
|
|
|
int pci_set_power_state(struct pci_dev *dev, pci_power_t state)
|
|
|
|
{
|
2008-07-07 01:36:24 +00:00
|
|
|
int error;
|
2008-07-07 01:32:52 +00:00
|
|
|
|
2019-01-09 20:14:42 +00:00
|
|
|
/* Bound the state we're entering */
|
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 (state > PCI_D3cold)
|
|
|
|
state = PCI_D3cold;
|
2008-07-07 01:32:52 +00:00
|
|
|
else if (state < PCI_D0)
|
|
|
|
state = PCI_D0;
|
|
|
|
else if ((state == PCI_D1 || state == PCI_D2) && pci_no_d1d2(dev))
|
2019-01-09 20:14:42 +00:00
|
|
|
|
2008-07-07 01:32:52 +00:00
|
|
|
/*
|
2019-01-09 20:14:42 +00:00
|
|
|
* If the device or the parent bridge do not support PCI
|
|
|
|
* PM, ignore the request if we're doing anything other
|
|
|
|
* than putting it into D0 (which would only happen on
|
|
|
|
* boot).
|
2008-07-07 01:32:52 +00:00
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
|
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
|
|
|
/* Check if we're already there */
|
|
|
|
if (dev->current_state == state)
|
|
|
|
return 0;
|
|
|
|
|
2009-03-26 21:51:40 +00:00
|
|
|
__pci_start_power_transition(dev, state);
|
|
|
|
|
2019-01-09 20:14:42 +00:00
|
|
|
/*
|
|
|
|
* This device is quirked not to be put into D3, so don't put it in
|
|
|
|
* D3
|
|
|
|
*/
|
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 (state >= PCI_D3hot && (dev->dev_flags & PCI_DEV_FLAGS_NO_D3))
|
2008-07-24 16:18:38 +00:00
|
|
|
return 0;
|
2008-07-07 01:32:52 +00:00
|
|
|
|
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
|
|
|
/*
|
|
|
|
* To put device in D3cold, we put device into D3hot in native
|
|
|
|
* way, then put device into D3cold with platform ops
|
|
|
|
*/
|
|
|
|
error = pci_raw_set_power_state(dev, state > PCI_D3hot ?
|
|
|
|
PCI_D3hot : state);
|
2008-07-07 01:32:52 +00:00
|
|
|
|
2009-03-26 21:51:40 +00:00
|
|
|
if (!__pci_complete_power_transition(dev, state))
|
|
|
|
error = 0;
|
2008-07-07 01:32:52 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_set_power_state);
|
2008-07-07 01:32:52 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* pci_choose_state - Choose the power state of a PCI device
|
|
|
|
* @dev: PCI device to be suspended
|
|
|
|
* @state: target sleep state for the whole system. This is the value
|
2019-01-09 20:14:42 +00:00
|
|
|
* that is passed to suspend() function.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Returns PCI power state suitable for given device and given system
|
|
|
|
* message.
|
|
|
|
*/
|
|
|
|
pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t state)
|
|
|
|
{
|
2007-07-20 02:03:22 +00:00
|
|
|
pci_power_t ret;
|
2005-03-19 05:15:48 +00:00
|
|
|
|
2013-06-18 08:22:14 +00:00
|
|
|
if (!dev->pm_cap)
|
2005-04-16 22:20:36 +00:00
|
|
|
return PCI_D0;
|
|
|
|
|
2008-07-07 01:32:02 +00:00
|
|
|
ret = platform_pci_choose_state(dev);
|
|
|
|
if (ret != PCI_POWER_ERROR)
|
|
|
|
return ret;
|
2005-09-03 22:56:57 +00:00
|
|
|
|
|
|
|
switch (state.event) {
|
|
|
|
case PM_EVENT_ON:
|
|
|
|
return PCI_D0;
|
|
|
|
case PM_EVENT_FREEZE:
|
2006-08-15 06:11:05 +00:00
|
|
|
case PM_EVENT_PRETHAW:
|
|
|
|
/* REVISIT both freeze and pre-thaw "should" use D0 */
|
2005-09-03 22:56:57 +00:00
|
|
|
case PM_EVENT_SUSPEND:
|
2008-02-23 18:13:25 +00:00
|
|
|
case PM_EVENT_HIBERNATE:
|
2005-09-03 22:56:57 +00:00
|
|
|
return PCI_D3hot;
|
2005-04-16 22:20:36 +00:00
|
|
|
default:
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_info(dev, "unrecognized suspend event %d\n",
|
2008-06-13 16:52:11 +00:00
|
|
|
state.event);
|
2005-04-16 22:20:36 +00:00
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
return PCI_D0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pci_choose_state);
|
|
|
|
|
2009-02-15 18:55:47 +00:00
|
|
|
#define PCI_EXP_SAVE_REGS 7
|
|
|
|
|
2013-12-17 23:43:45 +00:00
|
|
|
static struct pci_cap_saved_state *_pci_find_saved_cap(struct pci_dev *pci_dev,
|
|
|
|
u16 cap, bool extended)
|
2012-02-11 08:18:41 +00:00
|
|
|
{
|
|
|
|
struct pci_cap_saved_state *tmp;
|
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28 01:06:00 +00:00
|
|
|
hlist_for_each_entry(tmp, &pci_dev->saved_cap_space, next) {
|
2013-12-17 23:43:45 +00:00
|
|
|
if (tmp->cap.cap_extended == extended && tmp->cap.cap_nr == cap)
|
2012-02-11 08:18:41 +00:00
|
|
|
return tmp;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-12-17 23:43:45 +00:00
|
|
|
struct pci_cap_saved_state *pci_find_saved_cap(struct pci_dev *dev, char cap)
|
|
|
|
{
|
|
|
|
return _pci_find_saved_cap(dev, cap, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct pci_cap_saved_state *pci_find_saved_ext_cap(struct pci_dev *dev, u16 cap)
|
|
|
|
{
|
|
|
|
return _pci_find_saved_cap(dev, cap, true);
|
|
|
|
}
|
|
|
|
|
2006-08-21 13:22:22 +00:00
|
|
|
static int pci_save_pcie_state(struct pci_dev *dev)
|
|
|
|
{
|
2012-07-24 09:20:06 +00:00
|
|
|
int i = 0;
|
2006-08-21 13:22:22 +00:00
|
|
|
struct pci_cap_saved_state *save_state;
|
|
|
|
u16 *cap;
|
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
if (!pci_is_pcie(dev))
|
2006-08-21 13:22:22 +00:00
|
|
|
return 0;
|
|
|
|
|
2007-03-08 20:06:13 +00:00
|
|
|
save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
|
2006-08-21 13:22:22 +00:00
|
|
|
if (!save_state) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "buffer not found in %s\n", __func__);
|
2006-08-21 13:22:22 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2008-12-07 21:02:58 +00:00
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
cap = (u16 *)&save_state->cap.data[0];
|
|
|
|
pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &cap[i++]);
|
|
|
|
pcie_capability_read_word(dev, PCI_EXP_LNKCTL, &cap[i++]);
|
|
|
|
pcie_capability_read_word(dev, PCI_EXP_SLTCTL, &cap[i++]);
|
|
|
|
pcie_capability_read_word(dev, PCI_EXP_RTCTL, &cap[i++]);
|
|
|
|
pcie_capability_read_word(dev, PCI_EXP_DEVCTL2, &cap[i++]);
|
|
|
|
pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &cap[i++]);
|
|
|
|
pcie_capability_read_word(dev, PCI_EXP_SLTCTL2, &cap[i++]);
|
PCI: remove redundant capabilities checking in pci_{save, restore}_pcie_state
Unlike PCI Express v1's Capabilities Structure, v2's requires the entire
structure to be implemented. In v2 structures, register fields that
are not implemented are present but hardwired to 0x0. These may
include: Link Capabilities, Status, and Control; Slot Capabilities,
Status, and Control; Root Capabilities, Status, and Control; and all of
the '2' (Device, Link, and Slot) Capabilities, Status, and Control
registers.
This patch removes the redundant capability checks corresponding to the
Link 2's and Slot 2's, Capabilities, Status, and Control registers as they
will be present if Device Capabilities 2's registers are (which explains
why the macros for each of the three are identical).
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-01 21:16:43 +00:00
|
|
|
|
2006-08-21 13:22:22 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pci_restore_pcie_state(struct pci_dev *dev)
|
|
|
|
{
|
2012-07-24 09:20:06 +00:00
|
|
|
int i = 0;
|
2006-08-21 13:22:22 +00:00
|
|
|
struct pci_cap_saved_state *save_state;
|
|
|
|
u16 *cap;
|
|
|
|
|
|
|
|
save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
|
2012-07-24 09:20:06 +00:00
|
|
|
if (!save_state)
|
PCI: remove redundant capabilities checking in pci_{save, restore}_pcie_state
Unlike PCI Express v1's Capabilities Structure, v2's requires the entire
structure to be implemented. In v2 structures, register fields that
are not implemented are present but hardwired to 0x0. These may
include: Link Capabilities, Status, and Control; Slot Capabilities,
Status, and Control; Root Capabilities, Status, and Control; and all of
the '2' (Device, Link, and Slot) Capabilities, Status, and Control
registers.
This patch removes the redundant capability checks corresponding to the
Link 2's and Slot 2's, Capabilities, Status, and Control registers as they
will be present if Device Capabilities 2's registers are (which explains
why the macros for each of the three are identical).
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-01 21:16:43 +00:00
|
|
|
return;
|
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
cap = (u16 *)&save_state->cap.data[0];
|
|
|
|
pcie_capability_write_word(dev, PCI_EXP_DEVCTL, cap[i++]);
|
|
|
|
pcie_capability_write_word(dev, PCI_EXP_LNKCTL, cap[i++]);
|
|
|
|
pcie_capability_write_word(dev, PCI_EXP_SLTCTL, cap[i++]);
|
|
|
|
pcie_capability_write_word(dev, PCI_EXP_RTCTL, cap[i++]);
|
|
|
|
pcie_capability_write_word(dev, PCI_EXP_DEVCTL2, cap[i++]);
|
|
|
|
pcie_capability_write_word(dev, PCI_EXP_LNKCTL2, cap[i++]);
|
|
|
|
pcie_capability_write_word(dev, PCI_EXP_SLTCTL2, cap[i++]);
|
2006-08-21 13:22:22 +00:00
|
|
|
}
|
|
|
|
|
2006-11-09 00:17:15 +00:00
|
|
|
static int pci_save_pcix_state(struct pci_dev *dev)
|
|
|
|
{
|
2008-12-07 21:02:58 +00:00
|
|
|
int pos;
|
2006-11-09 00:17:15 +00:00
|
|
|
struct pci_cap_saved_state *save_state;
|
|
|
|
|
|
|
|
pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
|
2015-06-30 01:16:44 +00:00
|
|
|
if (!pos)
|
2006-11-09 00:17:15 +00:00
|
|
|
return 0;
|
|
|
|
|
2007-12-18 01:56:47 +00:00
|
|
|
save_state = pci_find_saved_cap(dev, PCI_CAP_ID_PCIX);
|
2006-11-09 00:17:15 +00:00
|
|
|
if (!save_state) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "buffer not found in %s\n", __func__);
|
2006-11-09 00:17:15 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2011-05-10 16:02:11 +00:00
|
|
|
pci_read_config_word(dev, pos + PCI_X_CMD,
|
|
|
|
(u16 *)save_state->cap.data);
|
2008-12-07 21:02:58 +00:00
|
|
|
|
2006-11-09 00:17:15 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pci_restore_pcix_state(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int i = 0, pos;
|
|
|
|
struct pci_cap_saved_state *save_state;
|
|
|
|
u16 *cap;
|
|
|
|
|
|
|
|
save_state = pci_find_saved_cap(dev, PCI_CAP_ID_PCIX);
|
|
|
|
pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
|
2015-06-30 01:16:44 +00:00
|
|
|
if (!save_state || !pos)
|
2006-11-09 00:17:15 +00:00
|
|
|
return;
|
2011-05-10 16:02:11 +00:00
|
|
|
cap = (u16 *)&save_state->cap.data[0];
|
2006-11-09 00:17:15 +00:00
|
|
|
|
|
|
|
pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
|
|
|
|
}
|
|
|
|
|
2019-01-09 14:22:08 +00:00
|
|
|
static void pci_save_ltr_state(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int ltr;
|
|
|
|
struct pci_cap_saved_state *save_state;
|
|
|
|
u16 *cap;
|
|
|
|
|
|
|
|
if (!pci_is_pcie(dev))
|
|
|
|
return;
|
|
|
|
|
|
|
|
ltr = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_LTR);
|
|
|
|
if (!ltr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
save_state = pci_find_saved_ext_cap(dev, PCI_EXT_CAP_ID_LTR);
|
|
|
|
if (!save_state) {
|
|
|
|
pci_err(dev, "no suspend buffer for LTR; ASPM issues possible after resume\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
cap = (u16 *)&save_state->cap.data[0];
|
|
|
|
pci_read_config_word(dev, ltr + PCI_LTR_MAX_SNOOP_LAT, cap++);
|
|
|
|
pci_read_config_word(dev, ltr + PCI_LTR_MAX_NOSNOOP_LAT, cap++);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pci_restore_ltr_state(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
struct pci_cap_saved_state *save_state;
|
|
|
|
int ltr;
|
|
|
|
u16 *cap;
|
|
|
|
|
|
|
|
save_state = pci_find_saved_ext_cap(dev, PCI_EXT_CAP_ID_LTR);
|
|
|
|
ltr = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_LTR);
|
|
|
|
if (!save_state || !ltr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
cap = (u16 *)&save_state->cap.data[0];
|
|
|
|
pci_write_config_word(dev, ltr + PCI_LTR_MAX_SNOOP_LAT, *cap++);
|
|
|
|
pci_write_config_word(dev, ltr + PCI_LTR_MAX_NOSNOOP_LAT, *cap++);
|
|
|
|
}
|
2006-11-09 00:17:15 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_save_state - save the PCI configuration space of a device before
|
|
|
|
* suspending
|
|
|
|
* @dev: PCI device that we're dealing with
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
int pci_save_state(struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
/* XXX: 100% dword access ok here? */
|
|
|
|
for (i = 0; i < 16; i++)
|
2009-11-25 02:55:51 +00:00
|
|
|
pci_read_config_dword(dev, i * 4, &dev->saved_config_space[i]);
|
2009-01-16 20:54:43 +00:00
|
|
|
dev->state_saved = true;
|
2014-09-07 18:03:32 +00:00
|
|
|
|
|
|
|
i = pci_save_pcie_state(dev);
|
|
|
|
if (i != 0)
|
2006-08-21 13:22:22 +00:00
|
|
|
return i;
|
2014-09-07 18:03:32 +00:00
|
|
|
|
|
|
|
i = pci_save_pcix_state(dev);
|
|
|
|
if (i != 0)
|
2006-11-09 00:17:15 +00:00
|
|
|
return i;
|
2014-09-07 18:03:32 +00:00
|
|
|
|
2019-01-09 14:22:08 +00:00
|
|
|
pci_save_ltr_state(dev);
|
2018-09-20 16:27:08 +00:00
|
|
|
pci_save_dpc_state(dev);
|
2014-11-06 16:45:55 +00:00
|
|
|
return pci_save_vc_state(dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_save_state);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
PCI: Fix regression in pci_restore_state(), v3
Commit 26f41062f28d ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-15 19:40:40 +00:00
|
|
|
static void pci_restore_config_dword(struct pci_dev *pdev, int offset,
|
PCI: Reprogram bridge prefetch registers on resume
On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
suspend/resume. The affected products include multiple generations of
NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such
as:
fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
[HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
DRM: failed to idle channel 0 [DRM]
Similarly, the NVIDIA proprietary driver also fails after resume (black
screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for
diagnosis, and their response indicated that it's a problem with the parent
PCI bridge (on the Intel SoC), not the GPU.
Runtime suspend/resume works fine, only S3 suspend is affected.
We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the
cases that I checked, this register has value 0 and we just have to rewrite
that value.
Linux already saves and restores PCI config space during suspend/resume,
but this register was being skipped because upon resume, it already has
value 0 (the correct, pre-suspend value).
Intel appear to have previously acknowledged this behaviour and the
requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
Based on that, rewrite the prefetch register values even when that appears
unnecessary.
We have confirmed this solution on all the affected models we have in-hands
(X542UQ, UX533FD, X530UN, V272UN).
Additionally, this solves an issue where r8169 MSI-X interrupts were broken
after S3 suspend/resume on ASUS X441UAR. This issue was recently worked
around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It
also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
that we had not yet patched. I suspect it will also fix the issue that was
worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
RTL8168g").
Thomas Martitz reports that this change also solves an issue where the AMD
Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
suspend/resume.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: Peter Wu <peter@lekensteyn.nl>
CC: stable@vger.kernel.org
2018-09-27 20:47:33 +00:00
|
|
|
u32 saved_val, int retry, bool force)
|
PCI: Fix regression in pci_restore_state(), v3
Commit 26f41062f28d ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-15 19:40:40 +00:00
|
|
|
{
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, offset, &val);
|
PCI: Reprogram bridge prefetch registers on resume
On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
suspend/resume. The affected products include multiple generations of
NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such
as:
fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
[HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
DRM: failed to idle channel 0 [DRM]
Similarly, the NVIDIA proprietary driver also fails after resume (black
screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for
diagnosis, and their response indicated that it's a problem with the parent
PCI bridge (on the Intel SoC), not the GPU.
Runtime suspend/resume works fine, only S3 suspend is affected.
We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the
cases that I checked, this register has value 0 and we just have to rewrite
that value.
Linux already saves and restores PCI config space during suspend/resume,
but this register was being skipped because upon resume, it already has
value 0 (the correct, pre-suspend value).
Intel appear to have previously acknowledged this behaviour and the
requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
Based on that, rewrite the prefetch register values even when that appears
unnecessary.
We have confirmed this solution on all the affected models we have in-hands
(X542UQ, UX533FD, X530UN, V272UN).
Additionally, this solves an issue where r8169 MSI-X interrupts were broken
after S3 suspend/resume on ASUS X441UAR. This issue was recently worked
around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It
also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
that we had not yet patched. I suspect it will also fix the issue that was
worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
RTL8168g").
Thomas Martitz reports that this change also solves an issue where the AMD
Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
suspend/resume.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: Peter Wu <peter@lekensteyn.nl>
CC: stable@vger.kernel.org
2018-09-27 20:47:33 +00:00
|
|
|
if (!force && val == saved_val)
|
PCI: Fix regression in pci_restore_state(), v3
Commit 26f41062f28d ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-15 19:40:40 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
for (;;) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_dbg(pdev, "restoring config space at offset %#x (was %#x, writing %#x)\n",
|
2014-04-19 00:13:50 +00:00
|
|
|
offset, val, saved_val);
|
PCI: Fix regression in pci_restore_state(), v3
Commit 26f41062f28d ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-15 19:40:40 +00:00
|
|
|
pci_write_config_dword(pdev, offset, saved_val);
|
|
|
|
if (retry-- <= 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, offset, &val);
|
|
|
|
if (val == saved_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mdelay(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-04-16 21:07:50 +00:00
|
|
|
static void pci_restore_config_space_range(struct pci_dev *pdev,
|
PCI: Reprogram bridge prefetch registers on resume
On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
suspend/resume. The affected products include multiple generations of
NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such
as:
fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
[HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
DRM: failed to idle channel 0 [DRM]
Similarly, the NVIDIA proprietary driver also fails after resume (black
screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for
diagnosis, and their response indicated that it's a problem with the parent
PCI bridge (on the Intel SoC), not the GPU.
Runtime suspend/resume works fine, only S3 suspend is affected.
We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the
cases that I checked, this register has value 0 and we just have to rewrite
that value.
Linux already saves and restores PCI config space during suspend/resume,
but this register was being skipped because upon resume, it already has
value 0 (the correct, pre-suspend value).
Intel appear to have previously acknowledged this behaviour and the
requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
Based on that, rewrite the prefetch register values even when that appears
unnecessary.
We have confirmed this solution on all the affected models we have in-hands
(X542UQ, UX533FD, X530UN, V272UN).
Additionally, this solves an issue where r8169 MSI-X interrupts were broken
after S3 suspend/resume on ASUS X441UAR. This issue was recently worked
around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It
also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
that we had not yet patched. I suspect it will also fix the issue that was
worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
RTL8168g").
Thomas Martitz reports that this change also solves an issue where the AMD
Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
suspend/resume.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: Peter Wu <peter@lekensteyn.nl>
CC: stable@vger.kernel.org
2018-09-27 20:47:33 +00:00
|
|
|
int start, int end, int retry,
|
|
|
|
bool force)
|
PCI: Fix regression in pci_restore_state(), v3
Commit 26f41062f28d ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-15 19:40:40 +00:00
|
|
|
{
|
|
|
|
int index;
|
|
|
|
|
|
|
|
for (index = end; index >= start; index--)
|
|
|
|
pci_restore_config_dword(pdev, 4 * index,
|
|
|
|
pdev->saved_config_space[index],
|
PCI: Reprogram bridge prefetch registers on resume
On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
suspend/resume. The affected products include multiple generations of
NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such
as:
fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
[HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
DRM: failed to idle channel 0 [DRM]
Similarly, the NVIDIA proprietary driver also fails after resume (black
screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for
diagnosis, and their response indicated that it's a problem with the parent
PCI bridge (on the Intel SoC), not the GPU.
Runtime suspend/resume works fine, only S3 suspend is affected.
We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the
cases that I checked, this register has value 0 and we just have to rewrite
that value.
Linux already saves and restores PCI config space during suspend/resume,
but this register was being skipped because upon resume, it already has
value 0 (the correct, pre-suspend value).
Intel appear to have previously acknowledged this behaviour and the
requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
Based on that, rewrite the prefetch register values even when that appears
unnecessary.
We have confirmed this solution on all the affected models we have in-hands
(X542UQ, UX533FD, X530UN, V272UN).
Additionally, this solves an issue where r8169 MSI-X interrupts were broken
after S3 suspend/resume on ASUS X441UAR. This issue was recently worked
around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It
also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
that we had not yet patched. I suspect it will also fix the issue that was
worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
RTL8168g").
Thomas Martitz reports that this change also solves an issue where the AMD
Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
suspend/resume.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: Peter Wu <peter@lekensteyn.nl>
CC: stable@vger.kernel.org
2018-09-27 20:47:33 +00:00
|
|
|
retry, force);
|
PCI: Fix regression in pci_restore_state(), v3
Commit 26f41062f28d ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-15 19:40:40 +00:00
|
|
|
}
|
|
|
|
|
2012-04-16 21:07:50 +00:00
|
|
|
static void pci_restore_config_space(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
if (pdev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
|
PCI: Reprogram bridge prefetch registers on resume
On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
suspend/resume. The affected products include multiple generations of
NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such
as:
fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
[HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
DRM: failed to idle channel 0 [DRM]
Similarly, the NVIDIA proprietary driver also fails after resume (black
screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for
diagnosis, and their response indicated that it's a problem with the parent
PCI bridge (on the Intel SoC), not the GPU.
Runtime suspend/resume works fine, only S3 suspend is affected.
We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the
cases that I checked, this register has value 0 and we just have to rewrite
that value.
Linux already saves and restores PCI config space during suspend/resume,
but this register was being skipped because upon resume, it already has
value 0 (the correct, pre-suspend value).
Intel appear to have previously acknowledged this behaviour and the
requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
Based on that, rewrite the prefetch register values even when that appears
unnecessary.
We have confirmed this solution on all the affected models we have in-hands
(X542UQ, UX533FD, X530UN, V272UN).
Additionally, this solves an issue where r8169 MSI-X interrupts were broken
after S3 suspend/resume on ASUS X441UAR. This issue was recently worked
around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It
also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
that we had not yet patched. I suspect it will also fix the issue that was
worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
RTL8168g").
Thomas Martitz reports that this change also solves an issue where the AMD
Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
suspend/resume.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: Peter Wu <peter@lekensteyn.nl>
CC: stable@vger.kernel.org
2018-09-27 20:47:33 +00:00
|
|
|
pci_restore_config_space_range(pdev, 10, 15, 0, false);
|
2012-04-16 21:07:50 +00:00
|
|
|
/* Restore BARs before the command register. */
|
PCI: Reprogram bridge prefetch registers on resume
On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
suspend/resume. The affected products include multiple generations of
NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such
as:
fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
[HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
DRM: failed to idle channel 0 [DRM]
Similarly, the NVIDIA proprietary driver also fails after resume (black
screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for
diagnosis, and their response indicated that it's a problem with the parent
PCI bridge (on the Intel SoC), not the GPU.
Runtime suspend/resume works fine, only S3 suspend is affected.
We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the
cases that I checked, this register has value 0 and we just have to rewrite
that value.
Linux already saves and restores PCI config space during suspend/resume,
but this register was being skipped because upon resume, it already has
value 0 (the correct, pre-suspend value).
Intel appear to have previously acknowledged this behaviour and the
requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
Based on that, rewrite the prefetch register values even when that appears
unnecessary.
We have confirmed this solution on all the affected models we have in-hands
(X542UQ, UX533FD, X530UN, V272UN).
Additionally, this solves an issue where r8169 MSI-X interrupts were broken
after S3 suspend/resume on ASUS X441UAR. This issue was recently worked
around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It
also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
that we had not yet patched. I suspect it will also fix the issue that was
worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
RTL8168g").
Thomas Martitz reports that this change also solves an issue where the AMD
Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
suspend/resume.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: Peter Wu <peter@lekensteyn.nl>
CC: stable@vger.kernel.org
2018-09-27 20:47:33 +00:00
|
|
|
pci_restore_config_space_range(pdev, 4, 9, 10, false);
|
|
|
|
pci_restore_config_space_range(pdev, 0, 3, 0, false);
|
|
|
|
} else if (pdev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
|
|
|
|
pci_restore_config_space_range(pdev, 12, 15, 0, false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Force rewriting of prefetch registers to avoid S3 resume
|
|
|
|
* issues on Intel PCI bridges that occur when these
|
|
|
|
* registers are not explicitly written.
|
|
|
|
*/
|
|
|
|
pci_restore_config_space_range(pdev, 9, 11, 0, true);
|
|
|
|
pci_restore_config_space_range(pdev, 0, 8, 0, false);
|
2012-04-16 21:07:50 +00:00
|
|
|
} else {
|
PCI: Reprogram bridge prefetch registers on resume
On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
suspend/resume. The affected products include multiple generations of
NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such
as:
fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
[HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
DRM: failed to idle channel 0 [DRM]
Similarly, the NVIDIA proprietary driver also fails after resume (black
screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for
diagnosis, and their response indicated that it's a problem with the parent
PCI bridge (on the Intel SoC), not the GPU.
Runtime suspend/resume works fine, only S3 suspend is affected.
We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the
cases that I checked, this register has value 0 and we just have to rewrite
that value.
Linux already saves and restores PCI config space during suspend/resume,
but this register was being skipped because upon resume, it already has
value 0 (the correct, pre-suspend value).
Intel appear to have previously acknowledged this behaviour and the
requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
Based on that, rewrite the prefetch register values even when that appears
unnecessary.
We have confirmed this solution on all the affected models we have in-hands
(X542UQ, UX533FD, X530UN, V272UN).
Additionally, this solves an issue where r8169 MSI-X interrupts were broken
after S3 suspend/resume on ASUS X441UAR. This issue was recently worked
around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It
also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
that we had not yet patched. I suspect it will also fix the issue that was
worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
RTL8168g").
Thomas Martitz reports that this change also solves an issue where the AMD
Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
suspend/resume.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: Peter Wu <peter@lekensteyn.nl>
CC: stable@vger.kernel.org
2018-09-27 20:47:33 +00:00
|
|
|
pci_restore_config_space_range(pdev, 0, 15, 0, false);
|
2012-04-16 21:07:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-30 00:54:55 +00:00
|
|
|
static void pci_restore_rebar_state(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
unsigned int pos, nbars, i;
|
|
|
|
u32 ctrl;
|
|
|
|
|
|
|
|
pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
|
|
|
|
if (!pos)
|
|
|
|
return;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
|
|
|
|
nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >>
|
|
|
|
PCI_REBAR_CTRL_NBAR_SHIFT;
|
|
|
|
|
|
|
|
for (i = 0; i < nbars; i++, pos += 8) {
|
|
|
|
struct resource *res;
|
|
|
|
int bar_idx, size;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
|
|
|
|
bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
|
|
|
|
res = pdev->resource + bar_idx;
|
|
|
|
size = order_base_2((resource_size(res) >> 20) | 1) - 1;
|
|
|
|
ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
|
2018-06-30 00:55:03 +00:00
|
|
|
ctrl |= size << PCI_REBAR_CTRL_BAR_SHIFT;
|
2018-06-30 00:54:55 +00:00
|
|
|
pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-11-14 18:28:18 +00:00
|
|
|
/**
|
2005-04-16 22:20:36 +00:00
|
|
|
* pci_restore_state - Restore the saved state of a PCI device
|
2019-01-09 20:14:42 +00:00
|
|
|
* @dev: PCI device that we're dealing with
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2010-11-30 23:43:26 +00:00
|
|
|
void pci_restore_state(struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-08-08 00:46:19 +00:00
|
|
|
if (!dev->state_saved)
|
2010-11-30 23:43:26 +00:00
|
|
|
return;
|
2009-09-09 21:49:59 +00:00
|
|
|
|
2019-01-09 14:22:08 +00:00
|
|
|
/*
|
|
|
|
* Restore max latencies (in the LTR capability) before enabling
|
|
|
|
* LTR itself (in the PCIe capability).
|
|
|
|
*/
|
|
|
|
pci_restore_ltr_state(dev);
|
|
|
|
|
2006-08-21 13:22:22 +00:00
|
|
|
pci_restore_pcie_state(dev);
|
2017-05-30 16:25:49 +00:00
|
|
|
pci_restore_pasid_state(dev);
|
|
|
|
pci_restore_pri_state(dev);
|
2011-12-17 13:24:40 +00:00
|
|
|
pci_restore_ats_state(dev);
|
PCI: Add Virtual Channel to save/restore support
While we don't really have any infrastructure for making use of VC
support, the system BIOS can configure the topology to non-default
VC values prior to boot. This may be due to silicon bugs, desire to
reserve traffic classes, or perhaps just BIOS bugs. When we reset
devices, the VC configuration may return to default values, which can
be incompatible with devices upstream. For instance, Nvidia GRID
cards provide a PCIe switch and some number of GPUs, all supporting
VC. The power-on default for VC is to support TC0-7 across VC0,
however some platforms will only enable TC0/VC0 mapping across the
topology. When we do a secondary bus reset on the downstream switch
port, the GPU is reset to a TC0-7/VC0 mapping while the opposite end
of the link only enables TC0/VC0. If the GPU attempts to use TC1-7,
it fails.
This patch attempts to provide complete support for VC save/restore,
even beyond the minimally required use case above. This includes
save/restore and reload of the arbitration table, save/restore and
reload of the port arbitration tables, and re-enabling of the
channels for VC, VC9, and MFVC capabilities.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-17 23:43:51 +00:00
|
|
|
pci_restore_vc_state(dev);
|
2018-06-30 00:54:55 +00:00
|
|
|
pci_restore_rebar_state(dev);
|
2018-09-20 16:27:08 +00:00
|
|
|
pci_restore_dpc_state(dev);
|
2006-08-21 13:22:22 +00:00
|
|
|
|
2015-09-17 15:09:37 +00:00
|
|
|
pci_cleanup_aer_error_status_regs(dev);
|
|
|
|
|
2012-04-16 21:07:50 +00:00
|
|
|
pci_restore_config_space(dev);
|
PCI: Fix regression in pci_restore_state(), v3
Commit 26f41062f28d ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-15 19:40:40 +00:00
|
|
|
|
2006-11-09 00:17:15 +00:00
|
|
|
pci_restore_pcix_state(dev);
|
2006-02-08 09:11:38 +00:00
|
|
|
pci_restore_msi_state(dev);
|
2015-07-07 19:24:35 +00:00
|
|
|
|
|
|
|
/* Restore ACS and IOV configuration state */
|
|
|
|
pci_enable_acs(dev);
|
2009-03-20 03:25:12 +00:00
|
|
|
pci_restore_iov_state(dev);
|
2007-01-25 08:34:08 +00:00
|
|
|
|
2009-09-09 21:49:59 +00:00
|
|
|
dev->state_saved = false;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_restore_state);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-05-10 16:02:27 +00:00
|
|
|
struct pci_saved_state {
|
|
|
|
u32 config_space[16];
|
|
|
|
struct pci_cap_saved_data cap[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_store_saved_state - Allocate and return an opaque struct containing
|
|
|
|
* the device saved state.
|
|
|
|
* @dev: PCI device that we're dealing with
|
|
|
|
*
|
2013-11-14 18:28:18 +00:00
|
|
|
* Return NULL if no state or error.
|
2011-05-10 16:02:27 +00:00
|
|
|
*/
|
|
|
|
struct pci_saved_state *pci_store_saved_state(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
struct pci_saved_state *state;
|
|
|
|
struct pci_cap_saved_state *tmp;
|
|
|
|
struct pci_cap_saved_data *cap;
|
|
|
|
size_t size;
|
|
|
|
|
|
|
|
if (!dev->state_saved)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
size = sizeof(*state) + sizeof(struct pci_cap_saved_data);
|
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28 01:06:00 +00:00
|
|
|
hlist_for_each_entry(tmp, &dev->saved_cap_space, next)
|
2011-05-10 16:02:27 +00:00
|
|
|
size += sizeof(struct pci_cap_saved_data) + tmp->cap.size;
|
|
|
|
|
|
|
|
state = kzalloc(size, GFP_KERNEL);
|
|
|
|
if (!state)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
memcpy(state->config_space, dev->saved_config_space,
|
|
|
|
sizeof(state->config_space));
|
|
|
|
|
|
|
|
cap = state->cap;
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28 01:06:00 +00:00
|
|
|
hlist_for_each_entry(tmp, &dev->saved_cap_space, next) {
|
2011-05-10 16:02:27 +00:00
|
|
|
size_t len = sizeof(struct pci_cap_saved_data) + tmp->cap.size;
|
|
|
|
memcpy(cap, &tmp->cap, len);
|
|
|
|
cap = (struct pci_cap_saved_data *)((u8 *)cap + len);
|
|
|
|
}
|
|
|
|
/* Empty cap_save terminates list */
|
|
|
|
|
|
|
|
return state;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_store_saved_state);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_load_saved_state - Reload the provided save state into struct pci_dev.
|
|
|
|
* @dev: PCI device that we're dealing with
|
|
|
|
* @state: Saved state returned from pci_store_saved_state()
|
|
|
|
*/
|
2014-12-03 21:40:31 +00:00
|
|
|
int pci_load_saved_state(struct pci_dev *dev,
|
|
|
|
struct pci_saved_state *state)
|
2011-05-10 16:02:27 +00:00
|
|
|
{
|
|
|
|
struct pci_cap_saved_data *cap;
|
|
|
|
|
|
|
|
dev->state_saved = false;
|
|
|
|
|
|
|
|
if (!state)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
memcpy(dev->saved_config_space, state->config_space,
|
|
|
|
sizeof(state->config_space));
|
|
|
|
|
|
|
|
cap = state->cap;
|
|
|
|
while (cap->size) {
|
|
|
|
struct pci_cap_saved_state *tmp;
|
|
|
|
|
2013-12-17 23:43:45 +00:00
|
|
|
tmp = _pci_find_saved_cap(dev, cap->cap_nr, cap->cap_extended);
|
2011-05-10 16:02:27 +00:00
|
|
|
if (!tmp || tmp->cap.size != cap->size)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
memcpy(tmp->cap.data, cap->data, tmp->cap.size);
|
|
|
|
cap = (struct pci_cap_saved_data *)((u8 *)cap +
|
|
|
|
sizeof(struct pci_cap_saved_data) + cap->size);
|
|
|
|
}
|
|
|
|
|
|
|
|
dev->state_saved = true;
|
|
|
|
return 0;
|
|
|
|
}
|
2014-12-03 21:40:31 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_load_saved_state);
|
2011-05-10 16:02:27 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_load_and_free_saved_state - Reload the save state pointed to by state,
|
|
|
|
* and free the memory allocated for it.
|
|
|
|
* @dev: PCI device that we're dealing with
|
|
|
|
* @state: Pointer to saved state returned from pci_store_saved_state()
|
|
|
|
*/
|
|
|
|
int pci_load_and_free_saved_state(struct pci_dev *dev,
|
|
|
|
struct pci_saved_state **state)
|
|
|
|
{
|
|
|
|
int ret = pci_load_saved_state(dev, *state);
|
|
|
|
kfree(*state);
|
|
|
|
*state = NULL;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_load_and_free_saved_state);
|
|
|
|
|
2014-02-26 18:26:00 +00:00
|
|
|
int __weak pcibios_enable_device(struct pci_dev *dev, int bars)
|
|
|
|
{
|
|
|
|
return pci_enable_resources(dev, bars);
|
|
|
|
}
|
|
|
|
|
2006-12-18 01:30:00 +00:00
|
|
|
static int do_pci_enable_device(struct pci_dev *dev, int bars)
|
|
|
|
{
|
|
|
|
int err;
|
2014-07-16 10:03:42 +00:00
|
|
|
struct pci_dev *bridge;
|
2014-01-29 23:13:51 +00:00
|
|
|
u16 cmd;
|
|
|
|
u8 pin;
|
2006-12-18 01:30:00 +00:00
|
|
|
|
|
|
|
err = pci_set_power_state(dev, PCI_D0);
|
|
|
|
if (err < 0 && err != -EIO)
|
|
|
|
return err;
|
2014-07-16 10:03:42 +00:00
|
|
|
|
|
|
|
bridge = pci_upstream_bridge(dev);
|
|
|
|
if (bridge)
|
|
|
|
pcie_aspm_powersave_config_link(bridge);
|
|
|
|
|
2006-12-18 01:30:00 +00:00
|
|
|
err = pcibios_enable_device(dev, bars);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
pci_fixup_device(pci_fixup_enable, dev);
|
|
|
|
|
2014-03-07 23:06:05 +00:00
|
|
|
if (dev->msi_enabled || dev->msix_enabled)
|
|
|
|
return 0;
|
|
|
|
|
2014-01-29 23:13:51 +00:00
|
|
|
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
|
|
|
|
if (pin) {
|
|
|
|
pci_read_config_word(dev, PCI_COMMAND, &cmd);
|
|
|
|
if (cmd & PCI_COMMAND_INTX_DISABLE)
|
|
|
|
pci_write_config_word(dev, PCI_COMMAND,
|
|
|
|
cmd & ~PCI_COMMAND_INTX_DISABLE);
|
|
|
|
}
|
|
|
|
|
2006-12-18 01:30:00 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2007-07-27 05:43:35 +00:00
|
|
|
* pci_reenable_device - Resume abandoned device
|
2006-12-18 01:30:00 +00:00
|
|
|
* @dev: PCI device to be resumed
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* NOTE: This function is a backend of pci_default_resume() and is not supposed
|
|
|
|
* to be called by normal code, write proper resume handler and use it instead.
|
2006-12-18 01:30:00 +00:00
|
|
|
*/
|
2007-07-27 05:43:35 +00:00
|
|
|
int pci_reenable_device(struct pci_dev *dev)
|
2006-12-18 01:30:00 +00:00
|
|
|
{
|
2009-04-03 07:41:46 +00:00
|
|
|
if (pci_is_enabled(dev))
|
2006-12-18 01:30:00 +00:00
|
|
|
return do_pci_enable_device(dev, (1 << PCI_NUM_RESOURCES) - 1);
|
|
|
|
return 0;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_reenable_device);
|
2006-12-18 01:30:00 +00:00
|
|
|
|
2013-07-22 21:37:17 +00:00
|
|
|
static void pci_enable_bridge(struct pci_dev *dev)
|
|
|
|
{
|
2013-11-06 17:00:51 +00:00
|
|
|
struct pci_dev *bridge;
|
2013-07-22 21:37:17 +00:00
|
|
|
int retval;
|
|
|
|
|
2013-11-06 17:00:51 +00:00
|
|
|
bridge = pci_upstream_bridge(dev);
|
|
|
|
if (bridge)
|
|
|
|
pci_enable_bridge(bridge);
|
2013-07-22 21:37:17 +00:00
|
|
|
|
2013-11-05 20:34:38 +00:00
|
|
|
if (pci_is_enabled(dev)) {
|
2013-11-05 20:34:51 +00:00
|
|
|
if (!dev->is_busmaster)
|
2013-11-05 20:34:38 +00:00
|
|
|
pci_set_master(dev);
|
2017-09-15 06:33:51 +00:00
|
|
|
return;
|
2013-11-05 20:34:38 +00:00
|
|
|
}
|
|
|
|
|
2013-07-22 21:37:17 +00:00
|
|
|
retval = pci_enable_device(dev);
|
|
|
|
if (retval)
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "Error enabling bridge (%d), continuing\n",
|
2013-07-22 21:37:17 +00:00
|
|
|
retval);
|
|
|
|
pci_set_master(dev);
|
|
|
|
}
|
|
|
|
|
2013-01-04 19:12:55 +00:00
|
|
|
static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-11-06 17:00:51 +00:00
|
|
|
struct pci_dev *bridge;
|
2005-04-16 22:20:36 +00:00
|
|
|
int err;
|
2007-12-20 04:28:08 +00:00
|
|
|
int i, bars = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-11-05 19:16:36 +00:00
|
|
|
/*
|
|
|
|
* Power state could be unknown at this point, either due to a fresh
|
|
|
|
* boot or a device removal call. So get the current power state
|
|
|
|
* so that things like MSI message writing will behave as expected
|
|
|
|
* (e.g. if the device really is in D0 at enable time).
|
|
|
|
*/
|
|
|
|
if (dev->pm_cap) {
|
|
|
|
u16 pmcsr;
|
|
|
|
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
|
|
|
|
dev->current_state = (pmcsr & PCI_PM_CTRL_STATE_MASK);
|
|
|
|
}
|
|
|
|
|
2013-02-11 23:47:01 +00:00
|
|
|
if (atomic_inc_return(&dev->enable_cnt) > 1)
|
2006-12-18 01:28:43 +00:00
|
|
|
return 0; /* already enabled */
|
|
|
|
|
2013-11-06 17:00:51 +00:00
|
|
|
bridge = pci_upstream_bridge(dev);
|
2017-09-15 06:33:51 +00:00
|
|
|
if (bridge)
|
2013-11-06 17:00:51 +00:00
|
|
|
pci_enable_bridge(bridge);
|
2013-07-22 21:37:17 +00:00
|
|
|
|
2011-12-18 02:33:37 +00:00
|
|
|
/* only skip sriov related */
|
|
|
|
for (i = 0; i <= PCI_ROM_RESOURCE; i++)
|
|
|
|
if (dev->resource[i].flags & flags)
|
|
|
|
bars |= (1 << i);
|
|
|
|
for (i = PCI_BRIDGE_RESOURCES; i < DEVICE_COUNT_RESOURCE; i++)
|
2007-12-20 04:28:08 +00:00
|
|
|
if (dev->resource[i].flags & flags)
|
|
|
|
bars |= (1 << i);
|
|
|
|
|
2006-12-18 01:30:00 +00:00
|
|
|
err = do_pci_enable_device(dev, bars);
|
2005-07-28 18:37:33 +00:00
|
|
|
if (err < 0)
|
2006-12-18 01:30:00 +00:00
|
|
|
atomic_dec(&dev->enable_cnt);
|
2006-12-18 01:28:43 +00:00
|
|
|
return err;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2007-12-20 04:28:08 +00:00
|
|
|
/**
|
|
|
|
* pci_enable_device_io - Initialize a device for use with IO space
|
|
|
|
* @dev: PCI device to be initialized
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Initialize device before it's used by a driver. Ask low-level code
|
|
|
|
* to enable I/O resources. Wake up the device if it was suspended.
|
|
|
|
* Beware, this function can fail.
|
2007-12-20 04:28:08 +00:00
|
|
|
*/
|
|
|
|
int pci_enable_device_io(struct pci_dev *dev)
|
|
|
|
{
|
2013-01-04 19:12:55 +00:00
|
|
|
return pci_enable_device_flags(dev, IORESOURCE_IO);
|
2007-12-20 04:28:08 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_enable_device_io);
|
2007-12-20 04:28:08 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_enable_device_mem - Initialize a device for use with Memory space
|
|
|
|
* @dev: PCI device to be initialized
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Initialize device before it's used by a driver. Ask low-level code
|
|
|
|
* to enable Memory resources. Wake up the device if it was suspended.
|
|
|
|
* Beware, this function can fail.
|
2007-12-20 04:28:08 +00:00
|
|
|
*/
|
|
|
|
int pci_enable_device_mem(struct pci_dev *dev)
|
|
|
|
{
|
2013-01-04 19:12:55 +00:00
|
|
|
return pci_enable_device_flags(dev, IORESOURCE_MEM);
|
2007-12-20 04:28:08 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_enable_device_mem);
|
2007-12-20 04:28:08 +00:00
|
|
|
|
PCI: switch pci_{enable,disable}_device() to be nestable
Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().
The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm].
In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers.
However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:
1. driverA starts pci_enable_device()
2. driverB starts pci_enable_device()
3. driverA shutdown pci_disable_device()
4. driverB shutdown pci_disable_device()
between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.
By using this modification, the device won't be disabled until all the
callers to enable() have called disable().
This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.
We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-22 20:40:31 +00:00
|
|
|
/**
|
|
|
|
* pci_enable_device - Initialize device before it's used by a driver.
|
|
|
|
* @dev: PCI device to be initialized
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Initialize device before it's used by a driver. Ask low-level code
|
|
|
|
* to enable I/O and memory. Wake up the device if it was suspended.
|
|
|
|
* Beware, this function can fail.
|
PCI: switch pci_{enable,disable}_device() to be nestable
Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().
The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm].
In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers.
However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:
1. driverA starts pci_enable_device()
2. driverB starts pci_enable_device()
3. driverA shutdown pci_disable_device()
4. driverB shutdown pci_disable_device()
between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.
By using this modification, the device won't be disabled until all the
callers to enable() have called disable().
This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.
We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-22 20:40:31 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Note we don't actually enable the device many times if we call
|
|
|
|
* this function repeatedly (we just increment the count).
|
PCI: switch pci_{enable,disable}_device() to be nestable
Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().
The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm].
In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers.
However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:
1. driverA starts pci_enable_device()
2. driverB starts pci_enable_device()
3. driverA shutdown pci_disable_device()
4. driverB shutdown pci_disable_device()
between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.
By using this modification, the device won't be disabled until all the
callers to enable() have called disable().
This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.
We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-22 20:40:31 +00:00
|
|
|
*/
|
|
|
|
int pci_enable_device(struct pci_dev *dev)
|
|
|
|
{
|
2013-01-04 19:12:55 +00:00
|
|
|
return pci_enable_device_flags(dev, IORESOURCE_MEM | IORESOURCE_IO);
|
PCI: switch pci_{enable,disable}_device() to be nestable
Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().
The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm].
In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers.
However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:
1. driverA starts pci_enable_device()
2. driverB starts pci_enable_device()
3. driverA shutdown pci_disable_device()
4. driverB shutdown pci_disable_device()
between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.
By using this modification, the device won't be disabled until all the
callers to enable() have called disable().
This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.
We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-22 20:40:31 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_enable_device);
|
PCI: switch pci_{enable,disable}_device() to be nestable
Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().
The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm].
In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers.
However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:
1. driverA starts pci_enable_device()
2. driverB starts pci_enable_device()
3. driverA shutdown pci_disable_device()
4. driverB shutdown pci_disable_device()
between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.
By using this modification, the device won't be disabled until all the
callers to enable() have called disable().
This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.
We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-22 20:40:31 +00:00
|
|
|
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
/*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Managed PCI resources. This manages device on/off, INTx/MSI/MSI-X
|
|
|
|
* on/off and BAR regions. pci_dev itself records MSI/MSI-X status, so
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
* there's no need to track it separately. pci_devres is initialized
|
|
|
|
* when a device is enabled using managed PCI device enable interface.
|
|
|
|
*/
|
|
|
|
struct pci_devres {
|
2007-02-25 12:36:01 +00:00
|
|
|
unsigned int enabled:1;
|
|
|
|
unsigned int pinned:1;
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
unsigned int orig_intx:1;
|
|
|
|
unsigned int restore_intx:1;
|
2017-12-12 06:40:56 +00:00
|
|
|
unsigned int mwi:1;
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
u32 region_mask;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void pcim_release(struct device *gendev, void *res)
|
|
|
|
{
|
2016-01-08 18:05:39 +00:00
|
|
|
struct pci_dev *dev = to_pci_dev(gendev);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
struct pci_devres *this = res;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (dev->msi_enabled)
|
|
|
|
pci_disable_msi(dev);
|
|
|
|
if (dev->msix_enabled)
|
|
|
|
pci_disable_msix(dev);
|
|
|
|
|
|
|
|
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++)
|
|
|
|
if (this->region_mask & (1 << i))
|
|
|
|
pci_release_region(dev, i);
|
|
|
|
|
2017-12-12 06:40:56 +00:00
|
|
|
if (this->mwi)
|
|
|
|
pci_clear_mwi(dev);
|
|
|
|
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
if (this->restore_intx)
|
|
|
|
pci_intx(dev, this->orig_intx);
|
|
|
|
|
2007-02-25 12:36:01 +00:00
|
|
|
if (this->enabled && !this->pinned)
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
pci_disable_device(dev);
|
|
|
|
}
|
|
|
|
|
2014-04-11 05:01:53 +00:00
|
|
|
static struct pci_devres *get_pci_dr(struct pci_dev *pdev)
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
{
|
|
|
|
struct pci_devres *dr, *new_dr;
|
|
|
|
|
|
|
|
dr = devres_find(&pdev->dev, pcim_release, NULL, NULL);
|
|
|
|
if (dr)
|
|
|
|
return dr;
|
|
|
|
|
|
|
|
new_dr = devres_alloc(pcim_release, sizeof(*new_dr), GFP_KERNEL);
|
|
|
|
if (!new_dr)
|
|
|
|
return NULL;
|
|
|
|
return devres_get(&pdev->dev, new_dr, NULL, NULL);
|
|
|
|
}
|
|
|
|
|
2014-04-11 05:01:53 +00:00
|
|
|
static struct pci_devres *find_pci_dr(struct pci_dev *pdev)
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
{
|
|
|
|
if (pci_is_managed(pdev))
|
|
|
|
return devres_find(&pdev->dev, pcim_release, NULL, NULL);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pcim_enable_device - Managed pci_enable_device()
|
|
|
|
* @pdev: PCI device to be initialized
|
|
|
|
*
|
|
|
|
* Managed pci_enable_device().
|
|
|
|
*/
|
|
|
|
int pcim_enable_device(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
struct pci_devres *dr;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
dr = get_pci_dr(pdev);
|
|
|
|
if (unlikely(!dr))
|
|
|
|
return -ENOMEM;
|
2008-01-30 09:20:04 +00:00
|
|
|
if (dr->enabled)
|
|
|
|
return 0;
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
|
|
|
|
rc = pci_enable_device(pdev);
|
|
|
|
if (!rc) {
|
|
|
|
pdev->is_managed = 1;
|
2007-02-25 12:36:01 +00:00
|
|
|
dr->enabled = 1;
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
}
|
|
|
|
return rc;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pcim_enable_device);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pcim_pin_device - Pin managed PCI device
|
|
|
|
* @pdev: PCI device to pin
|
|
|
|
*
|
|
|
|
* Pin managed PCI device @pdev. Pinned device won't be disabled on
|
|
|
|
* driver detach. @pdev must have been enabled with
|
|
|
|
* pcim_enable_device().
|
|
|
|
*/
|
|
|
|
void pcim_pin_device(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
struct pci_devres *dr;
|
|
|
|
|
|
|
|
dr = find_pci_dr(pdev);
|
2007-02-25 12:36:01 +00:00
|
|
|
WARN_ON(!dr || !dr->enabled);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
if (dr)
|
2007-02-25 12:36:01 +00:00
|
|
|
dr->pinned = 1;
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pcim_pin_device);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
|
2012-12-05 21:33:27 +00:00
|
|
|
/*
|
|
|
|
* pcibios_add_device - provide arch specific hooks when adding device dev
|
|
|
|
* @dev: the PCI device being added
|
|
|
|
*
|
|
|
|
* Permits the platform to provide architecture specific functionality when
|
|
|
|
* devices are added. This is the default implementation. Architecture
|
|
|
|
* implementations can override this.
|
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
int __weak pcibios_add_device(struct pci_dev *dev)
|
2012-12-05 21:33:27 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-06-04 17:18:14 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pcibios_release_device - provide arch specific hooks when releasing
|
|
|
|
* device dev
|
2013-06-04 17:18:14 +00:00
|
|
|
* @dev: the PCI device being released
|
|
|
|
*
|
|
|
|
* Permits the platform to provide architecture specific functionality when
|
|
|
|
* devices are released. This is the default implementation. Architecture
|
|
|
|
* implementations can override this.
|
|
|
|
*/
|
|
|
|
void __weak pcibios_release_device(struct pci_dev *dev) {}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* pcibios_disable_device - disable arch specific PCI resources for device dev
|
|
|
|
* @dev: the PCI device to disable
|
|
|
|
*
|
|
|
|
* Disables architecture specific PCI resources for the device. This
|
|
|
|
* is the default implementation. Architecture implementations can
|
|
|
|
* override this.
|
|
|
|
*/
|
2015-12-27 21:21:11 +00:00
|
|
|
void __weak pcibios_disable_device(struct pci_dev *dev) {}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-05-06 03:29:52 +00:00
|
|
|
/**
|
|
|
|
* pcibios_penalize_isa_irq - penalize an ISA IRQ
|
|
|
|
* @irq: ISA IRQ to penalize
|
|
|
|
* @active: IRQ active or not
|
|
|
|
*
|
|
|
|
* Permits the platform to provide architecture-specific functionality when
|
|
|
|
* penalizing ISA IRQs. This is the default implementation. Architecture
|
|
|
|
* implementations can override this.
|
|
|
|
*/
|
|
|
|
void __weak pcibios_penalize_isa_irq(int irq, int active) {}
|
|
|
|
|
2009-01-07 12:03:42 +00:00
|
|
|
static void do_pci_disable_device(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
u16 pci_command;
|
|
|
|
|
|
|
|
pci_read_config_word(dev, PCI_COMMAND, &pci_command);
|
|
|
|
if (pci_command & PCI_COMMAND_MASTER) {
|
|
|
|
pci_command &= ~PCI_COMMAND_MASTER;
|
|
|
|
pci_write_config_word(dev, PCI_COMMAND, pci_command);
|
|
|
|
}
|
|
|
|
|
|
|
|
pcibios_disable_device(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_disable_enabled_device - Disable device without updating enable_cnt
|
|
|
|
* @dev: PCI device to disable
|
|
|
|
*
|
|
|
|
* NOTE: This function is a backend of PCI power management routines and is
|
|
|
|
* not supposed to be called drivers.
|
|
|
|
*/
|
|
|
|
void pci_disable_enabled_device(struct pci_dev *dev)
|
|
|
|
{
|
2009-04-03 07:41:46 +00:00
|
|
|
if (pci_is_enabled(dev))
|
2009-01-07 12:03:42 +00:00
|
|
|
do_pci_disable_device(dev);
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* pci_disable_device - Disable PCI device after use
|
|
|
|
* @dev: PCI device to be disabled
|
|
|
|
*
|
|
|
|
* Signal to the system that the PCI device is not in use by the system
|
|
|
|
* anymore. This only involves disabling PCI bus-mastering, if active.
|
PCI: switch pci_{enable,disable}_device() to be nestable
Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().
The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm].
In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers.
However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:
1. driverA starts pci_enable_device()
2. driverB starts pci_enable_device()
3. driverA shutdown pci_disable_device()
4. driverB shutdown pci_disable_device()
between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.
By using this modification, the device won't be disabled until all the
callers to enable() have called disable().
This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.
We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-22 20:40:31 +00:00
|
|
|
*
|
|
|
|
* Note we don't actually disable the device until all callers of
|
2010-05-18 12:45:47 +00:00
|
|
|
* pci_enable_device() have called pci_disable_device().
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
void pci_disable_device(struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
struct pci_devres *dr;
|
2006-05-26 02:58:27 +00:00
|
|
|
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
dr = find_pci_dr(dev);
|
|
|
|
if (dr)
|
2007-02-25 12:36:01 +00:00
|
|
|
dr->enabled = 0;
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
|
2013-02-04 11:56:01 +00:00
|
|
|
dev_WARN_ONCE(&dev->dev, atomic_read(&dev->enable_cnt) <= 0,
|
|
|
|
"disabling already-disabled device");
|
|
|
|
|
2013-02-11 23:47:01 +00:00
|
|
|
if (atomic_dec_return(&dev->enable_cnt) != 0)
|
PCI: switch pci_{enable,disable}_device() to be nestable
Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().
The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm].
In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers.
However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:
1. driverA starts pci_enable_device()
2. driverB starts pci_enable_device()
3. driverA shutdown pci_disable_device()
4. driverB shutdown pci_disable_device()
between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.
By using this modification, the device won't be disabled until all the
callers to enable() have called disable().
This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.
We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-22 20:40:31 +00:00
|
|
|
return;
|
|
|
|
|
2009-01-07 12:03:42 +00:00
|
|
|
do_pci_disable_device(dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-01-07 12:03:42 +00:00
|
|
|
dev->is_busmaster = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_disable_device);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-04-06 21:39:36 +00:00
|
|
|
/**
|
|
|
|
* pcibios_set_pcie_reset_state - set reset state for device dev
|
2009-12-03 11:49:24 +00:00
|
|
|
* @dev: the PCIe device reset
|
2007-04-06 21:39:36 +00:00
|
|
|
* @state: Reset state to enter into
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Set the PCIe reset state for the device. This is the default
|
2007-04-06 21:39:36 +00:00
|
|
|
* implementation. Architecture implementations can override this.
|
|
|
|
*/
|
2012-06-19 12:54:49 +00:00
|
|
|
int __weak pcibios_set_pcie_reset_state(struct pci_dev *dev,
|
|
|
|
enum pcie_reset_state state)
|
2007-04-06 21:39:36 +00:00
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_set_pcie_reset_state - set reset state for device dev
|
2009-12-03 11:49:24 +00:00
|
|
|
* @dev: the PCIe device reset
|
2007-04-06 21:39:36 +00:00
|
|
|
* @state: Reset state to enter into
|
|
|
|
*
|
|
|
|
* Sets the PCI reset state for the device.
|
|
|
|
*/
|
|
|
|
int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state)
|
|
|
|
{
|
|
|
|
return pcibios_set_pcie_reset_state(dev, state);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_set_pcie_reset_state);
|
2007-04-06 21:39:36 +00:00
|
|
|
|
2018-03-09 17:06:53 +00:00
|
|
|
/**
|
|
|
|
* pcie_clear_root_pme_status - Clear root port PME interrupt status.
|
|
|
|
* @dev: PCIe root port or event collector.
|
|
|
|
*/
|
|
|
|
void pcie_clear_root_pme_status(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
pcie_capability_set_dword(dev, PCI_EXP_RTSTA, PCI_EXP_RTSTA_PME);
|
|
|
|
}
|
|
|
|
|
2010-02-17 22:36:58 +00:00
|
|
|
/**
|
|
|
|
* pci_check_pme_status - Check if given device has generated PME.
|
|
|
|
* @dev: Device to check.
|
|
|
|
*
|
|
|
|
* Check the PME status of the device and if set, clear it and clear PME enable
|
|
|
|
* (if set). Return 'true' if PME status and PME enable were both set or
|
|
|
|
* 'false' otherwise.
|
|
|
|
*/
|
|
|
|
bool pci_check_pme_status(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int pmcsr_pos;
|
|
|
|
u16 pmcsr;
|
|
|
|
bool ret = false;
|
|
|
|
|
|
|
|
if (!dev->pm_cap)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
pmcsr_pos = dev->pm_cap + PCI_PM_CTRL;
|
|
|
|
pci_read_config_word(dev, pmcsr_pos, &pmcsr);
|
|
|
|
if (!(pmcsr & PCI_PM_CTRL_PME_STATUS))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Clear PME status. */
|
|
|
|
pmcsr |= PCI_PM_CTRL_PME_STATUS;
|
|
|
|
if (pmcsr & PCI_PM_CTRL_PME_ENABLE) {
|
|
|
|
/* Disable PME to avoid interrupt flood. */
|
|
|
|
pmcsr &= ~PCI_PM_CTRL_PME_ENABLE;
|
|
|
|
ret = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
pci_write_config_word(dev, pmcsr_pos, pmcsr);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-02-17 22:44:09 +00:00
|
|
|
/**
|
|
|
|
* pci_pme_wakeup - Wake up a PCI device if its PME Status bit is set.
|
|
|
|
* @dev: Device to handle.
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
* @pme_poll_reset: Whether or not to reset the device's pme_poll flag.
|
2010-02-17 22:44:09 +00:00
|
|
|
*
|
|
|
|
* Check if @dev has generated PME and queue a resume request for it in that
|
|
|
|
* case.
|
|
|
|
*/
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
static int pci_pme_wakeup(struct pci_dev *dev, void *pme_poll_reset)
|
2010-02-17 22:44:09 +00:00
|
|
|
{
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
if (pme_poll_reset && dev->pme_poll)
|
|
|
|
dev->pme_poll = false;
|
|
|
|
|
PM: Make it possible to avoid races between wakeup and system sleep
One of the arguments during the suspend blockers discussion was that
the mainline kernel didn't contain any mechanisms making it possible
to avoid races between wakeup and system suspend.
Generally, there are two problems in that area. First, if a wakeup
event occurs exactly when /sys/power/state is being written to, it
may be delivered to user space right before the freezer kicks in, so
the user space consumer of the event may not be able to process it
before the system is suspended. Second, if a wakeup event occurs
after user space has been frozen, it is not generally guaranteed that
the ongoing transition of the system into a sleep state will be
aborted.
To address these issues introduce a new global sysfs attribute,
/sys/power/wakeup_count, associated with a running counter of wakeup
events and three helper functions, pm_stay_awake(), pm_relax(), and
pm_wakeup_event(), that may be used by kernel subsystems to control
the behavior of this attribute and to request the PM core to abort
system transitions into a sleep state already in progress.
The /sys/power/wakeup_count file may be read from or written to by
user space. Reads will always succeed (unless interrupted by a
signal) and return the current value of the wakeup events counter.
Writes, however, will only succeed if the written number is equal to
the current value of the wakeup events counter. If a write is
successful, it will cause the kernel to save the current value of the
wakeup events counter and to abort the subsequent system transition
into a sleep state if any wakeup events are reported after the write
has returned.
[The assumption is that before writing to /sys/power/state user space
will first read from /sys/power/wakeup_count. Next, user space
consumers of wakeup events will have a chance to acknowledge or
veto the upcoming system transition to a sleep state. Finally, if
the transition is allowed to proceed, /sys/power/wakeup_count will
be written to and if that succeeds, /sys/power/state will be written
to as well. Still, if any wakeup events are reported to the PM core
by kernel subsystems after that point, the transition will be
aborted.]
Additionally, put a wakeup events counter into struct dev_pm_info and
make these per-device wakeup event counters available via sysfs,
so that it's possible to check the activity of various wakeup event
sources within the kernel.
To illustrate how subsystems can use pm_wakeup_event(), make the
low-level PCI runtime PM wakeup-handling code use it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: markgross <markgross@thegnar.org>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
2010-07-05 20:43:53 +00:00
|
|
|
if (pci_check_pme_status(dev)) {
|
|
|
|
pci_wakeup_event(dev);
|
2010-12-29 12:22:08 +00:00
|
|
|
pm_request_resume(&dev->dev);
|
PM: Make it possible to avoid races between wakeup and system sleep
One of the arguments during the suspend blockers discussion was that
the mainline kernel didn't contain any mechanisms making it possible
to avoid races between wakeup and system suspend.
Generally, there are two problems in that area. First, if a wakeup
event occurs exactly when /sys/power/state is being written to, it
may be delivered to user space right before the freezer kicks in, so
the user space consumer of the event may not be able to process it
before the system is suspended. Second, if a wakeup event occurs
after user space has been frozen, it is not generally guaranteed that
the ongoing transition of the system into a sleep state will be
aborted.
To address these issues introduce a new global sysfs attribute,
/sys/power/wakeup_count, associated with a running counter of wakeup
events and three helper functions, pm_stay_awake(), pm_relax(), and
pm_wakeup_event(), that may be used by kernel subsystems to control
the behavior of this attribute and to request the PM core to abort
system transitions into a sleep state already in progress.
The /sys/power/wakeup_count file may be read from or written to by
user space. Reads will always succeed (unless interrupted by a
signal) and return the current value of the wakeup events counter.
Writes, however, will only succeed if the written number is equal to
the current value of the wakeup events counter. If a write is
successful, it will cause the kernel to save the current value of the
wakeup events counter and to abort the subsequent system transition
into a sleep state if any wakeup events are reported after the write
has returned.
[The assumption is that before writing to /sys/power/state user space
will first read from /sys/power/wakeup_count. Next, user space
consumers of wakeup events will have a chance to acknowledge or
veto the upcoming system transition to a sleep state. Finally, if
the transition is allowed to proceed, /sys/power/wakeup_count will
be written to and if that succeeds, /sys/power/state will be written
to as well. Still, if any wakeup events are reported to the PM core
by kernel subsystems after that point, the transition will be
aborted.]
Additionally, put a wakeup events counter into struct dev_pm_info and
make these per-device wakeup event counters available via sysfs,
so that it's possible to check the activity of various wakeup event
sources within the kernel.
To illustrate how subsystems can use pm_wakeup_event(), make the
low-level PCI runtime PM wakeup-handling code use it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: markgross <markgross@thegnar.org>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
2010-07-05 20:43:53 +00:00
|
|
|
}
|
2010-02-17 22:44:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_pme_wakeup_bus - Walk given bus and wake up devices on it, if necessary.
|
|
|
|
* @bus: Top bus of the subtree to walk.
|
|
|
|
*/
|
|
|
|
void pci_pme_wakeup_bus(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
if (bus)
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
pci_walk_bus(bus, pci_pme_wakeup, (void *)true);
|
2010-02-17 22:44:09 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2008-07-07 01:34:48 +00:00
|
|
|
/**
|
|
|
|
* pci_pme_capable - check the capability of PCI device to generate PME#
|
|
|
|
* @dev: PCI device to handle.
|
|
|
|
* @state: PCI state from which device will issue PME#.
|
|
|
|
*/
|
2008-07-19 12:39:24 +00:00
|
|
|
bool pci_pme_capable(struct pci_dev *dev, pci_power_t state)
|
2008-07-07 01:34:48 +00:00
|
|
|
{
|
2008-07-07 01:36:24 +00:00
|
|
|
if (!dev->pm_cap)
|
2008-07-07 01:34:48 +00:00
|
|
|
return false;
|
|
|
|
|
2008-07-07 01:36:24 +00:00
|
|
|
return !!(dev->pme_support & (1 << state));
|
2008-07-07 01:34:48 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_pme_capable);
|
2008-07-07 01:34:48 +00:00
|
|
|
|
2010-10-04 18:22:29 +00:00
|
|
|
static void pci_pme_list_scan(struct work_struct *work)
|
|
|
|
{
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
struct pci_pme_device *pme_dev, *n;
|
2010-10-04 18:22:29 +00:00
|
|
|
|
|
|
|
mutex_lock(&pci_pme_list_mutex);
|
2014-01-24 16:51:06 +00:00
|
|
|
list_for_each_entry_safe(pme_dev, n, &pci_pme_list, list) {
|
|
|
|
if (pme_dev->dev->pme_poll) {
|
|
|
|
struct pci_dev *bridge;
|
|
|
|
|
|
|
|
bridge = pme_dev->dev->bus->self;
|
|
|
|
/*
|
|
|
|
* If bridge is in low power state, the
|
|
|
|
* configuration space of subordinate devices
|
|
|
|
* may be not accessible
|
|
|
|
*/
|
|
|
|
if (bridge && bridge->current_state != PCI_D0)
|
|
|
|
continue;
|
2019-06-12 10:57:39 +00:00
|
|
|
/*
|
|
|
|
* If the device is in D3cold it should not be
|
|
|
|
* polled either.
|
|
|
|
*/
|
|
|
|
if (pme_dev->dev->current_state == PCI_D3cold)
|
|
|
|
continue;
|
|
|
|
|
2014-01-24 16:51:06 +00:00
|
|
|
pci_pme_wakeup(pme_dev->dev, NULL);
|
|
|
|
} else {
|
|
|
|
list_del(&pme_dev->list);
|
|
|
|
kfree(pme_dev);
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
}
|
2010-10-04 18:22:29 +00:00
|
|
|
}
|
2014-01-24 16:51:06 +00:00
|
|
|
if (!list_empty(&pci_pme_list))
|
2017-04-18 18:44:30 +00:00
|
|
|
queue_delayed_work(system_freezable_wq, &pci_pme_work,
|
|
|
|
msecs_to_jiffies(PME_TIMEOUT));
|
2010-10-04 18:22:29 +00:00
|
|
|
mutex_unlock(&pci_pme_list_mutex);
|
|
|
|
}
|
|
|
|
|
2015-09-29 23:10:24 +00:00
|
|
|
static void __pci_pme_active(struct pci_dev *dev, bool enable)
|
2008-07-07 01:34:48 +00:00
|
|
|
{
|
|
|
|
u16 pmcsr;
|
|
|
|
|
2013-04-10 10:32:51 +00:00
|
|
|
if (!dev->pme_support)
|
2008-07-07 01:34:48 +00:00
|
|
|
return;
|
|
|
|
|
2008-07-07 01:36:24 +00:00
|
|
|
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
|
2008-07-07 01:34:48 +00:00
|
|
|
/* Clear PME_Status by writing 1 to it and enable PME# */
|
|
|
|
pmcsr |= PCI_PM_CTRL_PME_STATUS | PCI_PM_CTRL_PME_ENABLE;
|
|
|
|
if (!enable)
|
|
|
|
pmcsr &= ~PCI_PM_CTRL_PME_ENABLE;
|
|
|
|
|
2008-07-07 01:36:24 +00:00
|
|
|
pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr);
|
2015-09-29 23:10:24 +00:00
|
|
|
}
|
|
|
|
|
2017-07-12 01:05:39 +00:00
|
|
|
/**
|
|
|
|
* pci_pme_restore - Restore PME configuration after config space restore.
|
|
|
|
* @dev: PCI device to update.
|
|
|
|
*/
|
|
|
|
void pci_pme_restore(struct pci_dev *dev)
|
2017-06-12 20:53:36 +00:00
|
|
|
{
|
|
|
|
u16 pmcsr;
|
|
|
|
|
|
|
|
if (!dev->pme_support)
|
|
|
|
return;
|
|
|
|
|
|
|
|
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
|
|
|
|
if (dev->wakeup_prepared) {
|
|
|
|
pmcsr |= PCI_PM_CTRL_PME_ENABLE;
|
2017-07-12 01:05:39 +00:00
|
|
|
pmcsr &= ~PCI_PM_CTRL_PME_STATUS;
|
2017-06-12 20:53:36 +00:00
|
|
|
} else {
|
|
|
|
pmcsr &= ~PCI_PM_CTRL_PME_ENABLE;
|
|
|
|
pmcsr |= PCI_PM_CTRL_PME_STATUS;
|
|
|
|
}
|
|
|
|
pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr);
|
|
|
|
}
|
|
|
|
|
2015-09-29 23:10:24 +00:00
|
|
|
/**
|
|
|
|
* pci_pme_active - enable or disable PCI device's PME# function
|
|
|
|
* @dev: PCI device to handle.
|
|
|
|
* @enable: 'true' to enable PME# generation; 'false' to disable it.
|
|
|
|
*
|
|
|
|
* The caller must verify that the device is capable of generating PME# before
|
|
|
|
* calling this function with @enable equal to 'true'.
|
|
|
|
*/
|
|
|
|
void pci_pme_active(struct pci_dev *dev, bool enable)
|
|
|
|
{
|
|
|
|
__pci_pme_active(dev, enable);
|
2008-07-07 01:34:48 +00:00
|
|
|
|
2012-10-26 05:07:51 +00:00
|
|
|
/*
|
|
|
|
* PCI (as opposed to PCIe) PME requires that the device have
|
|
|
|
* its PME# line hooked up correctly. Not all hardware vendors
|
|
|
|
* do this, so the PME never gets delivered and the device
|
|
|
|
* remains asleep. The easiest way around this is to
|
|
|
|
* periodically walk the list of suspended devices and check
|
|
|
|
* whether any have their PME flag set. The assumption is that
|
|
|
|
* we'll wake up often enough anyway that this won't be a huge
|
|
|
|
* hit, and the power savings from the devices will still be a
|
|
|
|
* win.
|
|
|
|
*
|
|
|
|
* Although PCIe uses in-band PME message instead of PME# line
|
|
|
|
* to report PME, PME does not work for some PCIe devices in
|
|
|
|
* reality. For example, there are devices that set their PME
|
|
|
|
* status bits, but don't really bother to send a PME message;
|
|
|
|
* there are PCI Express Root Ports that don't bother to
|
|
|
|
* trigger interrupts when they receive PME messages from the
|
|
|
|
* devices below. So PME poll is used for PCIe devices too.
|
|
|
|
*/
|
2010-10-04 18:22:29 +00:00
|
|
|
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
if (dev->pme_poll) {
|
2010-10-04 18:22:29 +00:00
|
|
|
struct pci_pme_device *pme_dev;
|
|
|
|
if (enable) {
|
|
|
|
pme_dev = kmalloc(sizeof(struct pci_pme_device),
|
|
|
|
GFP_KERNEL);
|
2013-10-16 18:32:53 +00:00
|
|
|
if (!pme_dev) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_warn(dev, "can't enable PME#\n");
|
2013-10-16 18:32:53 +00:00
|
|
|
return;
|
|
|
|
}
|
2010-10-04 18:22:29 +00:00
|
|
|
pme_dev->dev = dev;
|
|
|
|
mutex_lock(&pci_pme_list_mutex);
|
|
|
|
list_add(&pme_dev->list, &pci_pme_list);
|
|
|
|
if (list_is_singular(&pci_pme_list))
|
2017-04-18 18:44:30 +00:00
|
|
|
queue_delayed_work(system_freezable_wq,
|
|
|
|
&pci_pme_work,
|
|
|
|
msecs_to_jiffies(PME_TIMEOUT));
|
2010-10-04 18:22:29 +00:00
|
|
|
mutex_unlock(&pci_pme_list_mutex);
|
|
|
|
} else {
|
|
|
|
mutex_lock(&pci_pme_list_mutex);
|
|
|
|
list_for_each_entry(pme_dev, &pci_pme_list, list) {
|
|
|
|
if (pme_dev->dev == dev) {
|
|
|
|
list_del(&pme_dev->list);
|
|
|
|
kfree(pme_dev);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mutex_unlock(&pci_pme_list_mutex);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_dbg(dev, "PME# %s\n", enable ? "enabled" : "disabled");
|
2008-07-07 01:34:48 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_pme_active);
|
2008-07-07 01:34:48 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2018-05-08 22:18:32 +00:00
|
|
|
* __pci_enable_wake - enable PCI device as wakeup event source
|
2007-04-26 07:12:06 +00:00
|
|
|
* @dev: PCI device affected
|
|
|
|
* @state: PCI state from which device will issue wakeup events
|
|
|
|
* @enable: True to enable event generation; false to disable
|
|
|
|
*
|
|
|
|
* This enables the device as a wakeup event source, or disables it.
|
|
|
|
* When such events involves platform-specific hooks, those hooks are
|
|
|
|
* called automatically by this routine.
|
|
|
|
*
|
|
|
|
* Devices with legacy power management (no standard PCI PM capabilities)
|
2008-07-07 01:34:48 +00:00
|
|
|
* always require such platform hooks.
|
2007-04-26 07:12:06 +00:00
|
|
|
*
|
2008-07-07 01:34:48 +00:00
|
|
|
* RETURN VALUE:
|
|
|
|
* 0 is returned on success
|
|
|
|
* -EINVAL is returned if device is not supposed to wake up the system
|
|
|
|
* Error code depending on the platform is returned if both the platform and
|
|
|
|
* the native mechanism fail to enable the generation of wake-up events
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2018-05-08 22:18:32 +00:00
|
|
|
static int __pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-09-08 21:12:59 +00:00
|
|
|
int ret = 0;
|
2007-04-26 07:12:06 +00:00
|
|
|
|
2017-07-21 12:38:08 +00:00
|
|
|
/*
|
2018-09-27 21:53:53 +00:00
|
|
|
* Bridges that are not power-manageable directly only signal
|
|
|
|
* wakeup on behalf of subordinate devices which is set up
|
|
|
|
* elsewhere, so skip them. However, bridges that are
|
|
|
|
* power-manageable may signal wakeup for themselves (for example,
|
|
|
|
* on a hotplug event) and they need to be covered here.
|
2017-07-21 12:38:08 +00:00
|
|
|
*/
|
2018-09-27 21:53:53 +00:00
|
|
|
if (!pci_power_manageable(dev))
|
2017-07-21 12:38:08 +00:00
|
|
|
return 0;
|
|
|
|
|
2017-07-12 01:05:39 +00:00
|
|
|
/* Don't do the same thing twice in a row for one device. */
|
|
|
|
if (!!enable == !!dev->wakeup_prepared)
|
2009-09-08 21:14:49 +00:00
|
|
|
return 0;
|
|
|
|
|
2008-07-07 01:34:48 +00:00
|
|
|
/*
|
|
|
|
* According to "PCI System Architecture" 4th ed. by Tom Shanley & Don
|
|
|
|
* Anderson we should be doing PME# wake enable followed by ACPI wake
|
|
|
|
* enable. To disable wake-up we call the platform first, for symmetry.
|
2007-04-26 07:12:06 +00:00
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-09-08 21:12:59 +00:00
|
|
|
if (enable) {
|
|
|
|
int error;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-09-08 21:12:59 +00:00
|
|
|
if (pci_pme_capable(dev, state))
|
|
|
|
pci_pme_active(dev, true);
|
|
|
|
else
|
|
|
|
ret = 1;
|
2017-06-23 23:57:35 +00:00
|
|
|
error = platform_pci_set_wakeup(dev, true);
|
2009-09-08 21:12:59 +00:00
|
|
|
if (ret)
|
|
|
|
ret = error;
|
2009-09-08 21:14:49 +00:00
|
|
|
if (!ret)
|
|
|
|
dev->wakeup_prepared = true;
|
2009-09-08 21:12:59 +00:00
|
|
|
} else {
|
2017-06-23 23:57:35 +00:00
|
|
|
platform_pci_set_wakeup(dev, false);
|
2009-09-08 21:12:59 +00:00
|
|
|
pci_pme_active(dev, false);
|
2009-09-08 21:14:49 +00:00
|
|
|
dev->wakeup_prepared = false;
|
2009-09-08 21:12:59 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-09-08 21:12:59 +00:00
|
|
|
return ret;
|
2008-07-07 01:34:48 +00:00
|
|
|
}
|
2018-05-08 22:18:32 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_enable_wake - change wakeup settings for a PCI device
|
|
|
|
* @pci_dev: Target device
|
|
|
|
* @state: PCI state from which device will issue wakeup events
|
|
|
|
* @enable: Whether or not to enable event generation
|
|
|
|
*
|
|
|
|
* If @enable is set, check device_may_wakeup() for the device before calling
|
|
|
|
* __pci_enable_wake() for it.
|
|
|
|
*/
|
|
|
|
int pci_enable_wake(struct pci_dev *pci_dev, pci_power_t state, bool enable)
|
|
|
|
{
|
|
|
|
if (enable && !device_may_wakeup(&pci_dev->dev))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return __pci_enable_wake(pci_dev, state, enable);
|
|
|
|
}
|
2017-06-23 23:57:35 +00:00
|
|
|
EXPORT_SYMBOL(pci_enable_wake);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-08-18 19:38:00 +00:00
|
|
|
/**
|
|
|
|
* pci_wake_from_d3 - enable/disable device to wake up from D3_hot or D3_cold
|
|
|
|
* @dev: PCI device to prepare
|
|
|
|
* @enable: True to enable wake-up event generation; false to disable
|
|
|
|
*
|
|
|
|
* Many drivers want the device to wake up the system from D3_hot or D3_cold
|
|
|
|
* and this function allows them to set that up cleanly - pci_enable_wake()
|
|
|
|
* should not be called twice in a row to enable wake-up due to PCI PM vs ACPI
|
|
|
|
* ordering constraints.
|
|
|
|
*
|
2018-05-08 22:18:32 +00:00
|
|
|
* This function only returns error code if the device is not allowed to wake
|
|
|
|
* up the system from sleep or it is not capable of generating PME# from both
|
|
|
|
* D3_hot and D3_cold and the platform is unable to enable wake-up power for it.
|
2008-08-18 19:38:00 +00:00
|
|
|
*/
|
|
|
|
int pci_wake_from_d3(struct pci_dev *dev, bool enable)
|
|
|
|
{
|
|
|
|
return pci_pme_capable(dev, PCI_D3cold) ?
|
|
|
|
pci_enable_wake(dev, PCI_D3cold, enable) :
|
|
|
|
pci_enable_wake(dev, PCI_D3hot, enable);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_wake_from_d3);
|
2008-08-18 19:38:00 +00:00
|
|
|
|
2008-07-07 01:35:26 +00:00
|
|
|
/**
|
2008-07-28 18:49:26 +00:00
|
|
|
* pci_target_state - find an appropriate low power state for a given PCI dev
|
|
|
|
* @dev: PCI device
|
2017-06-23 12:58:11 +00:00
|
|
|
* @wakeup: Whether or not wakeup functionality will be enabled for the device.
|
2008-07-28 18:49:26 +00:00
|
|
|
*
|
|
|
|
* Use underlying platform code to find a supported low power state for @dev.
|
|
|
|
* If the platform can't manage @dev, return the deepest state from which it
|
|
|
|
* can generate wake events, based on any available PME info.
|
2008-07-07 01:35:26 +00:00
|
|
|
*/
|
2017-06-23 12:58:11 +00:00
|
|
|
static pci_power_t pci_target_state(struct pci_dev *dev, bool wakeup)
|
2008-07-07 01:35:26 +00:00
|
|
|
{
|
|
|
|
pci_power_t target_state = PCI_D3hot;
|
|
|
|
|
|
|
|
if (platform_pci_power_manageable(dev)) {
|
|
|
|
/*
|
2018-05-21 11:11:12 +00:00
|
|
|
* Call the platform to find the target state for the device.
|
2008-07-07 01:35:26 +00:00
|
|
|
*/
|
|
|
|
pci_power_t state = platform_pci_choose_state(dev);
|
|
|
|
|
|
|
|
switch (state) {
|
|
|
|
case PCI_POWER_ERROR:
|
|
|
|
case PCI_UNKNOWN:
|
|
|
|
break;
|
|
|
|
case PCI_D1:
|
|
|
|
case PCI_D2:
|
|
|
|
if (pci_no_d1d2(dev))
|
|
|
|
break;
|
2019-01-14 20:41:36 +00:00
|
|
|
/* else, fall through */
|
2008-07-07 01:35:26 +00:00
|
|
|
default:
|
|
|
|
target_state = state;
|
|
|
|
}
|
2016-09-18 03:39:20 +00:00
|
|
|
|
|
|
|
return target_state;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!dev->pm_cap)
|
2009-06-14 19:25:02 +00:00
|
|
|
target_state = PCI_D0;
|
2016-09-18 03:39:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the device is in D3cold even though it's not power-manageable by
|
|
|
|
* the platform, it may have been powered down by non-standard means.
|
|
|
|
* Best to let it slumber.
|
|
|
|
*/
|
|
|
|
if (dev->current_state == PCI_D3cold)
|
|
|
|
target_state = PCI_D3cold;
|
|
|
|
|
2017-06-23 12:58:11 +00:00
|
|
|
if (wakeup) {
|
2008-07-07 01:35:26 +00:00
|
|
|
/*
|
|
|
|
* Find the deepest state from which the device can generate
|
2018-05-21 11:11:12 +00:00
|
|
|
* PME#.
|
2008-07-07 01:35:26 +00:00
|
|
|
*/
|
2008-07-07 01:36:24 +00:00
|
|
|
if (dev->pme_support) {
|
|
|
|
while (target_state
|
|
|
|
&& !(dev->pme_support & (1 << target_state)))
|
|
|
|
target_state--;
|
2008-07-07 01:35:26 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-07-19 12:39:24 +00:00
|
|
|
return target_state;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_prepare_to_sleep - prepare PCI device for system-wide transition
|
|
|
|
* into a sleep state
|
2008-07-19 12:39:24 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
*
|
|
|
|
* Choose the power state appropriate for the device depending on whether
|
|
|
|
* it can wake up the system and/or is power manageable by the platform
|
|
|
|
* (PCI_D3hot is the default) and put the device into that state.
|
|
|
|
*/
|
|
|
|
int pci_prepare_to_sleep(struct pci_dev *dev)
|
|
|
|
{
|
2017-06-23 12:58:11 +00:00
|
|
|
bool wakeup = device_may_wakeup(&dev->dev);
|
|
|
|
pci_power_t target_state = pci_target_state(dev, wakeup);
|
2008-07-19 12:39:24 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
if (target_state == PCI_POWER_ERROR)
|
|
|
|
return -EIO;
|
|
|
|
|
2017-06-23 12:58:11 +00:00
|
|
|
pci_enable_wake(dev, target_state, wakeup);
|
2008-07-13 20:45:06 +00:00
|
|
|
|
2008-07-07 01:35:26 +00:00
|
|
|
error = pci_set_power_state(dev, target_state);
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
pci_enable_wake(dev, target_state, false);
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_prepare_to_sleep);
|
2008-07-07 01:35:26 +00:00
|
|
|
|
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_back_from_sleep - turn PCI device on during system-wide transition
|
|
|
|
* into working state
|
2008-07-07 01:35:26 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
*
|
2010-03-16 10:47:56 +00:00
|
|
|
* Disable device's system wake-up capability and put it into D0.
|
2008-07-07 01:35:26 +00:00
|
|
|
*/
|
|
|
|
int pci_back_from_sleep(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
pci_enable_wake(dev, PCI_D0, false);
|
|
|
|
return pci_set_power_state(dev, PCI_D0);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_back_from_sleep);
|
2008-07-07 01:35:26 +00:00
|
|
|
|
2010-02-17 22:44:58 +00:00
|
|
|
/**
|
|
|
|
* pci_finish_runtime_suspend - Carry out PCI-specific part of runtime suspend.
|
|
|
|
* @dev: PCI device being suspended.
|
|
|
|
*
|
|
|
|
* Prepare @dev to generate wake-up events at run time and put it into a low
|
|
|
|
* power state.
|
|
|
|
*/
|
|
|
|
int pci_finish_runtime_suspend(struct pci_dev *dev)
|
|
|
|
{
|
2017-06-23 12:58:11 +00:00
|
|
|
pci_power_t target_state;
|
2010-02-17 22:44:58 +00:00
|
|
|
int error;
|
|
|
|
|
2017-06-23 12:58:11 +00:00
|
|
|
target_state = pci_target_state(dev, device_can_wakeup(&dev->dev));
|
2010-02-17 22:44:58 +00:00
|
|
|
if (target_state == PCI_POWER_ERROR)
|
|
|
|
return -EIO;
|
|
|
|
|
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
|
|
|
dev->runtime_d3cold = target_state == PCI_D3cold;
|
|
|
|
|
2018-05-08 22:18:32 +00:00
|
|
|
__pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
|
2010-02-17 22:44:58 +00:00
|
|
|
|
|
|
|
error = pci_set_power_state(dev, target_state);
|
|
|
|
|
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 (error) {
|
2017-06-23 23:57:35 +00:00
|
|
|
pci_enable_wake(dev, target_state, 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
|
|
|
dev->runtime_d3cold = false;
|
|
|
|
}
|
2010-02-17 22:44:58 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2010-02-17 22:44:09 +00:00
|
|
|
/**
|
|
|
|
* pci_dev_run_wake - Check if device can generate run-time wake-up events.
|
|
|
|
* @dev: Device to check.
|
|
|
|
*
|
2013-11-14 18:28:18 +00:00
|
|
|
* Return true if the device itself is capable of generating wake-up events
|
2010-02-17 22:44:09 +00:00
|
|
|
* (through the platform or using the native PCIe PME) or if the device supports
|
|
|
|
* PME and one of its upstream bridges can generate wake-up events.
|
|
|
|
*/
|
|
|
|
bool pci_dev_run_wake(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
struct pci_bus *bus = dev->bus;
|
|
|
|
|
|
|
|
if (!dev->pme_support)
|
|
|
|
return false;
|
|
|
|
|
2017-06-23 12:58:11 +00:00
|
|
|
/* PME-capable in principle, but not from the target power state */
|
PCI / PM: Always check PME wakeup capability for runtime wakeup support
USB controller ASM1042 stops working after commit de3ef1eb1cd0 (PM /
core: Drop run_wake flag from struct dev_pm_info).
The device in question is not power managed by platform firmware,
furthermore, it only supports PME# from D3cold:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Before commit de3ef1eb1cd0, the device never gets runtime suspended.
After that commit, the device gets runtime suspended to D3hot, which can
not generate any PME#.
usb_hcd_pci_probe() unconditionally calls device_wakeup_enable(), hence
device_can_wakeup() in pci_dev_run_wake() always returns true.
So pci_dev_run_wake() needs to check PME wakeup capability as its first
condition.
In addition, change wakeup flag passed to pci_target_state() from false
to true, because we want to find the deepest state different from D3cold
that the device can still generate PME#. In this case, it's D0 for the
device in question.
Fixes: de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-07 06:11:20 +00:00
|
|
|
if (!pci_pme_capable(dev, pci_target_state(dev, true)))
|
2016-10-21 20:45:38 +00:00
|
|
|
return false;
|
|
|
|
|
PCI / PM: Always check PME wakeup capability for runtime wakeup support
USB controller ASM1042 stops working after commit de3ef1eb1cd0 (PM /
core: Drop run_wake flag from struct dev_pm_info).
The device in question is not power managed by platform firmware,
furthermore, it only supports PME# from D3cold:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Before commit de3ef1eb1cd0, the device never gets runtime suspended.
After that commit, the device gets runtime suspended to D3hot, which can
not generate any PME#.
usb_hcd_pci_probe() unconditionally calls device_wakeup_enable(), hence
device_can_wakeup() in pci_dev_run_wake() always returns true.
So pci_dev_run_wake() needs to check PME wakeup capability as its first
condition.
In addition, change wakeup flag passed to pci_target_state() from false
to true, because we want to find the deepest state different from D3cold
that the device can still generate PME#. In this case, it's D0 for the
device in question.
Fixes: de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-07 06:11:20 +00:00
|
|
|
if (device_can_wakeup(&dev->dev))
|
|
|
|
return true;
|
|
|
|
|
2010-02-17 22:44:09 +00:00
|
|
|
while (bus->parent) {
|
|
|
|
struct pci_dev *bridge = bus->self;
|
|
|
|
|
2017-06-23 23:58:53 +00:00
|
|
|
if (device_can_wakeup(&bridge->dev))
|
2010-02-17 22:44:09 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
bus = bus->parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We have reached the root bus. */
|
|
|
|
if (bus->bridge)
|
2017-06-23 23:58:53 +00:00
|
|
|
return device_can_wakeup(bus->bridge);
|
2010-02-17 22:44:09 +00:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_dev_run_wake);
|
|
|
|
|
2015-01-21 01:17:42 +00:00
|
|
|
/**
|
2019-06-06 22:32:31 +00:00
|
|
|
* pci_dev_need_resume - Check if it is necessary to resume the device.
|
2015-01-21 01:17:42 +00:00
|
|
|
* @pci_dev: Device to check.
|
|
|
|
*
|
2019-06-06 22:32:31 +00:00
|
|
|
* Return 'true' if the device is not runtime-suspended or it has to be
|
2015-01-21 01:17:42 +00:00
|
|
|
* reconfigured due to wakeup settings difference between system and runtime
|
2019-06-06 22:32:31 +00:00
|
|
|
* suspend, or the current power state of it is not suitable for the upcoming
|
|
|
|
* (system-wide) transition.
|
2015-01-21 01:17:42 +00:00
|
|
|
*/
|
2019-06-06 22:32:31 +00:00
|
|
|
bool pci_dev_need_resume(struct pci_dev *pci_dev)
|
2015-01-21 01:17:42 +00:00
|
|
|
{
|
|
|
|
struct device *dev = &pci_dev->dev;
|
2019-06-06 22:30:58 +00:00
|
|
|
pci_power_t target_state;
|
|
|
|
|
|
|
|
if (!pm_runtime_suspended(dev) || platform_pci_need_resume(pci_dev))
|
2019-06-06 22:32:31 +00:00
|
|
|
return true;
|
2015-01-21 01:17:42 +00:00
|
|
|
|
2019-06-06 22:32:31 +00:00
|
|
|
target_state = pci_target_state(pci_dev, device_may_wakeup(dev));
|
2019-06-06 22:30:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the earlier platform check has not triggered, D3cold is just power
|
|
|
|
* removal on top of D3hot, so no need to resume the device in that
|
|
|
|
* case.
|
|
|
|
*/
|
2019-06-06 22:32:31 +00:00
|
|
|
return target_state != pci_dev->current_state &&
|
|
|
|
target_state != PCI_D3cold &&
|
|
|
|
pci_dev->current_state != PCI_D3hot;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_dev_adjust_pme - Adjust PME setting for a suspended device.
|
|
|
|
* @pci_dev: Device to check.
|
|
|
|
*
|
|
|
|
* If the device is suspended and it is not configured for system wakeup,
|
|
|
|
* disable PME for it to prevent it from waking up the system unnecessarily.
|
|
|
|
*
|
|
|
|
* Note that if the device's power state is D3cold and the platform check in
|
|
|
|
* pci_dev_need_resume() has not triggered, the device's configuration need not
|
|
|
|
* be changed.
|
|
|
|
*/
|
|
|
|
void pci_dev_adjust_pme(struct pci_dev *pci_dev)
|
|
|
|
{
|
|
|
|
struct device *dev = &pci_dev->dev;
|
2015-01-21 01:17:42 +00:00
|
|
|
|
2015-09-29 23:10:24 +00:00
|
|
|
spin_lock_irq(&dev->power.lock);
|
|
|
|
|
2019-06-06 22:32:31 +00:00
|
|
|
if (pm_runtime_suspended(dev) && !device_may_wakeup(dev) &&
|
|
|
|
pci_dev->current_state < PCI_D3cold)
|
2015-09-29 23:10:24 +00:00
|
|
|
__pci_pme_active(pci_dev, false);
|
|
|
|
|
|
|
|
spin_unlock_irq(&dev->power.lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_dev_complete_resume - Finalize resume from system sleep for a device.
|
|
|
|
* @pci_dev: Device to handle.
|
|
|
|
*
|
|
|
|
* If the device is runtime suspended and wakeup-capable, enable PME for it as
|
|
|
|
* it might have been disabled during the prepare phase of system suspend if
|
|
|
|
* the device was not configured for system wakeup.
|
|
|
|
*/
|
|
|
|
void pci_dev_complete_resume(struct pci_dev *pci_dev)
|
|
|
|
{
|
|
|
|
struct device *dev = &pci_dev->dev;
|
|
|
|
|
|
|
|
if (!pci_dev_run_wake(pci_dev))
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock_irq(&dev->power.lock);
|
|
|
|
|
|
|
|
if (pm_runtime_suspended(dev) && pci_dev->current_state < PCI_D3cold)
|
|
|
|
__pci_pme_active(pci_dev, true);
|
|
|
|
|
|
|
|
spin_unlock_irq(&dev->power.lock);
|
2015-01-21 01:17:42 +00:00
|
|
|
}
|
|
|
|
|
2012-10-25 01:36:03 +00:00
|
|
|
void pci_config_pm_runtime_get(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
struct device *dev = &pdev->dev;
|
|
|
|
struct device *parent = dev->parent;
|
|
|
|
|
|
|
|
if (parent)
|
|
|
|
pm_runtime_get_sync(parent);
|
|
|
|
pm_runtime_get_noresume(dev);
|
|
|
|
/*
|
|
|
|
* pdev->current_state is set to PCI_D3cold during suspending,
|
|
|
|
* so wait until suspending completes
|
|
|
|
*/
|
|
|
|
pm_runtime_barrier(dev);
|
|
|
|
/*
|
|
|
|
* Only need to resume devices in D3cold, because config
|
|
|
|
* registers are still accessible for devices suspended but
|
|
|
|
* not in D3cold.
|
|
|
|
*/
|
|
|
|
if (pdev->current_state == PCI_D3cold)
|
|
|
|
pm_runtime_resume(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
void pci_config_pm_runtime_put(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
struct device *dev = &pdev->dev;
|
|
|
|
struct device *parent = dev->parent;
|
|
|
|
|
|
|
|
pm_runtime_put(dev);
|
|
|
|
if (parent)
|
|
|
|
pm_runtime_put_sync(parent);
|
|
|
|
}
|
|
|
|
|
2019-01-31 16:38:56 +00:00
|
|
|
static const struct dmi_system_id bridge_d3_blacklist[] = {
|
|
|
|
#ifdef CONFIG_X86
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Gigabyte X299 root port is not marked as hotplug capable
|
|
|
|
* which allows Linux to power manage it. However, this
|
|
|
|
* confuses the BIOS SMI handler so don't power manage root
|
|
|
|
* ports on that system.
|
|
|
|
*/
|
|
|
|
.ident = "X299 DESIGNARE EX-CF",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., Ltd."),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "X299 DESIGNARE EX-CF"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
2016-06-02 08:17:12 +00:00
|
|
|
/**
|
|
|
|
* pci_bridge_d3_possible - Is it possible to put the bridge into D3
|
|
|
|
* @bridge: Bridge to check
|
|
|
|
*
|
|
|
|
* This function checks if it is possible to move the bridge to D3.
|
2018-07-19 22:28:00 +00:00
|
|
|
* Currently we only allow D3 for recent enough PCIe ports and Thunderbolt.
|
2016-06-02 08:17:12 +00:00
|
|
|
*/
|
2016-10-28 08:52:06 +00:00
|
|
|
bool pci_bridge_d3_possible(struct pci_dev *bridge)
|
2016-06-02 08:17:12 +00:00
|
|
|
{
|
|
|
|
if (!pci_is_pcie(bridge))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
switch (pci_pcie_type(bridge)) {
|
|
|
|
case PCI_EXP_TYPE_ROOT_PORT:
|
|
|
|
case PCI_EXP_TYPE_UPSTREAM:
|
|
|
|
case PCI_EXP_TYPE_DOWNSTREAM:
|
|
|
|
if (pci_bridge_d3_disable)
|
|
|
|
return false;
|
2016-10-28 08:52:06 +00:00
|
|
|
|
|
|
|
/*
|
2018-07-19 22:27:59 +00:00
|
|
|
* Hotplug ports handled by firmware in System Management Mode
|
2016-10-28 08:52:06 +00:00
|
|
|
* may not be put into D3 by the OS (Thunderbolt on non-Macs).
|
|
|
|
*/
|
2018-07-19 22:27:59 +00:00
|
|
|
if (bridge->is_hotplug_bridge && !pciehp_is_native(bridge))
|
2016-10-28 08:52:06 +00:00
|
|
|
return false;
|
|
|
|
|
2016-06-02 08:17:12 +00:00
|
|
|
if (pci_bridge_d3_force)
|
|
|
|
return true;
|
|
|
|
|
2018-07-19 22:28:00 +00:00
|
|
|
/* Even the oldest 2010 Thunderbolt controller supports D3. */
|
|
|
|
if (bridge->is_thunderbolt)
|
|
|
|
return true;
|
|
|
|
|
2018-09-27 21:57:14 +00:00
|
|
|
/* Platform might know better if the bridge supports D3 */
|
|
|
|
if (platform_pci_bridge_d3(bridge))
|
|
|
|
return true;
|
|
|
|
|
2018-07-19 22:27:59 +00:00
|
|
|
/*
|
|
|
|
* Hotplug ports handled natively by the OS were not validated
|
|
|
|
* by vendors for runtime D3 at least until 2018 because there
|
|
|
|
* was no OS support.
|
|
|
|
*/
|
|
|
|
if (bridge->is_hotplug_bridge)
|
|
|
|
return false;
|
|
|
|
|
2019-01-31 16:38:56 +00:00
|
|
|
if (dmi_check_system(bridge_d3_blacklist))
|
|
|
|
return false;
|
|
|
|
|
2016-06-02 08:17:12 +00:00
|
|
|
/*
|
|
|
|
* It should be safe to put PCIe ports from 2015 or newer
|
|
|
|
* to D3.
|
|
|
|
*/
|
2018-02-22 12:59:23 +00:00
|
|
|
if (dmi_get_bios_year() >= 2015)
|
2016-06-02 08:17:12 +00:00
|
|
|
return true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_dev_check_d3cold(struct pci_dev *dev, void *data)
|
|
|
|
{
|
|
|
|
bool *d3cold_ok = data;
|
|
|
|
|
2016-10-28 08:52:06 +00:00
|
|
|
if (/* The device needs to be allowed to go D3cold ... */
|
|
|
|
dev->no_d3cold || !dev->d3cold_allowed ||
|
|
|
|
|
|
|
|
/* ... and if it is wakeup capable to do so from D3cold. */
|
|
|
|
(device_may_wakeup(&dev->dev) &&
|
|
|
|
!pci_pme_capable(dev, PCI_D3cold)) ||
|
|
|
|
|
|
|
|
/* If it is a bridge it must be allowed to go to D3. */
|
2017-02-03 14:53:51 +00:00
|
|
|
!pci_power_manageable(dev))
|
2016-06-02 08:17:12 +00:00
|
|
|
|
2016-10-28 08:52:06 +00:00
|
|
|
*d3cold_ok = false;
|
2016-06-02 08:17:12 +00:00
|
|
|
|
2016-10-28 08:52:06 +00:00
|
|
|
return !*d3cold_ok;
|
2016-06-02 08:17:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pci_bridge_d3_update - Update bridge D3 capabilities
|
|
|
|
* @dev: PCI device which is changed
|
|
|
|
*
|
|
|
|
* Update upstream bridge PM capabilities accordingly depending on if the
|
|
|
|
* device PM configuration was changed or the device is being removed. The
|
|
|
|
* change is also propagated upstream.
|
|
|
|
*/
|
2016-10-28 08:52:06 +00:00
|
|
|
void pci_bridge_d3_update(struct pci_dev *dev)
|
2016-06-02 08:17:12 +00:00
|
|
|
{
|
2016-10-28 08:52:06 +00:00
|
|
|
bool remove = !device_is_registered(&dev->dev);
|
2016-06-02 08:17:12 +00:00
|
|
|
struct pci_dev *bridge;
|
|
|
|
bool d3cold_ok = true;
|
|
|
|
|
|
|
|
bridge = pci_upstream_bridge(dev);
|
|
|
|
if (!bridge || !pci_bridge_d3_possible(bridge))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
2016-10-28 08:52:06 +00:00
|
|
|
* If D3 is currently allowed for the bridge, removing one of its
|
|
|
|
* children won't change that.
|
|
|
|
*/
|
|
|
|
if (remove && bridge->bridge_d3)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If D3 is currently allowed for the bridge and a child is added or
|
|
|
|
* changed, disallowance of D3 can only be caused by that child, so
|
|
|
|
* we only need to check that single device, not any of its siblings.
|
|
|
|
*
|
|
|
|
* If D3 is currently not allowed for the bridge, checking the device
|
|
|
|
* first may allow us to skip checking its siblings.
|
2016-06-02 08:17:12 +00:00
|
|
|
*/
|
|
|
|
if (!remove)
|
|
|
|
pci_dev_check_d3cold(dev, &d3cold_ok);
|
|
|
|
|
2016-10-28 08:52:06 +00:00
|
|
|
/*
|
|
|
|
* If D3 is currently not allowed for the bridge, this may be caused
|
|
|
|
* either by the device being changed/removed or any of its siblings,
|
|
|
|
* so we need to go through all children to find out if one of them
|
|
|
|
* continues to block D3.
|
|
|
|
*/
|
|
|
|
if (d3cold_ok && !bridge->bridge_d3)
|
2016-06-02 08:17:12 +00:00
|
|
|
pci_walk_bus(bridge->subordinate, pci_dev_check_d3cold,
|
|
|
|
&d3cold_ok);
|
|
|
|
|
|
|
|
if (bridge->bridge_d3 != d3cold_ok) {
|
|
|
|
bridge->bridge_d3 = d3cold_ok;
|
|
|
|
/* Propagate change to upstream bridges */
|
2016-10-28 08:52:06 +00:00
|
|
|
pci_bridge_d3_update(bridge);
|
2016-06-02 08:17:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_d3cold_enable - Enable D3cold for device
|
|
|
|
* @dev: PCI device to handle
|
|
|
|
*
|
|
|
|
* This function can be used in drivers to enable D3cold from the device
|
|
|
|
* they handle. It also updates upstream PCI bridge PM capabilities
|
|
|
|
* accordingly.
|
|
|
|
*/
|
|
|
|
void pci_d3cold_enable(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (dev->no_d3cold) {
|
|
|
|
dev->no_d3cold = false;
|
2016-10-28 08:52:06 +00:00
|
|
|
pci_bridge_d3_update(dev);
|
2016-06-02 08:17:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_d3cold_enable);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_d3cold_disable - Disable D3cold for device
|
|
|
|
* @dev: PCI device to handle
|
|
|
|
*
|
|
|
|
* This function can be used in drivers to disable D3cold from the device
|
|
|
|
* they handle. It also updates upstream PCI bridge PM capabilities
|
|
|
|
* accordingly.
|
|
|
|
*/
|
|
|
|
void pci_d3cold_disable(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (!dev->no_d3cold) {
|
|
|
|
dev->no_d3cold = true;
|
2016-10-28 08:52:06 +00:00
|
|
|
pci_bridge_d3_update(dev);
|
2016-06-02 08:17:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_d3cold_disable);
|
|
|
|
|
2008-07-07 01:34:48 +00:00
|
|
|
/**
|
|
|
|
* pci_pm_init - Initialize PM functions of given PCI device
|
|
|
|
* @dev: PCI device to handle.
|
|
|
|
*/
|
|
|
|
void pci_pm_init(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int pm;
|
2018-09-07 06:16:51 +00:00
|
|
|
u16 status;
|
2008-07-07 01:34:48 +00:00
|
|
|
u16 pmc;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-02-27 20:37:37 +00:00
|
|
|
pm_runtime_forbid(&dev->dev);
|
2012-11-20 08:08:22 +00:00
|
|
|
pm_runtime_set_active(&dev->dev);
|
|
|
|
pm_runtime_enable(&dev->dev);
|
2010-02-08 18:16:33 +00:00
|
|
|
device_enable_async_suspend(&dev->dev);
|
2009-09-08 21:14:49 +00:00
|
|
|
dev->wakeup_prepared = false;
|
2010-02-27 20:37:37 +00:00
|
|
|
|
2008-07-07 01:36:24 +00:00
|
|
|
dev->pm_cap = 0;
|
2013-04-10 10:32:51 +00:00
|
|
|
dev->pme_support = 0;
|
2008-07-07 01:36:24 +00:00
|
|
|
|
2008-07-07 01:34:48 +00:00
|
|
|
/* find PCI PM capability in list */
|
|
|
|
pm = pci_find_capability(dev, PCI_CAP_ID_PM);
|
|
|
|
if (!pm)
|
2009-01-16 16:14:51 +00:00
|
|
|
return;
|
2008-07-07 01:34:48 +00:00
|
|
|
/* Check device's ability to generate PME# */
|
|
|
|
pci_read_config_word(dev, pm + PCI_PM_PMC, &pmc);
|
2007-04-26 07:12:06 +00:00
|
|
|
|
2008-07-07 01:34:48 +00:00
|
|
|
if ((pmc & PCI_PM_CAP_VER_MASK) > 3) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "unsupported PM cap regs version (%u)\n",
|
2008-07-07 01:34:48 +00:00
|
|
|
pmc & PCI_PM_CAP_VER_MASK);
|
2009-01-16 16:14:51 +00:00
|
|
|
return;
|
2008-07-07 01:34:48 +00:00
|
|
|
}
|
|
|
|
|
2008-07-07 01:36:24 +00:00
|
|
|
dev->pm_cap = pm;
|
2009-12-31 11:15:54 +00:00
|
|
|
dev->d3_delay = PCI_PM_D3_WAIT;
|
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
|
|
|
dev->d3cold_delay = PCI_PM_D3COLD_WAIT;
|
2016-06-02 08:17:12 +00:00
|
|
|
dev->bridge_d3 = pci_bridge_d3_possible(dev);
|
PCI/PM: Enable D3/D3cold by default for most devices
This patch fixes the following bug:
http://marc.info/?l=linux-usb&m=134318961120825&w=2
Originally, device lower power states include D1, D2, D3. After that,
D3 is further divided into D3hot and D3cold. To support both scenario
safely, original D3 is mapped to D3cold.
When adding D3cold support, because worry about some device may have
broken D3cold support, D3cold is disabled by default. This disable D3
on original platform too. But some original platform may only have
working D3, but no working D1, D2. The root cause of the above bug is
it too.
To deal with this, this patch enables D3/D3cold by default for most
devices. This restores the original behavior. For some devices that
suspected to have broken D3cold support, such as PCIe port, D3cold is
disabled by default.
Reported-by: Bjorn Mork <bjorn@mork.no>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-08-08 01:07:38 +00:00
|
|
|
dev->d3cold_allowed = true;
|
2008-07-07 01:36:24 +00:00
|
|
|
|
|
|
|
dev->d1_support = false;
|
|
|
|
dev->d2_support = false;
|
|
|
|
if (!pci_no_d1d2(dev)) {
|
2008-08-22 15:37:02 +00:00
|
|
|
if (pmc & PCI_PM_CAP_D1)
|
2008-07-07 01:36:24 +00:00
|
|
|
dev->d1_support = true;
|
2008-08-22 15:37:02 +00:00
|
|
|
if (pmc & PCI_PM_CAP_D2)
|
2008-07-07 01:36:24 +00:00
|
|
|
dev->d2_support = true;
|
2008-08-22 15:37:02 +00:00
|
|
|
|
|
|
|
if (dev->d1_support || dev->d2_support)
|
2019-04-20 04:07:20 +00:00
|
|
|
pci_info(dev, "supports%s%s\n",
|
2008-09-23 18:43:34 +00:00
|
|
|
dev->d1_support ? " D1" : "",
|
|
|
|
dev->d2_support ? " D2" : "");
|
2008-07-07 01:36:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
pmc &= PCI_PM_CAP_PME_MASK;
|
|
|
|
if (pmc) {
|
2019-04-20 04:07:20 +00:00
|
|
|
pci_info(dev, "PME# supported from%s%s%s%s%s\n",
|
2008-08-22 15:37:02 +00:00
|
|
|
(pmc & PCI_PM_CAP_PME_D0) ? " D0" : "",
|
|
|
|
(pmc & PCI_PM_CAP_PME_D1) ? " D1" : "",
|
|
|
|
(pmc & PCI_PM_CAP_PME_D2) ? " D2" : "",
|
|
|
|
(pmc & PCI_PM_CAP_PME_D3) ? " D3hot" : "",
|
|
|
|
(pmc & PCI_PM_CAP_PME_D3cold) ? " D3cold" : "");
|
2008-07-07 01:36:24 +00:00
|
|
|
dev->pme_support = pmc >> PCI_PM_CAP_PME_SHIFT;
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
dev->pme_poll = true;
|
2008-07-07 01:34:48 +00:00
|
|
|
/*
|
|
|
|
* Make device's PM flags reflect the wake-up capability, but
|
|
|
|
* let the user space enable it to wake up the system as needed.
|
|
|
|
*/
|
|
|
|
device_set_wakeup_capable(&dev->dev, true);
|
|
|
|
/* Disable the PME# generation functionality */
|
2008-07-07 01:36:24 +00:00
|
|
|
pci_pme_active(dev, false);
|
2008-07-07 01:34:48 +00:00
|
|
|
}
|
2018-09-07 06:16:51 +00:00
|
|
|
|
|
|
|
pci_read_config_word(dev, PCI_STATUS, &status);
|
|
|
|
if (status & PCI_STATUS_IMM_READY)
|
|
|
|
dev->imm_ready = 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2015-10-29 22:35:39 +00:00
|
|
|
static unsigned long pci_ea_flags(struct pci_dev *dev, u8 prop)
|
|
|
|
{
|
2016-05-16 20:12:02 +00:00
|
|
|
unsigned long flags = IORESOURCE_PCI_FIXED | IORESOURCE_PCI_EA_BEI;
|
2015-10-29 22:35:39 +00:00
|
|
|
|
|
|
|
switch (prop) {
|
|
|
|
case PCI_EA_P_MEM:
|
|
|
|
case PCI_EA_P_VF_MEM:
|
|
|
|
flags |= IORESOURCE_MEM;
|
|
|
|
break;
|
|
|
|
case PCI_EA_P_MEM_PREFETCH:
|
|
|
|
case PCI_EA_P_VF_MEM_PREFETCH:
|
|
|
|
flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH;
|
|
|
|
break;
|
|
|
|
case PCI_EA_P_IO:
|
|
|
|
flags |= IORESOURCE_IO;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return flags;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct resource *pci_ea_get_resource(struct pci_dev *dev, u8 bei,
|
|
|
|
u8 prop)
|
|
|
|
{
|
|
|
|
if (bei <= PCI_EA_BEI_BAR5 && prop <= PCI_EA_P_IO)
|
|
|
|
return &dev->resource[bei];
|
2015-10-29 22:35:40 +00:00
|
|
|
#ifdef CONFIG_PCI_IOV
|
|
|
|
else if (bei >= PCI_EA_BEI_VF_BAR0 && bei <= PCI_EA_BEI_VF_BAR5 &&
|
|
|
|
(prop == PCI_EA_P_VF_MEM || prop == PCI_EA_P_VF_MEM_PREFETCH))
|
|
|
|
return &dev->resource[PCI_IOV_RESOURCES +
|
|
|
|
bei - PCI_EA_BEI_VF_BAR0];
|
|
|
|
#endif
|
2015-10-29 22:35:39 +00:00
|
|
|
else if (bei == PCI_EA_BEI_ROM)
|
|
|
|
return &dev->resource[PCI_ROM_RESOURCE];
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read an Enhanced Allocation (EA) entry */
|
|
|
|
static int pci_ea_read(struct pci_dev *dev, int offset)
|
|
|
|
{
|
|
|
|
struct resource *res;
|
|
|
|
int ent_size, ent_offset = offset;
|
|
|
|
resource_size_t start, end;
|
|
|
|
unsigned long flags;
|
2015-10-29 22:35:40 +00:00
|
|
|
u32 dw0, bei, base, max_offset;
|
2015-10-29 22:35:39 +00:00
|
|
|
u8 prop;
|
|
|
|
bool support_64 = (sizeof(resource_size_t) >= 8);
|
|
|
|
|
|
|
|
pci_read_config_dword(dev, ent_offset, &dw0);
|
|
|
|
ent_offset += 4;
|
|
|
|
|
|
|
|
/* Entry size field indicates DWORDs after 1st */
|
|
|
|
ent_size = ((dw0 & PCI_EA_ES) + 1) << 2;
|
|
|
|
|
|
|
|
if (!(dw0 & PCI_EA_ENABLE)) /* Entry not enabled */
|
|
|
|
goto out;
|
|
|
|
|
2015-10-29 22:35:40 +00:00
|
|
|
bei = (dw0 & PCI_EA_BEI) >> 4;
|
|
|
|
prop = (dw0 & PCI_EA_PP) >> 8;
|
|
|
|
|
2015-10-29 22:35:39 +00:00
|
|
|
/*
|
|
|
|
* If the Property is in the reserved range, try the Secondary
|
|
|
|
* Property instead.
|
|
|
|
*/
|
|
|
|
if (prop > PCI_EA_P_BRIDGE_IO && prop < PCI_EA_P_MEM_RESERVED)
|
2015-10-29 22:35:40 +00:00
|
|
|
prop = (dw0 & PCI_EA_SP) >> 16;
|
2015-10-29 22:35:39 +00:00
|
|
|
if (prop > PCI_EA_P_BRIDGE_IO)
|
|
|
|
goto out;
|
|
|
|
|
2015-10-29 22:35:40 +00:00
|
|
|
res = pci_ea_get_resource(dev, bei, prop);
|
2015-10-29 22:35:39 +00:00
|
|
|
if (!res) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "Unsupported EA entry BEI: %u\n", bei);
|
2015-10-29 22:35:39 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
flags = pci_ea_flags(dev, prop);
|
|
|
|
if (!flags) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "Unsupported EA properties: %#x\n", prop);
|
2015-10-29 22:35:39 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read Base */
|
|
|
|
pci_read_config_dword(dev, ent_offset, &base);
|
|
|
|
start = (base & PCI_EA_FIELD_MASK);
|
|
|
|
ent_offset += 4;
|
|
|
|
|
|
|
|
/* Read MaxOffset */
|
|
|
|
pci_read_config_dword(dev, ent_offset, &max_offset);
|
|
|
|
ent_offset += 4;
|
|
|
|
|
|
|
|
/* Read Base MSBs (if 64-bit entry) */
|
|
|
|
if (base & PCI_EA_IS_64) {
|
|
|
|
u32 base_upper;
|
|
|
|
|
|
|
|
pci_read_config_dword(dev, ent_offset, &base_upper);
|
|
|
|
ent_offset += 4;
|
|
|
|
|
|
|
|
flags |= IORESOURCE_MEM_64;
|
|
|
|
|
|
|
|
/* entry starts above 32-bit boundary, can't use */
|
|
|
|
if (!support_64 && base_upper)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (support_64)
|
|
|
|
start |= ((u64)base_upper << 32);
|
|
|
|
}
|
|
|
|
|
|
|
|
end = start + (max_offset | 0x03);
|
|
|
|
|
|
|
|
/* Read MaxOffset MSBs (if 64-bit entry) */
|
|
|
|
if (max_offset & PCI_EA_IS_64) {
|
|
|
|
u32 max_offset_upper;
|
|
|
|
|
|
|
|
pci_read_config_dword(dev, ent_offset, &max_offset_upper);
|
|
|
|
ent_offset += 4;
|
|
|
|
|
|
|
|
flags |= IORESOURCE_MEM_64;
|
|
|
|
|
|
|
|
/* entry too big, can't use */
|
|
|
|
if (!support_64 && max_offset_upper)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (support_64)
|
|
|
|
end += ((u64)max_offset_upper << 32);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (end < start) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "EA Entry crosses address boundary\n");
|
2015-10-29 22:35:39 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ent_size != ent_offset - offset) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "EA Entry Size (%d) does not match length read (%d)\n",
|
2015-10-29 22:35:39 +00:00
|
|
|
ent_size, ent_offset - offset);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
res->name = pci_name(dev);
|
|
|
|
res->start = start;
|
|
|
|
res->end = end;
|
|
|
|
res->flags = flags;
|
2015-10-29 22:35:40 +00:00
|
|
|
|
|
|
|
if (bei <= PCI_EA_BEI_BAR5)
|
2019-04-20 04:07:20 +00:00
|
|
|
pci_info(dev, "BAR %d: %pR (from Enhanced Allocation, properties %#02x)\n",
|
2015-10-29 22:35:40 +00:00
|
|
|
bei, res, prop);
|
|
|
|
else if (bei == PCI_EA_BEI_ROM)
|
2019-04-20 04:07:20 +00:00
|
|
|
pci_info(dev, "ROM: %pR (from Enhanced Allocation, properties %#02x)\n",
|
2015-10-29 22:35:40 +00:00
|
|
|
res, prop);
|
|
|
|
else if (bei >= PCI_EA_BEI_VF_BAR0 && bei <= PCI_EA_BEI_VF_BAR5)
|
2019-04-20 04:07:20 +00:00
|
|
|
pci_info(dev, "VF BAR %d: %pR (from Enhanced Allocation, properties %#02x)\n",
|
2015-10-29 22:35:40 +00:00
|
|
|
bei - PCI_EA_BEI_VF_BAR0, res, prop);
|
|
|
|
else
|
2019-04-20 04:07:20 +00:00
|
|
|
pci_info(dev, "BEI %d res: %pR (from Enhanced Allocation, properties %#02x)\n",
|
2015-10-29 22:35:40 +00:00
|
|
|
bei, res, prop);
|
|
|
|
|
2015-10-29 22:35:39 +00:00
|
|
|
out:
|
|
|
|
return offset + ent_size;
|
|
|
|
}
|
|
|
|
|
2016-04-05 17:12:45 +00:00
|
|
|
/* Enhanced Allocation Initialization */
|
2015-10-29 22:35:39 +00:00
|
|
|
void pci_ea_init(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int ea;
|
|
|
|
u8 num_ent;
|
|
|
|
int offset;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* find PCI EA capability in list */
|
|
|
|
ea = pci_find_capability(dev, PCI_CAP_ID_EA);
|
|
|
|
if (!ea)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* determine the number of entries */
|
|
|
|
pci_bus_read_config_byte(dev->bus, dev->devfn, ea + PCI_EA_NUM_ENT,
|
|
|
|
&num_ent);
|
|
|
|
num_ent &= PCI_EA_NUM_ENT_MASK;
|
|
|
|
|
|
|
|
offset = ea + PCI_EA_FIRST_ENT;
|
|
|
|
|
|
|
|
/* Skip DWORD 2 for type 1 functions */
|
|
|
|
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
|
|
|
|
offset += 4;
|
|
|
|
|
|
|
|
/* parse each EA entry */
|
|
|
|
for (i = 0; i < num_ent; ++i)
|
|
|
|
offset = pci_ea_read(dev, offset);
|
|
|
|
}
|
|
|
|
|
2012-02-11 08:18:41 +00:00
|
|
|
static void pci_add_saved_cap(struct pci_dev *pci_dev,
|
|
|
|
struct pci_cap_saved_state *new_cap)
|
|
|
|
{
|
|
|
|
hlist_add_head(&new_cap->next, &pci_dev->saved_cap_space);
|
|
|
|
}
|
|
|
|
|
2008-12-07 21:02:58 +00:00
|
|
|
/**
|
2013-12-17 23:43:45 +00:00
|
|
|
* _pci_add_cap_save_buffer - allocate buffer for saving given
|
2019-01-09 20:14:42 +00:00
|
|
|
* capability registers
|
2008-12-07 21:02:58 +00:00
|
|
|
* @dev: the PCI device
|
|
|
|
* @cap: the capability to allocate the buffer for
|
2013-12-17 23:43:45 +00:00
|
|
|
* @extended: Standard or Extended capability ID
|
2008-12-07 21:02:58 +00:00
|
|
|
* @size: requested size of the buffer
|
|
|
|
*/
|
2013-12-17 23:43:45 +00:00
|
|
|
static int _pci_add_cap_save_buffer(struct pci_dev *dev, u16 cap,
|
|
|
|
bool extended, unsigned int size)
|
2008-12-07 21:02:58 +00:00
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
struct pci_cap_saved_state *save_state;
|
|
|
|
|
2013-12-17 23:43:45 +00:00
|
|
|
if (extended)
|
|
|
|
pos = pci_find_ext_capability(dev, cap);
|
|
|
|
else
|
|
|
|
pos = pci_find_capability(dev, cap);
|
|
|
|
|
2015-06-30 01:16:44 +00:00
|
|
|
if (!pos)
|
2008-12-07 21:02:58 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
save_state = kzalloc(sizeof(*save_state) + size, GFP_KERNEL);
|
|
|
|
if (!save_state)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2011-05-10 16:02:11 +00:00
|
|
|
save_state->cap.cap_nr = cap;
|
2013-12-17 23:43:45 +00:00
|
|
|
save_state->cap.cap_extended = extended;
|
2011-05-10 16:02:11 +00:00
|
|
|
save_state->cap.size = size;
|
2008-12-07 21:02:58 +00:00
|
|
|
pci_add_saved_cap(dev, save_state);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-12-17 23:43:45 +00:00
|
|
|
int pci_add_cap_save_buffer(struct pci_dev *dev, char cap, unsigned int size)
|
|
|
|
{
|
|
|
|
return _pci_add_cap_save_buffer(dev, cap, false, size);
|
|
|
|
}
|
|
|
|
|
|
|
|
int pci_add_ext_cap_save_buffer(struct pci_dev *dev, u16 cap, unsigned int size)
|
|
|
|
{
|
|
|
|
return _pci_add_cap_save_buffer(dev, cap, true, size);
|
|
|
|
}
|
|
|
|
|
2008-12-07 21:02:58 +00:00
|
|
|
/**
|
|
|
|
* pci_allocate_cap_save_buffers - allocate buffers for saving capabilities
|
|
|
|
* @dev: the PCI device
|
|
|
|
*/
|
|
|
|
void pci_allocate_cap_save_buffers(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
2009-02-15 18:55:47 +00:00
|
|
|
error = pci_add_cap_save_buffer(dev, PCI_CAP_ID_EXP,
|
|
|
|
PCI_EXP_SAVE_REGS * sizeof(u16));
|
2008-12-07 21:02:58 +00:00
|
|
|
if (error)
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "unable to preallocate PCI Express save buffer\n");
|
2008-12-07 21:02:58 +00:00
|
|
|
|
|
|
|
error = pci_add_cap_save_buffer(dev, PCI_CAP_ID_PCIX, sizeof(u16));
|
|
|
|
if (error)
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "unable to preallocate PCI-X save buffer\n");
|
PCI: Add Virtual Channel to save/restore support
While we don't really have any infrastructure for making use of VC
support, the system BIOS can configure the topology to non-default
VC values prior to boot. This may be due to silicon bugs, desire to
reserve traffic classes, or perhaps just BIOS bugs. When we reset
devices, the VC configuration may return to default values, which can
be incompatible with devices upstream. For instance, Nvidia GRID
cards provide a PCIe switch and some number of GPUs, all supporting
VC. The power-on default for VC is to support TC0-7 across VC0,
however some platforms will only enable TC0/VC0 mapping across the
topology. When we do a secondary bus reset on the downstream switch
port, the GPU is reset to a TC0-7/VC0 mapping while the opposite end
of the link only enables TC0/VC0. If the GPU attempts to use TC1-7,
it fails.
This patch attempts to provide complete support for VC save/restore,
even beyond the minimally required use case above. This includes
save/restore and reload of the arbitration table, save/restore and
reload of the port arbitration tables, and re-enabling of the
channels for VC, VC9, and MFVC capabilities.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-17 23:43:51 +00:00
|
|
|
|
2019-01-09 14:22:08 +00:00
|
|
|
error = pci_add_ext_cap_save_buffer(dev, PCI_EXT_CAP_ID_LTR,
|
|
|
|
2 * sizeof(u16));
|
|
|
|
if (error)
|
|
|
|
pci_err(dev, "unable to allocate suspend buffer for LTR\n");
|
|
|
|
|
PCI: Add Virtual Channel to save/restore support
While we don't really have any infrastructure for making use of VC
support, the system BIOS can configure the topology to non-default
VC values prior to boot. This may be due to silicon bugs, desire to
reserve traffic classes, or perhaps just BIOS bugs. When we reset
devices, the VC configuration may return to default values, which can
be incompatible with devices upstream. For instance, Nvidia GRID
cards provide a PCIe switch and some number of GPUs, all supporting
VC. The power-on default for VC is to support TC0-7 across VC0,
however some platforms will only enable TC0/VC0 mapping across the
topology. When we do a secondary bus reset on the downstream switch
port, the GPU is reset to a TC0-7/VC0 mapping while the opposite end
of the link only enables TC0/VC0. If the GPU attempts to use TC1-7,
it fails.
This patch attempts to provide complete support for VC save/restore,
even beyond the minimally required use case above. This includes
save/restore and reload of the arbitration table, save/restore and
reload of the port arbitration tables, and re-enabling of the
channels for VC, VC9, and MFVC capabilities.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-17 23:43:51 +00:00
|
|
|
pci_allocate_vc_save_buffers(dev);
|
2008-12-07 21:02:58 +00:00
|
|
|
}
|
|
|
|
|
2012-02-11 08:18:30 +00:00
|
|
|
void pci_free_cap_save_buffers(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
struct pci_cap_saved_state *tmp;
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28 01:06:00 +00:00
|
|
|
struct hlist_node *n;
|
2012-02-11 08:18:30 +00:00
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28 01:06:00 +00:00
|
|
|
hlist_for_each_entry_safe(tmp, n, &dev->saved_cap_space, next)
|
2012-02-11 08:18:30 +00:00
|
|
|
kfree(tmp);
|
|
|
|
}
|
|
|
|
|
2008-10-14 06:02:53 +00:00
|
|
|
/**
|
2013-01-15 03:12:17 +00:00
|
|
|
* pci_configure_ari - enable or disable ARI forwarding
|
2008-10-14 06:02:53 +00:00
|
|
|
* @dev: the PCI device
|
2013-01-15 03:12:16 +00:00
|
|
|
*
|
|
|
|
* If @dev and its upstream bridge both support ARI, enable ARI in the
|
|
|
|
* bridge. Otherwise, disable ARI in the bridge.
|
2008-10-14 06:02:53 +00:00
|
|
|
*/
|
2013-01-15 03:12:17 +00:00
|
|
|
void pci_configure_ari(struct pci_dev *dev)
|
2008-10-14 06:02:53 +00:00
|
|
|
{
|
|
|
|
u32 cap;
|
2008-10-23 05:15:39 +00:00
|
|
|
struct pci_dev *bridge;
|
2008-10-14 06:02:53 +00:00
|
|
|
|
2012-02-29 23:06:33 +00:00
|
|
|
if (pcie_ari_disabled || !pci_is_pcie(dev) || dev->devfn)
|
2008-10-14 06:02:53 +00:00
|
|
|
return;
|
|
|
|
|
2008-10-23 05:15:39 +00:00
|
|
|
bridge = dev->bus->self;
|
2012-06-01 21:16:31 +00:00
|
|
|
if (!bridge)
|
2008-10-23 05:15:39 +00:00
|
|
|
return;
|
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2, &cap);
|
2008-10-14 06:02:53 +00:00
|
|
|
if (!(cap & PCI_EXP_DEVCAP2_ARI))
|
|
|
|
return;
|
|
|
|
|
2013-01-15 03:12:16 +00:00
|
|
|
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ARI)) {
|
|
|
|
pcie_capability_set_word(bridge, PCI_EXP_DEVCTL2,
|
|
|
|
PCI_EXP_DEVCTL2_ARI);
|
|
|
|
bridge->ari_enabled = 1;
|
|
|
|
} else {
|
|
|
|
pcie_capability_clear_word(bridge, PCI_EXP_DEVCTL2,
|
|
|
|
PCI_EXP_DEVCTL2_ARI);
|
|
|
|
bridge->ari_enabled = 0;
|
|
|
|
}
|
2008-10-14 06:02:53 +00:00
|
|
|
}
|
|
|
|
|
2009-12-04 20:15:21 +00:00
|
|
|
static int pci_acs_enable;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_request_acs - ask for ACS to be enabled if supported
|
|
|
|
*/
|
|
|
|
void pci_request_acs(void)
|
|
|
|
{
|
|
|
|
pci_acs_enable = 1;
|
|
|
|
}
|
|
|
|
|
2018-07-30 16:18:40 +00:00
|
|
|
static const char *disable_acs_redir_param;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_disable_acs_redir - disable ACS redirect capabilities
|
|
|
|
* @dev: the PCI device
|
|
|
|
*
|
|
|
|
* For only devices specified in the disable_acs_redir parameter.
|
|
|
|
*/
|
|
|
|
static void pci_disable_acs_redir(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
const char *p;
|
|
|
|
int pos;
|
|
|
|
u16 ctrl;
|
|
|
|
|
|
|
|
if (!disable_acs_redir_param)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p = disable_acs_redir_param;
|
|
|
|
while (*p) {
|
|
|
|
ret = pci_dev_str_match(dev, p, &p);
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_info_once("PCI: Can't parse disable_acs_redir parameter: %s\n",
|
|
|
|
disable_acs_redir_param);
|
|
|
|
|
|
|
|
break;
|
|
|
|
} else if (ret == 1) {
|
|
|
|
/* Found a match */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (*p != ';' && *p != ',') {
|
|
|
|
/* End of param or invalid format */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
p++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret != 1)
|
|
|
|
return;
|
|
|
|
|
2018-08-09 21:51:43 +00:00
|
|
|
if (!pci_dev_specific_disable_acs_redir(dev))
|
|
|
|
return;
|
|
|
|
|
2018-07-30 16:18:40 +00:00
|
|
|
pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS);
|
|
|
|
if (!pos) {
|
|
|
|
pci_warn(dev, "cannot disable ACS redirect for this hardware as it does not have ACS capabilities\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
pci_read_config_word(dev, pos + PCI_ACS_CTRL, &ctrl);
|
|
|
|
|
|
|
|
/* P2P Request & Completion Redirect */
|
|
|
|
ctrl &= ~(PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_EC);
|
|
|
|
|
|
|
|
pci_write_config_word(dev, pos + PCI_ACS_CTRL, ctrl);
|
|
|
|
|
|
|
|
pci_info(dev, "disabled ACS redirect\n");
|
|
|
|
}
|
|
|
|
|
2009-10-07 17:27:17 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_std_enable_acs - enable ACS on devices using standard ACS capabilities
|
2009-10-07 17:27:17 +00:00
|
|
|
* @dev: the PCI device
|
|
|
|
*/
|
2016-03-31 22:34:32 +00:00
|
|
|
static void pci_std_enable_acs(struct pci_dev *dev)
|
2009-10-07 17:27:17 +00:00
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
u16 cap;
|
|
|
|
u16 ctrl;
|
|
|
|
|
|
|
|
pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS);
|
|
|
|
if (!pos)
|
2016-03-31 22:34:32 +00:00
|
|
|
return;
|
2009-10-07 17:27:17 +00:00
|
|
|
|
|
|
|
pci_read_config_word(dev, pos + PCI_ACS_CAP, &cap);
|
|
|
|
pci_read_config_word(dev, pos + PCI_ACS_CTRL, &ctrl);
|
|
|
|
|
|
|
|
/* Source Validation */
|
|
|
|
ctrl |= (cap & PCI_ACS_SV);
|
|
|
|
|
|
|
|
/* P2P Request Redirect */
|
|
|
|
ctrl |= (cap & PCI_ACS_RR);
|
|
|
|
|
|
|
|
/* P2P Completion Redirect */
|
|
|
|
ctrl |= (cap & PCI_ACS_CR);
|
|
|
|
|
|
|
|
/* Upstream Forwarding */
|
|
|
|
ctrl |= (cap & PCI_ACS_UF);
|
|
|
|
|
|
|
|
pci_write_config_word(dev, pos + PCI_ACS_CTRL, ctrl);
|
2014-02-03 21:27:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_enable_acs - enable ACS if hardware support it
|
|
|
|
* @dev: the PCI device
|
|
|
|
*/
|
|
|
|
void pci_enable_acs(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (!pci_acs_enable)
|
2018-07-30 16:18:40 +00:00
|
|
|
goto disable_acs_redir;
|
2014-02-03 21:27:33 +00:00
|
|
|
|
2016-03-31 22:34:32 +00:00
|
|
|
if (!pci_dev_specific_enable_acs(dev))
|
2018-07-30 16:18:40 +00:00
|
|
|
goto disable_acs_redir;
|
2014-02-03 21:27:33 +00:00
|
|
|
|
2016-03-31 22:34:32 +00:00
|
|
|
pci_std_enable_acs(dev);
|
2018-07-30 16:18:40 +00:00
|
|
|
|
|
|
|
disable_acs_redir:
|
|
|
|
/*
|
|
|
|
* Note: pci_disable_acs_redir() must be called even if ACS was not
|
|
|
|
* enabled by the kernel because it may have been enabled by
|
|
|
|
* platform firmware. So if we are told to disable it, we should
|
|
|
|
* always disable it after setting the kernel's default
|
|
|
|
* preferences.
|
|
|
|
*/
|
|
|
|
pci_disable_acs_redir(dev);
|
2009-10-07 17:27:17 +00:00
|
|
|
}
|
|
|
|
|
2013-06-27 22:39:48 +00:00
|
|
|
static bool pci_acs_flags_enabled(struct pci_dev *pdev, u16 acs_flags)
|
|
|
|
{
|
|
|
|
int pos;
|
2013-06-27 22:39:54 +00:00
|
|
|
u16 cap, ctrl;
|
2013-06-27 22:39:48 +00:00
|
|
|
|
|
|
|
pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ACS);
|
|
|
|
if (!pos)
|
|
|
|
return false;
|
|
|
|
|
2013-06-27 22:39:54 +00:00
|
|
|
/*
|
|
|
|
* Except for egress control, capabilities are either required
|
|
|
|
* or only required if controllable. Features missing from the
|
|
|
|
* capability field can therefore be assumed as hard-wired enabled.
|
|
|
|
*/
|
|
|
|
pci_read_config_word(pdev, pos + PCI_ACS_CAP, &cap);
|
|
|
|
acs_flags &= (cap | PCI_ACS_EC);
|
|
|
|
|
2013-06-27 22:39:48 +00:00
|
|
|
pci_read_config_word(pdev, pos + PCI_ACS_CTRL, &ctrl);
|
|
|
|
return (ctrl & acs_flags) == acs_flags;
|
|
|
|
}
|
|
|
|
|
2012-06-11 05:27:07 +00:00
|
|
|
/**
|
|
|
|
* pci_acs_enabled - test ACS against required flags for a given device
|
|
|
|
* @pdev: device to test
|
|
|
|
* @acs_flags: required PCI ACS flags
|
|
|
|
*
|
|
|
|
* Return true if the device supports the provided flags. Automatically
|
|
|
|
* filters out flags that are not implemented on multifunction devices.
|
2013-06-27 22:39:48 +00:00
|
|
|
*
|
|
|
|
* Note that this interface checks the effective ACS capabilities of the
|
|
|
|
* device rather than the actual capabilities. For instance, most single
|
|
|
|
* function endpoints are not required to support ACS because they have no
|
|
|
|
* opportunity for peer-to-peer access. We therefore return 'true'
|
|
|
|
* regardless of whether the device exposes an ACS capability. This makes
|
|
|
|
* it much easier for callers of this function to ignore the actual type
|
|
|
|
* or topology of the device when testing ACS support.
|
2012-06-11 05:27:07 +00:00
|
|
|
*/
|
|
|
|
bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags)
|
|
|
|
{
|
2013-06-27 22:39:48 +00:00
|
|
|
int ret;
|
2012-06-11 05:27:07 +00:00
|
|
|
|
|
|
|
ret = pci_dev_specific_acs_enabled(pdev, acs_flags);
|
|
|
|
if (ret >= 0)
|
|
|
|
return ret > 0;
|
|
|
|
|
2013-06-27 22:39:48 +00:00
|
|
|
/*
|
|
|
|
* Conventional PCI and PCI-X devices never support ACS, either
|
|
|
|
* effectively or actually. The shared bus topology implies that
|
|
|
|
* any device on the bus can receive or snoop DMA.
|
|
|
|
*/
|
2012-06-11 05:27:07 +00:00
|
|
|
if (!pci_is_pcie(pdev))
|
|
|
|
return false;
|
|
|
|
|
2013-06-27 22:39:48 +00:00
|
|
|
switch (pci_pcie_type(pdev)) {
|
|
|
|
/*
|
|
|
|
* PCI/X-to-PCIe bridges are not specifically mentioned by the spec,
|
2013-11-14 18:28:18 +00:00
|
|
|
* but since their primary interface is PCI/X, we conservatively
|
2013-06-27 22:39:48 +00:00
|
|
|
* handle them as we would a non-PCIe device.
|
|
|
|
*/
|
|
|
|
case PCI_EXP_TYPE_PCIE_BRIDGE:
|
|
|
|
/*
|
|
|
|
* PCIe 3.0, 6.12.1 excludes ACS on these devices. "ACS is never
|
|
|
|
* applicable... must never implement an ACS Extended Capability...".
|
|
|
|
* This seems arbitrary, but we take a conservative interpretation
|
|
|
|
* of this statement.
|
|
|
|
*/
|
|
|
|
case PCI_EXP_TYPE_PCI_BRIDGE:
|
|
|
|
case PCI_EXP_TYPE_RC_EC:
|
|
|
|
return false;
|
|
|
|
/*
|
|
|
|
* PCIe 3.0, 6.12.1.1 specifies that downstream and root ports should
|
|
|
|
* implement ACS in order to indicate their peer-to-peer capabilities,
|
|
|
|
* regardless of whether they are single- or multi-function devices.
|
|
|
|
*/
|
|
|
|
case PCI_EXP_TYPE_DOWNSTREAM:
|
|
|
|
case PCI_EXP_TYPE_ROOT_PORT:
|
|
|
|
return pci_acs_flags_enabled(pdev, acs_flags);
|
|
|
|
/*
|
|
|
|
* PCIe 3.0, 6.12.1.2 specifies ACS capabilities that should be
|
|
|
|
* implemented by the remaining PCIe types to indicate peer-to-peer
|
2013-11-14 18:28:18 +00:00
|
|
|
* capabilities, but only when they are part of a multifunction
|
2013-06-27 22:39:48 +00:00
|
|
|
* device. The footnote for section 6.12 indicates the specific
|
|
|
|
* PCIe types included here.
|
|
|
|
*/
|
|
|
|
case PCI_EXP_TYPE_ENDPOINT:
|
|
|
|
case PCI_EXP_TYPE_UPSTREAM:
|
|
|
|
case PCI_EXP_TYPE_LEG_END:
|
|
|
|
case PCI_EXP_TYPE_RC_END:
|
|
|
|
if (!pdev->multifunction)
|
|
|
|
break;
|
|
|
|
|
|
|
|
return pci_acs_flags_enabled(pdev, acs_flags);
|
2012-06-11 05:27:07 +00:00
|
|
|
}
|
|
|
|
|
2013-06-27 22:39:48 +00:00
|
|
|
/*
|
2013-11-14 18:28:18 +00:00
|
|
|
* PCIe 3.0, 6.12.1.3 specifies no ACS capabilities are applicable
|
2013-06-27 22:39:48 +00:00
|
|
|
* to single function devices with the exception of downstream ports.
|
|
|
|
*/
|
2012-06-11 05:27:07 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_acs_path_enable - test ACS flags from start to end in a hierarchy
|
|
|
|
* @start: starting downstream device
|
|
|
|
* @end: ending upstream device or NULL to search to the root bus
|
|
|
|
* @acs_flags: required flags
|
|
|
|
*
|
|
|
|
* Walk up a device tree from start to end testing PCI ACS support. If
|
|
|
|
* any step along the way does not support the required flags, return false.
|
|
|
|
*/
|
|
|
|
bool pci_acs_path_enabled(struct pci_dev *start,
|
|
|
|
struct pci_dev *end, u16 acs_flags)
|
|
|
|
{
|
|
|
|
struct pci_dev *pdev, *parent = start;
|
|
|
|
|
|
|
|
do {
|
|
|
|
pdev = parent;
|
|
|
|
|
|
|
|
if (!pci_acs_enabled(pdev, acs_flags))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (pci_is_root_bus(pdev->bus))
|
|
|
|
return (end == NULL);
|
|
|
|
|
|
|
|
parent = pdev->bus->self;
|
|
|
|
} while (pdev != end);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-10-24 19:40:20 +00:00
|
|
|
/**
|
|
|
|
* pci_rebar_find_pos - find position of resize ctrl reg for BAR
|
|
|
|
* @pdev: PCI device
|
|
|
|
* @bar: BAR to find
|
|
|
|
*
|
|
|
|
* Helper to find the position of the ctrl register for a BAR.
|
|
|
|
* Returns -ENOTSUPP if resizable BARs are not supported at all.
|
|
|
|
* Returns -ENOENT if no ctrl register for the BAR could be found.
|
|
|
|
*/
|
|
|
|
static int pci_rebar_find_pos(struct pci_dev *pdev, int bar)
|
|
|
|
{
|
|
|
|
unsigned int pos, nbars, i;
|
|
|
|
u32 ctrl;
|
|
|
|
|
|
|
|
pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
|
|
|
|
if (!pos)
|
|
|
|
return -ENOTSUPP;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
|
|
|
|
nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >>
|
|
|
|
PCI_REBAR_CTRL_NBAR_SHIFT;
|
|
|
|
|
|
|
|
for (i = 0; i < nbars; i++, pos += 8) {
|
|
|
|
int bar_idx;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
|
|
|
|
bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
|
|
|
|
if (bar_idx == bar)
|
|
|
|
return pos;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_rebar_get_possible_sizes - get possible sizes for BAR
|
|
|
|
* @pdev: PCI device
|
|
|
|
* @bar: BAR to query
|
|
|
|
*
|
|
|
|
* Get the possible sizes of a resizable BAR as bitmask defined in the spec
|
|
|
|
* (bit 0=1MB, bit 19=512GB). Returns 0 if BAR isn't resizable.
|
|
|
|
*/
|
|
|
|
u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
|
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
u32 cap;
|
|
|
|
|
|
|
|
pos = pci_rebar_find_pos(pdev, bar);
|
|
|
|
if (pos < 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
|
|
|
|
return (cap & PCI_REBAR_CAP_SIZES) >> 4;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_rebar_get_current_size - get the current size of a BAR
|
|
|
|
* @pdev: PCI device
|
|
|
|
* @bar: BAR to set size to
|
|
|
|
*
|
|
|
|
* Read the size of a BAR from the resizable BAR config.
|
|
|
|
* Returns size if found or negative error code.
|
|
|
|
*/
|
|
|
|
int pci_rebar_get_current_size(struct pci_dev *pdev, int bar)
|
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
u32 ctrl;
|
|
|
|
|
|
|
|
pos = pci_rebar_find_pos(pdev, bar);
|
|
|
|
if (pos < 0)
|
|
|
|
return pos;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
|
2018-06-30 00:55:03 +00:00
|
|
|
return (ctrl & PCI_REBAR_CTRL_BAR_SIZE) >> PCI_REBAR_CTRL_BAR_SHIFT;
|
2017-10-24 19:40:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_rebar_set_size - set a new size for a BAR
|
|
|
|
* @pdev: PCI device
|
|
|
|
* @bar: BAR to set size to
|
|
|
|
* @size: new size as defined in the spec (0=1MB, 19=512GB)
|
|
|
|
*
|
|
|
|
* Set the new size of a BAR as defined in the spec.
|
|
|
|
* Returns zero if resizing was successful, error code otherwise.
|
|
|
|
*/
|
|
|
|
int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size)
|
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
u32 ctrl;
|
|
|
|
|
|
|
|
pos = pci_rebar_find_pos(pdev, bar);
|
|
|
|
if (pos < 0)
|
|
|
|
return pos;
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
|
|
|
|
ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
|
2018-06-30 00:55:03 +00:00
|
|
|
ctrl |= size << PCI_REBAR_CTRL_BAR_SHIFT;
|
2017-10-24 19:40:20 +00:00
|
|
|
pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-01-05 00:44:59 +00:00
|
|
|
/**
|
|
|
|
* pci_enable_atomic_ops_to_root - enable AtomicOp requests to root port
|
|
|
|
* @dev: the PCI device
|
|
|
|
* @cap_mask: mask of desired AtomicOp sizes, including one or more of:
|
|
|
|
* PCI_EXP_DEVCAP2_ATOMIC_COMP32
|
|
|
|
* PCI_EXP_DEVCAP2_ATOMIC_COMP64
|
|
|
|
* PCI_EXP_DEVCAP2_ATOMIC_COMP128
|
|
|
|
*
|
|
|
|
* Return 0 if all upstream bridges support AtomicOp routing, egress
|
|
|
|
* blocking is disabled on all upstream ports, and the root port supports
|
|
|
|
* the requested completion capabilities (32-bit, 64-bit and/or 128-bit
|
|
|
|
* AtomicOp completion), or negative otherwise.
|
|
|
|
*/
|
|
|
|
int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
|
|
|
|
{
|
|
|
|
struct pci_bus *bus = dev->bus;
|
|
|
|
struct pci_dev *bridge;
|
|
|
|
u32 cap, ctl2;
|
|
|
|
|
|
|
|
if (!pci_is_pcie(dev))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Per PCIe r4.0, sec 6.15, endpoints and root ports may be
|
|
|
|
* AtomicOp requesters. For now, we only support endpoints as
|
|
|
|
* requesters and root ports as completers. No endpoints as
|
|
|
|
* completers, and no peer-to-peer.
|
|
|
|
*/
|
|
|
|
|
|
|
|
switch (pci_pcie_type(dev)) {
|
|
|
|
case PCI_EXP_TYPE_ENDPOINT:
|
|
|
|
case PCI_EXP_TYPE_LEG_END:
|
|
|
|
case PCI_EXP_TYPE_RC_END:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (bus->parent) {
|
|
|
|
bridge = bus->self;
|
|
|
|
|
|
|
|
pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2, &cap);
|
|
|
|
|
|
|
|
switch (pci_pcie_type(bridge)) {
|
|
|
|
/* Ensure switch ports support AtomicOp routing */
|
|
|
|
case PCI_EXP_TYPE_UPSTREAM:
|
|
|
|
case PCI_EXP_TYPE_DOWNSTREAM:
|
|
|
|
if (!(cap & PCI_EXP_DEVCAP2_ATOMIC_ROUTE))
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Ensure root port supports all the sizes we care about */
|
|
|
|
case PCI_EXP_TYPE_ROOT_PORT:
|
|
|
|
if ((cap & cap_mask) != cap_mask)
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Ensure upstream ports don't block AtomicOps on egress */
|
|
|
|
if (!bridge->has_secondary_link) {
|
|
|
|
pcie_capability_read_dword(bridge, PCI_EXP_DEVCTL2,
|
|
|
|
&ctl2);
|
|
|
|
if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_EGRESS_BLOCK)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
bus = bus->parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
pcie_capability_set_word(dev, PCI_EXP_DEVCTL2,
|
|
|
|
PCI_EXP_DEVCTL2_ATOMIC_REQ);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pci_enable_atomic_ops_to_root);
|
|
|
|
|
2008-12-11 18:24:23 +00:00
|
|
|
/**
|
|
|
|
* pci_swizzle_interrupt_pin - swizzle INTx for device behind bridge
|
|
|
|
* @dev: the PCI device
|
2013-05-28 03:17:41 +00:00
|
|
|
* @pin: the INTx pin (1=INTA, 2=INTB, 3=INTC, 4=INTD)
|
2008-12-11 18:24:23 +00:00
|
|
|
*
|
|
|
|
* Perform INTx swizzling for a device behind one level of bridge. This is
|
|
|
|
* required by section 9.1 of the PCI-to-PCI bridge specification for devices
|
2009-07-01 21:24:30 +00:00
|
|
|
* behind bridges on add-in cards. For devices with ARI enabled, the slot
|
|
|
|
* number is always 0 (see the Implementation Note in section 2.2.8.1 of
|
|
|
|
* the PCI Express Base Specification, Revision 2.1)
|
2008-12-11 18:24:23 +00:00
|
|
|
*/
|
2012-04-12 15:33:07 +00:00
|
|
|
u8 pci_swizzle_interrupt_pin(const struct pci_dev *dev, u8 pin)
|
2008-12-11 18:24:23 +00:00
|
|
|
{
|
2009-07-01 21:24:30 +00:00
|
|
|
int slot;
|
|
|
|
|
|
|
|
if (pci_ari_enabled(dev->bus))
|
|
|
|
slot = 0;
|
|
|
|
else
|
|
|
|
slot = PCI_SLOT(dev->devfn);
|
|
|
|
|
|
|
|
return (((pin - 1) + slot) % 4) + 1;
|
2008-12-11 18:24:23 +00:00
|
|
|
}
|
|
|
|
|
2014-04-19 00:13:49 +00:00
|
|
|
int pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
u8 pin;
|
|
|
|
|
2005-11-03 00:24:39 +00:00
|
|
|
pin = dev->pin;
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!pin)
|
|
|
|
return -1;
|
2008-12-09 23:11:46 +00:00
|
|
|
|
2009-05-26 07:07:33 +00:00
|
|
|
while (!pci_is_root_bus(dev->bus)) {
|
2008-12-11 18:24:23 +00:00
|
|
|
pin = pci_swizzle_interrupt_pin(dev, pin);
|
2005-04-16 22:20:36 +00:00
|
|
|
dev = dev->bus->self;
|
|
|
|
}
|
|
|
|
*bridge = dev;
|
|
|
|
return pin;
|
|
|
|
}
|
|
|
|
|
2008-12-17 04:36:55 +00:00
|
|
|
/**
|
|
|
|
* pci_common_swizzle - swizzle INTx all the way to root bridge
|
|
|
|
* @dev: the PCI device
|
|
|
|
* @pinp: pointer to the INTx pin value (1=INTA, 2=INTB, 3=INTD, 4=INTD)
|
|
|
|
*
|
|
|
|
* Perform INTx swizzling for a device. This traverses through all PCI-to-PCI
|
|
|
|
* bridges all the way up to a PCI root bus.
|
|
|
|
*/
|
|
|
|
u8 pci_common_swizzle(struct pci_dev *dev, u8 *pinp)
|
|
|
|
{
|
|
|
|
u8 pin = *pinp;
|
|
|
|
|
2009-05-26 07:08:36 +00:00
|
|
|
while (!pci_is_root_bus(dev->bus)) {
|
2008-12-17 04:36:55 +00:00
|
|
|
pin = pci_swizzle_interrupt_pin(dev, pin);
|
|
|
|
dev = dev->bus->self;
|
|
|
|
}
|
|
|
|
*pinp = pin;
|
|
|
|
return PCI_SLOT(dev->devfn);
|
|
|
|
}
|
2015-04-08 18:21:33 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_common_swizzle);
|
2008-12-17 04:36:55 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_release_region - Release a PCI bar
|
|
|
|
* @pdev: PCI device whose resources were previously reserved by
|
|
|
|
* pci_request_region()
|
|
|
|
* @bar: BAR to release
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Releases the PCI I/O and memory resources previously reserved by a
|
|
|
|
* successful call to pci_request_region(). Call this function only
|
|
|
|
* after all use of the PCI regions has ceased.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
void pci_release_region(struct pci_dev *pdev, int bar)
|
|
|
|
{
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
struct pci_devres *dr;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (pci_resource_len(pdev, bar) == 0)
|
|
|
|
return;
|
|
|
|
if (pci_resource_flags(pdev, bar) & IORESOURCE_IO)
|
|
|
|
release_region(pci_resource_start(pdev, bar),
|
|
|
|
pci_resource_len(pdev, bar));
|
|
|
|
else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM)
|
|
|
|
release_mem_region(pci_resource_start(pdev, bar),
|
|
|
|
pci_resource_len(pdev, bar));
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
|
|
|
|
dr = find_pci_dr(pdev);
|
|
|
|
if (dr)
|
|
|
|
dr->region_mask &= ~(1 << bar);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_release_region);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* __pci_request_region - Reserved PCI I/O and memory resource
|
|
|
|
* @pdev: PCI device whose resources are to be reserved
|
|
|
|
* @bar: BAR to be reserved
|
|
|
|
* @res_name: Name to be associated with resource.
|
|
|
|
* @exclusive: whether the region access is exclusive or not
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Mark the PCI region associated with PCI device @pdev BAR @bar as
|
|
|
|
* being reserved by owner @res_name. Do not access any
|
|
|
|
* address inside the PCI regions unless this call returns
|
|
|
|
* successfully.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* If @exclusive is set, then the region is marked so that userspace
|
|
|
|
* is explicitly not allowed to map the resource via /dev/mem or
|
|
|
|
* sysfs MMIO access.
|
2009-01-10 01:03:20 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Returns 0 on success, or %EBUSY on error. A warning
|
|
|
|
* message is also printed on failure.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
static int __pci_request_region(struct pci_dev *pdev, int bar,
|
|
|
|
const char *res_name, int exclusive)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
struct pci_devres *dr;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (pci_resource_len(pdev, bar) == 0)
|
|
|
|
return 0;
|
2013-11-14 18:28:18 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (pci_resource_flags(pdev, bar) & IORESOURCE_IO) {
|
|
|
|
if (!request_region(pci_resource_start(pdev, bar),
|
|
|
|
pci_resource_len(pdev, bar), res_name))
|
|
|
|
goto err_out;
|
2014-04-19 00:13:49 +00:00
|
|
|
} else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
|
2008-10-23 02:55:31 +00:00
|
|
|
if (!__request_mem_region(pci_resource_start(pdev, bar),
|
|
|
|
pci_resource_len(pdev, bar), res_name,
|
|
|
|
exclusive))
|
2005-04-16 22:20:36 +00:00
|
|
|
goto err_out;
|
|
|
|
}
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
|
|
|
|
dr = find_pci_dr(pdev);
|
|
|
|
if (dr)
|
|
|
|
dr->region_mask |= 1 << bar;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_out:
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_warn(pdev, "BAR %d: can't reserve %pR\n", bar,
|
2008-10-20 04:07:37 +00:00
|
|
|
&pdev->resource[bar]);
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
2008-10-23 02:55:31 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_request_region - Reserve PCI I/O and memory resource
|
|
|
|
* @pdev: PCI device whose resources are to be reserved
|
|
|
|
* @bar: BAR to be reserved
|
|
|
|
* @res_name: Name to be associated with resource
|
2008-10-23 02:55:31 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Mark the PCI region associated with PCI device @pdev BAR @bar as
|
|
|
|
* being reserved by owner @res_name. Do not access any
|
|
|
|
* address inside the PCI regions unless this call returns
|
|
|
|
* successfully.
|
2008-10-23 02:55:31 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Returns 0 on success, or %EBUSY on error. A warning
|
|
|
|
* message is also printed on failure.
|
2008-10-23 02:55:31 +00:00
|
|
|
*/
|
|
|
|
int pci_request_region(struct pci_dev *pdev, int bar, const char *res_name)
|
|
|
|
{
|
|
|
|
return __pci_request_region(pdev, bar, res_name, 0);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_request_region);
|
2008-10-23 02:55:31 +00:00
|
|
|
|
2006-12-18 01:31:06 +00:00
|
|
|
/**
|
|
|
|
* pci_release_selected_regions - Release selected PCI I/O and memory resources
|
|
|
|
* @pdev: PCI device whose resources were previously reserved
|
|
|
|
* @bars: Bitmask of BARs to be released
|
|
|
|
*
|
|
|
|
* Release selected PCI I/O and memory resources previously reserved.
|
|
|
|
* Call this function only after all use of the PCI regions has ceased.
|
|
|
|
*/
|
|
|
|
void pci_release_selected_regions(struct pci_dev *pdev, int bars)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 6; i++)
|
|
|
|
if (bars & (1 << i))
|
|
|
|
pci_release_region(pdev, i);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_release_selected_regions);
|
2006-12-18 01:31:06 +00:00
|
|
|
|
2013-04-12 17:20:03 +00:00
|
|
|
static int __pci_request_selected_regions(struct pci_dev *pdev, int bars,
|
2014-04-19 00:13:49 +00:00
|
|
|
const char *res_name, int excl)
|
2006-12-18 01:31:06 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 6; i++)
|
|
|
|
if (bars & (1 << i))
|
2008-10-23 02:55:31 +00:00
|
|
|
if (__pci_request_region(pdev, i, res_name, excl))
|
2006-12-18 01:31:06 +00:00
|
|
|
goto err_out;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_out:
|
2014-04-19 00:13:49 +00:00
|
|
|
while (--i >= 0)
|
2006-12-18 01:31:06 +00:00
|
|
|
if (bars & (1 << i))
|
|
|
|
pci_release_region(pdev, i);
|
|
|
|
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-10-23 02:55:31 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_request_selected_regions - Reserve selected PCI I/O and memory resources
|
|
|
|
* @pdev: PCI device whose resources are to be reserved
|
|
|
|
* @bars: Bitmask of BARs to be requested
|
|
|
|
* @res_name: Name to be associated with resource
|
|
|
|
*/
|
|
|
|
int pci_request_selected_regions(struct pci_dev *pdev, int bars,
|
|
|
|
const char *res_name)
|
|
|
|
{
|
|
|
|
return __pci_request_selected_regions(pdev, bars, res_name, 0);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_request_selected_regions);
|
2008-10-23 02:55:31 +00:00
|
|
|
|
2014-04-19 00:13:49 +00:00
|
|
|
int pci_request_selected_regions_exclusive(struct pci_dev *pdev, int bars,
|
|
|
|
const char *res_name)
|
2008-10-23 02:55:31 +00:00
|
|
|
{
|
|
|
|
return __pci_request_selected_regions(pdev, bars, res_name,
|
|
|
|
IORESOURCE_EXCLUSIVE);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_request_selected_regions_exclusive);
|
2008-10-23 02:55:31 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_release_regions - Release reserved PCI I/O and memory resources
|
|
|
|
* @pdev: PCI device whose resources were previously reserved by
|
|
|
|
* pci_request_regions()
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Releases all PCI I/O and memory resources previously reserved by a
|
|
|
|
* successful call to pci_request_regions(). Call this function only
|
|
|
|
* after all use of the PCI regions has ceased.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
void pci_release_regions(struct pci_dev *pdev)
|
|
|
|
{
|
2006-12-18 01:31:06 +00:00
|
|
|
pci_release_selected_regions(pdev, (1 << 6) - 1);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_release_regions);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_request_regions - Reserve PCI I/O and memory resources
|
|
|
|
* @pdev: PCI device whose resources are to be reserved
|
|
|
|
* @res_name: Name to be associated with resource.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Mark all PCI regions associated with PCI device @pdev as
|
|
|
|
* being reserved by owner @res_name. Do not access any
|
|
|
|
* address inside the PCI regions unless this call returns
|
|
|
|
* successfully.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Returns 0 on success, or %EBUSY on error. A warning
|
|
|
|
* message is also printed on failure.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2006-03-05 02:52:42 +00:00
|
|
|
int pci_request_regions(struct pci_dev *pdev, const char *res_name)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-12-18 01:31:06 +00:00
|
|
|
return pci_request_selected_regions(pdev, ((1 << 6) - 1), res_name);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_request_regions);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-10-23 02:55:31 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_request_regions_exclusive - Reserve PCI I/O and memory resources
|
|
|
|
* @pdev: PCI device whose resources are to be reserved
|
|
|
|
* @res_name: Name to be associated with resource.
|
2008-10-23 02:55:31 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Mark all PCI regions associated with PCI device @pdev as being reserved
|
|
|
|
* by owner @res_name. Do not access any address inside the PCI regions
|
|
|
|
* unless this call returns successfully.
|
2008-10-23 02:55:31 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_request_regions_exclusive() will mark the region so that /dev/mem
|
|
|
|
* and the sysfs MMIO access will not be allowed.
|
2008-10-23 02:55:31 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Returns 0 on success, or %EBUSY on error. A warning message is also
|
|
|
|
* printed on failure.
|
2008-10-23 02:55:31 +00:00
|
|
|
*/
|
|
|
|
int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
|
|
|
|
{
|
|
|
|
return pci_request_selected_regions_exclusive(pdev,
|
|
|
|
((1 << 6) - 1), res_name);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_request_regions_exclusive);
|
2008-10-23 02:55:31 +00:00
|
|
|
|
2016-05-11 22:34:51 +00:00
|
|
|
/*
|
|
|
|
* Record the PCI IO range (expressed as CPU physical address + size).
|
2019-01-09 20:14:42 +00:00
|
|
|
* Return a negative value if an error has occurred, zero otherwise
|
2016-05-11 22:34:51 +00:00
|
|
|
*/
|
2018-03-14 18:15:52 +00:00
|
|
|
int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
|
|
|
|
resource_size_t size)
|
2016-05-11 22:34:51 +00:00
|
|
|
{
|
2018-03-14 18:15:53 +00:00
|
|
|
int ret = 0;
|
2016-05-11 22:34:51 +00:00
|
|
|
#ifdef PCI_IOBASE
|
2018-03-14 18:15:53 +00:00
|
|
|
struct logic_pio_hwaddr *range;
|
2016-05-11 22:34:51 +00:00
|
|
|
|
2018-03-14 18:15:53 +00:00
|
|
|
if (!size || addr + size < addr)
|
|
|
|
return -EINVAL;
|
2016-05-11 22:34:51 +00:00
|
|
|
|
|
|
|
range = kzalloc(sizeof(*range), GFP_ATOMIC);
|
2018-03-14 18:15:53 +00:00
|
|
|
if (!range)
|
|
|
|
return -ENOMEM;
|
2016-05-11 22:34:51 +00:00
|
|
|
|
2018-03-14 18:15:53 +00:00
|
|
|
range->fwnode = fwnode;
|
2016-05-11 22:34:51 +00:00
|
|
|
range->size = size;
|
2018-03-14 18:15:53 +00:00
|
|
|
range->hw_start = addr;
|
|
|
|
range->flags = LOGIC_PIO_CPU_MMIO;
|
2016-05-11 22:34:51 +00:00
|
|
|
|
2018-03-14 18:15:53 +00:00
|
|
|
ret = logic_pio_register_range(range);
|
|
|
|
if (ret)
|
|
|
|
kfree(range);
|
2016-05-11 22:34:51 +00:00
|
|
|
#endif
|
|
|
|
|
2018-03-14 18:15:53 +00:00
|
|
|
return ret;
|
2016-05-11 22:34:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
phys_addr_t pci_pio_to_address(unsigned long pio)
|
|
|
|
{
|
|
|
|
phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
|
|
|
|
|
|
|
|
#ifdef PCI_IOBASE
|
2018-03-14 18:15:53 +00:00
|
|
|
if (pio >= MMIO_UPPER_LIMIT)
|
2016-05-11 22:34:51 +00:00
|
|
|
return address;
|
|
|
|
|
2018-03-14 18:15:53 +00:00
|
|
|
address = logic_pio_to_hwaddr(pio);
|
2016-05-11 22:34:51 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
return address;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned long __weak pci_address_to_pio(phys_addr_t address)
|
|
|
|
{
|
|
|
|
#ifdef PCI_IOBASE
|
2018-03-14 18:15:53 +00:00
|
|
|
return logic_pio_trans_cpuaddr(address);
|
2016-05-11 22:34:51 +00:00
|
|
|
#else
|
|
|
|
if (address > IO_SPACE_LIMIT)
|
|
|
|
return (unsigned long)-1;
|
|
|
|
|
|
|
|
return (unsigned long) address;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2014-09-29 14:29:30 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_remap_iospace - Remap the memory mapped I/O space
|
|
|
|
* @res: Resource describing the I/O space
|
|
|
|
* @phys_addr: physical address of range to be mapped
|
2014-09-29 14:29:30 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Remap the memory mapped I/O space described by the @res and the CPU
|
|
|
|
* physical address @phys_addr into virtual address space. Only
|
|
|
|
* architectures that have memory mapped IO functions defined (and the
|
|
|
|
* PCI_IOBASE value defined) should call this function.
|
2014-09-29 14:29:30 +00:00
|
|
|
*/
|
2017-04-19 16:48:50 +00:00
|
|
|
int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
|
2014-09-29 14:29:30 +00:00
|
|
|
{
|
|
|
|
#if defined(PCI_IOBASE) && defined(CONFIG_MMU)
|
|
|
|
unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
|
|
|
|
|
|
|
|
if (!(res->flags & IORESOURCE_IO))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (res->end > IO_SPACE_LIMIT)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
|
|
|
|
pgprot_device(PAGE_KERNEL));
|
|
|
|
#else
|
2019-01-09 20:14:42 +00:00
|
|
|
/*
|
|
|
|
* This architecture does not have memory mapped I/O space,
|
|
|
|
* so this function should never be called
|
|
|
|
*/
|
2014-09-29 14:29:30 +00:00
|
|
|
WARN_ONCE(1, "This architecture does not support memory mapped I/O\n");
|
|
|
|
return -ENODEV;
|
|
|
|
#endif
|
|
|
|
}
|
2017-03-10 02:46:16 +00:00
|
|
|
EXPORT_SYMBOL(pci_remap_iospace);
|
2014-09-29 14:29:30 +00:00
|
|
|
|
2016-06-10 19:55:11 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_unmap_iospace - Unmap the memory mapped I/O space
|
|
|
|
* @res: resource to be unmapped
|
2016-06-10 19:55:11 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Unmap the CPU virtual address @res from virtual address space. Only
|
|
|
|
* architectures that have memory mapped IO functions defined (and the
|
|
|
|
* PCI_IOBASE value defined) should call this function.
|
2016-06-10 19:55:11 +00:00
|
|
|
*/
|
|
|
|
void pci_unmap_iospace(struct resource *res)
|
|
|
|
{
|
|
|
|
#if defined(PCI_IOBASE) && defined(CONFIG_MMU)
|
|
|
|
unsigned long vaddr = (unsigned long)PCI_IOBASE + res->start;
|
|
|
|
|
|
|
|
unmap_kernel_range(vaddr, resource_size(res));
|
|
|
|
#endif
|
|
|
|
}
|
2017-03-10 02:46:16 +00:00
|
|
|
EXPORT_SYMBOL(pci_unmap_iospace);
|
2016-06-10 19:55:11 +00:00
|
|
|
|
2018-07-18 20:40:26 +00:00
|
|
|
static void devm_pci_unmap_iospace(struct device *dev, void *ptr)
|
|
|
|
{
|
|
|
|
struct resource **res = ptr;
|
|
|
|
|
|
|
|
pci_unmap_iospace(*res);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devm_pci_remap_iospace - Managed pci_remap_iospace()
|
|
|
|
* @dev: Generic device to remap IO address for
|
|
|
|
* @res: Resource describing the I/O space
|
|
|
|
* @phys_addr: physical address of range to be mapped
|
|
|
|
*
|
|
|
|
* Managed pci_remap_iospace(). Map is automatically unmapped on driver
|
|
|
|
* detach.
|
|
|
|
*/
|
|
|
|
int devm_pci_remap_iospace(struct device *dev, const struct resource *res,
|
|
|
|
phys_addr_t phys_addr)
|
|
|
|
{
|
|
|
|
const struct resource **ptr;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
ptr = devres_alloc(devm_pci_unmap_iospace, sizeof(*ptr), GFP_KERNEL);
|
|
|
|
if (!ptr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
error = pci_remap_iospace(res, phys_addr);
|
|
|
|
if (error) {
|
|
|
|
devres_free(ptr);
|
|
|
|
} else {
|
|
|
|
*ptr = res;
|
|
|
|
devres_add(dev, ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_pci_remap_iospace);
|
|
|
|
|
2017-04-19 16:48:55 +00:00
|
|
|
/**
|
|
|
|
* devm_pci_remap_cfgspace - Managed pci_remap_cfgspace()
|
|
|
|
* @dev: Generic device to remap IO address for
|
|
|
|
* @offset: Resource address to map
|
|
|
|
* @size: Size of map
|
|
|
|
*
|
|
|
|
* Managed pci_remap_cfgspace(). Map is automatically unmapped on driver
|
|
|
|
* detach.
|
|
|
|
*/
|
|
|
|
void __iomem *devm_pci_remap_cfgspace(struct device *dev,
|
|
|
|
resource_size_t offset,
|
|
|
|
resource_size_t size)
|
|
|
|
{
|
|
|
|
void __iomem **ptr, *addr;
|
|
|
|
|
|
|
|
ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
|
|
|
|
if (!ptr)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
addr = pci_remap_cfgspace(offset, size);
|
|
|
|
if (addr) {
|
|
|
|
*ptr = addr;
|
|
|
|
devres_add(dev, ptr);
|
|
|
|
} else
|
|
|
|
devres_free(ptr);
|
|
|
|
|
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_pci_remap_cfgspace);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devm_pci_remap_cfg_resource - check, request region and ioremap cfg resource
|
|
|
|
* @dev: generic device to handle the resource for
|
|
|
|
* @res: configuration space resource to be handled
|
|
|
|
*
|
|
|
|
* Checks that a resource is a valid memory region, requests the memory
|
|
|
|
* region and ioremaps with pci_remap_cfgspace() API that ensures the
|
|
|
|
* proper PCI configuration space memory attributes are guaranteed.
|
|
|
|
*
|
|
|
|
* All operations are managed and will be undone on driver detach.
|
|
|
|
*
|
|
|
|
* Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
|
2017-10-30 00:07:11 +00:00
|
|
|
* on failure. Usage example::
|
2017-04-19 16:48:55 +00:00
|
|
|
*
|
|
|
|
* res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
|
|
|
* base = devm_pci_remap_cfg_resource(&pdev->dev, res);
|
|
|
|
* if (IS_ERR(base))
|
|
|
|
* return PTR_ERR(base);
|
|
|
|
*/
|
|
|
|
void __iomem *devm_pci_remap_cfg_resource(struct device *dev,
|
|
|
|
struct resource *res)
|
|
|
|
{
|
|
|
|
resource_size_t size;
|
|
|
|
const char *name;
|
|
|
|
void __iomem *dest_ptr;
|
|
|
|
|
|
|
|
BUG_ON(!dev);
|
|
|
|
|
|
|
|
if (!res || resource_type(res) != IORESOURCE_MEM) {
|
|
|
|
dev_err(dev, "invalid resource\n");
|
|
|
|
return IOMEM_ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
size = resource_size(res);
|
|
|
|
name = res->name ?: dev_name(dev);
|
|
|
|
|
|
|
|
if (!devm_request_mem_region(dev, res->start, size, name)) {
|
|
|
|
dev_err(dev, "can't request region for resource %pR\n", res);
|
|
|
|
return IOMEM_ERR_PTR(-EBUSY);
|
|
|
|
}
|
|
|
|
|
|
|
|
dest_ptr = devm_pci_remap_cfgspace(dev, res->start, size);
|
|
|
|
if (!dest_ptr) {
|
|
|
|
dev_err(dev, "ioremap failed for resource %pR\n", res);
|
|
|
|
devm_release_mem_region(dev, res->start, size);
|
|
|
|
dest_ptr = IOMEM_ERR_PTR(-ENOMEM);
|
|
|
|
}
|
|
|
|
|
|
|
|
return dest_ptr;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_pci_remap_cfg_resource);
|
|
|
|
|
2008-12-23 03:08:29 +00:00
|
|
|
static void __pci_set_master(struct pci_dev *dev, bool enable)
|
|
|
|
{
|
|
|
|
u16 old_cmd, cmd;
|
|
|
|
|
|
|
|
pci_read_config_word(dev, PCI_COMMAND, &old_cmd);
|
|
|
|
if (enable)
|
|
|
|
cmd = old_cmd | PCI_COMMAND_MASTER;
|
|
|
|
else
|
|
|
|
cmd = old_cmd & ~PCI_COMMAND_MASTER;
|
|
|
|
if (cmd != old_cmd) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_dbg(dev, "%s bus mastering\n",
|
2008-12-23 03:08:29 +00:00
|
|
|
enable ? "enabling" : "disabling");
|
|
|
|
pci_write_config_word(dev, PCI_COMMAND, cmd);
|
|
|
|
}
|
|
|
|
dev->is_busmaster = enable;
|
|
|
|
}
|
2008-10-23 02:55:31 +00:00
|
|
|
|
2012-06-26 03:30:57 +00:00
|
|
|
/**
|
|
|
|
* pcibios_setup - process "pci=" kernel boot arguments
|
|
|
|
* @str: string used to pass in "pci=" kernel boot arguments
|
|
|
|
*
|
|
|
|
* Process kernel boot arguments. This is the default implementation.
|
|
|
|
* Architecture specific implementations can override this as necessary.
|
|
|
|
*/
|
|
|
|
char * __weak __init pcibios_setup(char *str)
|
|
|
|
{
|
|
|
|
return str;
|
|
|
|
}
|
|
|
|
|
2011-10-28 21:48:38 +00:00
|
|
|
/**
|
|
|
|
* pcibios_set_master - enable PCI bus-mastering for device dev
|
|
|
|
* @dev: the PCI device to enable
|
|
|
|
*
|
|
|
|
* Enables PCI bus-mastering for the device. This is the default
|
|
|
|
* implementation. Architecture specific implementations can override
|
|
|
|
* this if necessary.
|
|
|
|
*/
|
|
|
|
void __weak pcibios_set_master(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
u8 lat;
|
|
|
|
|
2011-10-28 21:49:20 +00:00
|
|
|
/* The latency timer doesn't apply to PCIe (either Type 0 or Type 1) */
|
|
|
|
if (pci_is_pcie(dev))
|
|
|
|
return;
|
|
|
|
|
2011-10-28 21:48:38 +00:00
|
|
|
pci_read_config_byte(dev, PCI_LATENCY_TIMER, &lat);
|
|
|
|
if (lat < 16)
|
|
|
|
lat = (64 <= pcibios_max_latency) ? 64 : pcibios_max_latency;
|
|
|
|
else if (lat > pcibios_max_latency)
|
|
|
|
lat = pcibios_max_latency;
|
|
|
|
else
|
|
|
|
return;
|
2013-09-23 21:25:26 +00:00
|
|
|
|
2011-10-28 21:48:38 +00:00
|
|
|
pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* pci_set_master - enables bus-mastering for device dev
|
|
|
|
* @dev: the PCI device to enable
|
|
|
|
*
|
|
|
|
* Enables bus-mastering on the device and calls pcibios_set_master()
|
|
|
|
* to do the needed arch specific settings.
|
|
|
|
*/
|
2008-12-23 03:08:29 +00:00
|
|
|
void pci_set_master(struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-12-23 03:08:29 +00:00
|
|
|
__pci_set_master(dev, true);
|
2005-04-16 22:20:36 +00:00
|
|
|
pcibios_set_master(dev);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_set_master);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-12-23 03:08:29 +00:00
|
|
|
/**
|
|
|
|
* pci_clear_master - disables bus-mastering for device dev
|
|
|
|
* @dev: the PCI device to disable
|
|
|
|
*/
|
|
|
|
void pci_clear_master(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
__pci_set_master(dev, false);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_clear_master);
|
2008-12-23 03:08:29 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
2006-10-10 14:01:21 +00:00
|
|
|
* pci_set_cacheline_size - ensure the CACHE_LINE_SIZE register is programmed
|
|
|
|
* @dev: the PCI device for which MWI is to be enabled
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2006-10-10 14:01:21 +00:00
|
|
|
* Helper function for pci_set_mwi.
|
|
|
|
* Originally copied from drivers/net/acenic.c.
|
2005-04-16 22:20:36 +00:00
|
|
|
* Copyright 1998-2001 by Jes Sorensen, <jes@trained-monkey.org>.
|
|
|
|
*
|
|
|
|
* RETURNS: An appropriate -ERRNO error value on error, or zero for success.
|
|
|
|
*/
|
2009-09-22 08:34:48 +00:00
|
|
|
int pci_set_cacheline_size(struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
u8 cacheline_size;
|
|
|
|
|
|
|
|
if (!pci_cache_line_size)
|
2009-09-22 08:34:48 +00:00
|
|
|
return -EINVAL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Validate current setting: the PCI_CACHE_LINE_SIZE must be
|
|
|
|
equal to or multiple of the right value. */
|
|
|
|
pci_read_config_byte(dev, PCI_CACHE_LINE_SIZE, &cacheline_size);
|
|
|
|
if (cacheline_size >= pci_cache_line_size &&
|
|
|
|
(cacheline_size % pci_cache_line_size) == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Write the correct value. */
|
|
|
|
pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, pci_cache_line_size);
|
|
|
|
/* Read it back. */
|
|
|
|
pci_read_config_byte(dev, PCI_CACHE_LINE_SIZE, &cacheline_size);
|
|
|
|
if (cacheline_size == pci_cache_line_size)
|
|
|
|
return 0;
|
|
|
|
|
2019-04-20 04:07:20 +00:00
|
|
|
pci_info(dev, "cache line size of %d is not supported\n",
|
2014-04-19 00:13:50 +00:00
|
|
|
pci_cache_line_size << 2);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2009-09-22 08:34:48 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_set_cacheline_size);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* pci_set_mwi - enables memory-write-invalidate PCI transaction
|
|
|
|
* @dev: the PCI device for which MWI is enabled
|
|
|
|
*
|
2007-07-09 18:55:54 +00:00
|
|
|
* Enables the Memory-Write-Invalidate transaction in %PCI_COMMAND.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* RETURNS: An appropriate -ERRNO error value on error, or zero for success.
|
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
int pci_set_mwi(struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-04-25 20:32:25 +00:00
|
|
|
#ifdef PCI_DISABLE_MWI
|
|
|
|
return 0;
|
|
|
|
#else
|
2005-04-16 22:20:36 +00:00
|
|
|
int rc;
|
|
|
|
u16 cmd;
|
|
|
|
|
2006-10-10 14:01:21 +00:00
|
|
|
rc = pci_set_cacheline_size(dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
pci_read_config_word(dev, PCI_COMMAND, &cmd);
|
2014-04-19 00:13:49 +00:00
|
|
|
if (!(cmd & PCI_COMMAND_INVALIDATE)) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_dbg(dev, "enabling Mem-Wr-Inval\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
cmd |= PCI_COMMAND_INVALIDATE;
|
|
|
|
pci_write_config_word(dev, PCI_COMMAND, cmd);
|
|
|
|
}
|
|
|
|
return 0;
|
2014-04-25 20:32:25 +00:00
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_set_mwi);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2017-12-12 06:40:56 +00:00
|
|
|
/**
|
|
|
|
* pcim_set_mwi - a device-managed pci_set_mwi()
|
|
|
|
* @dev: the PCI device for which MWI is enabled
|
|
|
|
*
|
|
|
|
* Managed pci_set_mwi().
|
|
|
|
*
|
|
|
|
* RETURNS: An appropriate -ERRNO error value on error, or zero for success.
|
|
|
|
*/
|
|
|
|
int pcim_set_mwi(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
struct pci_devres *dr;
|
|
|
|
|
|
|
|
dr = find_pci_dr(dev);
|
|
|
|
if (!dr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
dr->mwi = 1;
|
|
|
|
return pci_set_mwi(dev);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pcim_set_mwi);
|
|
|
|
|
2007-07-09 18:55:54 +00:00
|
|
|
/**
|
|
|
|
* pci_try_set_mwi - enables memory-write-invalidate PCI transaction
|
|
|
|
* @dev: the PCI device for which MWI is enabled
|
|
|
|
*
|
|
|
|
* Enables the Memory-Write-Invalidate transaction in %PCI_COMMAND.
|
|
|
|
* Callers are not required to check the return value.
|
|
|
|
*
|
|
|
|
* RETURNS: An appropriate -ERRNO error value on error, or zero for success.
|
|
|
|
*/
|
|
|
|
int pci_try_set_mwi(struct pci_dev *dev)
|
|
|
|
{
|
2014-04-25 20:32:25 +00:00
|
|
|
#ifdef PCI_DISABLE_MWI
|
|
|
|
return 0;
|
|
|
|
#else
|
|
|
|
return pci_set_mwi(dev);
|
|
|
|
#endif
|
2007-07-09 18:55:54 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_try_set_mwi);
|
2007-07-09 18:55:54 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/**
|
|
|
|
* pci_clear_mwi - disables Memory-Write-Invalidate for device dev
|
|
|
|
* @dev: the PCI device to disable
|
|
|
|
*
|
|
|
|
* Disables PCI Memory-Write-Invalidate transaction on the device
|
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
void pci_clear_mwi(struct pci_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2014-04-25 20:32:25 +00:00
|
|
|
#ifndef PCI_DISABLE_MWI
|
2005-04-16 22:20:36 +00:00
|
|
|
u16 cmd;
|
|
|
|
|
|
|
|
pci_read_config_word(dev, PCI_COMMAND, &cmd);
|
|
|
|
if (cmd & PCI_COMMAND_INVALIDATE) {
|
|
|
|
cmd &= ~PCI_COMMAND_INVALIDATE;
|
|
|
|
pci_write_config_word(dev, PCI_COMMAND, cmd);
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_clear_mwi);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-08-15 19:23:41 +00:00
|
|
|
/**
|
|
|
|
* pci_intx - enables/disables PCI INTx for device dev
|
2005-10-23 18:57:38 +00:00
|
|
|
* @pdev: the PCI device to operate on
|
|
|
|
* @enable: boolean: whether to enable or disable PCI INTx
|
2005-08-15 19:23:41 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Enables/disables PCI INTx for device @pdev
|
2005-08-15 19:23:41 +00:00
|
|
|
*/
|
2014-04-19 00:13:49 +00:00
|
|
|
void pci_intx(struct pci_dev *pdev, int enable)
|
2005-08-15 19:23:41 +00:00
|
|
|
{
|
|
|
|
u16 pci_command, new;
|
|
|
|
|
|
|
|
pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
|
|
|
|
|
2014-04-19 00:13:49 +00:00
|
|
|
if (enable)
|
2005-08-15 19:23:41 +00:00
|
|
|
new = pci_command & ~PCI_COMMAND_INTX_DISABLE;
|
2014-04-19 00:13:49 +00:00
|
|
|
else
|
2005-08-15 19:23:41 +00:00
|
|
|
new = pci_command | PCI_COMMAND_INTX_DISABLE;
|
|
|
|
|
|
|
|
if (new != pci_command) {
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
struct pci_devres *dr;
|
|
|
|
|
2005-09-09 17:02:22 +00:00
|
|
|
pci_write_config_word(pdev, PCI_COMMAND, new);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 07:00:26 +00:00
|
|
|
|
|
|
|
dr = find_pci_dr(pdev);
|
|
|
|
if (dr && !dr->restore_intx) {
|
|
|
|
dr->restore_intx = 1;
|
|
|
|
dr->orig_intx = !enable;
|
|
|
|
}
|
2005-08-15 19:23:41 +00:00
|
|
|
}
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_intx);
|
2005-08-15 19:23:41 +00:00
|
|
|
|
2011-11-04 08:46:00 +00:00
|
|
|
static bool pci_check_and_set_intx_mask(struct pci_dev *dev, bool mask)
|
|
|
|
{
|
|
|
|
struct pci_bus *bus = dev->bus;
|
|
|
|
bool mask_updated = true;
|
|
|
|
u32 cmd_status_dword;
|
|
|
|
u16 origcmd, newcmd;
|
|
|
|
unsigned long flags;
|
|
|
|
bool irq_pending;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We do a single dword read to retrieve both command and status.
|
|
|
|
* Document assumptions that make this possible.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(PCI_COMMAND % 4);
|
|
|
|
BUILD_BUG_ON(PCI_COMMAND + 2 != PCI_STATUS);
|
|
|
|
|
|
|
|
raw_spin_lock_irqsave(&pci_lock, flags);
|
|
|
|
|
|
|
|
bus->ops->read(bus, dev->devfn, PCI_COMMAND, 4, &cmd_status_dword);
|
|
|
|
|
|
|
|
irq_pending = (cmd_status_dword >> 16) & PCI_STATUS_INTERRUPT;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check interrupt status register to see whether our device
|
|
|
|
* triggered the interrupt (when masking) or the next IRQ is
|
|
|
|
* already pending (when unmasking).
|
|
|
|
*/
|
|
|
|
if (mask != irq_pending) {
|
|
|
|
mask_updated = false;
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
origcmd = cmd_status_dword;
|
|
|
|
newcmd = origcmd & ~PCI_COMMAND_INTX_DISABLE;
|
|
|
|
if (mask)
|
|
|
|
newcmd |= PCI_COMMAND_INTX_DISABLE;
|
|
|
|
if (newcmd != origcmd)
|
|
|
|
bus->ops->write(bus, dev->devfn, PCI_COMMAND, 2, newcmd);
|
|
|
|
|
|
|
|
done:
|
|
|
|
raw_spin_unlock_irqrestore(&pci_lock, flags);
|
|
|
|
|
|
|
|
return mask_updated;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_check_and_mask_intx - mask INTx on pending interrupt
|
2012-01-21 19:02:35 +00:00
|
|
|
* @dev: the PCI device to operate on
|
2011-11-04 08:46:00 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Check if the device dev has its INTx line asserted, mask it and return
|
|
|
|
* true in that case. False is returned if no interrupt was pending.
|
2011-11-04 08:46:00 +00:00
|
|
|
*/
|
|
|
|
bool pci_check_and_mask_intx(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
return pci_check_and_set_intx_mask(dev, true);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_check_and_mask_intx);
|
|
|
|
|
|
|
|
/**
|
2014-01-15 00:10:39 +00:00
|
|
|
* pci_check_and_unmask_intx - unmask INTx if no interrupt is pending
|
2012-01-21 19:02:35 +00:00
|
|
|
* @dev: the PCI device to operate on
|
2011-11-04 08:46:00 +00:00
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Check if the device dev has its INTx line asserted, unmask it if not and
|
|
|
|
* return true. False is returned and the mask remains active if there was
|
|
|
|
* still an interrupt pending.
|
2011-11-04 08:46:00 +00:00
|
|
|
*/
|
|
|
|
bool pci_check_and_unmask_intx(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
return pci_check_and_set_intx_mask(dev, false);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_check_and_unmask_intx);
|
|
|
|
|
2013-08-06 10:18:36 +00:00
|
|
|
/**
|
2019-01-09 20:14:42 +00:00
|
|
|
* pci_wait_for_pending_transaction - wait for pending transaction
|
2013-08-06 10:18:36 +00:00
|
|
|
* @dev: the PCI device to operate on
|
|
|
|
*
|
|
|
|
* Return 0 if transaction is pending 1 otherwise.
|
|
|
|
*/
|
|
|
|
int pci_wait_for_pending_transaction(struct pci_dev *dev)
|
2008-10-21 09:38:25 +00:00
|
|
|
{
|
2013-12-17 23:43:39 +00:00
|
|
|
if (!pci_is_pcie(dev))
|
|
|
|
return 1;
|
2009-06-13 07:52:13 +00:00
|
|
|
|
2014-05-19 03:06:46 +00:00
|
|
|
return pci_wait_for_pending(dev, pci_pcie_cap(dev) + PCI_EXP_DEVSTA,
|
|
|
|
PCI_EXP_DEVSTA_TRPND);
|
2013-08-06 10:18:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pci_wait_for_pending_transaction);
|
|
|
|
|
2018-02-27 20:14:10 +00:00
|
|
|
static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
|
2016-02-22 20:05:48 +00:00
|
|
|
{
|
2018-02-27 20:14:10 +00:00
|
|
|
int delay = 1;
|
2016-02-22 20:05:48 +00:00
|
|
|
u32 id;
|
|
|
|
|
2017-08-29 19:45:45 +00:00
|
|
|
/*
|
2018-02-27 20:14:10 +00:00
|
|
|
* After reset, the device should not silently discard config
|
2017-08-29 19:45:45 +00:00
|
|
|
* requests, but it may still indicate that it needs more time by
|
|
|
|
* responding to them with CRS completions. The Root Port will
|
|
|
|
* generally synthesize ~0 data to complete the read (except when
|
|
|
|
* CRS SV is enabled and the read was for the Vendor ID; in that
|
|
|
|
* case it synthesizes 0x0001 data).
|
|
|
|
*
|
|
|
|
* Wait for the device to return a non-CRS completion. Read the
|
|
|
|
* Command register instead of Vendor ID so we don't have to
|
|
|
|
* contend with the CRS SV value.
|
|
|
|
*/
|
|
|
|
pci_read_config_dword(dev, PCI_COMMAND, &id);
|
|
|
|
while (id == ~0) {
|
|
|
|
if (delay > timeout) {
|
2018-02-27 20:14:10 +00:00
|
|
|
pci_warn(dev, "not ready %dms after %s; giving up\n",
|
|
|
|
delay - 1, reset_type);
|
2018-02-27 20:14:08 +00:00
|
|
|
return -ENOTTY;
|
2017-08-29 19:45:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (delay > 1000)
|
2018-02-27 20:14:10 +00:00
|
|
|
pci_info(dev, "not ready %dms after %s; waiting\n",
|
|
|
|
delay - 1, reset_type);
|
2017-08-29 19:45:45 +00:00
|
|
|
|
|
|
|
msleep(delay);
|
|
|
|
delay *= 2;
|
2016-02-22 20:05:48 +00:00
|
|
|
pci_read_config_dword(dev, PCI_COMMAND, &id);
|
2017-08-29 19:45:45 +00:00
|
|
|
}
|
2016-02-22 20:05:48 +00:00
|
|
|
|
2017-08-29 19:45:45 +00:00
|
|
|
if (delay > 1000)
|
2018-02-27 20:14:10 +00:00
|
|
|
pci_info(dev, "ready %dms after %s\n", delay - 1,
|
|
|
|
reset_type);
|
2018-02-27 20:14:08 +00:00
|
|
|
|
|
|
|
return 0;
|
2016-02-22 20:05:48 +00:00
|
|
|
}
|
|
|
|
|
2017-04-14 19:11:25 +00:00
|
|
|
/**
|
|
|
|
* pcie_has_flr - check if a device supports function level resets
|
2019-01-09 20:14:42 +00:00
|
|
|
* @dev: device to check
|
2017-04-14 19:11:25 +00:00
|
|
|
*
|
|
|
|
* Returns true if the device advertises support for PCIe function level
|
|
|
|
* resets.
|
|
|
|
*/
|
2018-08-09 20:04:14 +00:00
|
|
|
bool pcie_has_flr(struct pci_dev *dev)
|
2013-08-06 10:18:36 +00:00
|
|
|
{
|
|
|
|
u32 cap;
|
|
|
|
|
2017-04-03 21:02:50 +00:00
|
|
|
if (dev->dev_flags & PCI_DEV_FLAGS_NO_FLR_RESET)
|
2017-04-14 19:11:25 +00:00
|
|
|
return false;
|
2013-08-06 10:18:36 +00:00
|
|
|
|
2017-04-14 19:11:25 +00:00
|
|
|
pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &cap);
|
|
|
|
return cap & PCI_EXP_DEVCAP_FLR;
|
|
|
|
}
|
2018-08-09 20:04:14 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pcie_has_flr);
|
2013-08-06 10:18:36 +00:00
|
|
|
|
2017-04-14 19:11:25 +00:00
|
|
|
/**
|
|
|
|
* pcie_flr - initiate a PCIe function level reset
|
2019-01-09 20:14:42 +00:00
|
|
|
* @dev: device to reset
|
2017-04-14 19:11:25 +00:00
|
|
|
*
|
|
|
|
* Initiate a function level reset on @dev. The caller should ensure the
|
|
|
|
* device supports FLR before calling this function, e.g. by using the
|
|
|
|
* pcie_has_flr() helper.
|
|
|
|
*/
|
2018-02-27 20:14:08 +00:00
|
|
|
int pcie_flr(struct pci_dev *dev)
|
2017-04-14 19:11:25 +00:00
|
|
|
{
|
2013-08-06 10:18:36 +00:00
|
|
|
if (!pci_wait_for_pending_transaction(dev))
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "timed out waiting for pending transaction; performing function level reset anyway\n");
|
2009-06-13 07:52:13 +00:00
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR);
|
2018-02-27 20:14:10 +00:00
|
|
|
|
2018-09-07 06:16:51 +00:00
|
|
|
if (dev->imm_ready)
|
|
|
|
return 0;
|
|
|
|
|
2018-02-27 20:14:10 +00:00
|
|
|
/*
|
|
|
|
* Per PCIe r4.0, sec 6.6.2, a device must complete an FLR within
|
|
|
|
* 100ms, but may silently discard requests while the FLR is in
|
|
|
|
* progress. Wait 100ms before trying to access the device.
|
|
|
|
*/
|
|
|
|
msleep(100);
|
|
|
|
|
|
|
|
return pci_dev_wait(dev, "FLR", PCIE_RESET_READY_POLL_MS);
|
2008-10-21 09:38:25 +00:00
|
|
|
}
|
2017-04-14 19:11:25 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pcie_flr);
|
2008-11-11 09:17:47 +00:00
|
|
|
|
2009-06-13 07:52:13 +00:00
|
|
|
static int pci_af_flr(struct pci_dev *dev, int probe)
|
2008-11-11 09:17:48 +00:00
|
|
|
{
|
2009-06-13 07:52:13 +00:00
|
|
|
int pos;
|
2008-11-11 09:17:48 +00:00
|
|
|
u8 cap;
|
|
|
|
|
2009-06-13 07:52:13 +00:00
|
|
|
pos = pci_find_capability(dev, PCI_CAP_ID_AF);
|
|
|
|
if (!pos)
|
2008-11-11 09:17:48 +00:00
|
|
|
return -ENOTTY;
|
2009-06-13 07:52:13 +00:00
|
|
|
|
2017-04-03 21:02:50 +00:00
|
|
|
if (dev->dev_flags & PCI_DEV_FLAGS_NO_FLR_RESET)
|
|
|
|
return -ENOTTY;
|
|
|
|
|
2009-06-13 07:52:13 +00:00
|
|
|
pci_read_config_byte(dev, pos + PCI_AF_CAP, &cap);
|
2008-11-11 09:17:48 +00:00
|
|
|
if (!(cap & PCI_AF_CAP_TP) || !(cap & PCI_AF_CAP_FLR))
|
|
|
|
return -ENOTTY;
|
|
|
|
|
|
|
|
if (probe)
|
|
|
|
return 0;
|
|
|
|
|
2014-06-17 21:40:13 +00:00
|
|
|
/*
|
|
|
|
* Wait for Transaction Pending bit to clear. A word-aligned test
|
2019-05-30 13:05:58 +00:00
|
|
|
* is used, so we use the control offset rather than status and shift
|
2014-06-17 21:40:13 +00:00
|
|
|
* the test bit to match.
|
|
|
|
*/
|
2014-11-12 02:41:51 +00:00
|
|
|
if (!pci_wait_for_pending(dev, pos + PCI_AF_CTRL,
|
2014-06-17 21:40:13 +00:00
|
|
|
PCI_AF_STATUS_TP << 8))
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_err(dev, "timed out waiting for pending transaction; performing AF function level reset anyway\n");
|
2009-02-09 06:53:47 +00:00
|
|
|
|
2009-06-13 07:52:13 +00:00
|
|
|
pci_write_config_byte(dev, pos + PCI_AF_CTRL, PCI_AF_CTRL_FLR);
|
2018-02-27 20:14:10 +00:00
|
|
|
|
2018-09-07 06:16:51 +00:00
|
|
|
if (dev->imm_ready)
|
|
|
|
return 0;
|
|
|
|
|
2018-02-27 20:14:10 +00:00
|
|
|
/*
|
|
|
|
* Per Advanced Capabilities for Conventional PCI ECN, 13 April 2006,
|
|
|
|
* updated 27 July 2006; a device must complete an FLR within
|
|
|
|
* 100ms, but may silently discard requests while the FLR is in
|
|
|
|
* progress. Wait 100ms before trying to access the device.
|
|
|
|
*/
|
|
|
|
msleep(100);
|
|
|
|
|
|
|
|
return pci_dev_wait(dev, "AF_FLR", PCIE_RESET_READY_POLL_MS);
|
2008-11-11 09:17:48 +00:00
|
|
|
}
|
|
|
|
|
2011-03-05 20:48:44 +00:00
|
|
|
/**
|
|
|
|
* pci_pm_reset - Put device into PCI_D3 and back into PCI_D0.
|
|
|
|
* @dev: Device to reset.
|
|
|
|
* @probe: If set, only check if the device can be reset this way.
|
|
|
|
*
|
|
|
|
* If @dev supports native PCI PM and its PCI_PM_CTRL_NO_SOFT_RESET flag is
|
|
|
|
* unset, it will be reinitialized internally when going from PCI_D3hot to
|
|
|
|
* PCI_D0. If that's the case and the device is not in a low-power state
|
|
|
|
* already, force it into PCI_D3hot and back to PCI_D0, causing it to be reset.
|
|
|
|
*
|
|
|
|
* NOTE: This causes the caller to sleep for twice the device power transition
|
|
|
|
* cooldown period, which for the D0->D3hot and D3hot->D0 transitions is 10 ms
|
2013-11-14 18:28:18 +00:00
|
|
|
* by default (i.e. unless the @dev's d3_delay field has a different value).
|
2011-03-05 20:48:44 +00:00
|
|
|
* Moreover, only devices in D0 can be reset by this function.
|
|
|
|
*/
|
2009-06-13 07:52:14 +00:00
|
|
|
static int pci_pm_reset(struct pci_dev *dev, int probe)
|
2008-11-11 09:17:47 +00:00
|
|
|
{
|
2009-06-13 07:52:14 +00:00
|
|
|
u16 csr;
|
|
|
|
|
2014-11-21 18:24:08 +00:00
|
|
|
if (!dev->pm_cap || dev->dev_flags & PCI_DEV_FLAGS_NO_PM_RESET)
|
2009-06-13 07:52:14 +00:00
|
|
|
return -ENOTTY;
|
2008-11-11 09:17:47 +00:00
|
|
|
|
2009-06-13 07:52:14 +00:00
|
|
|
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &csr);
|
|
|
|
if (csr & PCI_PM_CTRL_NO_SOFT_RESET)
|
|
|
|
return -ENOTTY;
|
2008-11-11 09:17:47 +00:00
|
|
|
|
2009-06-13 07:52:14 +00:00
|
|
|
if (probe)
|
|
|
|
return 0;
|
2008-11-11 09:17:48 +00:00
|
|
|
|
2009-06-13 07:52:14 +00:00
|
|
|
if (dev->current_state != PCI_D0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
csr &= ~PCI_PM_CTRL_STATE_MASK;
|
|
|
|
csr |= PCI_D3hot;
|
|
|
|
pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, csr);
|
2009-12-31 11:15:54 +00:00
|
|
|
pci_dev_d3_sleep(dev);
|
2009-06-13 07:52:14 +00:00
|
|
|
|
|
|
|
csr &= ~PCI_PM_CTRL_STATE_MASK;
|
|
|
|
csr |= PCI_D0;
|
|
|
|
pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, csr);
|
2009-12-31 11:15:54 +00:00
|
|
|
pci_dev_d3_sleep(dev);
|
2009-06-13 07:52:14 +00:00
|
|
|
|
2018-02-27 20:14:10 +00:00
|
|
|
return pci_dev_wait(dev, "PM D3->D0", PCIE_RESET_READY_POLL_MS);
|
2009-06-13 07:52:14 +00:00
|
|
|
}
|
PCI: Add missing link delays required by the PCIe spec
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that
consists of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
+-01.0-[04-36]-- DS hotplug port
+-02.0-[37]----00.0 xHCI controller
\-04.0-[38-6b]-- DS hotplug port
The root port (1b.0) and the PCIe switch downstream ports are all PCIe
gen3 so they support 8GT/s link speeds.
We wait for the PCIe hierarchy to enter D3cold (runtime):
pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the
PCIe switch is put to reset and its power is re-applied. This means that
we must follow the rules in PCIe 4.0 section 6.6.1.
For the PCIe gen3 ports we are dealing with here, the following applies:
With a Downstream Port that supports Link speeds greater than 5.0
GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port. Software can determine when Link training
completes by polling the Data Link Layer Link Active bit or by setting
up an associated interrupt (see Section 6.7.3.3).
Translating this into the above topology we would need to do this (DLLLA
stands for Data Link Layer Link Active):
pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0
pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0
I've instrumented the kernel with additional logging so we can see the
actual delays the kernel performs:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
pcieport 0000:00:1b.0: waking up bus
pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:00:1b.0: PME# disabled
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:01:00.0: PME# disabled
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:00.0: PME# disabled
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:01.0: PME# disabled
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: PME# disabled
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:04.0: PME# disabled
pcieport 0000:02:01.0: PME# enabled
pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:04.0: PME# enabled
pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
...
thunderbolt 0000:03:00.0: PME# disabled
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
xhci_hcd 0000:37:00.0: PME# disabled
For the switch upstream port (01:00.0) we wait for 100ms but not taking
into account the DLLLA requirement. We then wait 10ms for D3hot -> D0
transition of the root port and the two downstream hotplug ports. This
means that we deviate from what the spec requires.
Performing the same check for system sleep (s2idle) transitions we can
see following when resuming from s2idle:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0)
pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001)
pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702)
pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001)
pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00)
pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400)
pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151)
pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00)
pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161)
pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402)
pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802)
pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302)
pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
This is even worse. None of the mandatory delays are performed. If this
would be S3 instead of s2idle then according to PCI FW spec 3.2 section
4.6.8. there is a specific _DSM that allows the OS to skip the delays
but this platform does not provide the _DSM and does not go to S3 anyway
so no firmware is involved that could already handle these delays.
In this particular Intel Coffee Lake platform these delays are not
actually needed because there is an additional delay as part of the ACPI
power resource that is used to turn on power to the hierarchy but since
that additional delay is not required by any of standards (PCIe, ACPI)
it is not present in the Intel Ice Lake, for example where missing the
mandatory delays causes pciehp to start tearing down the stack too early
(links are not yet trained).
For this reason, change the PCIe portdrv PM resume hooks so that they
perform the mandatory delays before the downstream component gets
resumed. We perform the delays before port services are resumed because
otherwise pciehp might find that the link is not up (even if it is just
training) and tears-down the hierarchy.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-12 10:57:38 +00:00
|
|
|
|
2018-05-17 21:44:11 +00:00
|
|
|
/**
|
PCI: Add missing link delays required by the PCIe spec
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that
consists of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
+-01.0-[04-36]-- DS hotplug port
+-02.0-[37]----00.0 xHCI controller
\-04.0-[38-6b]-- DS hotplug port
The root port (1b.0) and the PCIe switch downstream ports are all PCIe
gen3 so they support 8GT/s link speeds.
We wait for the PCIe hierarchy to enter D3cold (runtime):
pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the
PCIe switch is put to reset and its power is re-applied. This means that
we must follow the rules in PCIe 4.0 section 6.6.1.
For the PCIe gen3 ports we are dealing with here, the following applies:
With a Downstream Port that supports Link speeds greater than 5.0
GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port. Software can determine when Link training
completes by polling the Data Link Layer Link Active bit or by setting
up an associated interrupt (see Section 6.7.3.3).
Translating this into the above topology we would need to do this (DLLLA
stands for Data Link Layer Link Active):
pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0
pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0
I've instrumented the kernel with additional logging so we can see the
actual delays the kernel performs:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
pcieport 0000:00:1b.0: waking up bus
pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:00:1b.0: PME# disabled
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:01:00.0: PME# disabled
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:00.0: PME# disabled
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:01.0: PME# disabled
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: PME# disabled
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:04.0: PME# disabled
pcieport 0000:02:01.0: PME# enabled
pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:04.0: PME# enabled
pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
...
thunderbolt 0000:03:00.0: PME# disabled
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
xhci_hcd 0000:37:00.0: PME# disabled
For the switch upstream port (01:00.0) we wait for 100ms but not taking
into account the DLLLA requirement. We then wait 10ms for D3hot -> D0
transition of the root port and the two downstream hotplug ports. This
means that we deviate from what the spec requires.
Performing the same check for system sleep (s2idle) transitions we can
see following when resuming from s2idle:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0)
pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001)
pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702)
pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001)
pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00)
pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400)
pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151)
pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00)
pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161)
pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402)
pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802)
pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302)
pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
This is even worse. None of the mandatory delays are performed. If this
would be S3 instead of s2idle then according to PCI FW spec 3.2 section
4.6.8. there is a specific _DSM that allows the OS to skip the delays
but this platform does not provide the _DSM and does not go to S3 anyway
so no firmware is involved that could already handle these delays.
In this particular Intel Coffee Lake platform these delays are not
actually needed because there is an additional delay as part of the ACPI
power resource that is used to turn on power to the hierarchy but since
that additional delay is not required by any of standards (PCIe, ACPI)
it is not present in the Intel Ice Lake, for example where missing the
mandatory delays causes pciehp to start tearing down the stack too early
(links are not yet trained).
For this reason, change the PCIe portdrv PM resume hooks so that they
perform the mandatory delays before the downstream component gets
resumed. We perform the delays before port services are resumed because
otherwise pciehp might find that the link is not up (even if it is just
training) and tears-down the hierarchy.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-12 10:57:38 +00:00
|
|
|
* pcie_wait_for_link_delay - Wait until link is active or inactive
|
2018-05-17 21:44:11 +00:00
|
|
|
* @pdev: Bridge device
|
|
|
|
* @active: waiting for active or inactive?
|
PCI: Add missing link delays required by the PCIe spec
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that
consists of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
+-01.0-[04-36]-- DS hotplug port
+-02.0-[37]----00.0 xHCI controller
\-04.0-[38-6b]-- DS hotplug port
The root port (1b.0) and the PCIe switch downstream ports are all PCIe
gen3 so they support 8GT/s link speeds.
We wait for the PCIe hierarchy to enter D3cold (runtime):
pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the
PCIe switch is put to reset and its power is re-applied. This means that
we must follow the rules in PCIe 4.0 section 6.6.1.
For the PCIe gen3 ports we are dealing with here, the following applies:
With a Downstream Port that supports Link speeds greater than 5.0
GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port. Software can determine when Link training
completes by polling the Data Link Layer Link Active bit or by setting
up an associated interrupt (see Section 6.7.3.3).
Translating this into the above topology we would need to do this (DLLLA
stands for Data Link Layer Link Active):
pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0
pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0
I've instrumented the kernel with additional logging so we can see the
actual delays the kernel performs:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
pcieport 0000:00:1b.0: waking up bus
pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:00:1b.0: PME# disabled
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:01:00.0: PME# disabled
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:00.0: PME# disabled
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:01.0: PME# disabled
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: PME# disabled
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:04.0: PME# disabled
pcieport 0000:02:01.0: PME# enabled
pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:04.0: PME# enabled
pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
...
thunderbolt 0000:03:00.0: PME# disabled
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
xhci_hcd 0000:37:00.0: PME# disabled
For the switch upstream port (01:00.0) we wait for 100ms but not taking
into account the DLLLA requirement. We then wait 10ms for D3hot -> D0
transition of the root port and the two downstream hotplug ports. This
means that we deviate from what the spec requires.
Performing the same check for system sleep (s2idle) transitions we can
see following when resuming from s2idle:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0)
pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001)
pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702)
pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001)
pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00)
pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400)
pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151)
pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00)
pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161)
pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402)
pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802)
pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302)
pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
This is even worse. None of the mandatory delays are performed. If this
would be S3 instead of s2idle then according to PCI FW spec 3.2 section
4.6.8. there is a specific _DSM that allows the OS to skip the delays
but this platform does not provide the _DSM and does not go to S3 anyway
so no firmware is involved that could already handle these delays.
In this particular Intel Coffee Lake platform these delays are not
actually needed because there is an additional delay as part of the ACPI
power resource that is used to turn on power to the hierarchy but since
that additional delay is not required by any of standards (PCIe, ACPI)
it is not present in the Intel Ice Lake, for example where missing the
mandatory delays causes pciehp to start tearing down the stack too early
(links are not yet trained).
For this reason, change the PCIe portdrv PM resume hooks so that they
perform the mandatory delays before the downstream component gets
resumed. We perform the delays before port services are resumed because
otherwise pciehp might find that the link is not up (even if it is just
training) and tears-down the hierarchy.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-12 10:57:38 +00:00
|
|
|
* @delay: Delay to wait after link has become active (in ms)
|
2018-05-17 21:44:11 +00:00
|
|
|
*
|
|
|
|
* Use this to wait till link becomes active or inactive.
|
|
|
|
*/
|
PCI: Add missing link delays required by the PCIe spec
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that
consists of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
+-01.0-[04-36]-- DS hotplug port
+-02.0-[37]----00.0 xHCI controller
\-04.0-[38-6b]-- DS hotplug port
The root port (1b.0) and the PCIe switch downstream ports are all PCIe
gen3 so they support 8GT/s link speeds.
We wait for the PCIe hierarchy to enter D3cold (runtime):
pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the
PCIe switch is put to reset and its power is re-applied. This means that
we must follow the rules in PCIe 4.0 section 6.6.1.
For the PCIe gen3 ports we are dealing with here, the following applies:
With a Downstream Port that supports Link speeds greater than 5.0
GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port. Software can determine when Link training
completes by polling the Data Link Layer Link Active bit or by setting
up an associated interrupt (see Section 6.7.3.3).
Translating this into the above topology we would need to do this (DLLLA
stands for Data Link Layer Link Active):
pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0
pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0
I've instrumented the kernel with additional logging so we can see the
actual delays the kernel performs:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
pcieport 0000:00:1b.0: waking up bus
pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:00:1b.0: PME# disabled
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:01:00.0: PME# disabled
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:00.0: PME# disabled
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:01.0: PME# disabled
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: PME# disabled
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:04.0: PME# disabled
pcieport 0000:02:01.0: PME# enabled
pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:04.0: PME# enabled
pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
...
thunderbolt 0000:03:00.0: PME# disabled
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
xhci_hcd 0000:37:00.0: PME# disabled
For the switch upstream port (01:00.0) we wait for 100ms but not taking
into account the DLLLA requirement. We then wait 10ms for D3hot -> D0
transition of the root port and the two downstream hotplug ports. This
means that we deviate from what the spec requires.
Performing the same check for system sleep (s2idle) transitions we can
see following when resuming from s2idle:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0)
pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001)
pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702)
pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001)
pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00)
pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400)
pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151)
pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00)
pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161)
pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402)
pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802)
pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302)
pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
This is even worse. None of the mandatory delays are performed. If this
would be S3 instead of s2idle then according to PCI FW spec 3.2 section
4.6.8. there is a specific _DSM that allows the OS to skip the delays
but this platform does not provide the _DSM and does not go to S3 anyway
so no firmware is involved that could already handle these delays.
In this particular Intel Coffee Lake platform these delays are not
actually needed because there is an additional delay as part of the ACPI
power resource that is used to turn on power to the hierarchy but since
that additional delay is not required by any of standards (PCIe, ACPI)
it is not present in the Intel Ice Lake, for example where missing the
mandatory delays causes pciehp to start tearing down the stack too early
(links are not yet trained).
For this reason, change the PCIe portdrv PM resume hooks so that they
perform the mandatory delays before the downstream component gets
resumed. We perform the delays before port services are resumed because
otherwise pciehp might find that the link is not up (even if it is just
training) and tears-down the hierarchy.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-12 10:57:38 +00:00
|
|
|
bool pcie_wait_for_link_delay(struct pci_dev *pdev, bool active, int delay)
|
2018-05-17 21:44:11 +00:00
|
|
|
{
|
|
|
|
int timeout = 1000;
|
|
|
|
bool ret;
|
|
|
|
u16 lnk_status;
|
|
|
|
|
2018-09-20 16:27:17 +00:00
|
|
|
/*
|
|
|
|
* Some controllers might not implement link active reporting. In this
|
|
|
|
* case, we wait for 1000 + 100 ms.
|
|
|
|
*/
|
|
|
|
if (!pdev->link_active_reporting) {
|
|
|
|
msleep(1100);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PCIe r4.0 sec 6.6.1, a component must enter LTSSM Detect within 20ms,
|
|
|
|
* after which we should expect an link active if the reset was
|
|
|
|
* successful. If so, software must wait a minimum 100ms before sending
|
|
|
|
* configuration requests to devices downstream this port.
|
|
|
|
*
|
|
|
|
* If the link fails to activate, either the device was physically
|
|
|
|
* removed or the link is permanently failed.
|
|
|
|
*/
|
|
|
|
if (active)
|
|
|
|
msleep(20);
|
2018-05-17 21:44:11 +00:00
|
|
|
for (;;) {
|
|
|
|
pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
|
|
|
|
ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
|
|
|
|
if (ret == active)
|
2018-09-20 16:27:17 +00:00
|
|
|
break;
|
2018-05-17 21:44:11 +00:00
|
|
|
if (timeout <= 0)
|
|
|
|
break;
|
|
|
|
msleep(10);
|
|
|
|
timeout -= 10;
|
|
|
|
}
|
2018-09-20 16:27:17 +00:00
|
|
|
if (active && ret)
|
PCI: Add missing link delays required by the PCIe spec
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that
consists of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
+-01.0-[04-36]-- DS hotplug port
+-02.0-[37]----00.0 xHCI controller
\-04.0-[38-6b]-- DS hotplug port
The root port (1b.0) and the PCIe switch downstream ports are all PCIe
gen3 so they support 8GT/s link speeds.
We wait for the PCIe hierarchy to enter D3cold (runtime):
pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the
PCIe switch is put to reset and its power is re-applied. This means that
we must follow the rules in PCIe 4.0 section 6.6.1.
For the PCIe gen3 ports we are dealing with here, the following applies:
With a Downstream Port that supports Link speeds greater than 5.0
GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port. Software can determine when Link training
completes by polling the Data Link Layer Link Active bit or by setting
up an associated interrupt (see Section 6.7.3.3).
Translating this into the above topology we would need to do this (DLLLA
stands for Data Link Layer Link Active):
pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0
pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0
I've instrumented the kernel with additional logging so we can see the
actual delays the kernel performs:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
pcieport 0000:00:1b.0: waking up bus
pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:00:1b.0: PME# disabled
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:01:00.0: PME# disabled
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:00.0: PME# disabled
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:01.0: PME# disabled
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: PME# disabled
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:04.0: PME# disabled
pcieport 0000:02:01.0: PME# enabled
pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:04.0: PME# enabled
pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
...
thunderbolt 0000:03:00.0: PME# disabled
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
xhci_hcd 0000:37:00.0: PME# disabled
For the switch upstream port (01:00.0) we wait for 100ms but not taking
into account the DLLLA requirement. We then wait 10ms for D3hot -> D0
transition of the root port and the two downstream hotplug ports. This
means that we deviate from what the spec requires.
Performing the same check for system sleep (s2idle) transitions we can
see following when resuming from s2idle:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0)
pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001)
pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702)
pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001)
pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00)
pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400)
pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151)
pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00)
pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161)
pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402)
pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802)
pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302)
pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
This is even worse. None of the mandatory delays are performed. If this
would be S3 instead of s2idle then according to PCI FW spec 3.2 section
4.6.8. there is a specific _DSM that allows the OS to skip the delays
but this platform does not provide the _DSM and does not go to S3 anyway
so no firmware is involved that could already handle these delays.
In this particular Intel Coffee Lake platform these delays are not
actually needed because there is an additional delay as part of the ACPI
power resource that is used to turn on power to the hierarchy but since
that additional delay is not required by any of standards (PCIe, ACPI)
it is not present in the Intel Ice Lake, for example where missing the
mandatory delays causes pciehp to start tearing down the stack too early
(links are not yet trained).
For this reason, change the PCIe portdrv PM resume hooks so that they
perform the mandatory delays before the downstream component gets
resumed. We perform the delays before port services are resumed because
otherwise pciehp might find that the link is not up (even if it is just
training) and tears-down the hierarchy.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-12 10:57:38 +00:00
|
|
|
msleep(delay);
|
2018-09-20 16:27:17 +00:00
|
|
|
else if (ret != active)
|
|
|
|
pci_info(pdev, "Data Link Layer Link Active not %s in 1000 msec\n",
|
|
|
|
active ? "set" : "cleared");
|
|
|
|
return ret == active;
|
2018-05-17 21:44:11 +00:00
|
|
|
}
|
2009-06-13 07:52:14 +00:00
|
|
|
|
PCI: Add missing link delays required by the PCIe spec
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that
consists of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
+-01.0-[04-36]-- DS hotplug port
+-02.0-[37]----00.0 xHCI controller
\-04.0-[38-6b]-- DS hotplug port
The root port (1b.0) and the PCIe switch downstream ports are all PCIe
gen3 so they support 8GT/s link speeds.
We wait for the PCIe hierarchy to enter D3cold (runtime):
pcieport 0000:00:1b.0: power state changed by ACPI to D3cold
When it wakes up from D3cold, according to the PCIe 4.0 section 5.8 the
PCIe switch is put to reset and its power is re-applied. This means that
we must follow the rules in PCIe 4.0 section 6.6.1.
For the PCIe gen3 ports we are dealing with here, the following applies:
With a Downstream Port that supports Link speeds greater than 5.0
GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port. Software can determine when Link training
completes by polling the Data Link Layer Link Active bit or by setting
up an associated interrupt (see Section 6.7.3.3).
Translating this into the above topology we would need to do this (DLLLA
stands for Data Link Layer Link Active):
pcieport 0000:00:1b.0: wait for 100ms after DLLLA is set before access to 0000:01:00.0
pcieport 0000:02:00.0: wait for 100ms after DLLLA is set before access to 0000:03:00.0
pcieport 0000:02:02.0: wait for 100ms after DLLLA is set before access to 0000:37:00.0
I've instrumented the kernel with additional logging so we can see the
actual delays the kernel performs:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms
pcieport 0000:00:1b.0: waking up bus
pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:00:1b.0: PME# disabled
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:01:00.0: PME# disabled
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:00.0: PME# disabled
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:01.0: PME# disabled
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: PME# disabled
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:04.0: PME# disabled
pcieport 0000:02:01.0: PME# enabled
pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms
pcieport 0000:02:04.0: PME# enabled
pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
...
thunderbolt 0000:03:00.0: PME# disabled
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
xhci_hcd 0000:37:00.0: PME# disabled
For the switch upstream port (01:00.0) we wait for 100ms but not taking
into account the DLLLA requirement. We then wait 10ms for D3hot -> D0
transition of the root port and the two downstream hotplug ports. This
means that we deviate from what the spec requires.
Performing the same check for system sleep (s2idle) transitions we can
see following when resuming from s2idle:
pcieport 0000:00:1b.0: power state changed by ACPI to D0
pcieport 0000:00:1b.0: restoring config space at offset 0x2c (was 0x60, writing 0x60)
...
pcieport 0000:01:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
...
pcieport 0000:02:02.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:01.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:04.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:00.0: restoring config space at offset 0x3c (was 0x1ff, writing 0x201ff)
pcieport 0000:02:02.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:01.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:02.0: restoring config space at offset 0x20 (was 0x0, writing 0x73f073f0)
pcieport 0000:02:04.0: restoring config space at offset 0x2c (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:00.0: restoring config space at offset 0x2c (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x28 (was 0x0, writing 0x60)
pcieport 0000:02:01.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1ff10001)
pcieport 0000:02:00.0: restoring config space at offset 0x28 (was 0x0, writing 0x0)
pcieport 0000:02:02.0: restoring config space at offset 0x18 (was 0x0, writing 0x373702)
pcieport 0000:02:04.0: restoring config space at offset 0x24 (was 0x10001, writing 0x49f12001)
pcieport 0000:02:01.0: restoring config space at offset 0x20 (was 0x0, writing 0x73e05c00)
pcieport 0000:02:00.0: restoring config space at offset 0x24 (was 0x10001, writing 0x1fff1)
pcieport 0000:02:04.0: restoring config space at offset 0x20 (was 0x0, writing 0x89f07400)
pcieport 0000:02:01.0: restoring config space at offset 0x1c (was 0x101, writing 0x5151)
pcieport 0000:02:00.0: restoring config space at offset 0x20 (was 0x0, writing 0x8a008a00)
pcieport 0000:02:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0x1c (was 0x101, writing 0x6161)
pcieport 0000:02:01.0: restoring config space at offset 0x18 (was 0x0, writing 0x360402)
pcieport 0000:02:00.0: restoring config space at offset 0x1c (was 0x101, writing 0x1f1)
pcieport 0000:02:04.0: restoring config space at offset 0x18 (was 0x0, writing 0x6b3802)
pcieport 0000:02:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x18 (was 0x0, writing 0x30302)
pcieport 0000:02:01.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:04.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:00.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020)
pcieport 0000:02:01.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:04.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
pcieport 0000:02:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
xhci_hcd 0000:37:00.0: restoring config space at offset 0x10 (was 0x0, writing 0x73f00000)
...
thunderbolt 0000:03:00.0: restoring config space at offset 0x14 (was 0x0, writing 0x8a040000)
This is even worse. None of the mandatory delays are performed. If this
would be S3 instead of s2idle then according to PCI FW spec 3.2 section
4.6.8. there is a specific _DSM that allows the OS to skip the delays
but this platform does not provide the _DSM and does not go to S3 anyway
so no firmware is involved that could already handle these delays.
In this particular Intel Coffee Lake platform these delays are not
actually needed because there is an additional delay as part of the ACPI
power resource that is used to turn on power to the hierarchy but since
that additional delay is not required by any of standards (PCIe, ACPI)
it is not present in the Intel Ice Lake, for example where missing the
mandatory delays causes pciehp to start tearing down the stack too early
(links are not yet trained).
For this reason, change the PCIe portdrv PM resume hooks so that they
perform the mandatory delays before the downstream component gets
resumed. We perform the delays before port services are resumed because
otherwise pciehp might find that the link is not up (even if it is just
training) and tears-down the hierarchy.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-12 10:57:38 +00:00
|
|
|
/**
|
|
|
|
* pcie_wait_for_link - Wait until link is active or inactive
|
|
|
|
* @pdev: Bridge device
|
|
|
|
* @active: waiting for active or inactive?
|
|
|
|
*
|
|
|
|
* Use this to wait till link becomes active or inactive.
|
|
|
|
*/
|
|
|
|
bool pcie_wait_for_link(struct pci_dev *pdev, bool active)
|
|
|
|
{
|
|
|
|
return pcie_wait_for_link_delay(pdev, active, 100);
|
|
|
|
}
|
|
|
|
|
2014-06-19 07:22:44 +00:00
|
|
|
void pci_reset_secondary_bus(struct pci_dev *dev)
|
2009-06-13 07:52:15 +00:00
|
|
|
{
|
|
|
|
u16 ctrl;
|
2013-08-08 20:09:24 +00:00
|
|
|
|
|
|
|
pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &ctrl);
|
|
|
|
ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
|
|
|
|
pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
|
2018-03-09 22:36:33 +00:00
|
|
|
|
2013-08-08 20:10:13 +00:00
|
|
|
/*
|
|
|
|
* PCI spec v3.0 7.6.4.2 requires minimum Trst of 1ms. Double
|
2013-11-14 18:28:18 +00:00
|
|
|
* this to 2ms to ensure that we meet the minimum requirement.
|
2013-08-08 20:10:13 +00:00
|
|
|
*/
|
|
|
|
msleep(2);
|
2013-08-08 20:09:24 +00:00
|
|
|
|
|
|
|
ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
|
|
|
|
pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
|
2013-08-08 20:10:13 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Trhfa for conventional PCI is 2^25 clock cycles.
|
|
|
|
* Assuming a minimum 33MHz clock this results in a 1s
|
|
|
|
* delay before we can consider subordinate devices to
|
|
|
|
* be re-initialized. PCIe has some ways to shorten this,
|
|
|
|
* but we don't make use of them yet.
|
|
|
|
*/
|
|
|
|
ssleep(1);
|
2013-08-08 20:09:24 +00:00
|
|
|
}
|
2014-04-24 08:00:24 +00:00
|
|
|
|
2014-06-19 07:22:44 +00:00
|
|
|
void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
pci_reset_secondary_bus(dev);
|
|
|
|
}
|
|
|
|
|
2014-04-24 08:00:24 +00:00
|
|
|
/**
|
2018-07-19 23:04:11 +00:00
|
|
|
* pci_bridge_secondary_bus_reset - Reset the secondary bus on a PCI bridge.
|
2014-04-24 08:00:24 +00:00
|
|
|
* @dev: Bridge device
|
|
|
|
*
|
|
|
|
* Use the bridge control register to assert reset on the secondary bus.
|
|
|
|
* Devices on the secondary bus are left in power-on state.
|
|
|
|
*/
|
2018-07-19 23:04:11 +00:00
|
|
|
int pci_bridge_secondary_bus_reset(struct pci_dev *dev)
|
2014-04-24 08:00:24 +00:00
|
|
|
{
|
|
|
|
pcibios_reset_secondary_bus(dev);
|
2018-02-27 20:14:11 +00:00
|
|
|
|
2018-02-27 20:14:12 +00:00
|
|
|
return pci_dev_wait(dev, "bus reset", PCIE_RESET_READY_POLL_MS);
|
2014-04-24 08:00:24 +00:00
|
|
|
}
|
2018-08-31 17:34:14 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_bridge_secondary_bus_reset);
|
2013-08-08 20:09:24 +00:00
|
|
|
|
|
|
|
static int pci_parent_bus_reset(struct pci_dev *dev, int probe)
|
|
|
|
{
|
2009-06-13 07:52:15 +00:00
|
|
|
struct pci_dev *pdev;
|
|
|
|
|
2015-01-16 00:16:04 +00:00
|
|
|
if (pci_is_root_bus(dev->bus) || dev->subordinate ||
|
|
|
|
!dev->bus->self || dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET)
|
2009-06-13 07:52:15 +00:00
|
|
|
return -ENOTTY;
|
|
|
|
|
|
|
|
list_for_each_entry(pdev, &dev->bus->devices, bus_list)
|
|
|
|
if (pdev != dev)
|
|
|
|
return -ENOTTY;
|
|
|
|
|
|
|
|
if (probe)
|
|
|
|
return 0;
|
|
|
|
|
2018-07-19 23:04:11 +00:00
|
|
|
return pci_bridge_secondary_bus_reset(dev->bus->self);
|
2009-06-13 07:52:15 +00:00
|
|
|
}
|
|
|
|
|
2013-08-08 20:09:43 +00:00
|
|
|
static int pci_reset_hotplug_slot(struct hotplug_slot *hotplug, int probe)
|
|
|
|
{
|
|
|
|
int rc = -ENOTTY;
|
|
|
|
|
2018-09-08 07:59:01 +00:00
|
|
|
if (!hotplug || !try_module_get(hotplug->owner))
|
2013-08-08 20:09:43 +00:00
|
|
|
return rc;
|
|
|
|
|
|
|
|
if (hotplug->ops->reset_slot)
|
|
|
|
rc = hotplug->ops->reset_slot(hotplug, probe);
|
|
|
|
|
2018-09-08 07:59:01 +00:00
|
|
|
module_put(hotplug->owner);
|
2013-08-08 20:09:43 +00:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_dev_reset_slot_function(struct pci_dev *dev, int probe)
|
|
|
|
{
|
|
|
|
struct pci_dev *pdev;
|
|
|
|
|
2015-01-16 00:16:04 +00:00
|
|
|
if (dev->subordinate || !dev->slot ||
|
|
|
|
dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET)
|
2013-08-08 20:09:43 +00:00
|
|
|
return -ENOTTY;
|
|
|
|
|
|
|
|
list_for_each_entry(pdev, &dev->bus->devices, bus_list)
|
|
|
|
if (pdev != dev && pdev->slot == dev->slot)
|
|
|
|
return -ENOTTY;
|
|
|
|
|
|
|
|
return pci_reset_hotplug_slot(dev->slot->hotplug, probe);
|
|
|
|
}
|
|
|
|
|
2013-08-08 20:09:49 +00:00
|
|
|
static void pci_dev_lock(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
pci_cfg_access_lock(dev);
|
|
|
|
/* block PM suspend, driver probe, etc. */
|
|
|
|
device_lock(&dev->dev);
|
|
|
|
}
|
|
|
|
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
/* Return 1 on successful lock, 0 on contention */
|
|
|
|
static int pci_dev_trylock(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
if (pci_cfg_access_trylock(dev)) {
|
|
|
|
if (device_trylock(&dev->dev))
|
|
|
|
return 1;
|
|
|
|
pci_cfg_access_unlock(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-08-08 20:09:49 +00:00
|
|
|
static void pci_dev_unlock(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
device_unlock(&dev->dev);
|
|
|
|
pci_cfg_access_unlock(dev);
|
|
|
|
}
|
|
|
|
|
2017-06-01 11:10:38 +00:00
|
|
|
static void pci_dev_save_and_disable(struct pci_dev *dev)
|
2014-05-02 16:40:42 +00:00
|
|
|
{
|
|
|
|
const struct pci_error_handlers *err_handler =
|
|
|
|
dev->driver ? dev->driver->err_handler : NULL;
|
|
|
|
|
2017-06-01 11:10:37 +00:00
|
|
|
/*
|
2017-06-01 11:10:38 +00:00
|
|
|
* dev->driver->err_handler->reset_prepare() is protected against
|
2017-06-01 11:10:37 +00:00
|
|
|
* races with ->remove() by the device lock, which must be held by
|
|
|
|
* the caller.
|
|
|
|
*/
|
2017-06-01 11:10:38 +00:00
|
|
|
if (err_handler && err_handler->reset_prepare)
|
|
|
|
err_handler->reset_prepare(dev);
|
2014-05-02 16:40:42 +00:00
|
|
|
|
2013-08-08 20:10:02 +00:00
|
|
|
/*
|
|
|
|
* Wake-up device prior to save. PM registers default to D0 after
|
|
|
|
* reset and a simple register restore doesn't reliably return
|
|
|
|
* to a non-D0 state anyway.
|
|
|
|
*/
|
|
|
|
pci_set_power_state(dev, PCI_D0);
|
|
|
|
|
2013-08-08 20:09:49 +00:00
|
|
|
pci_save_state(dev);
|
|
|
|
/*
|
|
|
|
* Disable the device by clearing the Command register, except for
|
|
|
|
* INTx-disable which is set. This not only disables MMIO and I/O port
|
|
|
|
* BARs, but also prevents the device from being Bus Master, preventing
|
|
|
|
* DMA from the device including MSI/MSI-X interrupts. For PCI 2.3
|
|
|
|
* compliant devices, INTx-disable prevents legacy interrupts.
|
|
|
|
*/
|
|
|
|
pci_write_config_word(dev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pci_dev_restore(struct pci_dev *dev)
|
|
|
|
{
|
2017-06-01 11:10:38 +00:00
|
|
|
const struct pci_error_handlers *err_handler =
|
|
|
|
dev->driver ? dev->driver->err_handler : NULL;
|
2012-04-24 19:15:18 +00:00
|
|
|
|
2013-08-08 20:09:49 +00:00
|
|
|
pci_restore_state(dev);
|
|
|
|
|
2017-06-01 11:10:38 +00:00
|
|
|
/*
|
|
|
|
* dev->driver->err_handler->reset_done() is protected against
|
|
|
|
* races with ->remove() by the device lock, which must be held by
|
|
|
|
* the caller.
|
|
|
|
*/
|
|
|
|
if (err_handler && err_handler->reset_done)
|
|
|
|
err_handler->reset_done(dev);
|
2008-11-11 09:17:47 +00:00
|
|
|
}
|
2014-05-02 16:40:42 +00:00
|
|
|
|
2012-01-12 17:06:46 +00:00
|
|
|
/**
|
|
|
|
* __pci_reset_function_locked - reset a PCI device function while holding
|
|
|
|
* the @dev mutex lock.
|
|
|
|
* @dev: PCI device to reset
|
|
|
|
*
|
|
|
|
* Some devices allow an individual function to be reset without affecting
|
|
|
|
* other functions in the same device. The PCI device must be responsive
|
|
|
|
* to PCI config space in order to use this function.
|
|
|
|
*
|
|
|
|
* The device function is presumed to be unused and the caller is holding
|
|
|
|
* the device mutex lock when this function is called.
|
2019-01-09 20:14:42 +00:00
|
|
|
*
|
2012-01-12 17:06:46 +00:00
|
|
|
* Resetting the device will make the contents of PCI configuration space
|
|
|
|
* random, so any caller of this must be prepared to reinitialise the
|
|
|
|
* device including MSI, bus mastering, BARs, decoding IO and memory spaces,
|
|
|
|
* etc.
|
|
|
|
*
|
|
|
|
* Returns 0 if the device function was successfully reset or negative if the
|
|
|
|
* device doesn't support resetting a single function.
|
|
|
|
*/
|
|
|
|
int __pci_reset_function_locked(struct pci_dev *dev)
|
|
|
|
{
|
2017-06-01 11:10:39 +00:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
|
2017-10-25 22:09:24 +00:00
|
|
|
/*
|
|
|
|
* A reset method returns -ENOTTY if it doesn't support this device
|
|
|
|
* and we should try the next method.
|
|
|
|
*
|
|
|
|
* If it returns 0 (success), we're finished. If it returns any
|
|
|
|
* other error, we're also finished: this indicates that further
|
|
|
|
* reset mechanisms might be broken on the device.
|
|
|
|
*/
|
2017-06-01 11:10:39 +00:00
|
|
|
rc = pci_dev_specific_reset(dev, 0);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
|
|
|
if (pcie_has_flr(dev)) {
|
2018-02-27 20:14:08 +00:00
|
|
|
rc = pcie_flr(dev);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
2017-06-01 11:10:39 +00:00
|
|
|
}
|
|
|
|
rc = pci_af_flr(dev, 0);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
|
|
|
rc = pci_pm_reset(dev, 0);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
|
|
|
rc = pci_dev_reset_slot_function(dev, 0);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
|
|
|
return pci_parent_bus_reset(dev, 0);
|
2012-01-12 17:06:46 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__pci_reset_function_locked);
|
|
|
|
|
2009-07-27 20:37:48 +00:00
|
|
|
/**
|
|
|
|
* pci_probe_reset_function - check whether the device can be safely reset
|
|
|
|
* @dev: PCI device to reset
|
|
|
|
*
|
|
|
|
* Some devices allow an individual function to be reset without affecting
|
|
|
|
* other functions in the same device. The PCI device must be responsive
|
|
|
|
* to PCI config space in order to use this function.
|
|
|
|
*
|
|
|
|
* Returns 0 if the device function can be reset or negative if the
|
|
|
|
* device doesn't support resetting a single function.
|
|
|
|
*/
|
|
|
|
int pci_probe_reset_function(struct pci_dev *dev)
|
|
|
|
{
|
2017-06-01 11:10:39 +00:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
|
|
|
|
rc = pci_dev_specific_reset(dev, 1);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
|
|
|
if (pcie_has_flr(dev))
|
|
|
|
return 0;
|
|
|
|
rc = pci_af_flr(dev, 1);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
|
|
|
rc = pci_pm_reset(dev, 1);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
|
|
|
rc = pci_dev_reset_slot_function(dev, 1);
|
|
|
|
if (rc != -ENOTTY)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
return pci_parent_bus_reset(dev, 1);
|
2009-07-27 20:37:48 +00:00
|
|
|
}
|
|
|
|
|
2008-10-21 09:38:25 +00:00
|
|
|
/**
|
2009-06-13 07:52:13 +00:00
|
|
|
* pci_reset_function - quiesce and reset a PCI device function
|
|
|
|
* @dev: PCI device to reset
|
2008-10-21 09:38:25 +00:00
|
|
|
*
|
|
|
|
* Some devices allow an individual function to be reset without affecting
|
|
|
|
* other functions in the same device. The PCI device must be responsive
|
|
|
|
* to PCI config space in order to use this function.
|
|
|
|
*
|
|
|
|
* This function does not just reset the PCI portion of a device, but
|
|
|
|
* clears all the state associated with the device. This function differs
|
2017-09-05 23:21:23 +00:00
|
|
|
* from __pci_reset_function_locked() in that it saves and restores device state
|
|
|
|
* over the reset and takes the PCI device lock.
|
2008-10-21 09:38:25 +00:00
|
|
|
*
|
2009-06-13 07:52:13 +00:00
|
|
|
* Returns 0 if the device function was successfully reset or negative if the
|
2008-10-21 09:38:25 +00:00
|
|
|
* device doesn't support resetting a single function.
|
|
|
|
*/
|
|
|
|
int pci_reset_function(struct pci_dev *dev)
|
|
|
|
{
|
2009-06-13 07:52:13 +00:00
|
|
|
int rc;
|
2008-10-21 09:38:25 +00:00
|
|
|
|
2018-02-16 21:22:39 +00:00
|
|
|
if (!dev->reset_fn)
|
|
|
|
return -ENOTTY;
|
2008-10-21 09:38:25 +00:00
|
|
|
|
2017-06-01 11:10:37 +00:00
|
|
|
pci_dev_lock(dev);
|
2013-08-08 20:09:49 +00:00
|
|
|
pci_dev_save_and_disable(dev);
|
2008-10-21 09:38:25 +00:00
|
|
|
|
2017-06-01 11:10:39 +00:00
|
|
|
rc = __pci_reset_function_locked(dev);
|
2008-10-21 09:38:25 +00:00
|
|
|
|
2013-08-08 20:09:49 +00:00
|
|
|
pci_dev_restore(dev);
|
2017-06-01 11:10:37 +00:00
|
|
|
pci_dev_unlock(dev);
|
2008-10-21 09:38:25 +00:00
|
|
|
|
2009-06-13 07:52:13 +00:00
|
|
|
return rc;
|
2008-10-21 09:38:25 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_reset_function);
|
|
|
|
|
2017-08-02 01:11:02 +00:00
|
|
|
/**
|
|
|
|
* pci_reset_function_locked - quiesce and reset a PCI device function
|
|
|
|
* @dev: PCI device to reset
|
|
|
|
*
|
|
|
|
* Some devices allow an individual function to be reset without affecting
|
|
|
|
* other functions in the same device. The PCI device must be responsive
|
|
|
|
* to PCI config space in order to use this function.
|
|
|
|
*
|
|
|
|
* This function does not just reset the PCI portion of a device, but
|
|
|
|
* clears all the state associated with the device. This function differs
|
2017-09-05 23:21:23 +00:00
|
|
|
* from __pci_reset_function_locked() in that it saves and restores device state
|
2017-08-02 01:11:02 +00:00
|
|
|
* over the reset. It also differs from pci_reset_function() in that it
|
|
|
|
* requires the PCI device lock to be held.
|
|
|
|
*
|
|
|
|
* Returns 0 if the device function was successfully reset or negative if the
|
|
|
|
* device doesn't support resetting a single function.
|
|
|
|
*/
|
|
|
|
int pci_reset_function_locked(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2018-02-16 21:22:39 +00:00
|
|
|
if (!dev->reset_fn)
|
|
|
|
return -ENOTTY;
|
2017-08-02 01:11:02 +00:00
|
|
|
|
|
|
|
pci_dev_save_and_disable(dev);
|
|
|
|
|
|
|
|
rc = __pci_reset_function_locked(dev);
|
|
|
|
|
|
|
|
pci_dev_restore(dev);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_reset_function_locked);
|
|
|
|
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
/**
|
|
|
|
* pci_try_reset_function - quiesce and reset a PCI device function
|
|
|
|
* @dev: PCI device to reset
|
|
|
|
*
|
|
|
|
* Same as above, except return -EAGAIN if unable to lock device.
|
|
|
|
*/
|
|
|
|
int pci_try_reset_function(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2018-02-16 21:22:39 +00:00
|
|
|
if (!dev->reset_fn)
|
|
|
|
return -ENOTTY;
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
|
2017-06-01 11:10:37 +00:00
|
|
|
if (!pci_dev_trylock(dev))
|
|
|
|
return -EAGAIN;
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
|
2017-06-01 11:10:37 +00:00
|
|
|
pci_dev_save_and_disable(dev);
|
2017-06-01 11:10:39 +00:00
|
|
|
rc = __pci_reset_function_locked(dev);
|
2018-02-27 20:14:08 +00:00
|
|
|
pci_dev_restore(dev);
|
2017-06-01 11:10:37 +00:00
|
|
|
pci_dev_unlock(dev);
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_try_reset_function);
|
|
|
|
|
2015-01-16 00:16:04 +00:00
|
|
|
/* Do any devices on or below this bus prevent a bus reset? */
|
|
|
|
static bool pci_bus_resetable(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
2017-09-08 08:10:31 +00:00
|
|
|
|
|
|
|
if (bus->self && (bus->self->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET))
|
|
|
|
return false;
|
|
|
|
|
2015-01-16 00:16:04 +00:00
|
|
|
list_for_each_entry(dev, &bus->devices, bus_list) {
|
|
|
|
if (dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET ||
|
|
|
|
(dev->subordinate && !pci_bus_resetable(dev->subordinate)))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-08-08 20:09:55 +00:00
|
|
|
/* Lock devices from the top of the tree down */
|
|
|
|
static void pci_bus_lock(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &bus->devices, bus_list) {
|
|
|
|
pci_dev_lock(dev);
|
|
|
|
if (dev->subordinate)
|
|
|
|
pci_bus_lock(dev->subordinate);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Unlock devices from the bottom of the tree up */
|
|
|
|
static void pci_bus_unlock(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &bus->devices, bus_list) {
|
|
|
|
if (dev->subordinate)
|
|
|
|
pci_bus_unlock(dev->subordinate);
|
|
|
|
pci_dev_unlock(dev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
/* Return 1 on successful lock, 0 on contention */
|
|
|
|
static int pci_bus_trylock(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &bus->devices, bus_list) {
|
|
|
|
if (!pci_dev_trylock(dev))
|
|
|
|
goto unlock;
|
|
|
|
if (dev->subordinate) {
|
|
|
|
if (!pci_bus_trylock(dev->subordinate)) {
|
|
|
|
pci_dev_unlock(dev);
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
list_for_each_entry_continue_reverse(dev, &bus->devices, bus_list) {
|
|
|
|
if (dev->subordinate)
|
|
|
|
pci_bus_unlock(dev->subordinate);
|
|
|
|
pci_dev_unlock(dev);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-01-16 00:16:04 +00:00
|
|
|
/* Do any devices on or below this slot prevent a bus reset? */
|
|
|
|
static bool pci_slot_resetable(struct pci_slot *slot)
|
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
2017-09-08 08:10:33 +00:00
|
|
|
if (slot->bus->self &&
|
|
|
|
(slot->bus->self->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET))
|
|
|
|
return false;
|
|
|
|
|
2015-01-16 00:16:04 +00:00
|
|
|
list_for_each_entry(dev, &slot->bus->devices, bus_list) {
|
|
|
|
if (!dev->slot || dev->slot != slot)
|
|
|
|
continue;
|
|
|
|
if (dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET ||
|
|
|
|
(dev->subordinate && !pci_bus_resetable(dev->subordinate)))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-08-08 20:09:55 +00:00
|
|
|
/* Lock devices from the top of the tree down */
|
|
|
|
static void pci_slot_lock(struct pci_slot *slot)
|
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &slot->bus->devices, bus_list) {
|
|
|
|
if (!dev->slot || dev->slot != slot)
|
|
|
|
continue;
|
|
|
|
pci_dev_lock(dev);
|
|
|
|
if (dev->subordinate)
|
|
|
|
pci_bus_lock(dev->subordinate);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Unlock devices from the bottom of the tree up */
|
|
|
|
static void pci_slot_unlock(struct pci_slot *slot)
|
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &slot->bus->devices, bus_list) {
|
|
|
|
if (!dev->slot || dev->slot != slot)
|
|
|
|
continue;
|
|
|
|
if (dev->subordinate)
|
|
|
|
pci_bus_unlock(dev->subordinate);
|
|
|
|
pci_dev_unlock(dev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
/* Return 1 on successful lock, 0 on contention */
|
|
|
|
static int pci_slot_trylock(struct pci_slot *slot)
|
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &slot->bus->devices, bus_list) {
|
|
|
|
if (!dev->slot || dev->slot != slot)
|
|
|
|
continue;
|
|
|
|
if (!pci_dev_trylock(dev))
|
|
|
|
goto unlock;
|
|
|
|
if (dev->subordinate) {
|
|
|
|
if (!pci_bus_trylock(dev->subordinate)) {
|
|
|
|
pci_dev_unlock(dev);
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
list_for_each_entry_continue_reverse(dev,
|
|
|
|
&slot->bus->devices, bus_list) {
|
|
|
|
if (!dev->slot || dev->slot != slot)
|
|
|
|
continue;
|
|
|
|
if (dev->subordinate)
|
|
|
|
pci_bus_unlock(dev->subordinate);
|
|
|
|
pci_dev_unlock(dev);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-18 19:46:46 +00:00
|
|
|
/*
|
|
|
|
* Save and disable devices from the top of the tree down while holding
|
|
|
|
* the @dev mutex lock for the entire tree.
|
|
|
|
*/
|
|
|
|
static void pci_bus_save_and_disable_locked(struct pci_bus *bus)
|
2013-08-08 20:09:55 +00:00
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &bus->devices, bus_list) {
|
|
|
|
pci_dev_save_and_disable(dev);
|
|
|
|
if (dev->subordinate)
|
2019-02-18 19:46:46 +00:00
|
|
|
pci_bus_save_and_disable_locked(dev->subordinate);
|
2013-08-08 20:09:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2019-02-18 19:46:46 +00:00
|
|
|
* Restore devices from top of the tree down while holding @dev mutex lock
|
|
|
|
* for the entire tree. Parent bridges need to be restored before we can
|
|
|
|
* get to subordinate devices.
|
2013-08-08 20:09:55 +00:00
|
|
|
*/
|
2019-02-18 19:46:46 +00:00
|
|
|
static void pci_bus_restore_locked(struct pci_bus *bus)
|
2013-08-08 20:09:55 +00:00
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &bus->devices, bus_list) {
|
|
|
|
pci_dev_restore(dev);
|
|
|
|
if (dev->subordinate)
|
2019-02-18 19:46:46 +00:00
|
|
|
pci_bus_restore_locked(dev->subordinate);
|
2013-08-08 20:09:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-18 19:46:46 +00:00
|
|
|
/*
|
|
|
|
* Save and disable devices from the top of the tree down while holding
|
|
|
|
* the @dev mutex lock for the entire tree.
|
|
|
|
*/
|
|
|
|
static void pci_slot_save_and_disable_locked(struct pci_slot *slot)
|
2013-08-08 20:09:55 +00:00
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &slot->bus->devices, bus_list) {
|
|
|
|
if (!dev->slot || dev->slot != slot)
|
|
|
|
continue;
|
|
|
|
pci_dev_save_and_disable(dev);
|
|
|
|
if (dev->subordinate)
|
2019-02-18 19:46:46 +00:00
|
|
|
pci_bus_save_and_disable_locked(dev->subordinate);
|
2013-08-08 20:09:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2019-02-18 19:46:46 +00:00
|
|
|
* Restore devices from top of the tree down while holding @dev mutex lock
|
|
|
|
* for the entire tree. Parent bridges need to be restored before we can
|
|
|
|
* get to subordinate devices.
|
2013-08-08 20:09:55 +00:00
|
|
|
*/
|
2019-02-18 19:46:46 +00:00
|
|
|
static void pci_slot_restore_locked(struct pci_slot *slot)
|
2013-08-08 20:09:55 +00:00
|
|
|
{
|
|
|
|
struct pci_dev *dev;
|
|
|
|
|
|
|
|
list_for_each_entry(dev, &slot->bus->devices, bus_list) {
|
|
|
|
if (!dev->slot || dev->slot != slot)
|
|
|
|
continue;
|
|
|
|
pci_dev_restore(dev);
|
|
|
|
if (dev->subordinate)
|
2019-02-18 19:46:46 +00:00
|
|
|
pci_bus_restore_locked(dev->subordinate);
|
2013-08-08 20:09:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_slot_reset(struct pci_slot *slot, int probe)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2015-01-16 00:16:04 +00:00
|
|
|
if (!slot || !pci_slot_resetable(slot))
|
2013-08-08 20:09:55 +00:00
|
|
|
return -ENOTTY;
|
|
|
|
|
|
|
|
if (!probe)
|
|
|
|
pci_slot_lock(slot);
|
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
|
|
|
|
rc = pci_reset_hotplug_slot(slot->hotplug, probe);
|
|
|
|
|
|
|
|
if (!probe)
|
|
|
|
pci_slot_unlock(slot);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2013-08-14 20:06:05 +00:00
|
|
|
/**
|
|
|
|
* pci_probe_reset_slot - probe whether a PCI slot can be reset
|
|
|
|
* @slot: PCI slot to probe
|
|
|
|
*
|
|
|
|
* Return 0 if slot can be reset, negative if a slot reset is not supported.
|
|
|
|
*/
|
|
|
|
int pci_probe_reset_slot(struct pci_slot *slot)
|
|
|
|
{
|
|
|
|
return pci_slot_reset(slot, 1);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_probe_reset_slot);
|
|
|
|
|
2013-08-08 20:09:55 +00:00
|
|
|
/**
|
2018-07-19 23:04:15 +00:00
|
|
|
* __pci_reset_slot - Try to reset a PCI slot
|
2013-08-08 20:09:55 +00:00
|
|
|
* @slot: PCI slot to reset
|
|
|
|
*
|
|
|
|
* A PCI bus may host multiple slots, each slot may support a reset mechanism
|
|
|
|
* independent of other slots. For instance, some slots may support slot power
|
|
|
|
* control. In the case of a 1:1 bus to slot architecture, this function may
|
|
|
|
* wrap the bus reset to avoid spurious slot related events such as hotplug.
|
|
|
|
* Generally a slot reset should be attempted before a bus reset. All of the
|
|
|
|
* function of the slot and any subordinate buses behind the slot are reset
|
|
|
|
* through this function. PCI config space of all devices in the slot and
|
|
|
|
* behind the slot is saved before and restored after reset.
|
|
|
|
*
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
* Same as above except return -EAGAIN if the slot cannot be locked
|
|
|
|
*/
|
2018-07-19 23:04:15 +00:00
|
|
|
static int __pci_reset_slot(struct pci_slot *slot)
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = pci_slot_reset(slot, 1);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
if (pci_slot_trylock(slot)) {
|
2019-02-18 19:46:46 +00:00
|
|
|
pci_slot_save_and_disable_locked(slot);
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
might_sleep();
|
|
|
|
rc = pci_reset_hotplug_slot(slot->hotplug, 0);
|
2019-02-18 19:46:46 +00:00
|
|
|
pci_slot_restore_locked(slot);
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
pci_slot_unlock(slot);
|
|
|
|
} else
|
|
|
|
rc = -EAGAIN;
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2013-08-08 20:09:55 +00:00
|
|
|
static int pci_bus_reset(struct pci_bus *bus, int probe)
|
|
|
|
{
|
2018-07-19 23:04:09 +00:00
|
|
|
int ret;
|
|
|
|
|
2015-01-16 00:16:04 +00:00
|
|
|
if (!bus->self || !pci_bus_resetable(bus))
|
2013-08-08 20:09:55 +00:00
|
|
|
return -ENOTTY;
|
|
|
|
|
|
|
|
if (probe)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
pci_bus_lock(bus);
|
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
|
2018-07-19 23:04:11 +00:00
|
|
|
ret = pci_bridge_secondary_bus_reset(bus->self);
|
2013-08-08 20:09:55 +00:00
|
|
|
|
|
|
|
pci_bus_unlock(bus);
|
|
|
|
|
2018-07-19 23:04:09 +00:00
|
|
|
return ret;
|
2013-08-08 20:09:55 +00:00
|
|
|
}
|
|
|
|
|
2018-09-20 16:27:11 +00:00
|
|
|
/**
|
|
|
|
* pci_bus_error_reset - reset the bridge's subordinate bus
|
|
|
|
* @bridge: The parent device that connects to the bus to reset
|
|
|
|
*
|
|
|
|
* This function will first try to reset the slots on this bus if the method is
|
|
|
|
* available. If slot reset fails or is not available, this will fall back to a
|
|
|
|
* secondary bus reset.
|
|
|
|
*/
|
|
|
|
int pci_bus_error_reset(struct pci_dev *bridge)
|
|
|
|
{
|
|
|
|
struct pci_bus *bus = bridge->subordinate;
|
|
|
|
struct pci_slot *slot;
|
|
|
|
|
|
|
|
if (!bus)
|
|
|
|
return -ENOTTY;
|
|
|
|
|
|
|
|
mutex_lock(&pci_slot_mutex);
|
|
|
|
if (list_empty(&bus->slots))
|
|
|
|
goto bus_reset;
|
|
|
|
|
|
|
|
list_for_each_entry(slot, &bus->slots, list)
|
|
|
|
if (pci_probe_reset_slot(slot))
|
|
|
|
goto bus_reset;
|
|
|
|
|
|
|
|
list_for_each_entry(slot, &bus->slots, list)
|
|
|
|
if (pci_slot_reset(slot, 0))
|
|
|
|
goto bus_reset;
|
|
|
|
|
|
|
|
mutex_unlock(&pci_slot_mutex);
|
|
|
|
return 0;
|
|
|
|
bus_reset:
|
|
|
|
mutex_unlock(&pci_slot_mutex);
|
|
|
|
return pci_bus_reset(bridge->subordinate, 0);
|
|
|
|
}
|
|
|
|
|
2013-08-14 20:06:05 +00:00
|
|
|
/**
|
|
|
|
* pci_probe_reset_bus - probe whether a PCI bus can be reset
|
|
|
|
* @bus: PCI bus to probe
|
|
|
|
*
|
|
|
|
* Return 0 if bus can be reset, negative if a bus reset is not supported.
|
|
|
|
*/
|
|
|
|
int pci_probe_reset_bus(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
return pci_bus_reset(bus, 1);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_probe_reset_bus);
|
|
|
|
|
2013-08-08 20:09:55 +00:00
|
|
|
/**
|
2018-07-19 23:04:15 +00:00
|
|
|
* __pci_reset_bus - Try to reset a PCI bus
|
2013-08-08 20:09:55 +00:00
|
|
|
* @bus: top level PCI bus to reset
|
|
|
|
*
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
* Same as above except return -EAGAIN if the bus cannot be locked
|
2013-08-08 20:09:55 +00:00
|
|
|
*/
|
2018-07-19 23:04:15 +00:00
|
|
|
static int __pci_reset_bus(struct pci_bus *bus)
|
2013-08-08 20:09:55 +00:00
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = pci_bus_reset(bus, 1);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
if (pci_bus_trylock(bus)) {
|
2019-02-18 19:46:46 +00:00
|
|
|
pci_bus_save_and_disable_locked(bus);
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
might_sleep();
|
2018-07-19 23:04:11 +00:00
|
|
|
rc = pci_bridge_secondary_bus_reset(bus->self);
|
2019-02-18 19:46:46 +00:00
|
|
|
pci_bus_restore_locked(bus);
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
pci_bus_unlock(bus);
|
|
|
|
} else
|
|
|
|
rc = -EAGAIN;
|
2013-08-08 20:09:55 +00:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
/**
|
2018-07-19 23:04:15 +00:00
|
|
|
* pci_reset_bus - Try to reset a PCI bus
|
2018-07-19 23:04:12 +00:00
|
|
|
* @pdev: top level PCI device to reset via slot/bus
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
*
|
|
|
|
* Same as above except return -EAGAIN if the bus cannot be locked
|
|
|
|
*/
|
2018-07-19 23:04:15 +00:00
|
|
|
int pci_reset_bus(struct pci_dev *pdev)
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
{
|
2018-09-05 16:08:03 +00:00
|
|
|
return (!pci_probe_reset_slot(pdev->slot)) ?
|
2018-07-19 23:04:15 +00:00
|
|
|
__pci_reset_slot(pdev->slot) : __pci_reset_bus(pdev->bus);
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
}
|
2018-07-19 23:04:15 +00:00
|
|
|
EXPORT_SYMBOL_GPL(pci_reset_bus);
|
PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus()
When doing a function/slot/bus reset PCI grabs the device_lock for each
device to block things like suspend and driver probes, but call paths exist
where this lock may already be held. This creates an opportunity for
deadlock. For instance, vfio allows userspace to issue resets so long as
it owns the device(s). If a driver unbind .remove callback races with
userspace issuing a reset, we have a deadlock as userspace gets stuck
waiting on device_lock while another thread has device_lock and waits for
.remove to complete. To resolve this, we can make a version of the reset
interfaces which use trylock. With this, we can safely attempt a reset and
return error to userspace if there is contention.
[bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
the device, and B waits in this path:
driver_detach
device_lock # take device_lock
__device_release_driver
pci_device_remove # pci_bus_type.remove
vfio_pci_remove # pci_driver .remove
vfio_del_group_dev
wait_event(vfio.release_q, !vfio_dev_present) # wait (holding device_lock)
Now B is stuck until A gives up the file descriptor. If A tries to acquire
device_lock for any reason, we deadlock because A is waiting for B to release
the lock, and B is waiting for A to release the file descriptor.]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-16 22:14:31 +00:00
|
|
|
|
2007-05-15 11:59:13 +00:00
|
|
|
/**
|
|
|
|
* pcix_get_max_mmrbc - get PCI-X maximum designed memory read byte count
|
|
|
|
* @dev: PCI device to query
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Returns mmrbc: maximum designed memory read count in bytes or
|
|
|
|
* appropriate error value.
|
2007-05-15 11:59:13 +00:00
|
|
|
*/
|
|
|
|
int pcix_get_max_mmrbc(struct pci_dev *dev)
|
|
|
|
{
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
int cap;
|
2007-05-15 11:59:13 +00:00
|
|
|
u32 stat;
|
|
|
|
|
|
|
|
cap = pci_find_capability(dev, PCI_CAP_ID_PCIX);
|
|
|
|
if (!cap)
|
|
|
|
return -EINVAL;
|
|
|
|
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
if (pci_read_config_dword(dev, cap + PCI_X_STATUS, &stat))
|
2007-05-15 11:59:13 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
PCI: fix return value from pcix_get_max_mmrbc()
For the PCI_X_STATUS register, pcix_get_max_mmrbc() is returning an incorrect
value, which is based on:
(stat & PCI_X_STATUS_MAX_READ) >> 12
Valid return values are 512, 1024, 2048, 4096, which correspond to a 'stat'
(masked and right shifted by 21) of 0, 1, 2, 3, respectively.
A right shift by 11 would generate the correct return value when 'stat' (masked
and right shifted by 21) has a value of 1 or 2. But for a value of 0 or 3 it's
not possible to generate the correct return value by only right shifting.
Fix is based on pcix_get_mmrbc()'s similar dealings with the PCI_X_CMD register.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:40 +00:00
|
|
|
return 512 << ((stat & PCI_X_STATUS_MAX_READ) >> 21);
|
2007-05-15 11:59:13 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pcix_get_max_mmrbc);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pcix_get_mmrbc - get PCI-X maximum memory read byte count
|
|
|
|
* @dev: PCI device to query
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Returns mmrbc: maximum memory read count in bytes or appropriate error
|
|
|
|
* value.
|
2007-05-15 11:59:13 +00:00
|
|
|
*/
|
|
|
|
int pcix_get_mmrbc(struct pci_dev *dev)
|
|
|
|
{
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
int cap;
|
PCI: fix access of PCI_X_CMD by pcix get and set mmrbc functions
An e1000 driver on a system with a PCI-X bus was always being returned
a value of 135 from both pcix_get_mmrbc() and pcix_set_mmrbc(). This
value reflects an error return of PCIBIOS_BAD_REGISTER_NUMBER from
pci_bus_read_config_dword(,, cap + PCI_X_CMD,).
This is because for a dword, the following portion of the PCI_OP_READ()
macro:
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;
expands to:
if (pos & 3) return PCIBIOS_BAD_REGISTER_NUMBER;
And is always true for 'cap + PCI_X_CMD', which is 0xe4 + 2 = 0xe6. ('cap' is
the result of calling pci_find_capability(, PCI_CAP_ID_PCIX).)
The same problem exists for pci_bus_write_config_dword(,, cap + PCI_X_CMD,).
In both cases, instead of calling _dword(), _word() should be called.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:48 +00:00
|
|
|
u16 cmd;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
|
|
|
cap = pci_find_capability(dev, PCI_CAP_ID_PCIX);
|
|
|
|
if (!cap)
|
|
|
|
return -EINVAL;
|
|
|
|
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
if (pci_read_config_word(dev, cap + PCI_X_CMD, &cmd))
|
|
|
|
return -EINVAL;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
return 512 << ((cmd & PCI_X_CMD_MAX_READ) >> 2);
|
2007-05-15 11:59:13 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pcix_get_mmrbc);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pcix_set_mmrbc - set PCI-X maximum memory read byte count
|
|
|
|
* @dev: PCI device to query
|
|
|
|
* @mmrbc: maximum memory read count in bytes
|
|
|
|
* valid values are 512, 1024, 2048, 4096
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* If possible sets maximum memory read byte count, some bridges have errata
|
2007-05-15 11:59:13 +00:00
|
|
|
* that prevent this.
|
|
|
|
*/
|
|
|
|
int pcix_set_mmrbc(struct pci_dev *dev, int mmrbc)
|
|
|
|
{
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
int cap;
|
PCI: fix access of PCI_X_CMD by pcix get and set mmrbc functions
An e1000 driver on a system with a PCI-X bus was always being returned
a value of 135 from both pcix_get_mmrbc() and pcix_set_mmrbc(). This
value reflects an error return of PCIBIOS_BAD_REGISTER_NUMBER from
pci_bus_read_config_dword(,, cap + PCI_X_CMD,).
This is because for a dword, the following portion of the PCI_OP_READ()
macro:
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;
expands to:
if (pos & 3) return PCIBIOS_BAD_REGISTER_NUMBER;
And is always true for 'cap + PCI_X_CMD', which is 0xe4 + 2 = 0xe6. ('cap' is
the result of calling pci_find_capability(, PCI_CAP_ID_PCIX).)
The same problem exists for pci_bus_write_config_dword(,, cap + PCI_X_CMD,).
In both cases, instead of calling _dword(), _word() should be called.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:48 +00:00
|
|
|
u32 stat, v, o;
|
|
|
|
u16 cmd;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
2007-08-13 12:53:14 +00:00
|
|
|
if (mmrbc < 512 || mmrbc > 4096 || !is_power_of_2(mmrbc))
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
return -EINVAL;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
|
|
|
v = ffs(mmrbc) - 10;
|
|
|
|
|
|
|
|
cap = pci_find_capability(dev, PCI_CAP_ID_PCIX);
|
|
|
|
if (!cap)
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
return -EINVAL;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
if (pci_read_config_dword(dev, cap + PCI_X_STATUS, &stat))
|
|
|
|
return -EINVAL;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
|
|
|
if (v > (stat & PCI_X_STATUS_MAX_READ) >> 21)
|
|
|
|
return -E2BIG;
|
|
|
|
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
if (pci_read_config_word(dev, cap + PCI_X_CMD, &cmd))
|
|
|
|
return -EINVAL;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
|
|
|
o = (cmd & PCI_X_CMD_MAX_READ) >> 2;
|
|
|
|
if (o != v) {
|
2012-06-20 22:41:16 +00:00
|
|
|
if (v > o && (dev->bus->bus_flags & PCI_BUS_FLAGS_NO_MMRBC))
|
2007-05-15 11:59:13 +00:00
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
cmd &= ~PCI_X_CMD_MAX_READ;
|
|
|
|
cmd |= v << 2;
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
if (pci_write_config_word(dev, cap + PCI_X_CMD, cmd))
|
|
|
|
return -EIO;
|
2007-05-15 11:59:13 +00:00
|
|
|
}
|
PCI: cleanup error return for pcix get and set mmrbc functions
pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if
successful, or an appropriate error value, if not.
Distinguishing errors from correct values and understanding the meaning of an
error can be somewhat confusing in that:
correct values: 512, 1024, 2048, 4096
errors: -EINVAL -22
PCIBIOS_FUNC_NOT_SUPPORTED 0x81
PCIBIOS_BAD_VENDOR_ID 0x83
PCIBIOS_DEVICE_NOT_FOUND 0x86
PCIBIOS_BAD_REGISTER_NUMBER 0x87
PCIBIOS_SET_FAILED 0x88
PCIBIOS_BUFFER_TOO_SMALL 0x89
The PCIBIOS_ errors are returned from the PCI functions generated by the
PCI_OP_READ() and PCI_OP_WRITE() macros.
In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values
returned from pci_read_config_[word|dword]() and pci_write_config_word().
Following pcix_get_max_mmrbc()'s example, the following patch simply returns
-EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL
or -EIO for those encountered by pcix_set_mmrbc().
This simplification was chosen in light of the fact that none of the current
callers of these functions are interested in the specific type of error
encountered. In the future, should this change, one could simply create a
function that maps each PCIBIOS_ error to a corresponding unique errno value,
which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and
pcix_set_mmrbc().
Additionally, this patch eliminates some unnecessary variables.
Cc: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-03-10 03:26:55 +00:00
|
|
|
return 0;
|
2007-05-15 11:59:13 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pcix_set_mmrbc);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pcie_get_readrq - get PCI Express read request size
|
|
|
|
* @dev: PCI device to query
|
|
|
|
*
|
2019-01-09 20:14:42 +00:00
|
|
|
* Returns maximum memory read request in bytes or appropriate error value.
|
2007-05-15 11:59:13 +00:00
|
|
|
*/
|
|
|
|
int pcie_get_readrq(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
u16 ctl;
|
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &ctl);
|
2007-05-15 11:59:13 +00:00
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
return 128 << ((ctl & PCI_EXP_DEVCTL_READRQ) >> 12);
|
2007-05-15 11:59:13 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pcie_get_readrq);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pcie_set_readrq - set PCI Express maximum memory read request
|
|
|
|
* @dev: PCI device to query
|
2007-07-24 04:42:11 +00:00
|
|
|
* @rq: maximum memory read count in bytes
|
2007-05-15 11:59:13 +00:00
|
|
|
* valid values are 128, 256, 512, 1024, 2048, 4096
|
|
|
|
*
|
2011-06-28 23:26:25 +00:00
|
|
|
* If possible sets maximum memory read request in bytes
|
2007-05-15 11:59:13 +00:00
|
|
|
*/
|
|
|
|
int pcie_set_readrq(struct pci_dev *dev, int rq)
|
|
|
|
{
|
2012-07-24 09:20:06 +00:00
|
|
|
u16 v;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
2007-08-13 12:53:14 +00:00
|
|
|
if (rq < 128 || rq > 4096 || !is_power_of_2(rq))
|
2012-07-24 09:20:06 +00:00
|
|
|
return -EINVAL;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
2011-10-14 19:56:15 +00:00
|
|
|
/*
|
2019-01-09 20:14:42 +00:00
|
|
|
* If using the "performance" PCIe config, we clamp the read rq
|
|
|
|
* size to the max packet size to keep the host bridge from
|
|
|
|
* generating requests larger than we can cope with.
|
2011-10-14 19:56:15 +00:00
|
|
|
*/
|
|
|
|
if (pcie_bus_config == PCIE_BUS_PERFORMANCE) {
|
|
|
|
int mps = pcie_get_mps(dev);
|
|
|
|
|
|
|
|
if (mps < rq)
|
|
|
|
rq = mps;
|
|
|
|
}
|
|
|
|
|
|
|
|
v = (ffs(rq) - 8) << 12;
|
2007-05-15 11:59:13 +00:00
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
return pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL,
|
|
|
|
PCI_EXP_DEVCTL_READRQ, v);
|
2007-05-15 11:59:13 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pcie_set_readrq);
|
|
|
|
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
/**
|
|
|
|
* pcie_get_mps - get PCI Express maximum payload size
|
|
|
|
* @dev: PCI device to query
|
|
|
|
*
|
|
|
|
* Returns maximum payload size in bytes
|
|
|
|
*/
|
|
|
|
int pcie_get_mps(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
u16 ctl;
|
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &ctl);
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
return 128 << ((ctl & PCI_EXP_DEVCTL_PAYLOAD) >> 5);
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
}
|
2013-09-24 18:08:06 +00:00
|
|
|
EXPORT_SYMBOL(pcie_get_mps);
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pcie_set_mps - set PCI Express maximum payload size
|
|
|
|
* @dev: PCI device to query
|
2011-08-20 18:49:43 +00:00
|
|
|
* @mps: maximum payload size in bytes
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
* valid values are 128, 256, 512, 1024, 2048, 4096
|
|
|
|
*
|
|
|
|
* If possible sets maximum payload size
|
|
|
|
*/
|
|
|
|
int pcie_set_mps(struct pci_dev *dev, int mps)
|
|
|
|
{
|
2012-07-24 09:20:06 +00:00
|
|
|
u16 v;
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
|
|
|
|
if (mps < 128 || mps > 4096 || !is_power_of_2(mps))
|
2012-07-24 09:20:06 +00:00
|
|
|
return -EINVAL;
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
|
|
|
|
v = ffs(mps) - 8;
|
2013-11-14 18:28:18 +00:00
|
|
|
if (v > dev->pcie_mpss)
|
2012-07-24 09:20:06 +00:00
|
|
|
return -EINVAL;
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
v <<= 5;
|
|
|
|
|
2012-07-24 09:20:06 +00:00
|
|
|
return pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL,
|
|
|
|
PCI_EXP_DEVCTL_PAYLOAD, v);
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
}
|
2013-09-24 18:08:06 +00:00
|
|
|
EXPORT_SYMBOL(pcie_set_mps);
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
|
PCI: Add pcie_bandwidth_available() to compute bandwidth available to device
Add pcie_bandwidth_available() to compute the bandwidth available to a
device. This may be limited by the device itself or by a slower upstream
link leading to the device.
The available bandwidth at each link along the path is computed as:
link_width * link_speed * (1 - encoding_overhead)
2.5 and 5.0 GT/s links use 8b/10b encoding, which reduces the raw bandwidth
available by 20%; 8.0 GT/s and faster links use 128b/130b encoding, which
reduces it by about 1.5%.
The result is in Mb/s, i.e., megabits/second, of raw bandwidth.
Also return the device with the slowest link and the speed and width of
that link.
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
[bhelgaas: changelog, leave pcie_get_minimum_link() alone for now, return
bw directly, use pci_upstream_bridge(), check "next_bw <= bw" to find
uppermost limiting device, return speed/width of the limiting device]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-03-30 13:37:44 +00:00
|
|
|
/**
|
|
|
|
* pcie_bandwidth_available - determine minimum link settings of a PCIe
|
|
|
|
* device and its bandwidth limitation
|
|
|
|
* @dev: PCI device to query
|
|
|
|
* @limiting_dev: storage for device causing the bandwidth limitation
|
|
|
|
* @speed: storage for speed of limiting device
|
|
|
|
* @width: storage for width of limiting device
|
|
|
|
*
|
|
|
|
* Walk up the PCI device chain and find the point where the minimum
|
|
|
|
* bandwidth is available. Return the bandwidth available there and (if
|
|
|
|
* limiting_dev, speed, and width pointers are supplied) information about
|
|
|
|
* that point. The bandwidth returned is in Mb/s, i.e., megabits/second of
|
|
|
|
* raw bandwidth.
|
|
|
|
*/
|
|
|
|
u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev **limiting_dev,
|
|
|
|
enum pci_bus_speed *speed,
|
|
|
|
enum pcie_link_width *width)
|
|
|
|
{
|
|
|
|
u16 lnksta;
|
|
|
|
enum pci_bus_speed next_speed;
|
|
|
|
enum pcie_link_width next_width;
|
|
|
|
u32 bw, next_bw;
|
|
|
|
|
|
|
|
if (speed)
|
|
|
|
*speed = PCI_SPEED_UNKNOWN;
|
|
|
|
if (width)
|
|
|
|
*width = PCIE_LNK_WIDTH_UNKNOWN;
|
|
|
|
|
|
|
|
bw = 0;
|
|
|
|
|
|
|
|
while (dev) {
|
|
|
|
pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
|
|
|
|
|
|
|
|
next_speed = pcie_link_speed[lnksta & PCI_EXP_LNKSTA_CLS];
|
|
|
|
next_width = (lnksta & PCI_EXP_LNKSTA_NLW) >>
|
|
|
|
PCI_EXP_LNKSTA_NLW_SHIFT;
|
|
|
|
|
|
|
|
next_bw = next_width * PCIE_SPEED2MBS_ENC(next_speed);
|
|
|
|
|
|
|
|
/* Check if current device limits the total bandwidth */
|
|
|
|
if (!bw || next_bw <= bw) {
|
|
|
|
bw = next_bw;
|
|
|
|
|
|
|
|
if (limiting_dev)
|
|
|
|
*limiting_dev = dev;
|
|
|
|
if (speed)
|
|
|
|
*speed = next_speed;
|
|
|
|
if (width)
|
|
|
|
*width = next_width;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev = pci_upstream_bridge(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
return bw;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pcie_bandwidth_available);
|
|
|
|
|
2018-03-30 12:44:05 +00:00
|
|
|
/**
|
|
|
|
* pcie_get_speed_cap - query for the PCI device's link speed capability
|
|
|
|
* @dev: PCI device to query
|
|
|
|
*
|
|
|
|
* Query the PCI device speed capability. Return the maximum link speed
|
|
|
|
* supported by the device.
|
|
|
|
*/
|
|
|
|
enum pci_bus_speed pcie_get_speed_cap(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
u32 lnkcap2, lnkcap;
|
|
|
|
|
|
|
|
/*
|
PCI: Fix incorrect value returned from pcie_get_speed_cap()
The macros PCI_EXP_LNKCAP_SLS_*GB are values, not bit masks. We must mask
the register and compare it against them.
This fixes errors like this:
amdgpu: [powerplay] failed to send message 261 ret is 0
when a PCIe-v3 card is plugged into a PCIe-v1 slot, because the slot is
being incorrectly reported as PCIe-v3 capable.
6cf57be0f78e, which appeared in v4.17, added pcie_get_speed_cap() with the
incorrect test of PCI_EXP_LNKCAP_SLS as a bitmask. 5d9a63304032, which
appeared in v4.19, changed amdgpu to use pcie_get_speed_cap(), so the
amdgpu bug reports below are regressions in v4.19.
Fixes: 6cf57be0f78e ("PCI: Add pcie_get_speed_cap() to find max supported link speed")
Fixes: 5d9a63304032 ("drm/amdgpu: use pcie functions for link width and speed")
Link: https://bugs.freedesktop.org/show_bug.cgi?id=108704
Link: https://bugs.freedesktop.org/show_bug.cgi?id=108778
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
[bhelgaas: update comment, remove use of PCI_EXP_LNKCAP_SLS_8_0GB and
PCI_EXP_LNKCAP_SLS_16_0GB since those should be covered by PCI_EXP_LNKCAP2,
remove test of PCI_EXP_LNKCAP for zero, since that register is required]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # v4.17+
2018-11-26 16:37:13 +00:00
|
|
|
* Link Capabilities 2 was added in PCIe r3.0, sec 7.8.18. The
|
|
|
|
* implementation note there recommends using the Supported Link
|
|
|
|
* Speeds Vector in Link Capabilities 2 when supported.
|
|
|
|
*
|
|
|
|
* Without Link Capabilities 2, i.e., prior to PCIe r3.0, software
|
|
|
|
* should use the Supported Link Speeds field in Link Capabilities,
|
|
|
|
* where only 2.5 GT/s and 5.0 GT/s speeds were defined.
|
2018-03-30 12:44:05 +00:00
|
|
|
*/
|
|
|
|
pcie_capability_read_dword(dev, PCI_EXP_LNKCAP2, &lnkcap2);
|
|
|
|
if (lnkcap2) { /* PCIe r3.0-compliant */
|
2019-06-04 16:24:43 +00:00
|
|
|
if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_32_0GB)
|
|
|
|
return PCIE_SPEED_32_0GT;
|
|
|
|
else if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_16_0GB)
|
2018-03-30 12:44:05 +00:00
|
|
|
return PCIE_SPEED_16_0GT;
|
|
|
|
else if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
|
|
|
|
return PCIE_SPEED_8_0GT;
|
|
|
|
else if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
|
|
|
|
return PCIE_SPEED_5_0GT;
|
|
|
|
else if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
|
|
|
|
return PCIE_SPEED_2_5GT;
|
|
|
|
return PCI_SPEED_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &lnkcap);
|
PCI: Fix incorrect value returned from pcie_get_speed_cap()
The macros PCI_EXP_LNKCAP_SLS_*GB are values, not bit masks. We must mask
the register and compare it against them.
This fixes errors like this:
amdgpu: [powerplay] failed to send message 261 ret is 0
when a PCIe-v3 card is plugged into a PCIe-v1 slot, because the slot is
being incorrectly reported as PCIe-v3 capable.
6cf57be0f78e, which appeared in v4.17, added pcie_get_speed_cap() with the
incorrect test of PCI_EXP_LNKCAP_SLS as a bitmask. 5d9a63304032, which
appeared in v4.19, changed amdgpu to use pcie_get_speed_cap(), so the
amdgpu bug reports below are regressions in v4.19.
Fixes: 6cf57be0f78e ("PCI: Add pcie_get_speed_cap() to find max supported link speed")
Fixes: 5d9a63304032 ("drm/amdgpu: use pcie functions for link width and speed")
Link: https://bugs.freedesktop.org/show_bug.cgi?id=108704
Link: https://bugs.freedesktop.org/show_bug.cgi?id=108778
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
[bhelgaas: update comment, remove use of PCI_EXP_LNKCAP_SLS_8_0GB and
PCI_EXP_LNKCAP_SLS_16_0GB since those should be covered by PCI_EXP_LNKCAP2,
remove test of PCI_EXP_LNKCAP for zero, since that register is required]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # v4.17+
2018-11-26 16:37:13 +00:00
|
|
|
if ((lnkcap & PCI_EXP_LNKCAP_SLS) == PCI_EXP_LNKCAP_SLS_5_0GB)
|
|
|
|
return PCIE_SPEED_5_0GT;
|
|
|
|
else if ((lnkcap & PCI_EXP_LNKCAP_SLS) == PCI_EXP_LNKCAP_SLS_2_5GB)
|
|
|
|
return PCIE_SPEED_2_5GT;
|
2018-03-30 12:44:05 +00:00
|
|
|
|
|
|
|
return PCI_SPEED_UNKNOWN;
|
|
|
|
}
|
2018-06-25 18:17:41 +00:00
|
|
|
EXPORT_SYMBOL(pcie_get_speed_cap);
|
2018-03-30 12:44:05 +00:00
|
|
|
|
2018-03-30 13:24:36 +00:00
|
|
|
/**
|
|
|
|
* pcie_get_width_cap - query for the PCI device's link width capability
|
|
|
|
* @dev: PCI device to query
|
|
|
|
*
|
|
|
|
* Query the PCI device width capability. Return the maximum link width
|
|
|
|
* supported by the device.
|
|
|
|
*/
|
|
|
|
enum pcie_link_width pcie_get_width_cap(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
u32 lnkcap;
|
|
|
|
|
|
|
|
pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &lnkcap);
|
|
|
|
if (lnkcap)
|
|
|
|
return (lnkcap & PCI_EXP_LNKCAP_MLW) >> 4;
|
|
|
|
|
|
|
|
return PCIE_LNK_WIDTH_UNKNOWN;
|
|
|
|
}
|
2018-06-25 18:17:41 +00:00
|
|
|
EXPORT_SYMBOL(pcie_get_width_cap);
|
2018-03-30 13:24:36 +00:00
|
|
|
|
2018-03-30 13:32:03 +00:00
|
|
|
/**
|
|
|
|
* pcie_bandwidth_capable - calculate a PCI device's link bandwidth capability
|
|
|
|
* @dev: PCI device
|
|
|
|
* @speed: storage for link speed
|
|
|
|
* @width: storage for link width
|
|
|
|
*
|
|
|
|
* Calculate a PCI device's link bandwidth by querying for its link speed
|
|
|
|
* and width, multiplying them, and applying encoding overhead. The result
|
|
|
|
* is in Mb/s, i.e., megabits/second of raw bandwidth.
|
|
|
|
*/
|
|
|
|
u32 pcie_bandwidth_capable(struct pci_dev *dev, enum pci_bus_speed *speed,
|
|
|
|
enum pcie_link_width *width)
|
|
|
|
{
|
|
|
|
*speed = pcie_get_speed_cap(dev);
|
|
|
|
*width = pcie_get_width_cap(dev);
|
|
|
|
|
|
|
|
if (*speed == PCI_SPEED_UNKNOWN || *width == PCIE_LNK_WIDTH_UNKNOWN)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return *width * PCIE_SPEED2MBS_ENC(*speed);
|
|
|
|
}
|
|
|
|
|
2018-03-30 13:56:47 +00:00
|
|
|
/**
|
2018-08-06 23:25:35 +00:00
|
|
|
* __pcie_print_link_status - Report the PCI device's link speed and width
|
2018-03-30 13:56:47 +00:00
|
|
|
* @dev: PCI device to query
|
2018-08-06 23:25:35 +00:00
|
|
|
* @verbose: Print info even when enough bandwidth is available
|
2018-03-30 13:56:47 +00:00
|
|
|
*
|
2018-08-06 23:25:35 +00:00
|
|
|
* If the available bandwidth at the device is less than the device is
|
|
|
|
* capable of, report the device's maximum possible bandwidth and the
|
|
|
|
* upstream link that limits its performance. If @verbose, always print
|
|
|
|
* the available bandwidth, even if the device isn't constrained.
|
2018-03-30 13:56:47 +00:00
|
|
|
*/
|
2018-08-06 23:25:35 +00:00
|
|
|
void __pcie_print_link_status(struct pci_dev *dev, bool verbose)
|
2018-03-30 13:56:47 +00:00
|
|
|
{
|
|
|
|
enum pcie_link_width width, width_cap;
|
|
|
|
enum pci_bus_speed speed, speed_cap;
|
|
|
|
struct pci_dev *limiting_dev = NULL;
|
|
|
|
u32 bw_avail, bw_cap;
|
|
|
|
|
|
|
|
bw_cap = pcie_bandwidth_capable(dev, &speed_cap, &width_cap);
|
|
|
|
bw_avail = pcie_bandwidth_available(dev, &limiting_dev, &speed, &width);
|
|
|
|
|
2018-08-06 23:25:35 +00:00
|
|
|
if (bw_avail >= bw_cap && verbose)
|
2018-04-20 17:56:36 +00:00
|
|
|
pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s x%d link)\n",
|
2018-03-30 13:56:47 +00:00
|
|
|
bw_cap / 1000, bw_cap % 1000,
|
|
|
|
PCIE_SPEED2STR(speed_cap), width_cap);
|
2018-08-06 23:25:35 +00:00
|
|
|
else if (bw_avail < bw_cap)
|
2018-04-20 17:56:36 +00:00
|
|
|
pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
|
2018-03-30 13:56:47 +00:00
|
|
|
bw_avail / 1000, bw_avail % 1000,
|
|
|
|
PCIE_SPEED2STR(speed), width,
|
|
|
|
limiting_dev ? pci_name(limiting_dev) : "<unknown>",
|
|
|
|
bw_cap / 1000, bw_cap % 1000,
|
|
|
|
PCIE_SPEED2STR(speed_cap), width_cap);
|
|
|
|
}
|
2018-08-06 23:25:35 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pcie_print_link_status - Report the PCI device's link speed and width
|
|
|
|
* @dev: PCI device to query
|
|
|
|
*
|
|
|
|
* Report the available bandwidth at the device.
|
|
|
|
*/
|
|
|
|
void pcie_print_link_status(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
__pcie_print_link_status(dev, true);
|
|
|
|
}
|
2018-03-30 13:56:47 +00:00
|
|
|
EXPORT_SYMBOL(pcie_print_link_status);
|
|
|
|
|
2006-12-18 01:31:06 +00:00
|
|
|
/**
|
|
|
|
* pci_select_bars - Make BAR mask from the type of resource
|
2007-02-10 22:41:56 +00:00
|
|
|
* @dev: the PCI device for which BAR mask is made
|
2006-12-18 01:31:06 +00:00
|
|
|
* @flags: resource type mask to be selected
|
|
|
|
*
|
|
|
|
* This helper routine makes bar mask from the type of resource.
|
|
|
|
*/
|
|
|
|
int pci_select_bars(struct pci_dev *dev, unsigned long flags)
|
|
|
|
{
|
|
|
|
int i, bars = 0;
|
|
|
|
for (i = 0; i < PCI_NUM_RESOURCES; i++)
|
|
|
|
if (pci_resource_flags(dev, i) & flags)
|
|
|
|
bars |= (1 << i);
|
|
|
|
return bars;
|
|
|
|
}
|
2014-04-25 20:32:25 +00:00
|
|
|
EXPORT_SYMBOL(pci_select_bars);
|
2006-12-18 01:31:06 +00:00
|
|
|
|
2010-02-02 22:38:13 +00:00
|
|
|
/* Some architectures require additional programming to enable VGA */
|
|
|
|
static arch_set_vga_state_t arch_set_vga_state;
|
|
|
|
|
|
|
|
void __init pci_register_set_vga_state(arch_set_vga_state_t func)
|
|
|
|
{
|
|
|
|
arch_set_vga_state = func; /* NULL disables */
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_set_vga_state_arch(struct pci_dev *dev, bool decode,
|
2014-04-19 00:13:49 +00:00
|
|
|
unsigned int command_bits, u32 flags)
|
2010-02-02 22:38:13 +00:00
|
|
|
{
|
|
|
|
if (arch_set_vga_state)
|
|
|
|
return arch_set_vga_state(dev, decode, command_bits,
|
2011-05-25 04:00:49 +00:00
|
|
|
flags);
|
2010-02-02 22:38:13 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-08-11 05:52:06 +00:00
|
|
|
/**
|
|
|
|
* pci_set_vga_state - set VGA decode state on device and parents if requested
|
2009-09-17 22:28:22 +00:00
|
|
|
* @dev: the PCI device
|
|
|
|
* @decode: true = enable decoding, false = disable decoding
|
|
|
|
* @command_bits: PCI_COMMAND_IO and/or PCI_COMMAND_MEMORY
|
2011-05-26 02:21:25 +00:00
|
|
|
* @flags: traverse ancestors and change bridges
|
2010-06-01 05:32:24 +00:00
|
|
|
* CHANGE_BRIDGE_ONLY / CHANGE_BRIDGE
|
2009-08-11 05:52:06 +00:00
|
|
|
*/
|
|
|
|
int pci_set_vga_state(struct pci_dev *dev, bool decode,
|
2010-06-01 05:32:24 +00:00
|
|
|
unsigned int command_bits, u32 flags)
|
2009-08-11 05:52:06 +00:00
|
|
|
{
|
|
|
|
struct pci_bus *bus;
|
|
|
|
struct pci_dev *bridge;
|
|
|
|
u16 cmd;
|
2010-02-02 22:38:13 +00:00
|
|
|
int rc;
|
2009-08-11 05:52:06 +00:00
|
|
|
|
2014-04-05 21:14:22 +00:00
|
|
|
WARN_ON((flags & PCI_VGA_STATE_CHANGE_DECODES) && (command_bits & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
|
2009-08-11 05:52:06 +00:00
|
|
|
|
2010-02-02 22:38:13 +00:00
|
|
|
/* ARCH specific VGA enables */
|
2010-06-01 05:32:24 +00:00
|
|
|
rc = pci_set_vga_state_arch(dev, decode, command_bits, flags);
|
2010-02-02 22:38:13 +00:00
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
2010-06-01 05:32:24 +00:00
|
|
|
if (flags & PCI_VGA_STATE_CHANGE_DECODES) {
|
|
|
|
pci_read_config_word(dev, PCI_COMMAND, &cmd);
|
|
|
|
if (decode == true)
|
|
|
|
cmd |= command_bits;
|
|
|
|
else
|
|
|
|
cmd &= ~command_bits;
|
|
|
|
pci_write_config_word(dev, PCI_COMMAND, cmd);
|
|
|
|
}
|
2009-08-11 05:52:06 +00:00
|
|
|
|
2010-06-01 05:32:24 +00:00
|
|
|
if (!(flags & PCI_VGA_STATE_CHANGE_BRIDGE))
|
2009-08-11 05:52:06 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
bus = dev->bus;
|
|
|
|
while (bus) {
|
|
|
|
bridge = bus->self;
|
|
|
|
if (bridge) {
|
|
|
|
pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
|
|
|
|
&cmd);
|
|
|
|
if (decode == true)
|
|
|
|
cmd |= PCI_BRIDGE_CTL_VGA;
|
|
|
|
else
|
|
|
|
cmd &= ~PCI_BRIDGE_CTL_VGA;
|
|
|
|
pci_write_config_word(bridge, PCI_BRIDGE_CONTROL,
|
|
|
|
cmd);
|
|
|
|
}
|
|
|
|
bus = bus->parent;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-02-24 19:43:45 +00:00
|
|
|
/**
|
|
|
|
* pci_add_dma_alias - Add a DMA devfn alias for a device
|
|
|
|
* @dev: the PCI device for which alias is added
|
|
|
|
* @devfn: alias slot and function
|
|
|
|
*
|
2018-05-30 20:13:11 +00:00
|
|
|
* This helper encodes an 8-bit devfn as a bit number in dma_alias_mask
|
|
|
|
* which is used to program permissible bus-devfn source addresses for DMA
|
|
|
|
* requests in an IOMMU. These aliases factor into IOMMU group creation
|
|
|
|
* and are useful for devices generating DMA requests beyond or different
|
|
|
|
* from their logical bus-devfn. Examples include device quirks where the
|
|
|
|
* device simply uses the wrong devfn, as well as non-transparent bridges
|
|
|
|
* where the alias may be a proxy for devices in another domain.
|
|
|
|
*
|
|
|
|
* IOMMU group creation is performed during device discovery or addition,
|
|
|
|
* prior to any potential DMA mapping and therefore prior to driver probing
|
|
|
|
* (especially for userspace assigned devices where IOMMU group definition
|
|
|
|
* cannot be left as a userspace activity). DMA aliases should therefore
|
|
|
|
* be configured via quirks, such as the PCI fixup header quirk.
|
2016-02-24 19:43:45 +00:00
|
|
|
*/
|
|
|
|
void pci_add_dma_alias(struct pci_dev *dev, u8 devfn)
|
|
|
|
{
|
2016-03-03 14:38:02 +00:00
|
|
|
if (!dev->dma_alias_mask)
|
2018-08-30 10:32:36 +00:00
|
|
|
dev->dma_alias_mask = bitmap_zalloc(U8_MAX, GFP_KERNEL);
|
2016-03-03 14:38:02 +00:00
|
|
|
if (!dev->dma_alias_mask) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_warn(dev, "Unable to allocate DMA alias mask\n");
|
2016-03-03 14:38:02 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
set_bit(devfn, dev->dma_alias_mask);
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_info(dev, "Enabling fixed DMA alias to %02x.%d\n",
|
2016-02-24 19:43:54 +00:00
|
|
|
PCI_SLOT(devfn), PCI_FUNC(devfn));
|
2016-02-24 19:43:45 +00:00
|
|
|
}
|
|
|
|
|
2016-03-03 14:38:02 +00:00
|
|
|
bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2)
|
|
|
|
{
|
|
|
|
return (dev1->dma_alias_mask &&
|
|
|
|
test_bit(dev2->devfn, dev1->dma_alias_mask)) ||
|
|
|
|
(dev2->dma_alias_mask &&
|
|
|
|
test_bit(dev1->devfn, dev2->dma_alias_mask));
|
|
|
|
}
|
|
|
|
|
2013-12-01 01:34:37 +00:00
|
|
|
bool pci_device_is_present(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
u32 v;
|
|
|
|
|
2017-03-30 03:49:17 +00:00
|
|
|
if (pci_dev_is_disconnected(pdev))
|
|
|
|
return false;
|
2013-12-01 01:34:37 +00:00
|
|
|
return pci_bus_read_dev_vendor_id(pdev->bus, pdev->devfn, &v, 0);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_device_is_present);
|
|
|
|
|
2015-04-13 14:23:36 +00:00
|
|
|
void pci_ignore_hotplug(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
struct pci_dev *bridge = dev->bus->self;
|
|
|
|
|
|
|
|
dev->ignore_hotplug = 1;
|
|
|
|
/* Propagate the "ignore hotplug" setting to the parent bridge. */
|
|
|
|
if (bridge)
|
|
|
|
bridge->ignore_hotplug = 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_ignore_hotplug);
|
|
|
|
|
2017-04-10 11:58:12 +00:00
|
|
|
resource_size_t __weak pcibios_default_alignment(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-07-29 10:13:57 +00:00
|
|
|
/*
|
|
|
|
* Arches that don't want to expose struct resource to userland as-is in
|
|
|
|
* sysfs and /proc can implement their own pci_resource_to_user().
|
|
|
|
*/
|
|
|
|
void __weak pci_resource_to_user(const struct pci_dev *dev, int bar,
|
|
|
|
const struct resource *rsrc,
|
|
|
|
resource_size_t *start, resource_size_t *end)
|
|
|
|
{
|
|
|
|
*start = rsrc->start;
|
|
|
|
*end = rsrc->end;
|
|
|
|
}
|
|
|
|
|
2009-03-16 08:13:39 +00:00
|
|
|
#define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
|
|
|
|
static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
|
2009-11-06 22:41:23 +00:00
|
|
|
static DEFINE_SPINLOCK(resource_alignment_lock);
|
2009-03-16 08:13:39 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_specified_resource_alignment - get resource alignment specified by user.
|
|
|
|
* @dev: the PCI device to get
|
2017-04-10 11:58:14 +00:00
|
|
|
* @resize: whether or not to change resources' size when reassigning alignment
|
2009-03-16 08:13:39 +00:00
|
|
|
*
|
|
|
|
* RETURNS: Resource alignment if it is specified.
|
|
|
|
* Zero if it is not specified.
|
|
|
|
*/
|
2017-04-10 11:58:14 +00:00
|
|
|
static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
|
|
|
|
bool *resize)
|
2009-03-16 08:13:39 +00:00
|
|
|
{
|
2018-07-30 16:18:37 +00:00
|
|
|
int align_order, count;
|
2017-04-10 11:58:12 +00:00
|
|
|
resource_size_t align = pcibios_default_alignment();
|
2018-07-30 16:18:37 +00:00
|
|
|
const char *p;
|
|
|
|
int ret;
|
2009-03-16 08:13:39 +00:00
|
|
|
|
|
|
|
spin_lock(&resource_alignment_lock);
|
|
|
|
p = resource_alignment_param;
|
2017-04-10 11:58:12 +00:00
|
|
|
if (!*p && !align)
|
PCI: Ignore requested alignment for PROBE_ONLY and fixed resources
Users may request additional alignment of PCI resources, e.g., to align
BARs on page boundaries so they can be shared with guests via VFIO. This
of course may require reallocation if firmware has already assigned the
BARs with smaller alignments.
If the platform has requested PCI_PROBE_ONLY, we should never change any
PCI BARs, so we can't provide any additional alignment. Also, if a BAR is
marked as IORESOURCE_PCI_FIXED, e.g., for PCI Enhanced Allocation or if the
firmware depends on the current BAR value, we can't change the alignment.
In these cases, log a message and ignore the user's alignment requests.
[bhelgaas: changelog, use goto to simplify PCI_PROBE_ONLY check]
Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-09-13 09:00:31 +00:00
|
|
|
goto out;
|
|
|
|
if (pci_has_flag(PCI_PROBE_ONLY)) {
|
2017-04-10 11:58:12 +00:00
|
|
|
align = 0;
|
PCI: Ignore requested alignment for PROBE_ONLY and fixed resources
Users may request additional alignment of PCI resources, e.g., to align
BARs on page boundaries so they can be shared with guests via VFIO. This
of course may require reallocation if firmware has already assigned the
BARs with smaller alignments.
If the platform has requested PCI_PROBE_ONLY, we should never change any
PCI BARs, so we can't provide any additional alignment. Also, if a BAR is
marked as IORESOURCE_PCI_FIXED, e.g., for PCI Enhanced Allocation or if the
firmware depends on the current BAR value, we can't change the alignment.
In these cases, log a message and ignore the user's alignment requests.
[bhelgaas: changelog, use goto to simplify PCI_PROBE_ONLY check]
Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-09-13 09:00:31 +00:00
|
|
|
pr_info_once("PCI: Ignoring requested alignments (PCI_PROBE_ONLY)\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2009-03-16 08:13:39 +00:00
|
|
|
while (*p) {
|
|
|
|
count = 0;
|
|
|
|
if (sscanf(p, "%d%n", &align_order, &count) == 1 &&
|
|
|
|
p[count] == '@') {
|
|
|
|
p += count + 1;
|
|
|
|
} else {
|
|
|
|
align_order = -1;
|
|
|
|
}
|
2018-07-30 16:18:37 +00:00
|
|
|
|
|
|
|
ret = pci_dev_str_match(dev, p, &p);
|
|
|
|
if (ret == 1) {
|
|
|
|
*resize = true;
|
|
|
|
if (align_order == -1)
|
|
|
|
align = PAGE_SIZE;
|
|
|
|
else
|
|
|
|
align = 1 << align_order;
|
|
|
|
break;
|
|
|
|
} else if (ret < 0) {
|
|
|
|
pr_err("PCI: Can't parse resource_alignment parameter: %s\n",
|
|
|
|
p);
|
|
|
|
break;
|
2009-03-16 08:13:39 +00:00
|
|
|
}
|
2018-07-30 16:18:37 +00:00
|
|
|
|
2009-03-16 08:13:39 +00:00
|
|
|
if (*p != ';' && *p != ',') {
|
|
|
|
/* End of param or invalid format */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
p++;
|
|
|
|
}
|
PCI: Ignore requested alignment for PROBE_ONLY and fixed resources
Users may request additional alignment of PCI resources, e.g., to align
BARs on page boundaries so they can be shared with guests via VFIO. This
of course may require reallocation if firmware has already assigned the
BARs with smaller alignments.
If the platform has requested PCI_PROBE_ONLY, we should never change any
PCI BARs, so we can't provide any additional alignment. Also, if a BAR is
marked as IORESOURCE_PCI_FIXED, e.g., for PCI Enhanced Allocation or if the
firmware depends on the current BAR value, we can't change the alignment.
In these cases, log a message and ignore the user's alignment requests.
[bhelgaas: changelog, use goto to simplify PCI_PROBE_ONLY check]
Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-09-13 09:00:31 +00:00
|
|
|
out:
|
2009-03-16 08:13:39 +00:00
|
|
|
spin_unlock(&resource_alignment_lock);
|
|
|
|
return align;
|
|
|
|
}
|
|
|
|
|
2017-04-14 19:12:06 +00:00
|
|
|
static void pci_request_resource_alignment(struct pci_dev *dev, int bar,
|
2017-04-10 11:58:14 +00:00
|
|
|
resource_size_t align, bool resize)
|
2017-04-14 19:12:06 +00:00
|
|
|
{
|
|
|
|
struct resource *r = &dev->resource[bar];
|
|
|
|
resource_size_t size;
|
|
|
|
|
|
|
|
if (!(r->flags & IORESOURCE_MEM))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (r->flags & IORESOURCE_PCI_FIXED) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_info(dev, "BAR%d %pR: ignoring requested alignment %#llx\n",
|
2017-04-14 19:12:06 +00:00
|
|
|
bar, r, (unsigned long long)align);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
size = resource_size(r);
|
2017-04-17 20:20:58 +00:00
|
|
|
if (size >= align)
|
|
|
|
return;
|
2017-04-14 19:12:06 +00:00
|
|
|
|
2017-04-17 20:20:58 +00:00
|
|
|
/*
|
2017-04-10 11:58:14 +00:00
|
|
|
* Increase the alignment of the resource. There are two ways we
|
|
|
|
* can do this:
|
2017-04-17 20:20:58 +00:00
|
|
|
*
|
2017-04-10 11:58:14 +00:00
|
|
|
* 1) Increase the size of the resource. BARs are aligned on their
|
|
|
|
* size, so when we reallocate space for this resource, we'll
|
|
|
|
* allocate it with the larger alignment. This also prevents
|
|
|
|
* assignment of any other BARs inside the alignment region, so
|
|
|
|
* if we're requesting page alignment, this means no other BARs
|
|
|
|
* will share the page.
|
|
|
|
*
|
|
|
|
* The disadvantage is that this makes the resource larger than
|
|
|
|
* the hardware BAR, which may break drivers that compute things
|
|
|
|
* based on the resource size, e.g., to find registers at a
|
|
|
|
* fixed offset before the end of the BAR.
|
|
|
|
*
|
|
|
|
* 2) Retain the resource size, but use IORESOURCE_STARTALIGN and
|
|
|
|
* set r->start to the desired alignment. By itself this
|
|
|
|
* doesn't prevent other BARs being put inside the alignment
|
|
|
|
* region, but if we realign *every* resource of every device in
|
|
|
|
* the system, none of them will share an alignment region.
|
|
|
|
*
|
|
|
|
* When the user has requested alignment for only some devices via
|
|
|
|
* the "pci=resource_alignment" argument, "resize" is true and we
|
|
|
|
* use the first method. Otherwise we assume we're aligning all
|
|
|
|
* devices and we use the second.
|
2017-04-17 20:20:58 +00:00
|
|
|
*/
|
2017-04-10 11:58:14 +00:00
|
|
|
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_info(dev, "BAR%d %pR: requesting alignment to %#llx\n",
|
2017-04-17 20:20:58 +00:00
|
|
|
bar, r, (unsigned long long)align);
|
2017-04-14 19:12:06 +00:00
|
|
|
|
2017-04-10 11:58:14 +00:00
|
|
|
if (resize) {
|
|
|
|
r->start = 0;
|
|
|
|
r->end = align - 1;
|
|
|
|
} else {
|
|
|
|
r->flags &= ~IORESOURCE_SIZEALIGN;
|
|
|
|
r->flags |= IORESOURCE_STARTALIGN;
|
|
|
|
r->start = align;
|
|
|
|
r->end = r->start + size - 1;
|
|
|
|
}
|
2017-04-17 20:20:58 +00:00
|
|
|
r->flags |= IORESOURCE_UNSET;
|
2017-04-14 19:12:06 +00:00
|
|
|
}
|
|
|
|
|
2012-02-16 05:40:31 +00:00
|
|
|
/*
|
|
|
|
* This function disables memory decoding and releases memory resources
|
|
|
|
* of the device specified by kernel's boot parameter 'pci=resource_alignment='.
|
|
|
|
* It also rounds up size to specified alignment.
|
|
|
|
* Later on, the kernel will assign page-aligned memory resource back
|
|
|
|
* to the device.
|
|
|
|
*/
|
|
|
|
void pci_reassigndev_resource_alignment(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct resource *r;
|
2017-04-14 19:12:06 +00:00
|
|
|
resource_size_t align;
|
2012-02-16 05:40:31 +00:00
|
|
|
u16 command;
|
2017-04-10 11:58:14 +00:00
|
|
|
bool resize = false;
|
2012-02-16 05:40:31 +00:00
|
|
|
|
2016-09-13 09:00:32 +00:00
|
|
|
/*
|
|
|
|
* VF BARs are read-only zero according to SR-IOV spec r1.1, sec
|
|
|
|
* 3.4.1.11. Their resources are allocated from the space
|
|
|
|
* described by the VF BARx register in the PF's SR-IOV capability.
|
|
|
|
* We can't influence their alignment here.
|
|
|
|
*/
|
|
|
|
if (dev->is_virtfn)
|
|
|
|
return;
|
|
|
|
|
2012-03-19 05:46:26 +00:00
|
|
|
/* check if specified PCI is target device to reassign */
|
2017-04-10 11:58:14 +00:00
|
|
|
align = pci_specified_resource_alignment(dev, &resize);
|
2012-03-19 05:46:26 +00:00
|
|
|
if (!align)
|
2012-02-16 05:40:31 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL &&
|
|
|
|
(dev->class >> 8) == PCI_CLASS_BRIDGE_HOST) {
|
2018-01-18 18:55:24 +00:00
|
|
|
pci_warn(dev, "Can't reassign resources to host bridge\n");
|
2012-02-16 05:40:31 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
pci_read_config_word(dev, PCI_COMMAND, &command);
|
|
|
|
command &= ~PCI_COMMAND_MEMORY;
|
|
|
|
pci_write_config_word(dev, PCI_COMMAND, command);
|
|
|
|
|
2017-04-14 19:12:06 +00:00
|
|
|
for (i = 0; i <= PCI_ROM_RESOURCE; i++)
|
2017-04-10 11:58:14 +00:00
|
|
|
pci_request_resource_alignment(dev, i, align, resize);
|
PCI: Ignore requested alignment for PROBE_ONLY and fixed resources
Users may request additional alignment of PCI resources, e.g., to align
BARs on page boundaries so they can be shared with guests via VFIO. This
of course may require reallocation if firmware has already assigned the
BARs with smaller alignments.
If the platform has requested PCI_PROBE_ONLY, we should never change any
PCI BARs, so we can't provide any additional alignment. Also, if a BAR is
marked as IORESOURCE_PCI_FIXED, e.g., for PCI Enhanced Allocation or if the
firmware depends on the current BAR value, we can't change the alignment.
In these cases, log a message and ignore the user's alignment requests.
[bhelgaas: changelog, use goto to simplify PCI_PROBE_ONLY check]
Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-09-13 09:00:31 +00:00
|
|
|
|
2017-04-14 19:12:06 +00:00
|
|
|
/*
|
|
|
|
* Need to disable bridge's resource window,
|
2012-02-16 05:40:31 +00:00
|
|
|
* to enable the kernel to reassign new resource
|
|
|
|
* window later on.
|
|
|
|
*/
|
PCI: Rely on config space header type, not class code
The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).
When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code. The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-16 10:44:43 +00:00
|
|
|
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
|
2012-02-16 05:40:31 +00:00
|
|
|
for (i = PCI_BRIDGE_RESOURCES; i < PCI_NUM_RESOURCES; i++) {
|
|
|
|
r = &dev->resource[i];
|
|
|
|
if (!(r->flags & IORESOURCE_MEM))
|
|
|
|
continue;
|
2014-02-26 18:25:58 +00:00
|
|
|
r->flags |= IORESOURCE_UNSET;
|
2012-02-16 05:40:31 +00:00
|
|
|
r->end = resource_size(r) - 1;
|
|
|
|
r->start = 0;
|
|
|
|
}
|
|
|
|
pci_disable_bridge_window(dev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-04-12 17:20:03 +00:00
|
|
|
static ssize_t pci_set_resource_alignment_param(const char *buf, size_t count)
|
2009-03-16 08:13:39 +00:00
|
|
|
{
|
|
|
|
if (count > RESOURCE_ALIGNMENT_PARAM_SIZE - 1)
|
|
|
|
count = RESOURCE_ALIGNMENT_PARAM_SIZE - 1;
|
|
|
|
spin_lock(&resource_alignment_lock);
|
|
|
|
strncpy(resource_alignment_param, buf, count);
|
|
|
|
resource_alignment_param[count] = '\0';
|
|
|
|
spin_unlock(&resource_alignment_lock);
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2013-04-12 17:20:03 +00:00
|
|
|
static ssize_t pci_get_resource_alignment_param(char *buf, size_t size)
|
2009-03-16 08:13:39 +00:00
|
|
|
{
|
|
|
|
size_t count;
|
|
|
|
spin_lock(&resource_alignment_lock);
|
|
|
|
count = snprintf(buf, size, "%s", resource_alignment_param);
|
|
|
|
spin_unlock(&resource_alignment_lock);
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2018-12-21 07:54:33 +00:00
|
|
|
static ssize_t resource_alignment_show(struct bus_type *bus, char *buf)
|
2009-03-16 08:13:39 +00:00
|
|
|
{
|
|
|
|
return pci_get_resource_alignment_param(buf, PAGE_SIZE);
|
|
|
|
}
|
|
|
|
|
2018-12-21 07:54:33 +00:00
|
|
|
static ssize_t resource_alignment_store(struct bus_type *bus,
|
2009-03-16 08:13:39 +00:00
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
return pci_set_resource_alignment_param(buf, count);
|
|
|
|
}
|
|
|
|
|
2018-12-21 07:54:33 +00:00
|
|
|
static BUS_ATTR_RW(resource_alignment);
|
2009-03-16 08:13:39 +00:00
|
|
|
|
|
|
|
static int __init pci_resource_alignment_sysfs_init(void)
|
|
|
|
{
|
|
|
|
return bus_create_file(&pci_bus_type,
|
|
|
|
&bus_attr_resource_alignment);
|
|
|
|
}
|
|
|
|
late_initcall(pci_resource_alignment_sysfs_init);
|
|
|
|
|
2012-11-21 20:35:00 +00:00
|
|
|
static void pci_no_domains(void)
|
2007-10-11 20:57:27 +00:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_PCI_DOMAINS
|
|
|
|
pci_domains_supported = 0;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2018-05-15 09:07:00 +00:00
|
|
|
#ifdef CONFIG_PCI_DOMAINS_GENERIC
|
2014-09-29 14:29:27 +00:00
|
|
|
static atomic_t __domain_nr = ATOMIC_INIT(-1);
|
|
|
|
|
2018-05-15 09:07:00 +00:00
|
|
|
static int pci_get_new_domain_nr(void)
|
2014-09-29 14:29:27 +00:00
|
|
|
{
|
|
|
|
return atomic_inc_return(&__domain_nr);
|
|
|
|
}
|
2014-12-28 01:19:12 +00:00
|
|
|
|
2016-06-10 19:55:15 +00:00
|
|
|
static int of_pci_bus_find_domain_nr(struct device *parent)
|
2014-12-28 01:19:12 +00:00
|
|
|
{
|
|
|
|
static int use_dt_domains = -1;
|
PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr()
pci_create_root_bus() passes a "parent" pointer to
pci_bus_assign_domain_nr(). When CONFIG_PCI_DOMAINS_GENERIC is defined,
pci_bus_assign_domain_nr() dereferences that pointer. Many callers of
pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL
pointer dereference error.
7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
moved the "parent" dereference from arm64 to generic code. Only arm64 used
that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it
always supplied a valid "parent" pointer. Other arches supplied NULL
"parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they
used a no-op version of pci_bus_assign_domain_nr().
8c7d14746abc ("ARM/PCI: Move to generic PCI domains") defined
CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use
pci_common_init(), which supplies a NULL "parent" pointer.
These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash
with a NULL pointer dereference like this while probing PCI:
Unable to handle kernel NULL pointer dereference at virtual address 000000a4
PC is at pci_bus_assign_domain_nr+0x10/0x84
LR is at pci_create_root_bus+0x48/0x2e4
Kernel panic - not syncing: Attempted to kill init!
[bhelgaas: changelog, add "Reported:" and "Fixes:" tags]
Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1
Fixes: 8c7d14746abc ("ARM/PCI: Move to generic PCI domains")
Fixes: 7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
CC: stable@vger.kernel.org # v4.0+
2016-03-01 06:07:18 +00:00
|
|
|
int domain = -1;
|
2014-12-28 01:19:12 +00:00
|
|
|
|
PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr()
pci_create_root_bus() passes a "parent" pointer to
pci_bus_assign_domain_nr(). When CONFIG_PCI_DOMAINS_GENERIC is defined,
pci_bus_assign_domain_nr() dereferences that pointer. Many callers of
pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL
pointer dereference error.
7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
moved the "parent" dereference from arm64 to generic code. Only arm64 used
that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it
always supplied a valid "parent" pointer. Other arches supplied NULL
"parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they
used a no-op version of pci_bus_assign_domain_nr().
8c7d14746abc ("ARM/PCI: Move to generic PCI domains") defined
CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use
pci_common_init(), which supplies a NULL "parent" pointer.
These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash
with a NULL pointer dereference like this while probing PCI:
Unable to handle kernel NULL pointer dereference at virtual address 000000a4
PC is at pci_bus_assign_domain_nr+0x10/0x84
LR is at pci_create_root_bus+0x48/0x2e4
Kernel panic - not syncing: Attempted to kill init!
[bhelgaas: changelog, add "Reported:" and "Fixes:" tags]
Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1
Fixes: 8c7d14746abc ("ARM/PCI: Move to generic PCI domains")
Fixes: 7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
CC: stable@vger.kernel.org # v4.0+
2016-03-01 06:07:18 +00:00
|
|
|
if (parent)
|
|
|
|
domain = of_get_pci_domain_nr(parent->of_node);
|
2019-01-09 20:14:42 +00:00
|
|
|
|
2014-12-28 01:19:12 +00:00
|
|
|
/*
|
|
|
|
* Check DT domain and use_dt_domains values.
|
|
|
|
*
|
|
|
|
* If DT domain property is valid (domain >= 0) and
|
|
|
|
* use_dt_domains != 0, the DT assignment is valid since this means
|
|
|
|
* we have not previously allocated a domain number by using
|
|
|
|
* pci_get_new_domain_nr(); we should also update use_dt_domains to
|
|
|
|
* 1, to indicate that we have just assigned a domain number from
|
|
|
|
* DT.
|
|
|
|
*
|
|
|
|
* If DT domain property value is not valid (ie domain < 0), and we
|
|
|
|
* have not previously assigned a domain number from DT
|
|
|
|
* (use_dt_domains != 1) we should assign a domain number by
|
|
|
|
* using the:
|
|
|
|
*
|
|
|
|
* pci_get_new_domain_nr()
|
|
|
|
*
|
|
|
|
* API and update the use_dt_domains value to keep track of method we
|
|
|
|
* are using to assign domain numbers (use_dt_domains = 0).
|
|
|
|
*
|
|
|
|
* All other combinations imply we have a platform that is trying
|
|
|
|
* to mix domain numbers obtained from DT and pci_get_new_domain_nr(),
|
|
|
|
* which is a recipe for domain mishandling and it is prevented by
|
|
|
|
* invalidating the domain value (domain = -1) and printing a
|
|
|
|
* corresponding error.
|
|
|
|
*/
|
|
|
|
if (domain >= 0 && use_dt_domains) {
|
|
|
|
use_dt_domains = 1;
|
|
|
|
} else if (domain < 0 && use_dt_domains != 1) {
|
|
|
|
use_dt_domains = 0;
|
|
|
|
domain = pci_get_new_domain_nr();
|
|
|
|
} else {
|
2018-03-01 01:26:55 +00:00
|
|
|
if (parent)
|
|
|
|
pr_err("Node %pOF has ", parent->of_node);
|
|
|
|
pr_err("Inconsistent \"linux,pci-domain\" property in DT\n");
|
2014-12-28 01:19:12 +00:00
|
|
|
domain = -1;
|
|
|
|
}
|
|
|
|
|
2016-06-10 19:55:14 +00:00
|
|
|
return domain;
|
2014-12-28 01:19:12 +00:00
|
|
|
}
|
2016-06-10 19:55:15 +00:00
|
|
|
|
|
|
|
int pci_bus_find_domain_nr(struct pci_bus *bus, struct device *parent)
|
|
|
|
{
|
2016-06-10 20:36:26 +00:00
|
|
|
return acpi_disabled ? of_pci_bus_find_domain_nr(parent) :
|
|
|
|
acpi_pci_bus_find_domain_nr(bus);
|
2014-12-28 01:19:12 +00:00
|
|
|
}
|
|
|
|
#endif
|
2014-09-29 14:29:27 +00:00
|
|
|
|
2008-11-10 22:30:50 +00:00
|
|
|
/**
|
2012-10-30 06:26:18 +00:00
|
|
|
* pci_ext_cfg_avail - can we access extended PCI config space?
|
2008-11-10 22:30:50 +00:00
|
|
|
*
|
|
|
|
* Returns 1 if we can access PCI extended config space (offsets
|
|
|
|
* greater than 0xff). This is the default implementation. Architecture
|
|
|
|
* implementations can override this.
|
|
|
|
*/
|
2012-10-30 06:26:18 +00:00
|
|
|
int __weak pci_ext_cfg_avail(void)
|
2008-11-10 22:30:50 +00:00
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-12-09 06:52:13 +00:00
|
|
|
void __weak pci_fixup_cardbus(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pci_fixup_cardbus);
|
|
|
|
|
2008-11-22 17:37:14 +00:00
|
|
|
static int __init pci_setup(char *str)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
while (str) {
|
|
|
|
char *k = strchr(str, ',');
|
|
|
|
if (k)
|
|
|
|
*k++ = 0;
|
|
|
|
if (*str && (str = pcibios_setup(str)) && *str) {
|
2006-03-06 05:33:34 +00:00
|
|
|
if (!strcmp(str, "nomsi")) {
|
|
|
|
pci_no_msi();
|
2018-05-10 22:56:02 +00:00
|
|
|
} else if (!strncmp(str, "noats", 5)) {
|
|
|
|
pr_info("PCIe: ATS is disabled\n");
|
|
|
|
pcie_ats_disabled = true;
|
2007-10-05 20:17:58 +00:00
|
|
|
} else if (!strcmp(str, "noaer")) {
|
|
|
|
pci_no_aer();
|
2018-06-05 02:16:09 +00:00
|
|
|
} else if (!strcmp(str, "earlydump")) {
|
|
|
|
pci_early_dump = true;
|
2012-02-24 03:23:30 +00:00
|
|
|
} else if (!strncmp(str, "realloc=", 8)) {
|
|
|
|
pci_realloc_get_opt(str + 8);
|
2011-07-07 18:19:10 +00:00
|
|
|
} else if (!strncmp(str, "realloc", 7)) {
|
2012-02-24 03:23:30 +00:00
|
|
|
pci_realloc_get_opt("on");
|
2007-10-11 20:57:27 +00:00
|
|
|
} else if (!strcmp(str, "nodomains")) {
|
|
|
|
pci_no_domains();
|
2012-02-29 23:06:33 +00:00
|
|
|
} else if (!strncmp(str, "noari", 5)) {
|
|
|
|
pcie_ari_disabled = true;
|
2007-02-06 00:36:06 +00:00
|
|
|
} else if (!strncmp(str, "cbiosize=", 9)) {
|
|
|
|
pci_cardbus_io_size = memparse(str + 9, &str);
|
|
|
|
} else if (!strncmp(str, "cbmemsize=", 10)) {
|
|
|
|
pci_cardbus_mem_size = memparse(str + 10, &str);
|
2009-03-16 08:13:39 +00:00
|
|
|
} else if (!strncmp(str, "resource_alignment=", 19)) {
|
|
|
|
pci_set_resource_alignment_param(str + 19,
|
|
|
|
strlen(str + 19));
|
2009-04-22 22:52:09 +00:00
|
|
|
} else if (!strncmp(str, "ecrc=", 5)) {
|
|
|
|
pcie_ecrc_get_policy(str + 5);
|
2009-09-09 21:09:24 +00:00
|
|
|
} else if (!strncmp(str, "hpiosize=", 9)) {
|
|
|
|
pci_hotplug_io_size = memparse(str + 9, &str);
|
|
|
|
} else if (!strncmp(str, "hpmemsize=", 10)) {
|
|
|
|
pci_hotplug_mem_size = memparse(str + 10, &str);
|
2016-07-22 03:40:28 +00:00
|
|
|
} else if (!strncmp(str, "hpbussize=", 10)) {
|
|
|
|
pci_hotplug_bus_size =
|
|
|
|
simple_strtoul(str + 10, &str, 0);
|
|
|
|
if (pci_hotplug_bus_size > 0xff)
|
|
|
|
pci_hotplug_bus_size = DEFAULT_HOTPLUG_BUS_SIZE;
|
2011-10-03 14:50:20 +00:00
|
|
|
} else if (!strncmp(str, "pcie_bus_tune_off", 17)) {
|
|
|
|
pcie_bus_config = PCIE_BUS_TUNE_OFF;
|
PCI: Set PCI-E Max Payload Size on fabric
On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size. There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device. However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.
This can be achieved two ways:
- A conservative approach is to use the smallest common denominator of
the entire tree below a root complex for every device on that fabric.
This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.
It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.
- A more optimal way is possible, if it falls within a couple of
constraints:
* The top-level host bridge will never generate packets larger than the
smallest TLP (or if it can be controlled independently from its MPS at
least)
* The device will never generate packets larger than MPS (which can be
configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
some additional code to specifically deal with that case
Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.
In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.
To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls. "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.
NOTE: due to the location of the enablement, each arch will need to add
calls to this function. This patch only enables x86.
This patch includes a number of changes recommended by Benjamin
Herrenschmidt.
Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: Jon Mason <mason@myri.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-07-20 20:20:54 +00:00
|
|
|
} else if (!strncmp(str, "pcie_bus_safe", 13)) {
|
|
|
|
pcie_bus_config = PCIE_BUS_SAFE;
|
|
|
|
} else if (!strncmp(str, "pcie_bus_perf", 13)) {
|
|
|
|
pcie_bus_config = PCIE_BUS_PERFORMANCE;
|
2011-10-03 14:50:20 +00:00
|
|
|
} else if (!strncmp(str, "pcie_bus_peer2peer", 18)) {
|
|
|
|
pcie_bus_config = PCIE_BUS_PEER2PEER;
|
2012-04-30 21:21:02 +00:00
|
|
|
} else if (!strncmp(str, "pcie_scan_all", 13)) {
|
|
|
|
pci_add_flags(PCI_SCAN_ALL_PCIE_DEVS);
|
2018-07-30 16:18:40 +00:00
|
|
|
} else if (!strncmp(str, "disable_acs_redir=", 18)) {
|
2019-04-10 21:05:31 +00:00
|
|
|
disable_acs_redir_param = str + 18;
|
2006-03-06 05:33:34 +00:00
|
|
|
} else {
|
2019-04-20 04:03:46 +00:00
|
|
|
pr_err("PCI: Unknown option `%s'\n", str);
|
2006-03-06 05:33:34 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
str = k;
|
|
|
|
}
|
2006-09-26 08:52:41 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2006-09-26 08:52:41 +00:00
|
|
|
early_param("pci", pci_setup);
|
2019-04-10 21:05:31 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 'disable_acs_redir_param' is initialized in pci_setup(), above, to point
|
|
|
|
* to data in the __initdata section which will be freed after the init
|
|
|
|
* sequence is complete. We can't allocate memory in pci_setup() because some
|
|
|
|
* architectures do not have any memory allocation service available during
|
|
|
|
* an early_param() call. So we allocate memory and copy the variable here
|
|
|
|
* before the init section is freed.
|
|
|
|
*/
|
|
|
|
static int __init pci_realloc_setup_params(void)
|
|
|
|
{
|
|
|
|
disable_acs_redir_param = kstrdup(disable_acs_redir_param, GFP_KERNEL);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
pure_initcall(pci_realloc_setup_params);
|