kernel/linux.git/drivers/pci, branch linux-2.6.35.y

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

2011-08-01T20:55:00+00:00

[ upstream commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 ] frequency 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 Cc: Acked-by: Jesse Barnes Signed-off-by: Chris Ball Signed-off-by: Andi Kleen

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

2011-08-01T20:55:00+00:00

[ upstream commit be98ca652faa6468916a9b7608befff215a8ca70 ] Signed-off-by: Manoj Iyer Cc: Signed-off-by: Chris Ball Signed-off-by: Andi Kleen

PCI: Set PCIE maxpayload for card during hotplug insertion

2011-08-01T20:54:54+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 Signed-off-by: Andi Kleen

PCI: Add quirk for setting valid class for TI816X Endpoint

2011-08-01T20:54:54+00:00

commit 63c4408074cbcc070ac17fc10e524800eb9bd0b0 upstream. TI816X (common name for DM816x/C6A816x/AM389x family) devices configured to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus code to skip allocating BARs to these devices resulting into following type of error when trying to enable them: "Device 0000:01:00.0 not available because of resource collisions" The device cannot be operated because of the above issue. This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based) 'early' fixup quirk to replace class code with PCI_CLASS_MULTIMEDIA_VIDEO as class. Signed-off-by: Hemant Pedanekar Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

intel-iommu: Fix use after release during device attach

2011-04-28T15:21:15+00:00

upstream commit 7a6610139a Obtain the new pgd pointer before releasing the page containing this value. Cc: stable@kernel.org Signed-off-by: Jan Kiszka Signed-off-by: Andi Kleen Reviewed-by: Sheng Yang Signed-off-by: David Woodhouse

Revert "intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hang"

2011-04-28T15:21:14+00:00

This reverts commit 05f7676dc3559c2b9061fda4e44c085a8d32fb05. To quote Len Brown: intel_idle was deemed a "feature", and thus not included in 2.6.33.stable, and thus 2.6.33.stable does not need this patch. so I'm removing it. Cc: Len Brown Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

intel-iommu: Fix get_domain_for_dev() error path

2011-04-28T15:21:11+00:00

commit 2fe9723df8e45fd247782adea244a5e653c30bf4 upstream. If we run out of domain_ids and fail iommu_attach_domain(), we fall into domain_exit() without having setup enough of the domain structure for this to do anything useful. In fact, it typically runs off into the weeds walking the bogus domain->devices list. Just free the domain. Signed-off-by: Alex Williamson Acked-by: Donald Dutile Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

intel-iommu: Unlink domain from iommu

2011-04-28T15:21:11+00:00

commit a97590e56d0d58e1dd262353f7cbd84e81d8e600 upstream. When we remove a device, we unlink the iommu from the domain, but we never do the reverse unlinking of the domain from the iommu. This means that we never clear iommu->domain_ids, eventually leading to resource exhaustion if we repeatedly bind and unbind a device to a driver. Also free empty domains to avoid a resource leak. Signed-off-by: Alex Williamson Acked-by: Donald Dutile Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

PCI hotplug: acpiphp: set current_state to D0 in register_slot

2011-03-31T18:58:44+00:00

commit 47e9037ac16637cd7f12b8790ea7ce6680e42168 upstream. If a device doesn't support power management (pm_cap == 0) but it is acpi_pci_power_manageable() because there is a _PS0 method declared for it and _EJ0 is also declared for the slot then nobody is going to set current_state = PCI_D0 for this device. This is what I think it is happening: pci_enable_device | __pci_enable_device_flags /* here we do not set current_state because !pm_cap */ | do_pci_enable_device | pci_set_power_state | __pci_start_power_transition | pci_platform_power_transition /* platform_pci_power_manageable() calls acpi_pci_power_manageable that * returns true */ | platform_pci_set_power_state /* acpi_pci_set_power_state gets called and does nothing because the * acpi device has _EJ0, see the comment "If the ACPI device has _EJ0, * ignore the device" */ at this point if we refer to the commit message that introduced the comment above (10b3dcae0f275e2546e55303d64ddbb58cec7599), it is up to the hotplug driver to set the state to D0. However AFAICT the pci hotplug driver never does, in fact drivers/pci/hotplug/acpiphp_glue.c:register_slot sets the slot flags to (SLOT_ENABLED | SLOT_POWEREDON) but it does not set the pci device current state to PCI_D0. So my proposed fix is also to set current_state = PCI_D0 in register_slot. Comments are very welcome. Signed-off-by: Stefano Stabellini Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

PCI: sysfs: Fix failure path for addition of "vpd" attribute

2011-03-31T18:58:40+00:00

commit 0f12a4e29368a9476076515881d9ef4e5876c6e2 upstream. Commit 280c73d ("PCI: centralize the capabilities code in pci-sysfs.c") changed the initialisation of the "rom" and "vpd" attributes, and made the failure path for the "vpd" attribute incorrect. We must free the new attribute structure (attr), but instead we currently free dev->vpd->attr. That will normally be NULL, resulting in a memory leak, but it might be a stale pointer, resulting in a double-free. Found by inspection; compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen