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

PCI: Unhide the SMBus on the Compaq Evo D510 USDT

2009-09-24T15:27:29+00:00

commit 6b5096e4d4496e185cd1ada5d1b8e1d941c805ed upstream.

One more form factor for Compaq Evo D510, which needs the same quirk
as the other form factors. Apparently there's no hardware monitoring
chip on that one, but SPD EEPROMs, so it's still worth unhiding the
SMBus.

Signed-off-by: Jean Delvare 
Tested-by: Nuzhna Pomoshch 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

PCI: apply nv_msi_ht_cap_quirk on resume too

2009-09-24T15:27:16+00:00

commit 6dab62ee5a3bf4f71b8320c09db2e6022a19f40e upstream.

http://bugzilla.kernel.org/show_bug.cgi?id=12542 reports that with the
quirk not applied on resume, msi stops working after resuming and mcp78s
ahci fails due to IRQ mis-delivery.  Apply it on resume too.

Signed-off-by: Tejun Heo 
Cc: Peer Chen 
Cc: Tj 
Reported-by: Nicolas Derive 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

PCI SR-IOV: correct broken resource alignment calculations

2009-09-15T17:45:27+00:00

commit 6faf17f6f1ffc586d16efc2f9fa2083a7785ee74 upstream.

An SR-IOV capable device includes an SR-IOV PCIe capability which
describes the Virtual Function (VF) BAR requirements.  A typical SR-IOV
device can support multiple VFs whose BARs must be in a contiguous region,
effectively an array of VF BARs.  The BAR reports the size requirement
for a single VF.  We calculate the full range needed by simply multiplying
the VF BAR size with the number of possible VFs and create a resource
spanning the full range.

This all seems sane enough except it artificially inflates the alignment
requirement for the VF BAR.  The VF BAR need only be aligned to the size
of a single BAR not the contiguous range of VF BARs.  This can cause us
to fail to allocate resources for the BAR despite the fact that we
actually have enough space.

This patch adds a thin PCI specific layer over the generic
resource_alignment() function which is aware of the special nature of
VF BARs and does sorting and allocation based on the smaller alignment
requirement.

I recognize that while resource_alignment is generic, it's basically a
PCI helper.  An alternative to this patch is to add PCI VF BAR specific
information to struct resource.  I opted for the extra layer rather than
adding such PCI specific information to struct resource.  This does
have the slight downside that we don't cache the BAR size and re-read
for each alignment query (happens a small handful of times during boot
for each VF BAR).

Signed-off-by: Chris Wright 
Cc: Ivan Kokshaysky 
Cc: Linus Torvalds 
Cc: Matthew Wilcox 
Cc: Yu Zhao 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

Fix iommu address space allocation

2009-07-20T03:38:55+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:50:31+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:50:31+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:49:31+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: use fixed-up device class when configuring device

2009-06-04T10:29:43+00:00

The device class may be changed after the fixup, so re-read the class
value from pci_dev when configuring the device.  Otherwise some devices
such as JMicron SATA controller won't work.

Reviewed-by: Matthew Wilcox 
Reviewed-by: Grant Grundler 
Tested-by: Marc Dionne 
Signed-off-by: Yu Zhao 
Signed-off-by: Jesse Barnes

PCI Hotplug: acpiphp: don't store a pci_dev in acpiphp_func

2009-05-27T09:04:24+00:00

An oops can occur if a user attempts to use both PCI logical
hotplug and the ACPI physical hotplug driver (acpiphp) in this
sequence, where $slot/address == $device.

In other words, if acpiphp has claimed a PCI device, and that
device is logically removed, then acpiphp may oops when it
attempts to access it again.

	# echo 1 > /sys/bus/pci/devices/$device/remove
	# echo 0 > /sys/bus/pci/slots/$slot/power

Unable to handle kernel NULL pointer dereference (address 0000000000000000)
Call Trace:
 [] show_stack+0x50/0xa0
 [] show_regs+0x820/0x860
 [] die+0x190/0x2a0
 [] ia64_do_page_fault+0x8e0/0xa40
 [] ia64_native_leave_kernel+0x0/0x270
 [] pci_remove_bus_device+0x120/0x260
 [] acpiphp_disable_slot+0x410/0x540 [acpiphp]
 [] disable_slot+0xc0/0x120 [acpiphp]
 [] power_write_file+0x1e0/0x2a0 [pci_hotplug]
 [] pci_slot_attr_store+0x60/0xa0
 [] sysfs_write_file+0x230/0x2c0
 [] vfs_write+0x190/0x2e0
 [] sys_write+0x80/0x100
 [] ia64_ret_from_syscall+0x0/0x20
 [] __kernel_syscall_via_break+0x0/0x20

The root cause of this oops is that the logical remove ("echo 1 >
/sys/bus/pci/devices/$device/remove") destroyed the pci_dev. The
pci_dev struct itself wasn't deallocated because acpiphp kept a
reference, but some of its fields became invalid.

acpiphp doesn't have any real reason to keep a pointer to a
pci_dev around. It can always derive it using pci_get_slot().

If a logical remove destroys the pci_dev, acpiphp won't find it
and is thus prevented from causing mischief.

Reviewed-by: Matthew Wilcox 
Reviewed-by: Kenji Kaneshige 
Tested-by: Kenji Kaneshige 
Reported-by: Kenji Kaneshige 
Acked-by: Bjorn Helgaas 
Signed-off-by: Alex Chiang 
Signed-off-by: Jesse Barnes

PCI PM: Fix initialization and kexec breakage for some devices

2009-05-19T22:26:07+00:00

Recent PCI PM changes introduced a bug that causes some devices to be
mishandled after kexec and during early initialization.  The failure
scenario in the kexec case is the following:

* Assume a PCI device is not power-manageable by the platform and has
  PCI_PM_CTRL_NO_SOFT_RESET set in PMCSR.
* The device is put into D3 before kexec (using the native PCI PM).
* After kexec, pci_setup_device() sets the device's power state to
  PCI_UNKNOWN.
* pci_set_power_state(dev, PCI_D0) is called by the device's driver.
* __pci_start_power_transition(dev, PCI_D0) is called and since the
  device is not power-manageable by the platform, it causes
  pci_update_current_state(dev, PCI_D0) to be called.  As a result
  the device's current_state field is updated to PCI_D3, in
  accordance with the contents of its PCI PM registers.
* pci_raw_set_power_state() is called and it changes the device power
  state to D0.  *However*, it should also call pci_restore_bars() to
  reinitialize the device, but it doesn't, because the device's
  current_state field has been modified earlier.

To prevent this from happening, modify pci_platform_power_transition()
so that it doesn't use pci_update_current_state() to update the
current_state field for devices that aren't power-manageable by the
platform.  Instead, this field should be updated directly for devices
that don't support the native PCI PM.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jesse Barnes