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

PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICH

2011-04-30T14:53:18+00:00

commit 87e3dc3855430bd254370afc79f2ed92250f5b7c upstream.

Some broken BIOSes on ICH4 chipset report an ACPI region which is in
conflict with legacy IDE ports when ACPI is disabled. Even though the
regions overlap, IDE ports are working correctly (we cannot find out
the decoding rules on chipsets).

So the only problem is the reported region itself, if we don't reserve
the region in the quirk everything works as expected.

This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO
which is 0x1000. Some regions might be (and are by a fast google
query) below this border, but the only difference is that they won't
be reserved anymore. They should still work though the same as before.

The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl):
pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io  0x0100-0x017f]

At 0x0100 a 128 bytes long ACPI region is reported in the quirk for
ICH4. ata_piix then fails to find disks because the IDE legacy ports
are zeroed:
ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007])

References: https://bugzilla.novell.com/show_bug.cgi?id=558740
Signed-off-by: Jiri Slaby 
Cc: Bjorn Helgaas 
Cc: "David S. Miller" 
Cc: Thomas Renninger 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

PCI: add more checking to ICH region quirks

2011-04-30T14:53:17+00:00

commit cdb9755849fbaf2bb9c0a009ba5baa817a0f152d upstream.

Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN
and GPIO_EN bits are set to 1. Add checks for these bits into the
quirks prior to the region creation.

While at it, name the constants by macros.

Signed-off-by: Jiri Slaby 
Cc: Bjorn Helgaas 
Cc: "David S. Miller" 
Cc: Thomas Renninger 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

PCI: disable MSI on VIA K8M800

2010-08-13T20:50:35+00:00

commit 549e15611b4ac1de51ef0e0a79c2704f50a638a2 upstream.

MSI delivery from on-board ahci controller doesn't work on K8M800.  At
this point, it's unclear whether the culprit is with the ahci
controller or the host bridge.  Given the track record and considering
the rather minimal impact of MSI, disabling it seems reasonable.

Signed-off-by: Tejun Heo 
Reported-by: Rainer Hurtado Navarro 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

Fix iommu address space allocation

2009-07-20T03:44:59+00:00

commit a15a519ed6e5e644f5a33c213c00b0c1d3cfe683 upstream.

This fixes kernel.org bug #13584. The IOVA code attempted to optimise
the insertion of new ranges into the rbtree, with the unfortunate result
that some ranges just didn't get inserted into the tree at all. Then
those ranges would be handed out more than once, and things kind of go
downhill from there.

Introduced after 2.6.25 by ddf02886cbe665d67ca750750196ea5bf524b10b
("PCI: iova RB tree setup tweak").

Signed-off-by: David Woodhouse 
Cc: mark gross 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

PCI PM: Follow PCI_PM_CTRL_NO_SOFT_RESET during transitions from D3

2009-07-02T23:32:00+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:31:59+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:31:34+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

PCI quirk: disable MSI on VIA VT3364 chipsets

2009-05-08T21:54:35+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

PCIe: portdrv: call pci_disable_device during remove

2009-03-17T00:52:56+00:00

commit d89987193631bf23d1735c55d13a06d4b8d0e9bd upstream.

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

Signed-off-by: Alex Chiang 
Signed-off-by: Matthew Wilcox 
Signed-off-by: Greg Kroah-Hartman

PCI: Enable PCIe AER only after checking firmware support

2009-03-17T00:52:56+00:00

commit 1f9f13c8d59c1d8da1a602b71d1ab96d1d37d69e upstream.

The PCIe port driver currently sets the PCIe AER error reporting bits for
any root or switch port without first checking to see if firmware will grant
control. This patch moves setting these bits to the AER service driver
aer_enable_port routine.  The bits are then set for the root port and any
downstream switch ports after the check for firmware support (aer_osc_setup)
is made. The patch also unsets the bits in a similar fashion when the AER
service driver is unloaded.

Reviewed-by: Alex Chiang 
Signed-off-by: Andrew Patterson 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman