Merge branch 'pci/resource' into next

* pci/resource: (26 commits)
  Revert "[PATCH] Insert GART region into resource map"
  PCI: Log IDE resource quirk in dmesg
  PCI: Change pci_bus_alloc_resource() type_mask to unsigned long
  PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region()
  resources: Set type in __request_region()
  PCI: Don't check resource_size() in pci_bus_alloc_resource()
  s390/PCI: Use generic pci_enable_resources()
  tile PCI RC: Use default pcibios_enable_device()
  sparc/PCI: Use default pcibios_enable_device() (Leon only)
  sh/PCI: Use default pcibios_enable_device()
  microblaze/PCI: Use default pcibios_enable_device()
  alpha/PCI: Use default pcibios_enable_device()
  PCI: Add "weak" generic pcibios_enable_device() implementation
  PCI: Don't enable decoding if BAR hasn't been assigned an address
  PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bit
  PCI: Don't try to claim IORESOURCE_UNSET resources
  PCI: Check IORESOURCE_UNSET before updating BAR
  PCI: Don't clear IORESOURCE_UNSET when updating BAR
  PCI: Mark resources as IORESOURCE_UNSET if we can't assign them
  PCI: Remove pci_find_parent_resource() use for allocation
  ...

Merge branch 'pci/misc' into next

* pci/misc:
  PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled

Revert "[PATCH] Insert GART region into resource map"

This reverts commit 56dd669a138c, which makes the GART visible in
/proc/iomem.  This fixes a regression: e501b3d87f00 ("agp: Support 64-bit
APBASE") exposed an existing problem with a conflict between the GART
region and a PCI BAR region.

The GART addresses are bus addresses, not CPU addresses, and therefore
should not be inserted in iomem_resource.

On many machines, the GART region is addressable by the CPU as well as by
an AGP master, but CPU addressability is not required by the spec.  On some
of these machines, the GART is mapped by a PCI BAR, and in that case, the
PCI core automatically inserts it into iomem_resource, just as it does for
all BARs.

Inserting it here means we'll have a conflict if the PCI core later tries
to claim the GART region, so let's drop the insertion here.

The conflict indirectly causes X failures, as reported by Jouni in the
bugzilla below.  We detected the conflict even before e501b3d87f00, but
after it the AGP code (fix_northbridge()) uses the PCI resource (which is
zeroed because of the conflict) instead of reading the BAR again.

Conflicts:
arch/x86_64/kernel/aperture.c

Fixes: e501b3d87f00 agp: Support 64-bit APBASE
Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201
Reported-and-tested-by: Jouni Mettälä <jtmettala@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Log IDE resource quirk in dmesg

Make a note in dmesg when we overwrite legacy IDE BAR info.  We previously
logged something like this:

  pci 0000:00:1f.1: reg 0x10: [io  0x0000-0x0007]

and then silently overwrote the resource.  There's an example in the
bugzilla below.  This doesn't fix the bugzilla; it just makes what's going
on more obvious.

No functional change; merely adds some dev_info() calls.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=48451
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Change pci_bus_alloc_resource() type_mask to unsigned long

The pci_bus_alloc_resource() "type_mask" parameter is used to compare with
the "flags" member of a struct resource, so it should be the same type,
namely "unsigned long".

No functional change because all current IORESOURCE_* flags fit in 32 bits.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region()

When allocating space from a bus resource, i.e., from apertures leading to
this bus, make sure the entire resource type matches.  The previous code
assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a single bit
set, but this is not true.  IORESOURCE_TYPE_BITS is really an enumeration,
and we have to check all the bits.

See 72dcb1197228 ("resources: Add register address resource type").

No functional change.  If we used this path for allocating IRQs, DMA
channels, or bus numbers, this would fix a bug because those types are
indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM.  But we
don't, so this shouldn't make any difference.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

resources: Set type in __request_region()

We don't set the type (I/O, memory, etc.) of resources added by
__request_region(), which leads to confusing messages like this:

    address space collision: [io  0x1000-0x107f] conflicts with ACPI CPU throttle [??? 0x00001010-0x00001015 flags 0x80000000]

Set the type of a new resource added by __request_region() (used by
request_region() and request_mem_region()) to the type of its parent.  This
makes the resource tree internally consistent and fixes messages like the
above, where the ACPI CPU throttle resource really is an I/O port region,
but request_region() didn't fill in the type, so %pR didn't know how to
print it.

Sample dmesg showing the issue at the link below.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Don't check resource_size() in pci_bus_alloc_resource()

Paul reported that after f75b99d5a77d ("PCI: Enforce bus address limits in
resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not
set), intel-gtt complained "can't ioremap flush page - no chipset
flushing".  In addition, other PCI resource allocations, e.g., for bridge
windows, failed.

This happens because we incorrectly skip bus resources of
[mem 0x00000000-0xffffffff] because we think they are of size zero.
When resource_size_t is 32 bits wide, resource_size() on
[mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1)
overflows.

Therefore, we can't use "resource_size() == 0" to decide that allocation
from this resource will fail.  allocate_resource() should fail anyway if it
can't satisfy the address constraints, so we should just depend on that.

A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid,
but we do fall back to it as a default when we don't have information about
host bridge apertures.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611
Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation
Reported-and-tested-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

s390/PCI: Use generic pci_enable_resources()

The generic pci_enable_resources() does essentially the same thing as the
code in the s390 version of pcibios_enable_device().

There are differences, but I don't think any of them are a problem.  The
generic code:

  - Checks everything up to PCI_NUM_RESOURCES, not PCI_BAR_COUNT (6), so
    we'll now check the ROM resource, IOV resources, and bridge windows.

  - Checks for res->flags & IORESOURCE_UNSET.  The s390 code never sets
    IORESOURCE_UNSET, so this isn't a problem.

  - Checks res->parent.  The s390 pcibios_add_device() calls
    pci_claim_resource() on all BARs (except ROM, IOV, and bridge windows)
    so this isn't a problem either.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>

tile PCI RC: Use default pcibios_enable_device()

We don't need anything arch-specific in pcibios_enable_device(), so drop
the arch implementation and use the default generic one.

Note: pci_enable_resources() checks that r->parent is non-NULL, which
basically checks that pci_claim_resource() or request_resource() has been
called for each BAR.  I don't see where that happens for tile, but this
patch doesn't change that behavior, so if it worked before, it should still
work.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Chris Metcalf <cmetcalf@tilera.com>

sparc/PCI: Use default pcibios_enable_device() (Leon only)

We don't need anything arch-specific in pcibios_enable_device() so drop
the arch implementation and use the default generic one.

Note that sparc has two pcibios_enable_device() implementations other than
the one removed here.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Daniel Hellstrom <daniel@gaisler.com

sh/PCI: Use default pcibios_enable_device()

We don't need anything arch-specific in pcibios_enable_device(), so drop
the arch implementation and use the default generic one.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Paul Mundt <lethal@linux-sh.org>
CC: linux-sh@vger.kernel.org

microblaze/PCI: Use default pcibios_enable_device()

We don't need anything arch-specific in pcibios_enable_device(), so drop
the arch implementation and use the default generic one.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <monstr@monstr.eu>
CC: microblaze-uclinux@itee.uq.edu.au

alpha/PCI: Use default pcibios_enable_device()

We don't need anything arch-specific in pcibios_enable_device(), so drop
the arch implementation and use the default generic one.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: linux-alpha@vger.kernel.org

PCI: Add "weak" generic pcibios_enable_device() implementation

Many architectures implement pcibios_enable_device() the same way, so
provide a default implementation in the core.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Don't enable decoding if BAR hasn't been assigned an address

Don't enable memory or I/O decoding if we haven't assigned or claimed the
BAR's resource.

If we enable decoding for a BAR that hasn't been assigned an address, we'll
likely cause bus conflicts.  This declines to enable decoding for resources
with IORESOURCE_UNSET.

Note that drivers can use pci_enable_device_io() or pci_enable_device_mem()
if they only care about specific types of BARs.  In that case, we don't
bother checking whether the corresponding resources are assigned or
claimed.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled

Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left
them disabled"), pciehp surprise removal stopped working.

This happens because pci_reenable_device() on the hotplug bridge (used in
the pciehp_configure_device() path) clears the Interrupt Disable bit, which
apparently breaks the bridge's MSI hotplug event reporting.

Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
which is used by both pci_enable_device() and pci_reenable_device().  But
we use pci_reenable_device() after the driver may have enabled MSI or
MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.

This patch clears Interrupt Disable only when MSI/MSI-X has not been
enabled.

Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled
Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691
Reported-and-tested-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>

PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bit

If we don't support 64-bit addresses, i.e., CONFIG_PHYS_ADDR_T_64BIT is not
set, we can't deal with BARs above 4GB.  In this case we already pretend
the BAR contained zero; this patch also sets IORESOURCE_UNSET so we can try
to reallocate it later.

I don't think this is exactly correct: what we care about here are *bus*
addresses, not CPU addresses, so the tests of sizeof(resource_size_t)
probably should be on sizeof(dma_addr_t) instead.  But this is what's been
in -next, so we'll fix that later.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Don't try to claim IORESOURCE_UNSET resources

If the IORESOURCE_UNSET bit is set, it means we haven't assigned an address
yet, so don't try to claim the region.

Also, make the error messages more uniform and add info about which BAR is
involved.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Check IORESOURCE_UNSET before updating BAR

Check to make sure we don't update a BAR with an address we haven't
assigned.

If we haven't assigned an address to a resource, we shouldn't write it to a
BAR.  This isn't a problem for the usual path via pci_assign_resource(),
which clears IORESOURCE_UNSET before calling pci_update_resource(), but
paths like pci_restore_bars() can call this for resources we haven't
assigned.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Don't clear IORESOURCE_UNSET when updating BAR

Clear IORESOURCE_UNSET when we assign an address to a resource, not when we
write the address to the BAR.

Also, drop the "BAR %d: set to %pR" message; this is mostly redundant with
the "BAR %d: assigned %pR" message from pci_assign_resource().

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Mark resources as IORESOURCE_UNSET if we can't assign them

When assigning addresses to resources, mark them with IORESOURCE_UNSET
before we start and clear IORESOURCE_UNSET if assignment is successful.
That means that if we print the resource during assignment, we will show
the size, not a meaningless address.

Also, clear IORESOURCE_UNSET if we do assign an address, so we print the
address when it is valid.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Remove pci_find_parent_resource() use for allocation

If the resource hasn't been allocated yet, pci_find_parent_resource() is
documented as returning the region "where it should be allocated from."
This is impossible in general because there may be several candidates: a
prefetchable BAR can be put in either a prefetchable or non-prefetchable
window, a transparent bridge may have overlapping positively- and
subtractively-decoded windows, and a root bus may have several windows of
the same type.

Allocation should be done by pci_bus_alloc_resource(), which iterates
through all bus resources and looks for the best match, e.g., one with the
desired prefetchability attributes, and falls back to less-desired
possibilities.

The only valid use of pci_find_parent_resource() is to find the parent of
an already-allocated resource so we can claim it via request_resource(),
and all we need for that is a bus region of the correct type that contains
the resource.

Note that like 8c8def26bfaa ("PCI: allow matching of prefetchable resources
to non-prefetchable windows"), this depends on pci_bus_for_each_resource()
iterating through positively-decoded regions before subtractively-decoded
ones.  We prefer not to return a subtractively-decoded region because
requesting from it will likely conflict with the overlapping positively-
decoded window (see Launchpad report below).

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Linus Torvalds <torvalds@linux-foundation.org>

vsprintf: Add support for IORESOURCE_UNSET in %pR

Sometimes we have a struct resource where we know the type (MEM/IO/etc.)
and the size, but we haven't assigned address space for it.  The
IORESOURCE_UNSET flag is a way to indicate this situation.  For these
"unset" resources, the start address is meaningless, so print only the
size, e.g.,

  - pci 0000:0c:00.0: reg 184: [mem 0x00000000-0x00001fff 64bit]
  + pci 0000:0c:00.0: reg 184: [mem size 0x2000 64bit]

For %pr (printing with raw flags), we still print the address range,
because %pr is mostly used for debugging anyway.

Thanks to Fengguang Wu <fengguang.wu@intel.com> for suggesting
resource_size().

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

resource: Add resource_contains()

We have two identical copies of resource_contains() already, and more
places that could use it.  This moves it to ioport.h where it can be
shared.

resource_contains(struct resource *r1, struct resource *r2) returns true
iff r1 and r2 are the same type (most callers already checked this
separately) and the r1 address range completely contains r2.

In addition, the new resource_contains() checks that both r1 and r2 have
addresses assigned to them.  If a resource is IORESOURCE_UNSET, it doesn't
have a valid address and can't contain or be contained by another resource.
Some callers already check this or for res->start.

No functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

i2o: Use pci_bus_alloc_resource(), not allocate_resource() directly

Convert i2o_res_alloc() to use pci_bus_alloc_resource() rather than
pci_find_parent_resource() and allocate_resource().  We don't have a
resource to start with, so pci_find_parent_resource() can't do anything
useful: a bus may have several memory resources available, so there might
be several possible parents.  This is more likely on root buses because
host bridges may have any number of apertures.

I'm pretty sure this didn't work in the first place because it passed
size == min == max to allocate_resource().  The min and max parameters are
constraints on the *addresses* of the resource, not on its size, so I think
it was impossible for allocate_resource() to succeed.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Merge branches 'pci/host-designware', 'pci/host-imx6' and 'pci/host-rcar' into next

* pci/host-designware:
  PCI: designware: Fix RC BAR to be single 64-bit non-prefetchable memory BAR

* pci/host-imx6:
  PCI: imx6: Wait for retraining

* pci/host-rcar:
  PCI: rcar: Make the Kconfig dependencies more generic
  PCI: rcar: Break out window size handling
  PCI: rcar: Register each instance independently
  PCI: rcar: Fix bridge logic configuration accesses
  PCI: rcar: Add error interrupt handling
  PCI: rcar: Check platform_get_irq() return code

PCI: rcar: Make the Kconfig dependencies more generic

Update the R-Car Generation 2 PCI driver Kconfig dependencies to follow
same style as other drivers - no SoC dependencies.

Also, update the COMPILE_TEST bits to depend on ARM. This since the DMA
bounce buffer and dma_ops handling code is ARM specific.

[bhelgaas: adjust context after dropping DMABOUNCE patches]
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

i2o: Refactor i2o_iop_systab_set() PCI space allocation

Refactor the PCI space allocation in i2o_iop_systab_set().  This might
improve readability slightly, but mainly it is to make the next patch
simpler.

No functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

i2o: Fix I/O space alignment requirement

When i2o_iop_systab_set() allocates I/O port space, it specifies 1Mb
alignment required.  This seems unlikely, since most platforms have only
64Kb of I/O space total.  I think 4Kb is a more reasonable choice, since
that's the minimum alignment of a PCI-PCI bridge I/O window.

My guess is that this is a copy/paste error from the memory allocation
code, which specifies 1Mb alignment (which is the minimum alignment of a
PCI-PCI bridge memory window).

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

i2o: Fix I/O space allocation copy/paste error

When i2o_iop_systab_set() allocates I/O port space, it assigns the base of
the new I/O port region to sb->current_mem_base, not sb->current_io_base.
This looks like a copy/paste error, because we do use current_io_base, but
there's no other place that sets it.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Merge branch 'pci/dead-code' into next

* pci/dead-code:
  PCI: Remove unused SR-IOV VF Migration support
  iommu/amd: Add include of <linux/irqreturn.h>
  mei: Add include of <linux/irqreturn.h>
  misc: mic: Add include of <linux/irqreturn.h>

Merge branch 'pci/pciehp' into next

* pci/pciehp:
  PCI: pciehp: Cleanup whitespace
  PCI: pciehp: Remove a non-existent card, regardless of "surprise" capability
  PCI: pciehp: Don't turn slot off when hot-added device already exists
  PCI: pciehp: Add hotplug_lock to serialize hotplug events
  PCI: pciehp: Ensure very fast hotplug events are also processed
  PCI: pciehp: Disable link notification across slot reset
  PCI: pciehp: Don't check adapter or latch status while disabling
  PCI: pciehp: Don't disable the link permanently during removal
  PCI: pciehp: Enable link state change notifications
  PCI: pciehp: Use link change notifications for hot-plug and removal
  PCI: pciehp: Make check_link_active() non-static

Merge branch 'pci/list-for-each-entry' into next

* pci/list-for-each-entry:
  PCI: frv: replace now removed pci_bus_b() causing build failure

PCI: frv: replace now removed pci_bus_b() causing build failure

In commit 94e6a9b93064 ("PCI: Remove pci_bus_b() and use
list_for_each_entry() directly") the function pci_bus_b() was removed, but
one instance of its usage was missed.

Replace it in the same fashion that the original commit did.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yijing Wang <wangyijing@huawei.com>

PCI: pciehp: Cleanup whitespace

Minor whitespace cleanup; no functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Remove a non-existent card, regardless of "surprise" capability

In case a card is physically yanked out, it should immediately be removed,
regardless of the "surprise" capability bit. Thus:

  - Always handle the physical removal - regardless of the "surprise" bit.
  - Don't use "surprise" capability when making decisions about enabling
    presence detect notifications.
  - Reword the comments to indicate the intent.

Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: imx6: Wait for retraining

This patch handles the case where the PCIe link is up and running, yet
drops into the LTSSM training mode. The link spends short time in the LTSSM
training mode, but the current code can misinterpret it as the link being
stalled.  Waiting for the LTSSM training to complete fixes the issue.

Quoting Sascha:

  This is broken since commit 7f9f40c01cce ('PCI: imx6: Report "link up"
  only after link training completes').

  The designware driver changes the PORT_LOGIC_SPEED_CHANGE bit in
  dw_pcie_host_init() which causes the link to be retrained. During the
  next call to dw_pcie_rd_conf() the link is then reported being down and
  the function returns PCIBIOS_DEVICE_NOT_FOUND resulting in nonfunctioning
  PCIe.

Fixes: 7f9f40c01cce (PCI: imx6: Report "link up" only after link training completes)
Tested-by: Troy Kisky <troy.kisky@boundarydevices.com>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>

PCI: designware: Fix RC BAR to be single 64-bit non-prefetchable memory BAR

The Synopsys PCIe core provides one pair of 32-bit BARs (BAR 0 and BAR 1).
The BARs can be configured as follows:

  - One 64-bit BAR: BARs 0 and 1 are combined to form a single 64-bit BAR
  - Two 32-bit BARs: BARs 0 and 1 are two independent 32-bit BARs

This patch corrects 64-bit, non-prefetchable memory BAR configuration
implemented in dw driver.

Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Pratyush Anand <pratyush.anand@st.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: stable@vger.kernel.org # v3.12+

PCI: Remove unused SR-IOV VF Migration support

This reverts commit 74bb1bcc7dbb ("PCI: handle SR-IOV Virtual Function
Migration"), removing this exported interface:

  pci_sriov_migration()

Since pci_sriov_migration() is unused, it is impossible to schedule
sriov_migration_task() or use any of the other migration infrastructure.

This is based on Stephen Hemminger's patch (see link below), but goes a bit
further.

Link: http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplumber.net
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Stephen Hemminger <stephen@networkplumber.org>

iommu/amd: Add include of <linux/irqreturn.h>

We currently include <linux/irqreturn.h> in <linux/pci.h>, but I'm about to
remove that from linux/pci.h, so add explicit includes where needed.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

mei: Add include of <linux/irqreturn.h>

We currently include <linux/irqreturn.h> in <linux/pci.h>, but I'm about to
remove that from linux/pci.h, so add explicit includes where needed.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>

Merge branch 'pci/misc' into next

* pci/misc:
  PCI: Enable INTx if BIOS left them disabled
  ia64/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device
  x86/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device
  PCI: Update outdated comment for pcibios_bus_report_status()
  PCI: Cleanup per-arch list of object files
  PCI: cpqphp: Fix hex vs decimal typo in cpqhpc_probe()
  x86/PCI: Fix function definition whitespace
  x86/PCI: Reword comments
  x86/PCI: Remove unnecessary local variable initialization
  PCI: Remove unnecessary list_empty(&pci_pme_list) check

PCI: Enable INTx if BIOS left them disabled

Some firmware leaves the Interrupt Disable bit set even if the device uses
INTx interrupts.  Clear Interrupt Disable so we get those interrupts.

Based on the report mentioned below, if the user selects the "EHCI only"
option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS
with the PCI_COMMAND_INTX_DISABLE bit set.

Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601
Reported-by: Chris Cheng <chris.cheng@atrustcorp.com>
Reported-and-tested-by: Jamie Chen <jamie.chen@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Merge branch 'pci/host-mvebu' into next

* pci/host-mvebu:
  PCI: mvebu: Call request_resource() on the apertures
  bus: mvebu-mbus: Fix incorrect size for PCI aperture resources
  PCI: mvebu: Fix potential issue in range parsing
  PCI: mvebu: Use Device ID and revision from underlying endpoint

Merge branch 'pci/list-for-each-entry' into next

* pci/list-for-each-entry:
  PCI: Remove pci_bus_b() and use list_for_each_entry() directly
  pcmcia: Use list_for_each_entry() for bus traversal
  powerpc/PCI: Use list_for_each_entry() for bus traversal
  drm: Use list_for_each_entry() for bus traversal
  ARM/PCI: Use list_for_each_entry() for bus traversal
  ACPI / hotplug / PCI: Use list_for_each_entry() for bus traversal

misc: mic: Add include of <linux/irqreturn.h>

We currently include <linux/irqreturn.h> in <linux/pci.h>, but I'm about to
remove that from linux/pci.h, so add explicit includes where needed.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Sudeep Dutt <sudeep.dutt@intel.com>

PCI: mvebu: Call request_resource() on the apertures

It is typical for host drivers to request a resource for the aperture; once
this is done the PCI core will properly populate resources for all BARs in
the system.

With this patch cat /proc/iomem will now show:

  e0000000-efffffff : PCI MEM 0000
    e0000000-e00fffff : PCI Bus 0000:01
      e0000000-e001ffff : 0000:01:00.0

Tested on Kirkwood.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>

bus: mvebu-mbus: Fix incorrect size for PCI aperture resources

reg[0] is the DT base, reg[1] is the DT length in bytes,
struct resource.end is the inclusive end address, so a -1 is required.

Tested on kirkwood.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>

PCI: rcar: Break out window size handling

Break out the hard coded window size code to allow dynamic setup. The
window size is still left at 1GiB but with this patch changing window size
is easy for testing.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

PCI: rcar: Register each instance independently

Convert the code to allow per-device probe() like other device drivers.
This also delays driver registration due to change from subsys_initcall()
to regular module_platform_driver().

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

PCI: rcar: Fix bridge logic configuration accesses

The bridge logic at slot 0 only supports reads up to 0x40 and the rest of
the PCI configuration space for this slot is marked as reserved in the
manual.

Trying a read from offset 0x100 is producing an error from the bridge. With
error interrupts enabled, the following is printed:

  pci-rcar-gen2 ee0d0000.pci: error irq: status 00000014

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

PCI: rcar: Add error interrupt handling

Add option to enable interrupts to report any errors from the AHB-PCI
bridge to help find any issues with the bridge when in use.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

PCI: rcar: Check platform_get_irq() return code

The current code does not check the return from platform_get_irq() so add
an error check and return if this call does fail.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

Merge branch 'pci/msi' into next

* pci/msi:
  vfio: Use pci_enable_msi_range() and pci_enable_msix_range()
  ahci: Use pci_enable_msi_range() instead of pci_enable_msi_block()
  ahci: Fix broken fallback to single MSI mode
  PCI/MSI: Add pci_enable_msi_exact() and pci_enable_msix_exact()
  PCI/MSI: Fix cut-and-paste errors in documentation
  PCI/MSI: Add pci_enable_msi() documentation back
  PCI/MSI: Fix pci_msix_vec_count() htmldocs failure
  PCI/MSI: Fix leak of msi_attrs
  PCI/MSI: Check kmalloc() return value, fix leak of name

Merge branch 'pci/virtualization' into next

* pci/virtualization:
  PCI: Enable quirks for PCIe ACS on Intel PCH root ports
  PCI: Add pci_dev_flag for ACS enable quirks
  PCI: Add device-specific PCI ACS enable

Merge branch 'pci/scan-bridge' into next

* pci/scan-bridge:
  PCI: Don't scan random busses in pci_scan_bridge()
  PCI: Check for child busses which use more bus numbers than allocated
  PCI: Remove pci_fixup_parent_subordinate_busnr()
  PCI: Make sure bus number resources stay within their parents bounds
  PCI: Use request_resource_conflict() instead of insert_ for bus numbers
  PCI: Assign CardBus bus number only during the second pass
  PCI: Clarify the "scan anyway" comment in pci_scan_bridge()
  PCI: Increment max correctly in pci_scan_bridge()

vfio: Use pci_enable_msi_range() and pci_enable_msix_range()

pci_enable_msix() and pci_enable_msi_block() have been deprecated; use
pci_enable_msix_range() and pci_enable_msi_range() instead.

[bhelgaas: changelog]
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Williamson <alex.williamson@redhat.com>

ahci: Use pci_enable_msi_range() instead of pci_enable_msi_block()

pci_enable_msi_block() has been deprecated; use pci_enable_msi_range()
instead.

[bhelgaas: changelog]
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Tejun Heo <tj@kernel.org>

ahci: Fix broken fallback to single MSI mode

Commit 7b92b4f61ec4 ("PCI/MSI: Remove pci_enable_msi_block_auto()")
introduced a regression: if multiple MSI initialization fails, the code
falls back to INTx rather than to single MSI.

Fixes: 7b92b4f61ec4 ("PCI/MSI: Remove pci_enable_msi_block_auto()")
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Tejun Heo <tj@kernel.org>

ia64/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device

Setting the IORESOURCE_ROM_SHADOW flag on a VGA card other than the primary
prevents it from reading its own ROM.  It will get the content of the
shadow ROM at C000 instead, which is of the primary VGA card and the driver
of the secondary card will bail out.

Fix this by checking if the arch code or vga-arbitration has already
determined the vga_default_device, if so only apply the fix to this primary
video device and let the comment reflect this.

[bhelgaas: add subject, split x86 & ia64 into separate patches,
include vgaarb.h]
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

x86/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device

Setting the IORESOURCE_ROM_SHADOW flag on a VGA card other than the primary
prevents it from reading its own ROM.  It will get the content of the
shadow ROM at C000 instead, which is of the primary VGA card and the driver
of the secondary card will bail out.

Fix this by checking if the arch code or vga-arbitration has already
determined the vga_default_device, if so only apply the fix to this primary
video device and let the comment reflect this.

[bhelgaas: add subject, split x86 & ia64 into separate patches]
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

PCI: Remove pci_bus_b() and use list_for_each_entry() directly

Replace list_for_each() with list_for_each_entry(), which means we no
longer need pci_bus_b() and can remove it.

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: mvebu: Fix potential issue in range parsing

The second parameter of of_read_number() is not the index, but a size.  As
it happens, in this case it may work just fine because of the conversion to
u32 and the favorable endianness on this architecture.

Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout")
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org # v3.12+

pcmcia: Use list_for_each_entry() for bus traversal

Replace list_for_each() + pci_bus_b() with list_for_each_entry().

[bhelgaas: fix "silbling" typo]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

powerpc/PCI: Use list_for_each_entry() for bus traversal

Replace list_for_each() + pci_bus_b() with list_for_each_entry().

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

drm: Use list_for_each_entry() for bus traversal

Replace list_for_each() + pci_bus_b() with list_for_each_entry().

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

ARM/PCI: Use list_for_each_entry() for bus traversal

Replace list_for_each() + pci_bus_b() with list_for_each_entry().

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

ACPI / hotplug / PCI: Use list_for_each_entry() for bus traversal

Replace list_for_each() + pci_bus_b() with list_for_each_entry().

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>

PCI: Update outdated comment for pcibios_bus_report_status()

pci_find_device() has been superseded by pci_get_device().

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Don't turn slot off when hot-added device already exists

If we found device already exists during hot add device, we should leave
it, not turn the slot off.

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI/MSI: Add pci_enable_msi_exact() and pci_enable_msix_exact()

The new functions are special cases for pci_enable_msi_range() and
pci_enable_msix_range() when a particular number of MSI or MSI-X
is needed.

By contrast with pci_enable_msi_range() and pci_enable_msix_range()
functions, pci_enable_msi_exact() and pci_enable_msix_exact()
return zero in case of success, which indicates MSI or MSI-X
interrupts have been successfully allocated.

Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI/MSI: Fix cut-and-paste errors in documentation

Function pci_enable_msi_range() is used in examples where
pci_enable_msix_range() should have been used instead.

Reported-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Cleanup per-arch list of object files

setup-bus.o is now included unconditionally as of commit 7dc303033425
("PCI: Always build setup-bus when PCI is enabled").  Remove it from the
per-arch list of object files.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: cpqphp: Fix hex vs decimal typo in cpqhpc_probe()

This is a static checker fix and I can't test it, but from the context it
definitely looks like hexadecimal 0x20 was intended here instead of decimal
20.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

x86/PCI: Fix function definition whitespace

Consistently put the function type, name, and parameters on one line,
wrapping only as necessary.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

x86/PCI: Reword comments

Reword comments so they make sense.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

x86/PCI: Remove unnecessary local variable initialization

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: mvebu: Use Device ID and revision from underlying endpoint

Marvell SoCs place the SoC number into the PCIe endpoint device ID.  The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.

The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.

When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality.  Debian would
like to use this in order to aid installing the correct DTB file.

Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org # v3.11+

PCI: pciehp: Add hotplug_lock to serialize hotplug events

Today it is there is no protection around pciehp_enable_slot() and
pciehp_disable_slot() to ensure that they complete before another
hot-plug operation can be done on that particular slot.

This patch introduces the slot->hotplug_lock to ensure that any hotplug
operations (add / remove) complete before another hotplug event can begin
processing on that particular slot.

Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Ensure very fast hotplug events are also processed

Today, this is how all the hotplug and unplug events work:

Hotplug / Removal needs to be done
  => Set slot->state (protected by slot->lock) to either
    POWERON_STATE (for enabling) or POWEROFF_STATE (for disabling).
  => Submit the work item for pciehp_power_thread() to slot->wq.

Problem:
  There is a problem if the hotplug events can happen fast enough that
  they do not give SW enough time to add or remove the new devices.

  => Assume: Event for unplug comes (e.g. surprise removal). But
     before the pciehp_power_thread() work item was executed, the
     card was replaced by another card, causing surprise hotplug event.

  => What goes wrong:
    => The hot-removal event sets slot->state to POWEROFF_STATE, and
       schedules the pciehp_power_thread().
    => The hot-add event sets slot->state to POWERON_STATE, and
       schedules the pciehp_power_thread().
    => Now the pciehp_power_thread() is scheduled twice, and on both
       occasions it will find POWERON_STATE and will try to add the
       devices on the slot, and will fail complaining that the devices
       already exist.

  => Why this is a problem: If the device was replaced between the hot
     removal and hot-add, then we should unload the old driver and
     reload the new one. This does not happen today. The kernel or the
     driver is not even aware that the device was replaced.

     The problem is that the pciehp_power_thread() only looks at the
     slot->state which would only contain the *latest* state - not
     the actual event (add / remove) that was the intent of the IRQ
     handler who submitted the work.

What this patch does:

  => Hotplug events pass on an actual request (for addition or removal)
     to pciehp_power_thread() which is local to that work item
     submission.

  => pciehp_power_thread() does not need to look at slote->state and
     hence no locks needed in that.

  => Essentially this results in all the hotplug and unplug events
     "replayed" by pciehp_power_thread().

Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Disable link notification across slot reset

Disable the link notification (in addition to presence detect
notifications) across the slot reset since the reset could flap the link,
and we don't want to treat it as hot unplug followed by a hotplug.

Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Don't check adapter or latch status while disabling

It does not make much sense to refuse to disable a slot if an adapter is
not present or the latch is open. If an adapter is not present, it provides
an even better reason to disable the device slot.

This is specially a problem for link state hot-plug, because some ports use
in band mechanism for presence detection. Thus when link goes down,
presence detect also goes down. We _want_ that the removal should take
place in such case.

Thus remove the checks for adapter and latch in pciehp_disable_slot()

Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Don't disable the link permanently during removal

We need future link up events for hot-add, thus don't disable the link
permanently during device removal. Also, remove the static functions that
are now left unused.

This reverts part of 2debd9289997 ("PCI: pciehp: Disable/enable link during
slot power off/on").  This was discussed at the URL below, where it was
revealed that it was done for a bug in a PCIe repeater chip on that
particular platform.

Link: https://lkml.kernel.org/r/CAErSpo72KZ-a2OSQLWoK71GCgwBt676XZdGt4tEYm-6UYnLmPw@mail.gmail.com
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Enable link state change notifications

Enable the Link state notifications unconditionally. Enable the
presence detection notification only if attention button is absent.
This was discussed at this thread:
    https://lkml.kernel.org/r/529E5C0E.80903@gmail.com

Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Don't scan random busses in pci_scan_bridge()

When assigning a new bus number in pci_scan_bridge we check whether
max+1 is free by calling pci_find_bus. If it does already exist then we
assume that we are rescanning and that this is the right bus to scan.

This is fragile. If max+1 lies outside of bus->busn_res.end then we will
rescan some random bus from somewhere else in the hierachy. This patch
checks for this case and prints a warning.

[bhelgaas: add parent/child bus number info to dev_warn()]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Check for child busses which use more bus numbers than allocated

pci_scan_child_bus can (potentially) return a bus number higher than the
subordinate value of the child bus. Possible reasons are that bus numbers
are reserved for SR-IOV or for CardBus (SR-IOV is done without checks and
the CardBus checks are sketchy at best).

We clamp the returned value to the actual subordinate value and print a
warning if too many bus numbers are reserved.

[bhelgaas: whitespace]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Remove pci_fixup_parent_subordinate_busnr()

The function has no effect.

If pcibios_assign_all_busses() is not set then the function does nothing.

If it is set then in pci_scan_bridge we are always in the branch where
we assign the bus numbers ourselves and the subordinate values of all
parent busses will be set to 0xff since that is what they inherited from
their parent bus and ultimately from the root bus.

Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Enable quirks for PCIe ACS on Intel PCH root ports

Many of the currently available Intel PCH-based root ports do not provide
PCIe ACS capabilities.  Without this, we must assume that peer-to-peer
traffic between multifunction root ports and between devices behind root
ports is possible.  This lack of isolation is exposed by grouping the
devices together in the same IOMMU group.  If we want to expose these
devices to userspace, vfio uses IOMMU groups as the unit of ownership, thus
making it very difficult to assign individual devices to separate users.

The good news is that the chipset does provide ACS-like isolation
capabilities, but we do need to verify and enable those capabilities if the
BIOS has not done so.  This patch implements the device specific enabling
and testing of equivalent ACS function for these devices.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>

PCI: Add pci_dev_flag for ACS enable quirks

Quirks that enable ACS-compatible functionality on a device need some way
to track whether a given device has been enabled.  Rather than create new
data structures for this, allocate one of the pci_dev_flags to indicate
this setup.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Add device-specific PCI ACS enable

Some devices support PCI ACS-like features, but don't report it using the
standard PCIe capabilities.  We already provide hooks for device-specific
testing of ACS, but not for device-specific enabling of ACS.  This provides
that setup hook.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Use link change notifications for hot-plug and removal

A lot of systems do not have the fancy buttons and LEDs, and instead
want to rely only on the Link state change events to drive the hotplug
and removal state machinery.
(http://www.spinics.net/lists/hotplug/msg05802.html)

This patch adds support for that functionality. Here are the details
about the patch itself:

* Define and use interrupt events for linkup / linkdown.

* Make the pcie_isr() also look at link events, and direct control to
  corresponding (new) link state change handler function.

* Introduce the functions to handle link-up and link-down events and
  queue the add / removal work in the slot->wq to be processed by
  pciehp_power_thread()

As a side note, this patch also fixes the bug
https://bugzilla.kernel.org/show_bug.cgi?id=65521 "pciehp ignores Data Link
Layer State Changed bit."

Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: pciehp: Make check_link_active() non-static

check_link_active() functionality needs to be used by subsequent patches
(that introduce link state change based hotplug). Thus make the function
non-static, and rename it to pciehp_check_link_active() so as to be
consistent with other non-static functions.

Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Make sure bus number resources stay within their parents bounds

Right now we use 0xff for busn_res.end when probing and later reduce it to
the value that is actually used. This does not work if a parent bridge has
already a lower subordinate value. For example during hotplug of a new
bridge below an already-configured bridge the following message is printed
from pci_bus_insert_busn_res():

  pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-9b] (conflicts with (null) [bus 05-9b])

This patch clamps the bus range to that of the parent and also ensures that
we do not exceed the parents range when assigning the final subordinate
value.

We also check that busses configured by the firmware fit into their parents
bounds.

[bhelgaas: reword dev_warn() and fix printk format warning]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Use request_resource_conflict() instead of insert_ for bus numbers

If a conflict happens during insert_resource_conflict() and all conflicts
fit within the newly inserted resource then they will become children of
the new resource. This is almost certainly not what we want for bus
numbers.

Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Assign CardBus bus number only during the second pass

Right now the CardBus code in pci_scan_bridge() is executed during both
passes. Since we always allocate the bus number ourselves it makes sense
to put it into the second pass.

Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Clarify the "scan anyway" comment in pci_scan_bridge()

Initially when we encountered a bus that was already present we skipped
it. Since 74710ded8e16 'PCI: always scan child buses' we continue
scanning in order to allow user triggered rescans of already existing
busses.

The old comment suggested that the reason for continuing the scan is a
bug in the i450NX chipset. This is not the case.

Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Increment max correctly in pci_scan_bridge()

This patch fixes two small issues:
 - If pci_add_new_bus() fails, max must not be incremented. Otherwise
   an incorrect value is returned from pci_scan_bridge().
 - If the bus is already present, max must be incremented. I think
   that this case should only be hit if we trigger a manual rescan of a
   CardBus bridge.

Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Remove unnecessary list_empty(&pci_pme_list) check

list_for_each_entry() handles empty lists just fine, so there's no need to
check whether the list is empty first.

No functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>

PCI/MSI: Add pci_enable_msi() documentation back

We deprecated pci_enable_msi() in 302a2523c277 ("PCI/MSI: Add
pci_enable_msi_range() and pci_enable_msix_range()").

But we changed our minds after noticing that:

  - pci_enable_msi() doesn't have confusing return values like
    pci_enable_msi_block() and pci_enable_msix() did, and

  - pci_enable_msi() has a hundred or so callers that we don't want to
    change.

This adds back the pci_enable_msi() documentation.

[bhelgaas: changelog]
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>