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

PCI PM: Follow PCI_PM_CTRL_NO_SOFT_RESET during transitions from D3

2009-07-02T23:40:54+00:00

commit f62795f1e892ca9269849fa83de97621da7e02c0 upstream.

According to the PCI PM specification (PCI Bus Power Management
Interface Specification, Rev. 1.2, Section 5.4.1) we are supposed to
reinitialize devices that have PCI_PM_CTRL_NO_SOFT_RESET clear during
all transitions from PCI_D3hot to PCI_D0, but we only do it if the
device's current_state field is equal to PCI_UNKNOWN.

This may lead to problems if a device with PCI_PM_CTRL_NO_SOFT_RESET
unset is put into PCI_D3hot at run time by its driver and
pci_set_power_state() is used to put it back into PCI_D0, because in
that case the device will remain uninitialized after
pci_set_power_state() has returned.  Prevent that from happening by
modifying pci_raw_set_power_state() to reinitialize devices with
PCI_PM_CTRL_NO_SOFT_RESET unset during all transitions from D3 to D0.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

PCI PM: Fix handling of devices without PM support by pci_target_state()

2009-07-02T23:40:53+00:00

commit d2abdf62882d982c58e7a6b09ecdcfcc28075e2e upstream.

If a PCI device is not power-manageable either by the platform, or
with the help of the native PCI PM interface, pci_target_state() will
return either PCI_D3hot, or PCI_POWER_ERROR for it, depending on
whether or not the device is configured to wake up the system.  Alas,
none of these return values is correct, because each of them causes
pci_prepare_to_sleep() to return error code, although it should
complete successfully in such a case.

Fix this problem by making pci_target_state() always return PCI_D0
for devices that cannot be power managed.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

PCI: disable ASPM on VIA root-port-under-bridge configurations

2009-07-02T23:40:36+00:00

commit 8e822df700694ca6850d1e0c122fd7004b2778d8 upstream.

VIA has a strange chipset, it has root port under a bridge. Disable ASPM
for such strange chipset.

Tested-by: Wolfgang Denk 
Signed-off-by: Shaohua Li 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Avoid panic() for DRHD at address zero.

2009-05-08T22:45:10+00:00

(cherry picked from commit e523b38e2f568af58baa13120a994cbf24e6dee0)

If the BIOS does something obviously stupid, like claiming that the
registers for the IOMMU are at physical address zero, then print a nasty
message and abort, rather than trying to set up the IOMMU and then later
panicking.

It's becoming more and more obvious that trusting this stuff to the BIOS
was a mistake.

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Fix oops in device_to_iommu() when devices not found.

2009-05-08T22:45:10+00:00

(cherry picked from commit 4958c5dc7bcb2e42d985cd26aeafd8a7eca9ab1e)

It's possible for a device in the drhd->devices[] array to be NULL if
it wasn't found at boot time, which means we have to check for that
case.

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Fix device-to-iommu mapping for PCI-PCI bridges.

2009-05-08T22:45:10+00:00

(cherry picked from commit 924b6231edfaf1e764ffb4f97ea382bf4facff58)

When the DMAR table identifies that a PCI-PCI bridge belongs to a given
IOMMU, that means that the bridge and all devices behind it should be
associated with the IOMMU. Not just the bridge itself.

This fixes the device_to_iommu() function accordingly.

(It's broken if you have the same PCI bus numbers in multiple domains,
but this function was always broken in that way; I'll be dealing with
that later).

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

PCI quirk: disable MSI on VIA VT3364 chipsets

2009-05-08T22:45:04+00:00

commit 162dedd39dcc6eca3fc0d29cf19658c6c13b840e upstream.

Without this patch, Broadcom BCM5906 Ethernet controllers set up via MSI
cause the machine to hang.  Tejun agreed that the best is to blacklist
the whole chipset and after adding it, seeing the other VIA quirks
disabling MSI, this very much looks like the right way.

Cc: 
Signed-off-by: Thomas Renninger 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

PCI/x86: detect host bridge config space size w/o using quirks

2009-04-27T17:36:51+00:00

upstream commit: dfadd9edff498d767008edc6b2a6e86a7a19934d

Many host bridges support a 4k config space, so check them directy
instead of using quirks to add them.

We only need to do this extra check for host bridges at this point,
because only host bridges are known to have extended address space
without also having a PCI-X/PCI-E caps.  Other devices with this
property could be done with quirks (if there are any).

As a bonus, we can remove the quirks for AMD host bridges with family
10h and 11h since they're not needed any more.

With this patch, we can get correct pci cfg size of new Intel CPUs/IOHs
with host bridges.

Signed-off-by: Yinghai Lu 
Acked-by: H. Peter Anvin 
Reviewed-by: Matthew Wilcox 
Cc: 
Signed-off-by: Jesse Barnes 
Signed-off-by: Chris Wright

PCIe: portdrv: call pci_disable_device during remove

2009-03-12T19:42:35+00:00

The PCIe port driver calls pci_enable_device() during probe but
never calls pci_disable_device() during remove.

Cc: stable@kernel.org
Signed-off-by: Alex Chiang 
Signed-off-by: Matthew Wilcox

pci: Fix typo in message while disabling HT MSI mapping

2009-03-12T19:42:29+00:00

"Enabling" should read "Disabling"

Signed-off-by: Prakash Punnoor 
Signed-off-by: Matthew Wilcox