linux-toradex.git/drivers/pci, branch v2.6.30.5

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

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6

2009-05-15T23:47:55+00:00

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
  PCI MSI: Fix MSI-X with NIU cards
  PCI: Fix pci-e port driver slot_reset bad default return value

PCI MSI: Fix MSI-X with NIU cards

2009-05-12T00:02:27+00:00

The NIU device refuses to allow accesses to MSI-X registers before MSI-X
is enabled.  This patch fixes the problem by moving the read of the mask
register to after MSI-X is enabled.

Reported-by: David S. Miller 
Tested-by: David S. Miller 
Reviewed-by: David S. Miller 
Signed-off-by: Matthew Wilcox 
Signed-off-by: Jesse Barnes

intel-iommu: PAE memory corruption fix

2009-05-11T14:51:01+00:00

PAGE_MASK is 0xFFFFF000 on i386 -- even with PAE.

So it's not sufficient to ensure that you use phys_addr_t or uint64_t
everywhere you handle physical addresses -- you also have to avoid using
the construct 'addr & PAGE_MASK', because that will strip the high 32
bits of the address.

This patch avoids that problem by using PHYSICAL_PAGE_MASK instead of
PAGE_MASK where appropriate. It leaves '& PAGE_MASK' in a few instances
that don't matter -- where it's being used on the virtual bus addresses
we're dishing out, which are 32-bit anyway.

Since PHYSICAL_PAGE_MASK is not present on other architectures, we have
to define it (to PAGE_MASK) if it's not already defined.

Maybe it would be better just to fix PAGE_MASK for i386/PAE?

Signed-off-by: David Woodhouse 
Signed-off-by: Linus Torvalds