linux-stable.git/drivers/pci, branch linux-2.6.34.y

PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs

2014-02-10T21:11:38+00:00

commit cdb1f35dc7de42802527140a3613871c394548e1 upstream.

commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream.

Some BIOS implementations leave the Intel GPU interrupts enabled,
even though no one is handling them (f.e. i915 driver is never loaded).
Additionally the interrupt destination is not set up properly
and the interrupt ends up -somewhere-.

These spurious interrupts are "sticky" and the kernel disables
the (shared) interrupt line after 100.000+ generated interrupts.

Fix it by disabling the still enabled interrupts.
This resolves crashes often seen on monitor unplug.

Tested on the following boards:
- Intel DH61CR: Affected
- Intel DH67BL: Affected
- Intel S1200KP server board: Affected
- Asus P8H61-M LE: Affected, but system does not crash.
  Probably the IRQ ends up somewhere unnoticed.

According to reports on the net, the Intel DH61WW board is also affected.

Many thanks to Jesse Barnes from Intel for helping
with the register configuration and to Intel in general
for providing public hardware documentation.

Signed-off-by: Thomas Jarosch 
Tested-by: Charlie Suffin 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau 
Signed-off-by: Paul Gortmaker

PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs

2013-01-16T21:44:57+00:00

commit 4cac2eb158c6da0c761689345c6cc5df788a6292 upstream.

Previously we claimed device ID 0x7450, regardless of the vendor, which is
clearly wrong.  Now we'll claim that device ID only for AMD.

I suspect this was just a typo in the original code, but it's possible this
change will break shpchp on non-7450 AMD bridges.  If so, we'll have to fix
them as we find them.

Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863
Reported-by: Ralf Jung 
Cc: Joerg Roedel 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Jesse Barnes 
Signed-off-by: Paul Gortmaker

PCI: ARI is a PCIe v2 feature

2012-05-17T15:21:19+00:00

commit 864d296cf948aef0fa32b81407541572583f7572 upstream.

The function pci_enable_ari() may mistakenly set the downstream port
of a v1 PCIe switch in ARI Forwarding mode.  This is a PCIe v2 feature,
and with an SR-IOV device on that switch port believing the switch above
is ARI capable it may attempt to use functions 8-255, translating into
invalid (non-zero) device numbers for that bus.  This has been seen
to cause Completion Timeouts and general misbehaviour including hangs
and panics.

Acked-by: Don Dutile 
Tested-by: Don Dutile 
Signed-off-by: Chris Wright 
Signed-off-by: Jesse Barnes 
Signed-off-by: Paul Gortmaker

PCI: Set PCIE maxpayload for card during hotplug insertion

2012-05-17T15:20:44+00:00

commit e522a7126c7c144a1dd14c6f217ac31e71082b1d upstream.

The following patch sets the MaxPayload setting to match the parent
reading when inserting a PCIE card into a hotplug slot.  On our system,
the upstream bridge is set to 256, but when inserting a card, the card
setting defaults to 128.  As soon as I/O is performed to the card it
starts receiving errors since the payload size is too small.

Reviewed-by: Kenji Kaneshige 
Signed-off-by: Jordan Hargrave 
Signed-off-by: Jesse Barnes 
Signed-off-by: Paul Gortmaker

PCI: Add quirk for setting valid class for TI816X Endpoint

2012-05-17T15:20:41+00:00

commit 63c4408074cbcc070ac17fc10e524800eb9bd0b0 upstream.

TI816X (common name for DM816x/C6A816x/AM389x family) devices configured
to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus
code to skip allocating BARs to these devices resulting into following
type of error when trying to enable them:

"Device 0000:01:00.0 not available because of resource collisions"

The device cannot be operated because of the above issue.

This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based)
'early' fixup quirk to replace class code with
PCI_CLASS_MULTIMEDIA_VIDEO as class.

Signed-off-by: Hemant Pedanekar 
Signed-off-by: Jesse Barnes 
Signed-off-by: Paul Gortmaker

intel-iommu: Force-disable IOMMU for iGFX on broken Cantiga revisions.

2012-03-14T14:57:50+00:00

commit 2d9e667efdfb4e986074d98e7d9a424003c7c43b upstream.

Certain revisions of this chipset appear to be broken. There is a shadow
GTT which mirrors the real GTT but contains pre-translated physical
addresses, for performance reasons. When a GTT update happens, the
translations are done once and the resulting physical addresses written
back to the shadow GTT.

Except sometimes, the physical address is actually written back to the
_real_ GTT, not the shadow GTT. Thus we start to see faults when that
physical address is fed through translation again.

Signed-off-by: David Woodhouse 
Signed-off-by: Paul Gortmaker

intel-iommu: Fix get_domain_for_dev() error path

2012-03-14T14:57:22+00:00

commit 2fe9723df8e45fd247782adea244a5e653c30bf4 upstream.

If we run out of domain_ids and fail iommu_attach_domain(), we
fall into domain_exit() without having setup enough of the
domain structure for this to do anything useful.  In fact, it
typically runs off into the weeds walking the bogus domain->devices
list.  Just free the domain.

Signed-off-by: Alex Williamson 
Acked-by: Donald Dutile 
Signed-off-by: David Woodhouse 
Signed-off-by: Paul Gortmaker

intel-iommu: Unlink domain from iommu

2012-03-14T14:57:22+00:00

commit a97590e56d0d58e1dd262353f7cbd84e81d8e600 upstream.

When we remove a device, we unlink the iommu from the domain, but
we never do the reverse unlinking of the domain from the iommu.
This means that we never clear iommu->domain_ids, eventually leading
to resource exhaustion if we repeatedly bind and unbind a device
to a driver.  Also free empty domains to avoid a resource leak.

Signed-off-by: Alex Williamson 
Acked-by: Donald Dutile 
Signed-off-by: David Woodhouse 
Signed-off-by: Paul Gortmaker

PCI hotplug: acpiphp: set current_state to D0 in register_slot

2012-03-14T14:56:48+00:00

commit 47e9037ac16637cd7f12b8790ea7ce6680e42168 upstream.

If a device doesn't support power management (pm_cap == 0) but it is
acpi_pci_power_manageable() because there is a _PS0 method declared for
it and _EJ0 is also declared for the slot then nobody is going to set
current_state = PCI_D0 for this device.  This is what I think it is
happening:

pci_enable_device
    |
__pci_enable_device_flags
/* here we do not set current_state because !pm_cap */
    |
do_pci_enable_device
    |
pci_set_power_state
    |
__pci_start_power_transition
    |
pci_platform_power_transition
/* platform_pci_power_manageable() calls acpi_pci_power_manageable that
 * returns true */
    |
platform_pci_set_power_state
/* acpi_pci_set_power_state gets called and does nothing because the
 * acpi device has _EJ0, see the comment "If the ACPI device has _EJ0,
 * ignore the device" */

at this point if we refer to the commit message that introduced the
comment above (10b3dcae0f275e2546e55303d64ddbb58cec7599), it is up to
the hotplug driver to set the state to D0.
However AFAICT the pci hotplug driver never does, in fact
drivers/pci/hotplug/acpiphp_glue.c:register_slot sets the slot flags to
(SLOT_ENABLED | SLOT_POWEREDON) but it does not set the pci device
current state to PCI_D0.

So my proposed fix is also to set current_state = PCI_D0 in
register_slot.
Comments are very welcome.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Jesse Barnes 
Signed-off-by: Paul Gortmaker

PCI: return correct value when writing to the "reset" attribute

2011-06-26T16:47:15+00:00

commit 447c5dd7338638f526e9bcf7dcf69b4da5835c7d upstream.

A successful write() to the "reset" sysfs attribute should return the
number of bytes written, not 0. Otherwise userspace (bash) retries the
write over and over again.

Acked-by: Michael S. Tsirkin 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Michal Schmidt 
Signed-off-by: Jesse Barnes 
Signed-off-by: Paul Gortmaker