linux-toradex.git/drivers/pci, branch v3.0.71

PCI/PM: Clean up PME state when removing a device

2013-02-17T18:46:20+00:00

commit 249bfb83cf8ba658955f0245ac3981d941f746ee upstream.

Devices are added to pci_pme_list when drivers use pci_enable_wake()
or pci_wake_from_d3(), but they aren't removed from the list unless
the driver explicitly disables wakeup.  Many drivers never disable
wakeup, so their devices remain on the list even after they are
removed, e.g., via hotplug.  A subsequent PME poll will oops when
it tries to touch the device.

This patch disables PME# on a device before removing it, which removes
the device from pci_pme_list.  This is safe even if the device never
had PME# enabled.

This oops can be triggered by unplugging a Thunderbolt ethernet adapter
on a Macbook Pro, as reported by Daniel below.

[bhelgaas: changelog]
Reference: http://lkml.kernel.org/r/CAMVG2svG21yiM1wkH4_2pen2n+cr2-Zv7TbH3Gj+8MwevZjDbw@mail.gmail.com
Reported-and-tested-by: Daniel J Blueman 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported

2013-01-28T04:46:28+00:00

commit 9e16721498b0c3d3ebfa0b503c63d35c0a4c0642 upstream.

Right now using pcie_aspm=force will not enable ASPM if the FADT indicates
ASPM is unsupported.  However, the semantics of force should probably allow
for this, especially as they did before 3c076351c4 ("PCI: Rework ASPM
disable code")

This patch just skips the clearing of any ASPM setup that the firmware has
carried out on this bus if pcie_aspm=force is being used.

Reference: http://bugs.launchpad.net/bugs/962038
Signed-off-by: Colin Ian King 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Prevent devices with RMRRs from being placed into SI Domain

2013-01-21T19:44:59+00:00

commit ea2447f700cab264019b52e2b417d689e052dcfd upstream.

This patch is to prevent non-USB devices that have RMRRs associated with them from
being placed into the SI Domain during init. This fixes the issue where the RMRR info
for devices being placed in and out of the SI Domain gets lost.

Signed-off-by: Thomas Mingarelli 
Tested-by: Shuah Khan 
Reviewed-by: Donald Dutile 
Reviewed-by: Alex Williamson 
Signed-off-by: Joerg Roedel 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Free old page tables before creating superpage

2013-01-17T16:44:12+00:00

commit 6491d4d02893d9787ba67279595990217177b351 upstream.

The dma_pte_free_pagetable() function will only free a page table page
if it is asked to free the *entire* 2MiB range that it covers. So if a
page table page was used for one or more small mappings, it's likely to
end up still present in the page tables... but with no valid PTEs.

This was fine when we'd only be repopulating it with 4KiB PTEs anyway
but the same virtual address range can end up being reused for a
*large-page* mapping. And in that case were were trying to insert the
large page into the second-level page table, and getting a complaint
from the sanity check in __domain_mapping() because there was already a
corresponding entry. This was *relatively* harmless; it led to a memory
leak of the old page table page, but no other ill-effects.

Fix it by calling dma_pte_clear_range (hopefully redundant) and
dma_pte_free_pagetable() before setting up the new large page.

Signed-off-by: David Woodhouse 
Tested-by: Ravi Murty 
Tested-by: Sudeep Dutt 
Signed-off-by: Linus Torvalds 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz

2013-01-11T17:03:49+00:00

commit 812089e01b9f65f90fc8fc670d8cce72a0e01fbb upstream.

Otherwise it fails like this on cards like the Transcend 16GB SDHC card:

    mmc0: new SDHC card at address b368
    mmcblk0: mmc0:b368 SDC   15.0 GiB
    mmcblk0: error -110 sending status command, retrying
    mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0

Tested on my Lenovo x200 laptop.

[bhelgaas: changelog]
Signed-off-by: Andy Lutomirski 
Signed-off-by: Bjorn Helgaas 
Acked-by: Chris Ball 
CC: Manoj Iyer 
Signed-off-by: Greg Kroah-Hartman

PCI : Calculate right add_size

2012-11-26T19:34:57+00:00

commit a4ac9fea016fc5c09227eb479bd35e34978323a4 upstream.

During debug of one SRIOV enabled hotplug device, we found found that
add_size is not passed properly.

The device has devices under two level bridges:

 +-[0000:80]-+-00.0-[81-8f]--
 |           +-01.0-[90-9f]--
 |           +-02.0-[a0-af]----00.0-[a1-a3]--+-02.0-[a2]--+-00.0  Oracle Corporation Device
 |           |                               \-03.0-[a3]--+-00.0  Oracle Corporation Device

Which means later the parent bridge will not try to add a big enough range:

[  557.455077] pci 0000:a0:00.0: BAR 14: assigned [mem 0xf9000000-0xf93fffff]
[  557.461974] pci 0000:a0:00.0: BAR 15: assigned [mem 0xf6000000-0xf61fffff pref]
[  557.469340] pci 0000:a1:02.0: BAR 14: assigned [mem 0xf9000000-0xf91fffff]
[  557.476231] pci 0000:a1:02.0: BAR 15: assigned [mem 0xf6000000-0xf60fffff pref]
[  557.483582] pci 0000:a1:03.0: BAR 14: assigned [mem 0xf9200000-0xf93fffff]
[  557.490468] pci 0000:a1:03.0: BAR 15: assigned [mem 0xf6100000-0xf61fffff pref]
[  557.497833] pci 0000:a1:03.0: BAR 14: can't assign mem (size 0x200000)
[  557.504378] pci 0000:a1:03.0: failed to add optional resources res=[mem 0xf9200000-0xf93fffff]
[  557.513026] pci 0000:a1:02.0: BAR 14: can't assign mem (size 0x200000)
[  557.519578] pci 0000:a1:02.0: failed to add optional resources res=[mem 0xf9000000-0xf91fffff]

It turns out we did not calculate size1 properly.

static resource_size_t calculate_memsize(resource_size_t size,
                resource_size_t min_size,
                resource_size_t size1,
                resource_size_t old_size,
                resource_size_t align)
{
        if (size < min_size)
                size = min_size;
        if (old_size == 1 )
                old_size = 0;
        if (size < old_size)
                size = old_size;
        size = ALIGN(size + size1, align);
        return size;
}

We should not pass add_size with min_size in calculate_memsize since
that will make add_size not contribute final add_size.

So just pass add_size with size1 to calculate_memsize().

With this change, we should have chance to remove extra addon in
pci_reassign_resource.

Signed-off-by: Yinghai Lu 
Signed-off-by: Jesse Barnes 
Cc: Andrew Worsley 
Signed-off-by: Greg Kroah-Hartman

PCI : ability to relocate assigned pci-resources

2012-11-26T19:34:57+00:00

commit 2bbc6942273b5b3097bd265d82227bdd84b351b2 upstream.

Currently pci-bridges are allocated enough resources to satisfy their immediate
requirements.  Any additional resource-requests fail if additional free space,
contiguous to the one already allocated, is not available. This behavior is not
reasonable since sufficient contiguous resources, that can satisfy the request,
are available at a different location.

This patch provides the ability to expand and relocate a allocated resource.

	v2: Changelog: Fixed size calculation in pci_reassign_resource()
	v3: Changelog : Split this patch. The resource.c changes are already
			upstream. All the pci driver changes are in here.

Signed-off-by: Ram Pai 
Signed-off-by: Jesse Barnes 
Cc: Andrew Worsley 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Fix AB-BA lockdep report

2012-11-17T21:14:26+00:00

commit 3e7abe2556b583e87dabda3e0e6178a67b20d06f upstream.

When unbinding a device so that I could pass it through to a KVM VM, I
got the lockdep report below.  It looks like a legitimate lock
ordering problem:

 - domain_context_mapping_one() takes iommu->lock and calls
   iommu_support_dev_iotlb(), which takes device_domain_lock (inside
   iommu->lock).

 - domain_remove_one_dev_info() starts by taking device_domain_lock
   then takes iommu->lock inside it (near the end of the function).

So this is the classic AB-BA deadlock.  It looks like a safe fix is to
simply release device_domain_lock a bit earlier, since as far as I can
tell, it doesn't protect any of the stuff accessed at the end of
domain_remove_one_dev_info() anyway.

BTW, the use of device_domain_lock looks a bit unsafe to me... it's
at least not obvious to me why we aren't vulnerable to the race below:

  iommu_support_dev_iotlb()
                                          domain_remove_dev_info()

  lock device_domain_lock
    find info
  unlock device_domain_lock

                                          lock device_domain_lock
                                            find same info
                                          unlock device_domain_lock

                                          free_devinfo_mem(info)

  do stuff with info after it's free

However I don't understand the locking here well enough to know if
this is a real problem, let alone what the best fix is.

Anyway here's the full lockdep output that prompted all of this:

     =======================================================
     [ INFO: possible circular locking dependency detected ]
     2.6.39.1+ #1
     -------------------------------------------------------
     bash/13954 is trying to acquire lock:
      (&(&iommu->lock)->rlock){......}, at: [] domain_remove_one_dev_info+0x121/0x230

     but task is already holding lock:
      (device_domain_lock){-.-...}, at: [] domain_remove_one_dev_info+0x208/0x230

     which lock already depends on the new lock.

     the existing dependency chain (in reverse order) is:

     -> #1 (device_domain_lock){-.-...}:
            [] lock_acquire+0x9d/0x130
            [] _raw_spin_lock_irqsave+0x55/0xa0
            [] domain_context_mapping_one+0x600/0x750
            [] domain_context_mapping+0x3f/0x120
            [] iommu_prepare_identity_map+0x1c5/0x1e0
            [] intel_iommu_init+0x88e/0xb5e
            [] pci_iommu_init+0x16/0x41
            [] do_one_initcall+0x45/0x190
            [] kernel_init+0xe3/0x168
            [] kernel_thread_helper+0x4/0x10

     -> #0 (&(&iommu->lock)->rlock){......}:
            [] __lock_acquire+0x195e/0x1e10
            [] lock_acquire+0x9d/0x130
            [] _raw_spin_lock_irqsave+0x55/0xa0
            [] domain_remove_one_dev_info+0x121/0x230
            [] device_notifier+0x72/0x90
            [] notifier_call_chain+0x8c/0xc0
            [] __blocking_notifier_call_chain+0x78/0xb0
            [] blocking_notifier_call_chain+0x16/0x20
            [] __device_release_driver+0xbc/0xe0
            [] device_release_driver+0x2f/0x50
            [] driver_unbind+0xa3/0xc0
            [] drv_attr_store+0x2c/0x30
            [] sysfs_write_file+0xe6/0x170
            [] vfs_write+0xce/0x190
            [] sys_write+0x54/0xa0
            [] system_call_fastpath+0x16/0x1b

     other info that might help us debug this:

     6 locks held by bash/13954:
      #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x44/0x170
      #1:  (s_active#3){++++.+}, at: [] sysfs_write_file+0xcd/0x170
      #2:  (&__lockdep_no_validate__){+.+.+.}, at: [] driver_unbind+0x9b/0xc0
      #3:  (&__lockdep_no_validate__){+.+.+.}, at: [] device_release_driver+0x27/0x50
      #4:  (&(&priv->bus_notifier)->rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x5f/0xb0
      #5:  (device_domain_lock){-.-...}, at: [] domain_remove_one_dev_info+0x208/0x230

     stack backtrace:
     Pid: 13954, comm: bash Not tainted 2.6.39.1+ #1
     Call Trace:
      [] print_circular_bug+0xf7/0x100
      [] __lock_acquire+0x195e/0x1e10
      [] ? trace_hardirqs_off+0xd/0x10
      [] ? trace_hardirqs_on_caller+0x13d/0x180
      [] lock_acquire+0x9d/0x130
      [] ? domain_remove_one_dev_info+0x121/0x230
      [] _raw_spin_lock_irqsave+0x55/0xa0
      [] ? domain_remove_one_dev_info+0x121/0x230
      [] ? trace_hardirqs_off+0xd/0x10
      [] domain_remove_one_dev_info+0x121/0x230
      [] device_notifier+0x72/0x90
      [] notifier_call_chain+0x8c/0xc0
      [] __blocking_notifier_call_chain+0x78/0xb0
      [] blocking_notifier_call_chain+0x16/0x20
      [] __device_release_driver+0xbc/0xe0
      [] device_release_driver+0x2f/0x50
      [] driver_unbind+0xa3/0xc0
      [] drv_attr_store+0x2c/0x30
      [] sysfs_write_file+0xe6/0x170
      [] vfs_write+0xce/0x190
      [] sys_write+0x54/0xa0
      [] system_call_fastpath+0x16/0x1b

Signed-off-by: Roland Dreier 
Signed-off-by: David Woodhouse 
Cc: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

PCI: Check P2P bridge for invalid secondary/subordinate range

2012-10-12T20:28:09+00:00

commit 1965f66e7db08d1ebccd24a59043eba826cc1ce8 upstream.

For bridges with "secondary > subordinate", i.e., invalid bus number
apertures, we don't enumerate anything behind the bridge unless the
user specified "pci=assign-busses".

This patch makes us automatically try to reassign the downstream bus
numbers in this case (just for that bridge, not for all bridges as
"pci=assign-busses" does).

We don't discover all the devices on the Intel DP43BF motherboard
without this change (or "pci=assign-busses") because its BIOS configures
a bridge as:

    pci 0000:00:1e.0: PCI bridge to [bus 20-08] (subtractive decode)

[bhelgaas: changelog, change message to dev_info]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18412
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=625754
Reported-by: Brian C. Huffman 
Reported-by: VL 
Tested-by: VL 
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas

PCI: acpiphp: check whether _ADR evaluation succeeded

2012-10-12T20:28:03+00:00

commit dfb117b3e50c52c7b3416db4a4569224b8db80bb upstream.

Check whether we evaluated _ADR successfully.  Previously we ignored
failure, so we would have used garbage data from the stack as the device
and function number.

We return AE_OK so that we ignore only this slot and continue looking
for other slots.

Found by Coverity (CID 113981).

Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 2.6.32/3.0: adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman