* pci/host-exynos:
  PCI: exynos: Remove unnecessary OOM messages

* pci/host-rcar:
  PCI: rcar: Add gen2 device tree support
  PCI: rcar: Add R-Car PCIe device tree bindings
  PCI: rcar: Add MSI support for PCIe
  PCI: rcar: Add Renesas R-Car PCIe driver
  PCI: rcar: Use new OF interrupt mapping when possible

* pci/amd-numa:
  x86/PCI: Clean up and mark early_root_info_init() as deprecated
  x86/PCI: Work around AMD Fam15h BIOSes that fail to provide _PXM
  x86/PCI: Warn if we have to "guess" host bridge node information

Add device tree probing support to the 'pci-rcar-gen2' driver.

[Sergei: numerous fixes/cleanups/additions]
[bhelgaas: whitespace fix]
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Arnd Bergmann <arnd@arndb.de>

This patch adds the bindings for the R-Car PCIe driver.  The driver resides
under drivers/pci/host/pcie-rcar.c
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

Add MSI support to the R-Car PCIe driver.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

This PCIe Host driver currently does not support MSI, so cards fall back to
INTx interrupts.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>

The site-specific OOM messages are unnecessary, because they duplicate the
MM subsystem generic OOM message.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

early_root_info_init() is now deprecated in favor of info in ACPI.  Add a
note to that effect.  Also, clean up the code a bit.

There is no functional change.
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

* dma-api:
  iommu/exynos: Remove unnecessary "&" from function pointers
  DMA-API: Update dma_pool_create ()and dma_pool_alloc() descriptions
  DMA-API: Fix duplicated word in DMA-API-HOWTO.txt
  DMA-API: Capitalize "CPU" consistently
  sh/PCI: Pass GAPSPCI_DMA_BASE CPU & bus address to dma_declare_coherent_memory()
  DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t
  DMA-API: Clarify physical/bus address distinction

* pci/virtualization:
  PCI: Mark RTL8110SC INTx masking as broken

* pci/msi:
  PCI/MSI: Remove pci_enable_msi_block()

* pci/misc:
  PCI: Remove pcibios_add_platform_entries()
  s390/pci: use pdev->dev.groups for attribute creation
  PCI: Move Open Firmware devspec attribute to PCI common code

* pci/resource:
  PCI: Add resource allocation comments
  PCI: Simplify __pci_assign_resource() coding style
  PCI: Change pbus_size_mem() return values to be more conventional
  PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
  PCI: Support BAR sizes up to 8GB
  resources: Clarify sanity check message
  PCI: Don't add disabled subtractive decode bus resources
  PCI: Don't print anything while decoding is disabled
  PCI: Don't set BAR to zero if dma_addr_t is too small
  PCI: Don't convert BAR address to resource if dma_addr_t is too small
  PCI: Reject BAR above 4GB if dma_addr_t is too small
  PCI: Fail safely if we can't handle BARs larger than 4GB
  x86/gart: Tidy messages and add bridge device info
  x86/gart: Replace printk() with pr_info()
  x86/PCI: Move pcibios_assign_resources() annotation to definition
  x86/PCI: Mark ATI SBx00 HPET BAR as IORESOURCE_PCI_FIXED
  x86/PCI: Don't try to move IORESOURCE_PCI_FIXED resources
  x86/PCI: Fix Broadcom CNB20LE unintended sign extension

Remove unnecessary "&" from function pointers in exynos_iommu_ops.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>

Use "boundary" to be more descriptive than "alloc" in the dma_pool_create()
documentation.

Replace "SLAB_KERNEL" and "SLAB_ATOMIC" with the correct "GFP_KERNEL" and
"GFP_ATOMIC."

[bhelgaas: changelog]
Signed-off-by: Gioh Kim <gioh.kim@lge.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

"coherent" is written twice when it should be just once.
Signed-off-by: Emilio López <emilio@elopez.com.ar>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Sometimes we used "cpu," other times "CPU."  Use "CPU" consistently.
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Add comments in the code to match the allocation strategy of 7c671426dfc3
("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources").

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

If an allocation succeeds, we can return success immediately.  Then we
don't have to test for success in the subsequent code.

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

pbus_size_mem() previously returned 0 for failure and 1 for success.
Change it to return -ENOSPC for failure and 0 for success.

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

This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.

Previously we put all prefetchable resources in the prefetchable bridge
window.  If any of those resources was 32-bit only, we restricted the
window to be below 4GB.

After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window.  We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.

With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.

The new strategy is:

  1) If the prefetchable window is 64 bits wide, we put only 64-bit
     prefetchable resources in it.  Any 32-bit prefetchable resources go in
     the non-prefetchable window.

  2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
     prefetchable resources in it.

  3) If there is no prefetchable window, all MMIO resources go in the
     non-prefetchable window.

This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window.  We previously assigned prefetchable
space, but now we'll assign non-prefetchable space.  This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB.  In those cases, the old strategy would work and would have
better performance.

[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

This is needed for some of the Xeon Phi type systems.

[bhelgaas: added Nikhil, use ARRAY_SIZE() to connect with decl, folded in
Kevin's "order < 0" fix to ARRAY_SIZE() usage]
Signed-off-by: Nikhil P Rao <nikhil.rao@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The resource map sanity check message is a bit confusing.  Change it to be
more readable:

  -resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
  +resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

For a subtractive decode bridge, we previously added and printed all
resources of the primary bus, even if they were not valid.  In the example
below, the bridge 00:1c.3 has no windows enabled, so there are no valid
resources on bus 02.  But since 02:00.0 is subtractive decode bridge, we
add and print all those invalid resources, which don't really make sense:

  pci 0000:00:1c.3: PCI bridge to [bus 02-03]
  pci 0000:02:00.0: PCI bridge to [bus 03] (subtractive decode)
  pci 0000:02:00.0:   bridge window [??? 0x00000000 flags 0x0] (subtractive decode)

Add and print the subtractively-decoded resources only if they are valid.

There's an example in the dmesg log attached to the bugzilla below (but
this patch doesn't fix the bug reported there).

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

If the console is a PCI device, and we try to print to it while its
decoding is disabled, the system will hang.  This particular printk hasn't
caused a problem yet, but it could, so this fixes it.

See also 0ff9514b ("PCI: Don't print anything while decoding is
disabled").
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

If a BAR is above 4GB and our dma_addr_t is too small, don't clear the BAR
to zero: that doesn't disable the BAR, and it makes it more likely that the
BAR will conflict with things if we turn on the memory enable bit (as we
will at "out:" if the device was already enabled at the handoff).

We should also print the BAR info and its original size so we can follow
the process when we try to assign space to it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

If dma_addr_t is too small to represent the BAR value,
pcibios_bus_to_resource() will fail, so just remember the BAR size directly
in the resource.  The resource is already marked UNSET, so we know the
address isn't valid anyway.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

We can only handle BARs above 4GB if dma_addr_t (not resource_size_t) is 64
bits wide.  If we have a 64-bit resource_size_t and a 32-bit dma_addr_t,
we can't deal with BARs above 4GB.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

We can only handle BARs larger than 4GB if both dma_addr_t and
resource_size_t are 64 bits wide.  If dma_addr_t is 32 bits, we can't
represent all the bus addresses, and if resource_size_t is 32 bits, we
can't represent all the CPU addresses.

Previously we cleared res->flags (at "fail:") for resources that were too
large.  That means we think the BAR doesn't exist at all, which in turn
means that we could enable the device even though we can't keep track of
where the BAR is and we can't make sure it doesn't overlap something else.

This preserves the type flags (MEM/IO) so we can keep from enabling the
device.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Print the AGP bridge info the same way as the rest of the kernel, e.g.,
"0000:00:04.0" instead of "00:04:00".

Also print the AGP aperture address range the same way we print resources,
and label it explicitly as a bus address range.

No functional change except the message changes.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Replace printk() with pr_info(), pr_err(), etc.  Define pr_fmt() to prefix
output with "AGP: ".

No functional change except the addition of "AGP: " prefix in dmesg output.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Move the pcibios_assign_resources() fs_initcall annotation next to the
function definition.  No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Remove pcibios_add_platform_entries().  Architecture-specific attributes
can be achieved by setting pdev->dev.groups.

Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrettSigned-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Let the driver core handle attribute creation by putting all s390
specific pci attributes in an attribute group which is referenced
by pdev->dev.groups in pcibios_add_device.

Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrettReviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

The BIOS is supposed to provide ACPI _PXM methods for PCI host bridges if
it cares about platform topology.  But some BIOSes do not, so add Fam15h
to the list of CPUs for which we fall back to reading node numbers from the
hardware.

Note that pci_acpi_scan_root() warns about the BIOS bug if we use this
information because (1) the hardware node numbers are not necessarily
compatible with other logical node numbers from ACPI, and (2) the lack of
_PXM forces OS updates that would not otherwise be required.

[bhelgaas: changelog, comments]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=72051Tested-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Robert Richter <rric@kernel.org>
Cc: Daniel J Blueman <daniel@numascale.com>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>

The vast majority of platforms are not supplying ACPI _PXM (proximity)
information corresponding to host bridge (PNP0A03/PNP0A08) devices
resulting in sysfs "numa_node" values of -1 (NUMA_NO_NODE):

  # for i in /sys/devices/pci0000\:00/*/numa_node; do cat $i; done | uniq
  -1

  # find /sys/ -name "numa_node" | while read fname; do cat $fname; \
    done | uniq
  -1

AMD based platforms provide a fall-back for this situation via amd_bus.c.
These platforms snoop out the information by directly reading specific
registers from the Northbridge and caching them via alloc_pci_root_info().

Later during boot processing when host bridges are discovered -
pci_acpi_scan_root() - the kernel looks for their corresponding ACPI _PXM
method - drivers/acpi/numa.c::acpi_get_node().  If the BIOS supplied a _PXM
method then that node (proximity) value is associated.  If the BIOS did not
supply a _PXM method *and* the platform is AMD-based, the fall-back cached
values obtained directly from the Northbridge are used; otherwise,
"NUMA_NO_NODE" is associated.

There are a number of issues with this fall-back mechanism the most notable
being that amd_bus.c extracts a 3-bit number from a CPU register and uses
it as the node number.  The node numbers used by Linux are logical and
there's no reason they need to be identical to settings in the CPU
registers.  So if we have some node information obtained in the normal way
(from _PXM, SLIT, SRAT, etc.) and some from amd_bus.c, there's no reason to
believe they will be compatible.

This patch warns when this situation occurs:

  pci_root PNP0A08:00: [Firmware Bug]: no _PXM; falling back to node 0 from hardware (may be inconsistent with ACPI node numbers)

Link: https://bugzilla.kernel.org/show_bug.cgi?id=72051Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

dma_declare_coherent_memory() needs both the CPU physical address and the
bus address of the device memory.  They are the same on this platform, but
in general we should use pcibios_resource_to_bus() to account for any
address translation done by the PCI host bridge.

This makes no difference on Dreamcast, but is safer if the usage is copied
to future drivers.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
CC: Magnus Damm <damm@opensource.se>
CC: linux-sh@vger.kernel.org

dma_declare_coherent_memory() takes two addresses for a region of memory: a
"bus_addr" and a "device_addr".  I think the intent is that "bus_addr" is
the physical address a *CPU* would use to access the region, and
"device_addr" is the bus address the *device* would use to address the
region.

Rename "bus_addr" to "phys_addr" and change its type to phys_addr_t.
Most callers already supply a phys_addr_t for this argument.  The others
supply a 32-bit integer (a constant, unsigned int, or __u32) and need no
change.

Use "unsigned long", not phys_addr_t, to hold PFNs.

No functional change (this could theoretically fix a truncation in a config
with 32-bit dma_addr_t and 64-bit phys_addr_t, but I don't think there are
any such cases involving this code).
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: James Bottomley <jbottomley@Parallels.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>

The DMA-API documentation sometimes refers to "physical addresses" when it
really means "bus addresses."  Sometimes these are identical, but they may
be different if the bridge leading to the bus performs address translation.
Update the documentation to use "bus address" when appropriate.

Also, consistently capitalize "DMA", use parens with function names, use
dev_printk() in examples, and reword a few sections for clarity.

No functional change; documentation changes only.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: James Bottomley <jbottomley@Parallels.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>

INTx masking does not work on this device.  To see this, configure the
network device UP on an active network, note that the interrupt count
continues to increment for the device in /proc/interrupts.  Use setpci to
set the PCI_COMMAND_INTX_DISABLE bit in the PCI_COMMAND register.  As
expected, the interrupt count ceases to increment.  However, reading the
PCI_STATUS_INTERRUPT bit of the PCI_STATUS register does not indicate that
interrupts are pending and clearing PCI_COMMAND_INTX_DISABLE in the
PCI_COMMAND register does not allow the device to continue operation.

This does not affect operation of the host r8169 driver, but it does
prevent the device from being functional when assigned to a VM, such as
with QEMU and VFIO.  The guest driver successfully probes the device, but
there is no traffic.  Mark INTx masking as broken, allowing the more
restrictive APIC masking to be used instead.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

There are no users of pci_enable_msi_block() function left.  Obsolete it in
favor of pci_enable_msi_range() and pci_enable_msi_exact() functions.

Previously, we called arch_setup_msi_irqs() once, requesting the same
vector count we passed to arch_msi_check_device().  Now we may call it
several times: if it returns failure, we may retry and request fewer
vectors.

We don't keep track of the vector count we initially passed to
arch_msi_check_device().  We only keep track of the number of vectors
successfully set up by arch_setup_msi_irqs(), and this is what we use to
clean things up when disabling MSI.  Therefore, we assume that
arch_msi_check_device() does nothing that will have to be cleaned up later.

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

Move the devspec OF attribute to PCI common code's set of device attributes
since it's not architecture dependent.  As a side effect microblaze and
powerpc no longer need to use pcibios_add_platform_entries().

[bhelgaas: fold in #include for compile error]
Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrettSigned-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

* pci/hotplug:
  PCI: rphahp: Fix endianess issues
  PCI: Allow hotplug service drivers to operate in polling mode
  PCI: pciehp: Acknowledge spurious "cmd completed" event
  PCI: pciehp: Use PCI_EXP_SLTCAP_PSN define
  PCI: hotplug: Remove unnecessary "dev->bus" test

* pci/msi:
  GenWQE: Use pci_enable_msi_exact() instead of pci_enable_msi_block()
  PCI/MSI: Simplify populate_msi_sysfs()
  PCI/portdrv: Use pci_enable_msix_exact() instead of pci_enable_msix()

* pci/virtualization:
  PCI: Add Patsburg (X79) to Intel PCH root port ACS quirk

* pci/misc:
  PCI: Fix use of uninitialized MPS value
  PCI: Remove dead code
  MAINTAINERS: Add arch/x86/kernel/quirks.c to PCI file patterns
  PCI: Remove unnecessary __ref annotations
  PCI: Fail new_id for vendor/device values already built into driver
  PCI: Add new ID for Intel GPU "spurious interrupt" quirk
  PCI: Update my email address
  PCI: Fix incorrect vgaarb conditional in WARN_ON()
  PCI: Use designated initialization in PCI_VDEVICE
  PCI: Remove old serial device IDs
  PCI: Remove unnecessary includes of <linux/init.h>
  powerpc/PCI: Fix NULL dereference in sys_pciconfig_iobase() list traversal

If "pcie_bus_config == PCIE_BUS_PERFORMANCE", we don't initialize "smpss",
so we pass a pointer to garbage into pcie_bus_configure_set(), where we
compute "mps" based on the garbage.  We then pass the garbage "mps" to
pcie_write_mps(), which ignores it in the PCIE_BUS_PERFORMANCE case.

Coverity isn't smart enough to deduce that we ignore the garbage (it's a
lot to expect from a human, too), so initialize "smpss" to a safe value in
all cases.

Found by Coverity (CID 146454).
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

"pdev" can never be NULL here, so remove the test.

Found by Coverity (CID 744313).
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>