On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
function 1 doesn't work if it is powered on before the SATA controller at
function 0.  The result is that PATA doesn't work after resume, and we
print messages like this:

  pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
  irq 17: nobody cared (try booting with the "irqpoll" option)

Async resume was introduced in v3.15 by 76569faa ("PM / sleep:
Asynchronous threads for resume_noirq").  Prior to that, we powered on
the functions in order, so this problem shouldn't happen.

e6b7e41c ("ata: Disabling the async PM for JMicron chip 363/361")
solved the problem for JMicron 361 and 363 devices.  With async suspend
disabled, we always power on function 0 before function 1.

Barto then reported the same problem with a JMicron 368 (see comment #57 in
the bugzilla).

Rather than extending the blacklist piecemeal, disable async suspend for
all JMicron multi-function SATA/PATA/AHCI devices.

This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
the problem will occur even if pata_jmicron isn't loaded until after the
suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
power-on order even if the drivers aren't loaded.

[bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551Reported-and-tested-by: NBarto <mister.freeman@laposte.net>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.15+

Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device
functions other than function 0, so that on multi-function devices, we will
always read VPD from function 0 instead of from the other functions.

[bhelgaas: changelog]
Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
CC: stable@vger.kernel.org

Remove a broken link in drivers/pci/quirks.c.
Signed-off-by: NRami Rosen <ramirose@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Some quirks search for a HyperTransport capability and use a hard-coded TTL
value of 48 to avoid an infinite loop.

Move the definition of PCI_FIND_CAP_TTL to pci.h and use it instead of the
hard-coded TTL values.

[bhelgaas: changelog]
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The PCI class in dev->class is a three-byte value comprising a base class,
sub-class, and interface type.  PCI_CLASS_NOT_DEFINED includes the base
class and sub-class, but not the interface type, so it should be shifted to
make space for the interface.  It happens that PCI_CLASS_NOT_DEFINED is
zero, so it doesn't matter in the end, but we should still use it
consistently with other class definitions.

Treat PCI_CLASS_NOT_DEFINED as a base class/sub-class value that should
appear in bits 8-23 of dev->class.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Revert aeb30016 ("PCI: add Intel USB specific reset method").

We checked for "dev->class == PCI_CLASS_SERIAL_USB", but dev->class
contains the entire three-byte base class/sub-class/interface, while
PCI_CLASS_SERIAL_USB is only the two-byte base class/sub-class.

This error meant that we used the Intel device-specific reset on devices
with class code 0x000c03 instead of those with class code 0x0c03xx.
0x000c03 is a reserved value in the 0x00 backwards compatibility base
class and shouldn't match any devices, so I think reset_intel_generic_dev()
always failed.

I considered adding a shift, but I can't test it, so it's as likely to
break something as to fix something.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Yu Zhao <yu.zhao@intel.com>
CC: Mathias Nyman <mathias.nyman@intel.com>

In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO".
But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class
and needs to be shifted to make space for the low-order interface byte.

Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.

Fixes: 63c44080 ("PCI: Add quirk for setting valid class for TI816X Endpoint")
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Hemant Pedanekar <hemantp@ti.com>

In the generic quirk fixup_rev1_53c810(), added by a5312e28 ("[PATCH]
PCI: NCR 53c810 quirk"), we assigned "class = PCI_CLASS_STORAGE_SCSI".  But
PCI_CLASS_STORAGE_SCSI is only the two-byte base class/sub-class and needs
to be shifted to make space for the low-order interface byte.

Furthermore, we had a similar quirk, pci_fixup_ncr53c810(), for arch/x86,
which assigned class correctly.  The arch code is linked before the PCI
core, so arch quirks run before generic quirks.  Therefore, on x86, the x86
arch quirk ran first, and the generic quirk did nothing because it saw that
dev->class was already set.  But on other arches, the generic quirk set the
wrong class code.

Fix the generic quirk to set the correct class code and remove the
now-unnecessary x86-specific quirk.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Matthew Wilcox <matthew@wil.cx>

be6646bf ("PCI: Prevent xHCI driver from claiming AMD Nolan USB3 DRD
device") added a quirk to override the PCI class code of the AMD Nolan
device.

Use PCI_CLASS_SERIAL_USB instead of a bare number to improve greppability.
Also add a log message about what we're doing.

No functional change except the new message.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NHuang Rui <ray.huang@amd.com>
CC: Jason Chang <jason.chang@amd.com>
CC: Felipe Balbi <balbi@ti.com>

Intersil/Techwell TW686[4589]-based video capture cards have an empty
(zero) class code.  Fix it.
Signed-off-by: NKrzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Just like Haswell, Intel Atom Cherrytrail does not need the default 10ms
d3_delay imposed by the PCI specification.

Expand quirk_remove_d3_delay() to apply to Cherrytrail devices, so we can
ignore the 10ms delay before entering or exiting D3 suspend.

[bhelgaas: changelog, comment]
Signed-off-by: NSrinidhi Kasagar <srinidhi.kasagar@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Marvell 9120 SATA controller has the same issue as a number of others, so
use the same quirk for this one.  The other quirks were added by
cc346a47 ("PCI: Add function 1 DMA alias quirk for Marvell devices").
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>

Intel confirms that 9-series chipset root ports provide ACS-equivalent
isolation when configured via the existing Intel PCH ACS quirk setup.
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 PCI core now disables MSI and MSI-X for all devices during enumeration
regardless of CONFIG_PCI_MSI.  Remove device-specific code to disable
MSI/MSI-X.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The SiS apic bug workaround is now obsolete as we cache the register
values for performance reasons.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Cohen <david.a.cohen@linux.intel.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dimitri Sivanich <sivanich@sgi.com>
Cc: Grant Likely <grant.likely@linaro.org>
Link: http://lkml.kernel.org/r/1428978610-28986-22-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

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>