Fix a typo in one of the kernel messages.
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Intel has verified that there is no peer-to-peer between functions for the
below selection of 82580, 82576, 82575, I350, and 82571 multi-port devices.
This adds the necessary quirks to consider the functions isolated from each
other.  82571 quad-port devices are omitted due to likely lack of
ACS/isolation in the onboard switch, rendering quirks for the downstream
endpoints useless.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: John Ronciak <john.ronciak@intel.com>

Some AMD CS553x devices have read-only BARs because of a firmware or
hardware defect.  There's a workaround in quirk_cs5536_vsa(), but it no
longer works after 36e81648 ("PCI: Restore detection of read-only
BARs").  Prior to 36e81648, we filled in res->start; afterwards we
leave it zeroed out.  The quirk only updated the size, so the driver tried
to use a region starting at zero, which didn't work.

Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
hard-code the sizes.

On Nix's system BAR 2's read-only value is 0x6200.  Prior to 36e81648,
we interpret that as a 512-byte BAR based on the lowest-order bit set.  Per
datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
avoid clearing any address bits if a platform uses only 64-byte alignment.

[bhelgaas: changelog, reduce BAR 2 size to 64]
Fixes: 36e81648 ("PCI: Restore detection of read-only BARs")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdfReported-and-tested-by: NNix <nix@esperi.org.uk>
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v.2.6.27+

Intel has confirmed that the Wellsburg chipset, while not reporting ACS,
does provide the proper isolation through the RCBA/BSPR registers, so the
same quirk works for this set of device IDs.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NDon Dugger <donald.d.dugger@intel.com>

The Adaptec 3405 is actually an Intel 80333 I/O processor where the exposed
device at 0e.0 is actually the address translation unit of the I/O
processor and a hidden, private device at 01.0 masters the DMA for the
device.  Create a fixed alias between the exposed and hidden devfn so we
can enable the IOMMU.

Scenarios like this are potentially likely for any device incorporating
this I/O processor, so this little bit of abstraction with the fixed alias
table should make future additions trivial.

Without this fix, booting a system with the Intel IOMMU enabled and an
Adaptec 3405 at 02:0e.0 results in a flood of errors like this:

  dmar: DRHD: handling fault status reg 3
  dmar: DMAR:[DMA Write] Request device [02:01.0] fault addr ffbff000
  DMAR:[fault reason 02] Present bit in context entry is clear

[bhelgaas: changelog, comment]
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Adaptec OEM Raid Solutions <aacraid@adaptec.com>

As Skyhawk and BE3-R (both multi-function devices) don't advertise the
PCI-ACS capability, the vfio driver places all the functions of these
devices in a single IOMMU group.  Attaching (via PCI-passthru) two
different Skyhawk/BE3-R partitions (nPAR, Flex, etc. PFs) using vfio, to
different guests doesn't work as vfio only allows functions in *different*
IOMMU groups to be assigned to different guests.

As peer-to-peer access between PFs in Skyhawk/BE3-R is not possible, we can
treat them as "fully isolated" even though the device doesn't advertise
ACS.  Add a PCI quirk for Skyhawk and BE3-R chips to fix this problem.
Signed-off-by: NVasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>

Some AMD/ATI GPUs report NoSoftRst- to indicate that they perform a reset
when software transitions them from D3hot to D0, but there is no apparent
effect on the device: the monitor remains synced and the framebuffer
contents are retained.

Callers of pci_reset_function() don't necessarily have a way to validate
whether a reset was effective, so we don't want to rely on NoSoftRst if
it's known to be inaccurate.  Returning an error in such cases appears to
be the better option.  For users like vfio-pci, this allows the driver to
escalate to the bus reset interfaces.

If a device lives on the root bus, there's really no further
escalation path, so we exempt PM reset as potentially better than
nothing.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>

Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets.  I've also been able to
confirm this behavior on multiple systems.  The device never returns from
reset and attempts to access config space of the device after reset result
in hangs.  Blacklist bus reset for the device to avoid this issue.

[bhelgaas: This regression appeared in v3.14.  Andreas bisected it to
425c1b22 ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.]

[bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.orgReported-by: NAndreas Hartmann <andihartmann@freenet.de>
Tested-by: NAndreas Hartmann <andihartmann@freenet.de>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.14+

The AMD Nolan (NL) SoC contains a DesignWare USB3 Dual-Role Device that can
be operated either as a USB Host or a USB Device.  In the AMD NL platform,
this device ([1022:7912]) has a class code of PCI_CLASS_SERIAL_USB_XHCI
(0x0c0330), which means the xhci driver will claim it.

But the dwc3 driver is a more specific driver for this device, and we'd
prefer to use it instead of xhci.  To prevent xhci from claiming the
device, change the class code to 0x0c03fe, which the PCI r3.0 spec defines
as "USB device (not host controller)".  The dwc3 driver can then claim it
based on its Vendor and Device ID.
Suggested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Jason Chang <jason.chang@amd.com>
Signed-off-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

AMD has confirmed that peer-to-peer between two southbridge functions does
not occur.

Add a quirk to indicate that these functions are isolated even though they
don't have an ACS capability.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=81841Signed-off-by: NMarti Raudsepp <marti@juffo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJoel Schopp <joel.schopp@amd.com>

Intel has verified there is no peer-to-peer between functions for the below
selection of 82598, 82599, and X520 10G NICs.  These NICs lack an ACS
capability, so we're not able to determine this isolation without the help
of quirks.

Generalize the Solarflare quirk and add these Intel 10G NICs.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJohn Ronciak <John.ronciak@intel.com>

Solarflare confirms that these devices do not allow peer-to-peer between
functions.  Quirk them to allow IOMMU grouping to expose this isolation.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRobert Stonehouse <rstonehouse@solarflare.com>

pci_get_dma_source() is unused, so remove it.  We now have
dma_alias_devfn() to describe this.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The Crocodile chip occasionally comes up with 4k and 8k BAR sizes.  Due to
an erratum, setting the SR-IOV page size causes the physical function BARs
to expand to the system page size.  Since ppc64 uses 64k pages, when Linux
tries to assign the smaller resource sizes to the now 64k BARs the address
will be truncated and the BARs will overlap.

Force Linux to allocate the resource as a full page, which avoids the
overlap.

[bhelgaas: print expanded resource, too]
Signed-off-by: NDouglas Lehr <dllehr@us.ibm.com>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NMilton Miller <miltonm@us.ibm.com>
CC: stable@vger.kernel.org

The VFIO driver routes LSI interrupts by capturing, masking, and then
delivering.  When passing though Mellanox adapters from host to guest,
interrupt storm are reported from host and guest.  That's because the PCI
command register INTx Disable bit doesn't work on Mellanox devices.

  # lspci | grep Mellanox
  0001:05:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
  0005:01:00.0 Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] (rev b0)

Amir Vadai confirmed that all Mellanox devices have same problem.
The patch marks broken INTx masking for all Mellanox adapters.
Suggested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-By: NAmir Vadai <amirv@mellanox.com>

This bridge sometimes shows up as a root complex device and sometimes as a
discrete PCIe-to-PCI bridge.  Testing indicates that in the latter case, we
need to enable the PCIe bridge DMA alias quirk.
Reported-by: NMilos Kaurin <milos.kaurin@gmail.com>
Tested-by: NMilos Kaurin <milos.kaurin@gmail.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add two quirks to support thunderbolt suspend/resume on Apple systems.
We need to perform two different actions during suspend and resume:

The whole controller has to be powered down before suspend. If this is
not done then the native host interface device will be gone after resume
if a thunderbolt device was plugged in before suspending. The controller
represents itself as multiple PCI devices/bridges. To power it down we
hook into the upstream bridge of the controller and call the magic ACPI
methods.  Power will be restored automatically during resume (by the
firmware presumably).

During resume we have to wait for the native host interface to
reestablish all pci tunnels. Since there is no parent-child relationship
between the NHI and the bridges we have to explicitly wait for them
using device_pm_wait_for_dev. We do this in the resume_noirq phase of
the downstream bridges of the controller (which lead into the
thunderbolt tunnels).
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add pci_fixup_suspend_late as a new pci_fixup_pass. The pass is called
from suspend_noirq and poweroff_noirq. Using the same pass for suspend
and hibernate is consistent with resume_early which is called by
resume_noirq and restore_noirq.

The new quirk pass is required for Thunderbolt support on Apple
hardware.
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This device uses function 1 as the PCIe requester ID.

This vendor has similar boards based on the same Marvell 88SE9235 chipset,
but this patch was only tested with the 642L.

Tested on ASUS Sabertooth 990FX (AMD).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679Signed-off-by: NJérôme Carretero <cJ-ko@zougloub.eu>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>

Merge quoted strings that are broken across lines into a single entity.
The compiler merges them anyway, but checkpatch complains about it, and
merging them makes it easier to grep for strings.

No functional change.

[bhelgaas: changelog, do the same for everything under drivers/pci]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Fix various whitespace errors.

No functional change.

[bhelgaas: fix other similar problems]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The ITE 8892 is a PCIe-to-PCI bridge but doesn't have a PCIe capability.
Quirk it so we can figure out the DMA alias for devices below the bridge,
so they work correctly with an IOMMU.

[bhelgaas: add changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=73551Reported-by: NRonald <rwarsow@gmx.de>
Tested-by: NRonald <rwarsow@gmx.de>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The quirk is intended to be extremely generic, but we only apply it to
known offending devices.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=44881Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Several Marvell devices and a JMicron device have a similar DMA requester
ID problem to Ricoh, except they use function 1 as the PCIe requester ID.
Add a quirk for these to populate the DMA alias with the correct devfn.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679Tested-by: NGeorge Spelvin <linux@horizon.com>
Tested-by: NAndreas Schrägle <ajs124.ajs124@gmail.com>
Tested-by: NTobias N <qemu@suppser.de>
Tested-by: <daxcore@online.de>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The existing quirk for these devices (pci_get_dma_source()) doesn't really
solve the problem; re-implement it using the DMA alias iterator.  We'll
come back later and remove the existing quirk and dma_source interface.
Note that device ID 0xe822 is typically function 0 and 0xe230 has been
tested to not need the quirk and are therefore removed versus the
equivalent dma_source quirk.  If there exist in other configurations we can
re-add them.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=605888Tested-by: NPat Erley <pat-lkml@erley.org>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.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: NThomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.4+

Intel has updated Red Hat bz1037684 to note that X79 PCH root ports also
provide isolation and the same ACS quirks apply.  Some sources indicate
additional device IDs for X79, but this patch includes only the ones
specifically identified by Intel:
https://bugzilla.redhat.com/show_bug.cgi?id=1037684#c11Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NDon Dugger <donald.d.dugger@intel.com>

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: NBjorn Helgaas <bhelgaas@google.com>

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: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NDon Dugger <donald.d.dugger@intel.com>

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: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

These interfaces:

  pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
  pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)

took a pci_dev, but they really depend only on the pci_bus.  And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:

  pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
  pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)

In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.

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

This tool hasn't been maintained in over a decade, and is pretty much
useless these days.  Let's pretend it never happened.

Also remove a long-dead email address.
Signed-off-by: NDave Jones <davej@fedoraproject.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix whitespace, capitalization, and spelling errors.  No functional change.
I know "busses" is not an error, but "buses" was more common, so I used it
consistently.

Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus())
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The latest Intel Haswell chipsets have a hardware optimization which
allows on-chip PCI devices to ignore the 10ms delay before entering
or exiting D3 suspend.

This patch implements the optimization as a PCI quirk, since we want
tight control over which devices use it. This way we can test each device
individually to be sure there are no issues before we enable the quirk.
The first set of devices are from the Haswell platform, which includes
every PCI device that is on the northbridge and southbridge.

This patch reduces the Haswell suspend time from 93 ms to 47 ms and resume
time from 160 ms to 64 ms.
Signed-off-by: NTodd Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

New routine has been added to avoid duplication of code to wait for
pending PCI transactions to complete.  This makes use of that function.
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NVipul Pandya <vipul@chelsio.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

T4 can wedge if there are DMAs in flight within the chip and Bus
Master has been disabled.  We need to have it on till the Function
Level Reset completes.  T4 can also suffer a Head Of Line blocking
problem if MSI-X interrupts are disabled before the FLR has completed.
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NVipul Pandya <vipul@chelsio.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

AMD confirmed that peer-to-peer between these devices is
not possible.  We can therefore claim that they support a
subset of ACS.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NDonald Dutile <ddutile@redhat.com>

PCI PM cap register offset has been saved in pci_pm_init(),
so we can use pdev->pm_cap instead of using pci_find_capability(..)
here.
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

To add AMD CZ SATA controller device ID of IDE mode.

[bhelgaas: drop pci_ids.h update]
Signed-off-by: NShane Huang <shane.huang@amd.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org