* 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>

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>

I'm not asserting any claim over arch/x86/kernel/quirks.c, and I don't plan
to merge changes to it, but some of the quirks there are PCI-related, and
I'd like to see changes to them.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Some PCI functions used to be marked __devinit.  When CONFIG_HOTPLUG was
not set, these functions were discarded after boot.  A few callers of these
__devinit functions were marked __ref to indicate that they could safely
call the __devinit functions even though the callers were not __devinit.

But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref
annotations is also gone, so remove them.  Relevant historical commits:

  54b956b9 Remove __dev* markings from init.h
  a8e4b9c1 PCI: add generic pci_hp_add_bridge()
  0ab2b57f PCI: fix section mismatch warning in pci_scan_child_bus
  451124a7 PCI: fix 4x section mismatch warnings
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

While using the sysfs new_id interface, the user can unintentionally feed
incorrect values if the driver static table has a matching entry.  This is
possible since only the device and vendor fields are mandatory and the rest
are optional.  As a result, store_new_id() will fill in default values that
are then passed on to the driver and can have unintended consequences.

As an example, consider the ixgbe driver and the 82599EB network card:

  echo "8086 10fb" > /sys/bus/pci/drivers/ixgbe/new_id

This will pass a pci_device_id with driver_data = 0 to ixgbe_probe(), which
uses that zero to index a table of card operations.  The zeroth entry of
the table does *not* correspond to the 82599 operations.

This change returns an error if the user attempts to add a dynid for a
vendor/device combination for which a static entry already exists.
However, if the user intentionally wants a different set of values, she
must provide all the 7 fields and that will be accepted.

[bhelgaas: drop KVM text since the problem isn't KVM-specific]
Signed-off-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>

After a CPU upgrade while keeping the same mainboard, we faced "spurious
interrupt" problems again.

It turned out that the new CPU also featured a new GPU with a different PCI
ID.

Add this PCI ID to the quirk table.  Probably all other Intel GPU PCI IDs
are affected, too, but I don't want to add them without a test system.

See f67fd55f ("PCI: Add quirk for still enabled interrupts on Intel
Sandy Bridge GPUs") for some history.

[bhelgaas: add f67fd55f reference, stable tag]
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.4+

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers using these two
interfaces need to be updated to use the new pci_enable_msi_range()  or
pci_enable_msi_exact() and pci_enable_msix_range() or
pci_enable_msix_exact() interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Numerical values stored in the device tree are encoded in Big Endian and
should be byte swapped when running in Little Endian.

The RPA hotplug module should convert those values as well.

Note that in rpaphp_get_drc_props(), the comparison between indexes[i+1]
and *index is done using the BE values (whatever is the current endianess).
This doesn't matter since we are checking for equality here.  This way only
the returned value is byte swapped.

RPA also made RTAS calls which implies BE values to be used.  According to
the patch done in RTAS (http://patchwork.ozlabs.org/patch/336865), no
additional conversion is required in RPA.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

3448a19d "vgaarb: use bridges to control VGA routing where possible"
added the "flags & PCI_VGA_STATE_CHANGE_DECODES" condition to an existing
WARN_ON(), but used bitwise AND (&) instead of logical AND (&&), so the
condition is never true.  Replace with logical AND.

Found by Coverity (CID 142811).

Fixes: 3448a19d "vgaarb: use bridges to control VGA routing where possible"
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: David Airlie <airlied@redhat.com>

Bodo reported that on the Asrock M3A UCC, v3.12.6 hangs during boot unless
he uses "pci=nocrs".  This regression was caused by 7bc5e3f2 ("x86/PCI:
use host bridge _CRS info by default on 2008 and newer machines"), which
appeared in v2.6.34.

The reason is that the HPET address appears in a PCI device BAR, and this
address is not contained in any of the host bridge windows.  Linux moves
the PCI BAR into a window, but the original address was published via the
HPET table and an ACPI device, so changing the BAR is a bad idea.  Here's
the dmesg info:

  ACPI: HPET id: 0x43538301 base: 0xfed00000
  pci_root PNP0A03:00: host bridge window [mem 0xd0000000-0xdfffffff]
  pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
  pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05
  pci 0000:00:14.0: reg 14: [mem 0xfed00000-0xfed003ff]
  hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
  pnp 00:06: Plug and Play ACPI device, IDs PNP0103 (active)
  pnp 00:06: [mem 0xfed00000-0xfed003ff]

When we notice the BAR is not in a host bridge window, we try to move it,
but that causes a hang shortly thereafter:

  pci 0000:00:14.0: no compatible bridge window for [mem 0xfed00000-0xfed003ff]
  pci 0000:00:14.0: BAR 1: assigned [mem 0xf0000000-0xf00003ff]

This patch marks the BAR as IORESOURCE_PCI_FIXED to prevent Linux from
moving it.  This depends on a previous patch ("x86/PCI: Don't try to move
IORESOURCE_PCI_FIXED resources") to check for this flag when
pci_claim_resource() fails.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=68591Reported-and-tested-by: Bodo Eggert <7eggert@gmx.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>