kernel/git/stable/linux-stable.git/drivers/pci, branch linux-2.6.39.y

mmc: Added quirks for Ricoh 1180:e823 lower base clock frequency

2011-08-03T19:42:42+00:00

commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 upstream. Ricoh 1180:e823 does not recognize certain types of SD/MMC cards, as reported at http://launchpad.net/bugs/773524. Lowering the SD base clock frequency from 200Mhz to 50Mhz fixes this issue. This solution was suggest by Koji Matsumuro, Ricoh Company, Ltd. This change has no negative performance effect on standard SD cards, though it's quite possible that there will be one on UHS-1 cards. Signed-off-by: Manoj Iyer Tested-by: Daniel Manrique Cc: Koji Matsumuro Acked-by: Jesse Barnes Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

PCI / PM: Block races between runtime PM and system sleep

2011-07-09T06:15:25+00:00

commit a5f76d5eba157bf637beb2dd18026db2917c512e upstream. After commit e8665002477f0278f84f898145b1f141ba26ee26 (PM: Allow pm_runtime_suspend() to succeed during system suspend) it is possible that a device resumed by the pm_runtime_resume(dev) in pci_pm_prepare() will be suspended immediately from a work item, timer function or otherwise, defeating the very purpose of calling pm_runtime_resume(dev) from there. To prevent that from happening it is necessary to increment the runtime PM usage counter of the device by replacing pm_runtime_resume() with pm_runtime_get_sync(). Moreover, the incremented runtime PM usage counter has to be decremented by the corresponding pci_pm_complete(), via pm_runtime_put_sync(). Signed-off-by: Rafael J. Wysocki Acked-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

mmc: Add PCI fixup quirks for Ricoh 1180:e823 reader

2011-07-09T06:15:12+00:00

commit be98ca652faa6468916a9b7608befff215a8ca70 upstream. Signed-off-by: Manoj Iyer Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

PCI: Set PCIE maxpayload for card during hotplug insertion

2011-06-23T22:05:34+00:00

commit e522a7126c7c144a1dd14c6f217ac31e71082b1d upstream. The following patch sets the MaxPayload setting to match the parent reading when inserting a PCIE card into a hotplug slot. On our system, the upstream bridge is set to 256, but when inserting a card, the card setting defaults to 128. As soon as I/O is performed to the card it starts receiving errors since the payload size is too small. Reviewed-by: Kenji Kaneshige Signed-off-by: Jordan Hargrave Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

intel-iommu: Add domain check in domain_remove_one_dev_info

2011-06-23T22:05:31+00:00

commit 8519dc4401ddf8a5399f979870bbeeadbc111186 upstream. The comment in domain_remove_one_dev_info() states "No need to compare PCI domain; it has to be the same". But for the si_domain that isn't going to be true, as it consists of all the PCI devices that are identity mapped thus multiple PCI domains can be in si_domain. The code needs to validate the PCI domain too. Signed-off-by: Mike Habeck Signed-off-by: Mike Travis Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

intel-iommu: Remove Host Bridge devices from identity mapping

2011-06-23T22:05:31+00:00

commit 825507d6d059f1cbe2503e0e5a3926225b983aec upstream. When using the 1:1 (identity) PCI DMA remapping, PCI Host Bridge devices that do not use the IOMMU causes a kernel panic. Fix that by not inserting those devices into the si_domain. Signed-off-by: Mike Travis Reviewed-by: Mike Habeck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

intel-iommu: Use coherent DMA mask when requested

2011-06-23T22:05:31+00:00

commit c681d0ba1252954208220ad32248a3e8e2fc98e4 upstream. The __intel_map_single function is not honoring the passed in DMA mask. This results in not using the coherent DMA mask when called from intel_alloc_coherent(). Signed-off-by: Mike Travis Acked-by: Chris Wright Reviewed-by: Mike Habeck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

intel-iommu: Dont cache iova above 32bit

2011-06-23T22:05:31+00:00

commit 1c9fc3d11b84fbd0c4f4aa7855702c2a1f098ebb upstream. Mike Travis and Mike Habeck reported an issue where iova allocation would return a range that was larger than a device's dma mask. https://lkml.org/lkml/2011/3/29/423 The dmar initialization code will reserve all PCI MMIO regions and copy those reservations into a domain specific iova tree. It is possible for one of those regions to be above the dma mask of a device. It is typical to allocate iovas with a 32bit mask (despite device's dma mask possibly being larger) and cache the result until it exhausts the lower 32bit address space. Freeing the iova range that is >= the last iova in the lower 32bit range when there is still an iova above the 32bit range will corrupt the cached iova by pointing it to a region that is above 32bit. If that region is also larger than the device's dma mask, a subsequent allocation will return an unusable iova and cause dma failure. Simply don't cache an iova that is above the 32bit caching boundary. Reported-by: Mike Travis Reported-by: Mike Habeck Acked-by: Mike Travis Tested-by: Mike Habeck Signed-off-by: Chris Wright Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

intel-iommu: Speed up processing of the identity_mapping function

2011-06-23T22:05:31+00:00

commit cb452a4040bb051d92e85d6e7eb60c11734c1781 upstream. When there are a large count of PCI devices, and the pass through option for iommu is set, much time is spent in the identity_mapping function hunting though the iommu domains to check if a specific device is "identity mapped". Speed up the function by checking the cached info to see if it's mapped to the static identity domain. Signed-off-by: Mike Travis Reviewed-by: Mike Habeck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

intel-iommu: Check for identity mapping candidate using system dma mask

2011-06-23T22:05:31+00:00

commit 8fcc5372fbac085199d84a880503ed67aba3fe49 upstream. The identity mapping code appears to make the assumption that if the devices dma_mask is greater than 32bits the device can use identity mapping. But that is not true: take the case where we have a 40bit device in a 44bit architecture. The device can potentially receive a physical address that it will truncate and cause incorrect addresses to be used. Instead check to see if the device's dma_mask is large enough to address the system's dma_mask. Signed-off-by: Mike Travis Reviewed-by: Mike Habeck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman