In https://bugzilla.kernel.org/show_bug.cgi?id=48981
Peter reported that /proc/bus/pci/??/??.? does not work for 3.6.
This is because the device configuration space registers are
not accessible if the corresponding parent bridge is suspended or
the device is put into D3cold state.

This is the same as /sys/bus/pci/devices/0000:??:??.?/config access
issue.  So the function used to solve sysfs issue is used to solve
this issue.

This patch moves pci_config_pm_runtime_get()/_put() from pci/pci-sysfs.c
to pci/pci.c and makes them extern so they can be used by both the
sysfs and proc paths.

[bhelgaas: changelog, references, reporters]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48981
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=49031Reported-by: NForrest Loomis <cybercyst@gmail.com>
Reported-by: NPeter <lekensteyn@gmail.com>
Reported-by: NMicael Dias <kam1kaz3@gmail.com>
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org		# v3.6+

Some actions during shutdown need device to be in D0 state, such as
MSI shutdown etc, so resume device before shutdown.

Without this patch, a device may not be enumerated after a kexec
because the corresponding bridge is not in D0, so that
configuration space of the device is not accessible.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org		# v3.6+

If a PCI device and its parents are put into D3cold, unbinding the
device will trigger deadlock as follow:

- driver_unbind
  - device_release_driver
    - device_lock(dev)				<--- previous lock here
    - __device_release_driver
      - pm_runtime_get_sync
        ...
          - rpm_resume(dev)
            - rpm_resume(dev->parent)
              ...
                - pci_pm_runtime_resume
                  ...
                  - pci_set_power_state
                    - __pci_start_power_transition
                      - pci_wakeup_bus(dev->parent->subordinate)
                        - pci_walk_bus
                          - device_lock(dev)	<--- deadlock here


If we do not do device_lock in pci_walk_bus, we can avoid deadlock.
Device_lock in pci_walk_bus is introduced in commit:
d71374da, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38.  The patch author Zhang Yanmin
said device_lock is added to pci_walk_bus because:

  Some error handling functions call pci_walk_bus. For example, PCIe
  aer. Here we lock the device, so the driver wouldn't detach from the
  device, as the cb might call driver's callback function.

So I fixed the deadlock as follows:

- remove device_lock from pci_walk_bus
- add device_lock into callback if callback will call driver's callback

I checked pci_walk_bus users one by one, and found only PCIe aer needs
device lock.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org		# v3.6+
CC: Zhang Yanmin <yanmin.zhang@intel.com>

Commit 0d52f54e (PCI / ACPI: Make acpiphp
ignore root bridges using PCIe native hotplug) added code that made the
acpiphp driver completely ignore PCIe root complexes for which the kernel
had been granted control of the native PCIe hotplug feature by the BIOS
through _OSC. Later commit 619a5182
"PCI hotplug: Always allow acpiphp to handle non-PCIe bridges" relaxed
the constraints to allow acpiphp driver handle non-PCIe bridges under
such a complex.  The constraint needs to be relaxed further to allow
acpiphp driver to handle PCIe ports without native PCIe hotplug capability.

Some MR-IOV switch chipsets, such PLX8696, support multiple virtual PCIe
switches and may migrate downstream ports among virtual switches.  To
migrate a downstream port from the source virtual switch to the target, the
port needs to be hot-removed from the source and hot-added into the target.
The pciehp driver can't be used here because there are no slots within the
virtual PCIe switch.  So acpiphp driver is used to support downstream port
migration.  A typical configuration is as below:

    [Root without native PCIe HP]
        [Upstream port of vswitch without native PCIe HP]
            [Downstream port of vswitch with native PCIe HP]
                [PCIe endpoint]

Here acpiphp driver will be used to handle root ports and upstream port
in the virtual switch, and pciehp driver will be used to handle downstream
ports in the virtual switch.
Signed-off-by: NJiang Liu <liuj97@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>

This patch changes .add/.remove interfaces of acpi_pci_driver.
In the current implementation acpi_handle is passed as a parameter
of .add/.remove interface.  However, the acpi_pci_root structure
contains more useful information than just the acpi_handle.  This
enables us to avoid some useless lookups in each acpi_pci_driver.

Note: This changes interfaces used by acpi_pci_register_driver(), an
exported symbol.  This patch updates all the in-kernel users, but any
out-of-kernel acpi_pci_register_driver() users will need updates.

[bhelgaas: changelog]
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This restores the previous behavior of stopping all child devices before
removing any of them.  The current SR-IOV design, where removing the PF
also drops references on all the VFs, depends on having the VFs continue
to exist after having been stopped.

[bhelgaas: changelog]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This reverts commit 433efd22.

When we remove an SR-IOV device, we have this call chain:

    driver .remove() method
        pci_disable_sriov()
            sriov_disable()
                virtfn_remove()
                    pci_get_domain_bus_and_slot()

sriov_disable() is only called for PFs, not for VFs.  When it's called
for a PF, it loops through all the VFs and calls virtfn_remove() for
each.  But we stop and remove VFs before PFs, so by the time we get
to virtfn_remove(), the VFs have already been stopped and deleted
from the device list.  Now pci_get_domain_bus_and_slot(), which uses
bus_find_device() and relies on that device list, doesn't find the
VFs, so the VF references aren't released correctly.
Reported-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch (as1591) moves the pm_runtime_get_noresume() and
pm_runtime_put_sync() calls from __device_suspend() and
device_resume() to device_prepare() and device_complete() in the PM
core.

The reason for doing this is to make sure that parent devices remain
at full power (i.e., don't go into runtime suspend) while their
children are being resumed from a system sleep.

The PCI core already contained equivalent code to serve the same
purpose.  The patch removes the duplicated code, since it is no longer
needed.  One of the comments from the PCI core gets moved into the PM
core, and a second comment is added to explain whe the _get_noresume
and _put_sync calls are present.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Most architectures implement this in exactly the same way. Instead of
having each architecture duplicate this function, provide a single
implementation in the core and make it a weak symbol so that it can be
overridden on architectures where it is required.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Remove the __init annotations in order to keep pci_fixup_irqs() around
after init (e.g. for hotplug). This requires the same change for the
implementation of pcibios_update_irq() on all architectures. While at
it, all __devinit annotations are removed as well, since they will be
useless now that HOTPLUG is always on.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Should use struct pci_bus_resource instead of struct pci_host_bridge_window

Commit 45ca9e97 ("PCI: add helpers for building PCI bus resource lists")
added pci_free_resource_list() and used it in pci_bus_remove_resources().
Later it was also used for host bridge aperture lists, which was fine until
commit 0efd5aab ("PCI: add struct pci_host_bridge_window with CPU/bus
address offset").  That commit added offset information, so we needed a
struct pci_host_bridge_window that was separate from struct
pci_bus_resource.

Commit 0efd5aab should have split the host bridge aperture users of
pci_free_resource_list() from the pci_bus_resource user
(pci_bus_remove_resources()), but it did not.

[bhelgaas: changelog -- 0efd5aab was mine, so this is all my fault]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

For bridges with "secondary > subordinate", i.e., invalid bus number
apertures, we don't enumerate anything behind the bridge unless the
user specified "pci=assign-busses".

This patch makes us automatically try to reassign the downstream bus
numbers in this case (just for that bridge, not for all bridges as
"pci=assign-busses" does).

We don't discover all the devices on the Intel DP43BF motherboard
without this change (or "pci=assign-busses") because its BIOS configures
a bridge as:

    pci 0000:00:1e.0: PCI bridge to [bus 20-08] (subtractive decode)

[bhelgaas: changelog, change message to dev_info]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18412
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=625754Reported-by: NBrian C. Huffman <bhuffman@graze.net>
Reported-by: NVL <vl.homutov@gmail.com>
Tested-by: NVL <vl.homutov@gmail.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org

Function eeh_rmv_from_parent_pe() could be called by the path of
either normal PCI hotplug, or EEH recovery. For the former case,
we need purge the corresponding PE on removal of the associated
PE bus.

The patch tries to cover that by passing more information to function
pcibios_remove_pci_devices() so that we know if the corresponding PE
needs to be purged or be marked as "invalid".
Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch removes hardcoded sysfs attributes manipulation and
converts them into generic pci_bus->drv_attrs. This saves several bytes.
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

We piggyback on "xen/swiotlb: Use the swiotlb_late_init_with_tbl to init
Xen-SWIOTLB late when PV PCI is used." functionality to start up
the Xen-SWIOTLB if we are hot-plugged. This allows us to bypass
the need to supply 'iommu=soft' on the Linux command line (mostly).
With this patch, if a user forgot 'iommu=soft' on the command line,
and hotplug a PCI device they will get:

pcifront pci-0: Installing PCI frontend
Warning: only able to allocate 4 MB for software IO TLB
software IO TLB [mem 0x2a000000-0x2a3fffff] (4MB) mapped at [ffff88002a000000-ffff88002a3fffff]
pcifront pci-0: Creating PCI Frontend Bus 0000:00
pcifront pci-0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xfffffffff]
pci 0000:00:00.0: [8086:10d3] type 00 class 0x020000
pci 0000:00:00.0: reg 10: [mem 0xfe5c0000-0xfe5dffff]
pci 0000:00:00.0: reg 14: [mem 0xfe500000-0xfe57ffff]
pci 0000:00:00.0: reg 18: [io  0xe000-0xe01f]
pci 0000:00:00.0: reg 1c: [mem 0xfe5e0000-0xfe5e3fff]
pcifront pci-0: claiming resource 0000:00:00.0/0
pcifront pci-0: claiming resource 0000:00:00.0/1
pcifront pci-0: claiming resource 0000:00:00.0/2
pcifront pci-0: claiming resource 0000:00:00.0/3
e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:00:00.0: Disabling ASPM L0s L1
e1000e 0000:00:00.0: enabling device (0000 -> 0002)
e1000e 0000:00:00.0: Xen PCI mapped GSI16 to IRQ34
e1000e 0000:00:00.0: (unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:00:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:1b:21:ab:c6:13
e1000e 0000:00:00.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:00:00.0: eth0: MAC: 3, PHY: 8, PBA No: E46981-005

The "Warning only" will go away if one supplies 'iommu=soft' instead
as we have a higher chance of being able to allocate large swaths of
memory.
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Following code has a race window between pci_find_bus() and pci_get_slot()
if PCI hotplug operation happens between them which removes the pci_bus.
So use PCI hotplug safe interface pci_get_domain_bus_and_slot() instead,
which also reduces code complexity.

    struct pci_bus *pci_bus = pci_find_bus(domain, busno);
    struct pci_dev *pci_dev = pci_get_slot(pci_bus, devfn);
Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Following code has a race window between pci_find_bus() and pci_get_slot()
if PCI hotplug operation happens between them which removes the pci_bus.
So use PCI hotplug safe interface pci_get_domain_bus_and_slot() instead,
which also reduces code complexity.

    struct pci_bus *pci_bus = pci_find_bus(domain, busno);
    struct pci_dev *pci_dev = pci_get_slot(pci_bus, devfn);
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Following code has a race window between pci_find_bus() and pci_get_slot()
if PCI hotplug operation happens between them which removes the pci_bus.
So use PCI hotplug safe interface pci_get_domain_bus_and_slot() instead,
which also reduces code complexity.

    struct pci_bus *pci_bus = pci_find_bus(domain, busno);
    struct pci_dev *pci_dev = pci_get_slot(pci_bus, devfn);
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The original idea comes from Ram Pai.  This patch puts the chunk of
code for calculating the minimal alignment of memory window into a
separate inline function.
Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch changes pbus_size_io() and pbus_size_mem() to do window (I/O,
memory and prefetchable memory) reassignment based on the minimal
alignments for the P2P bridge, which was retrieved by window_alignment().

[bhelgaas: changelog]
Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch implements a weak function to return the default I/O or memory
window alignment for a P2P bridge.  By default, I/O windows are aligned to
4KiB or 1KiB and memory windows are aligned to 4MiB.  Some platforms, e.g.,
powernv, have special alignment requirements and can override
pcibios_window_alignment().

[bhelgaas: changelog]
Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Options without prompts and without dependencies don't usefully have a
default value - they're intended to be selected from other options
only.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

register & 0x0B == 0x04 is never true, the code will always take the
(identical) 0x00 path anyway. Remove the dead code paths.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44151Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

In function pci_get_subsys() there is a check:

	/*
	 * pci_find_subsys() can be called on the ide_setup() path,
	 * super-early in boot.  But the down_read() will enable local
	 * interrupts, which can cause some machines to crash.  So here we
	 * detect and flag that situation and bail out early.
	 */
	if (unlikely(no_pci_devices()))
		return NULL;

But there is no ide_setup() now, and no down_read() either, which
makes the check obsolete. So remove it.
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Previously, the driver ignored resume unless the pciehp_force module_param
was specified.  On some laptops that means that interrupts are not
delivered after S3, so card removals and insertions are not handled.
This patch makes the driver handle resume regardless of pciehp_force.

[bhelgaas: changelog]
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>

Since pci_error_handlers is just a function table make it const.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NLinas Vepstas <linasvepstas@gmail.com>

On some platforms, root port has neither MSI/MSI-X nor INTx interrupt
generated in RC mode. In this case, we have to use other interrupt, e.g.,
system shared interrupt, for port service IRQ to have AER, Hot-plug, etc.,
services work.
Signed-off-by: NShengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit 982245f0 ("remove
CONFIG_PCI_NAMES") removed pci's usage of classlist.h, devlist.h, and
gen-devlist. Remove pci's .gitignore file, because now none of its
entries are used.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

These messages don't seem to add much value.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The completion message in do_recovery() is currently KERN_DEBUG,
while the starting message in aer_print_port_info() is KERN_INFO.
This changes the completion message to KERN_INFO to match the
starting message.

[bhelgaas: changelog, use dev_info() instead of dev_printk(KERN_INFO)]
Signed-off-by: NLance Ortiz <lance.ortiz@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The fakephp driver was scheduled for removal in 2011.

Fakephp presented /sys/bus/pci/slots/.../power files for every PCI
function.  Writing "0" to one of these files logically removed the device
from the system.  The PCI core now provides the same functionality with
/sys/bus/pci/devices/.../remove.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This fixes a kernel warning https://lkml.org/lkml/2012/7/31/682

pci_get_subsys() may get called in late system reboot stage, using
a sleepable kmalloc() sounds fragile and will cause a kernel warning
with my recent commmit 55c844a4 "x86/reboot: Fix a warning message
triggered by stop_other_cpus()" which disable local interrupt in
late system shutdown/reboot phase. Using a local parameter instead
will fix it and make it eligible for calling from atomic context.

Do the same change for the pci_get_class() as suggested by Bjorn Helgaas.

Initializing the on-stack struct pci_device_id suggested by Fengguang Wu
and Jiri Slaby.  Section 6.7.8 of the C99 standard guarantees that when we
initialize some of the struct members, the rest of the struct is implicitly
initialized the same as objects with static storage duration, i.e., to zero
in this case.

[bhelgaas: changelog, incorporate Fengguang/Jiri initialization fix]
Bisected-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NFengguang Wu <fengguang.wu@intel.com>

If we try to print to the console device while its decoding is disabled,
the system will hang.
Reported-and-tested-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NOlof Johansson <olof@lixom.net>

Use PCI Express Capability access functions to simplify PCIe ASPM.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use PCI Express Capability access functions to simplify PCIe AER.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use PCI Express Capability access functions to simplify PCIe PME.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use PCI Express Capability access functions to simplify pciehp.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>

Use PCI Express Capability access functions to simplify portdrv.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>

Use PCI Express Capability access functions to simplify pcihp_slot.c.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>

Before initiating an FLR, we should wait for completion of any outstanding
non-posted requests.  See PCIe spec r3.0, sec 6.6.2.

This makes reset_intel_82599_sfp_virtfn() very similar to the generic
pcie_flr().  The only difference is that the 82599 doesn't report FLR
support in the VF Device Capability register.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>