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>

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

Certain NTB devices have a hardware erratum where, regardless of
pre-configured value, reading the BAR size returns 4096.  To work around
this issue, add a PCI quirk to read the appropriate values from an
alternative register in PCI config space and move the resource endpoints
to the appropriate location.
Signed-off-by: NJon Mason <jon.mason@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Before every call of quirk_io_region(), pci_read_config_word() is called.
We can fold that call into quirk_io_region() to make code more readable.

[bhelgaas: changelog, fill bus_region directly rather than copying from res]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The following PCIe devices with revision lower than 0x18 have this bug:

 AR8161(1091)/AR8162(1090)/AR8171(10A1)/AR8172(10A0)/E210X(E091).
Signed-off-by: NHuang,Xiong <xiong@qca.qualcomm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NWei Yang <weiyang@linux.vnet.ibm.com>

Otherwise it fails like this on cards like the Transcend 16GB SDHC card:

    mmc0: new SDHC card at address b368
    mmcblk0: mmc0:b368 SDC   15.0 GiB
    mmcblk0: error -110 sending status command, retrying
    mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0

Tested on my Lenovo x200 laptop.

[bhelgaas: changelog]
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NChris Ball <cjb@laptop.org>
CC: Manoj Iyer <manoj.iyer@canonical.com>
CC: stable@vger.kernel.org

CONFIG_HOTPLUG is going away as an option so __devexit_p, __devint,
__devinitdata, __devinitconst, and _devexit are no longer needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Meilhaus ME-2000i and ME-2600i data acquisition cards supported by
the Comedi "me_daq" driver use the PLX PCI 9050 PCI Target bridge chip
affected by the bug that prevents the chip's local configuration
registers being read from BAR0 or BAR1 base addresses that are an odd
multiple of 128 bytes.  Use the PLX PCI 9050 quirk handler for these
devices to re-allocate affected regions to a 256-byte boundary.
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The PLX PCI 9050 PCI Target bridge controller has a bug that prevents
its local configuration registers being read through BAR0 (memory) or
BAR1 (i/o) if the base address lies on an odd 128-byte boundary, i.e. if
bit 7 of the base address is non-zero.  This bug is described in the PCI
9050 errata list, version 1.4, May 2005.  It was fixed in the
pin-compatible PCI 9052, which can be distinguished from the PCI 9050 by
checking the revision in the PCI header, which is hard-coded for these
chips.

Workaround the problem by re-allocating the affected regions to a
256-byte boundary.  Note that BAR0 and/or BAR1 may have been disabled
(size 0) during initialization of the PCI chip when its configuration is
read from a serial EEPROM.

Currently, the fix-up has only been used for devices with the default
vendor and device ID of the PLX PCI 9050.  The PCI 9052 shares the same
default device ID as the PCI 9050 but they have different PCI revision
codes.
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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

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

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

This change implements PCIe root complex support for tilegx using
the kernel support layer for accessing the TRIO hardware shim.

Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> [changes in 07487f3]
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>

My "PCI: Integrate 'pci_fixup_final' quirks into hot-plug paths" patch
introduced an undefined reference to 'pci_fixup_final_inited' when
CONFIG_PCI_QUIRKS is not enabled (on x86_64):
  drivers/built-in.o: In function `pci_bus_add_device':
  (.text+0x4f62): undefined reference to `pci_fixup_final_inited'

This patch removes the external reference ending up with a result closer
to what we ultimately want when the boot path issues described in the
original patch are resolved.

References:
  https://lkml.org/lkml/2012/7/9/542    Original, offending, patch
  https://lkml.org/lkml/2012/7/12/338	Randy's catch
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRandy Dunlap <rdunlap@xenotime.net>

Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend.  It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b6128 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.

It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working.  Consequently
commit c2fb8a3f (USB: add
NO_D3_DURING_SLEEP flag and revert 151b6128) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.

Now we know the actual cause of the problem.  Thanks to AceLan Kao for
tracking it down.

According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows.  When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state.  If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so.  This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3.  The end result is
a system hang or memory corruption.

Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend.  This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.

In theory we could do this for every PCI device.  However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.

Finally the affected systems can suspend with USB wakeup working
properly.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728Based-on-patch-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NDâniel Fraga <fragabr@gmail.com>
Tested-by: NJavier Marcet <jmarcet@gmail.com>
Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
Tested-by: NOleksij Rempel <bug-track@fisher-privat.net>
Tested-by: NPavel Pisa <pisa@cmp.felk.cvut.cz>
Cc: stable <stable@vger.kernel.org>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Final fixups are currently applied only at boot-time by
pci_apply_final_quirks(), which is an fs_initcall().  Hot-added devices
don't get these fixups, so they may not be completely initialized.

This patch makes us run final fixups for hot-added devices in
pci_bus_add_device() just before the new device becomes eligible for driver
binding.

This patch keeps the fs_initcall() for devices present at boot because we
do resource assignment between pci_bus_add_device and the fs_initcall(),
and we don't want to break any fixups that depend on that assignment.  This
is a design issue that may be addressed in the future -- any resource
assignment should be done *before* device_add().

[bhelgaas: changelog]
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Final fixups are executed during device enumeration.  If we support
hotplug, this may be after boot, so final fixups cannot be __init.

[bhelgaas: changelog]
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

9d265124 and 15a260d5 added quirks for P2P bridges that support
I/O windows that start/end at 1K boundaries, not just the 4K boundaries
defined by the PCI spec.  For details, see the IOBL_ADR register and the
EN1K bit in the CNF register in the Intel 82870P2 (P64H2).

These quirks complicate the code that reads P2P bridge windows
(pci_read_bridge_io() and pci_cfg_fake_ranges()) because the bridge
I/O resource is updated in the HEADER quirk, in pci_read_bridge_io(),
in pci_setup_bridge(), and again in the FINAL quirk.  This is confusing
and makes it impossible to reassign the bridge windows after FINAL
quirks are run.

This patch adds support for 1K windows in the generic paths, so the
HEADER quirk only has to enable this support.  The FINAL quirk, which
used to undo damage done by pci_setup_bridge(), is no longer needed.

This removes "if (!res->start) res->start = ..." from pci_read_bridge_io();
that was part of 9d265124 to avoid overwriting the resource filled in
by the quirk.  Since pci_read_bridge_io() itself now knows about
granularity, the quirk no longer updates the resource and this test is no
longer needed.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The enable/suspend/resume_early/resume fixups can be called at any time, so
they can't be __init or __devinit.

[bhelgaas: changelog]
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

__nv_msi_ht_cap_quirk() acquires a temporary reference via
'pci_get_bus_and_slot()' that is never released.

This patch releases the temporary reference.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>