linux/drivers/pci/hotplug, branch v3.4-rc2

PCI: make acpihp use __pci_remove_bus_device instead

2012-02-27T20:17:16Z

pci_stop_bus_device gets called before in the same loop. Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes

PCI: Rename pci_remove_bus_device to pci_stop_and_remove_bus_device

2012-02-27T20:12:18Z

The old pci_remove_bus_device actually did stop and remove. Make the name reflect that to reduce confusion. This patch is done by sed scripts and changes back some incorrect __pci_remove_bus_device changes. Suggested-by: Jesse Barnes Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes

PCI hotplug: cpcihp: fix debug module parameter to be bool

2012-02-14T16:45:03Z

Fix debug variable from module parameter to be really bool to fix 'warning: return from incompatible pointer type'. Acked-by: Scott Murray Signed-off-by: Danny Kukawka Signed-off-by: Jesse Barnes

PCI: pciehp: Disable/enable link during slot power off/on

2012-02-14T16:45:02Z

On a system with a repeater on the system board to support gen2 hotplug, we found that when an ExpressModule is removed from some slots, /var/log/messages will be full of "card present/not present" warnings. It turns out the root complex is continually trying to train the link to the repeater because the repeater has not been reset. This patch will disable the link at removal time to allow the repeater to be reset properly. This also prevents a potential AER message at removal time. Also, when testing hotplug on a system under development, we found if we boot the system without an EM installed, and later hot-add an EM, it does not work with Linux, but another OS is ok. The root cause is that BIOS left link disabled when slot was empty at boot time, and other OS is modifying the link disable bit in link ctrl during power on/off. So we should do the same thing to disable/enable link during power off/on. -v2: check link DLLA bit instead of 100ms waiting. Separate link disable/enable functions to another patch. Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes

PCI: pciehp: Add Disable/enable link functions

2012-02-14T16:45:01Z

Will use it during power off/on of slots Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes

PCI: pciehp: Add pcie_wait_link_not_active()

2012-02-14T16:45:01Z

Will use it for link disable status checking. Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes

PCI: pciehp: make check_link_active more helpful

2012-02-14T16:45:00Z

A few changes: - remove the 'inline' and let the complier decide - return a bool to indicate whether the link was active - add a debug message to indicate link state when it beocmes active Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes

PCI: pciehp: replace unconditional sleep with config space access check

2012-02-14T16:45:00Z

During reviewing | PCI: pciehp: wait 1000 ms before Link Training check Linus said: >... > That's a *long* time, and it's irritating to the user. It makes the > user think "the machine is slow". >... > And quite frankly, an unconditional one-second delay here seems bad. >Two seconds was unacceptable, one second is just bad. Try to access the pci conf of a pci device that is supposed to show up in 1s. If we can read back a valid vendor/device id, we can return early. Related discussion could be found: https://lkml.org/lkml/2011/12/6/339 -v2: seperate code to pci_bus_read_dev_vendor_id() from pci_scan_device() and reuse it from pciehp code. Suggested by Matthew Wilcox. -v3: According to Kenj, don't use array in stack, and don't wait too long for crs, also return fail status if not found. Also separate pci_bus_dev_read_vendor_id() change to another patch. Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes

PCI: drivers/pci/hotplug/ibmphp_ebda.c: add missing iounmap

2012-02-14T16:44:47Z

Add missing iounmap in error handling code, in a case where the function already preforms iounmap on some other execution path. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression e; statement S,S1; int ret; @@ e = $ioremap\|ioremap_nocache$(...) ... when != iounmap(e) if (<+...e...+>) S ... when any when != iounmap(e) *if (...) { ... when != iounmap(e) return ...; } ... when any iounmap(e); // Signed-off-by: Julia Lawall Signed-off-by: Jesse Barnes

PCI: Can continually add funcs after adding func0

2012-02-14T16:44:47Z

Boot up a KVM guest, and hotplug multifunction devices(func1,func2,func0,func3) to guest. for i in 1 2 0 3;do qemu-img create /tmp/resize$i.qcow2 1G -f qcow2 (qemu) drive_add 0x11.$i id=drv11$i,if=none,file=/tmp/resize$i.qcow2 (qemu) device_add virtio-blk-pci,id=dev11$i,drive=drv11$i,addr=0x11.$i,multifunction=on done In linux kernel, when func0 of the slot is hot-added, the whole slot will be marked as 'enabled', then driver will ignore other new hotadded funcs. But in Win7 & WinXP, we can continaully add other funcs after adding func0, all funcs will be added in guest. drivers/pci/hotplug/acpiphp_glue.c: static int acpiphp_check_bridge(struct acpiphp_bridge *bridge) { .... for (slot = bridge->slots; slot; slot = slot->next) { if (slot->flags & SLOT_ENABLED) { acpiphp_disable_slot() else acpiphp_enable_slot() .... | } v enable_device() | v //only don't enable slot if func0 is not added list_for_each_entry(func, &slot->funcs, sibling) { ... } slot->flags |= SLOT_ENABLED; //mark slot to 'enabled' This patch just make pci driver can continaully add funcs after adding func 0. Only mark slot to 'enabled' when all funcs are added. For pci multifunction hotplug, we can add functions one by one(func 0 is necessary), and all functions will be removed in one time. Signed-off-by: Amos Kong Signed-off-by: Jesse Barnes