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

PCI hotplug: acpiphp should be linked after vendor drivers

2009-11-04T16:47:14Z

As a followup to 71a082efc9fdc12068a3cee6cebb1330b00ebeee, it's conceivable that some vendors may expose PCI hotplug functionality through both vendor mechanisms and ACPI. The native mechanism will generally be a superset of any functionality provided via ACPI, so the acpiphp driver should always be initialised after any others. Change the link order such that acpiphp will not be initialised until any other statically linked drivers have had an opportunity to claim the hardware. Signed-off-by: Matthew Garrett Signed-off-by: Jesse Barnes

PCI hotplug: add pci_configure_slot()

2009-09-15T00:39:05Z

This patch adds a new pci_configure_slot() function that programs the PCI bus characteristics for a newly-added device. This is based on code in pciehp_pci.c, but should be generic enough to be used by pciehp, shpchp, and acpiphp. The hotplug_params struct and the program_hpp_typeX() functions are based on the ACPI definitions, but they aren't really ACPI-specific, and there's no alternate implementation, so I don't see the need to abstract them yet. Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Chiang Reviewed-by: Kenji Kaneshige Acked-by: Kenji Kaneshige Signed-off-by: Jesse Barnes

PCI hotplug: Change link order of pciehp & acpiphp

2009-01-27T23:35:51Z

Some hardware exposes PCIE slots in such a way that they can be claimed by either the acpiphp or pciehp driver. pciehp is the preferred driver if the firmware allows the OS to claim control via the _OSC method so should be loaded first - if it fails to bind (either due to a missing _OSC method or the firmware refusing to hand off control) then we can fall back to acpiphp or a vendor-specific driver. This patch simply changes the link order to ensure that pciehp will be initialised before acpiphp if both are statically built into the kernel. Signed-off-by: Matthew Garrett Acked-by: Randy Dunlap Signed-off-by: Jesse Barnes

PCI: pciehp: add ACPI based slot detection

2009-01-07T19:13:10Z

There is a problem that some non hot-pluggable PCIe slots are detected as hot-pluggable by pciehp on some platforms. The immediate cause of this problem is that hot-plug capable bit in the Slot Capabilities register is set even for non hot-pluggable slots on those platforms. It seems a BIOS/hardware problem, but we need workaround about that. Some of those platforms define hot-pluggable PCIe slots on ACPI namespace properly, while hot-plug capable bit in the Slot Capabilities register is set improperly. So using ACPI namespace information in pciehp to detect PCIe hot-pluggable slots would be a workaround. This patch adds 'pciehp_detect_mode' module option. When 'acpi' is specified, pciehp uses ACPI namespace information to detect PCIe hot-pluggable slots. Signed-off-by: Kenji Kaneshige Signed-off-by: Jesse Barnes

PCI: hotplug: Link fakephp last

2008-02-01T23:04:20Z

Currently, fakephp will claim all devices; we really only want it to claim those not in slots. Signed-off-by: Alex Chiang Signed-off-by: Matthew Wilcox Signed-off-by: Kristen Carlson Accardi Signed-off-by: Greg Kroah-Hartman

ACPIPHP: use ACPI dock driver

2006-06-28T07:08:06Z

Modify the acpiphp driver to use the ACPI dock driver for dock notifications. Only load the acpiphp driver if we find we have pci dock devices. Signed-off-by: Kristen Carlson Accardi Signed-off-by: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Len Brown

[PATCH] PCI Hotplug: add common acpi functions to core

2006-03-23T22:35:17Z

shpchprm_acpi.c and pciehprm_acpi.c are nearly identical. In addition, there are functions in both these files that are also in acpiphp_glue.c. This patch will remove duplicate functions from shpchp, pciehp, and acpiphp and move this functionality to pci_hotplug, as it is not hardware specific. Get rid of shpchprm* and pciehprm* files since they are no longer needed. shpchprm_nonacpi.c and pciehprm_nonacpi.c are identical, as well as shpchprm_legacy.c and can be replaced with a macro. This patch also changes acpiphp to use the common hpp code. Signed-off-by: Kristen Carlson Accardi Signed-off-by: Greg Kroah-Hartman

[PATCH] acpiphp: add dock event handling

2006-03-23T22:35:15Z

These patches add generic dock event handling to acpiphp. If there are pci devices that need to be inserted/removed after the dock event, the event notification will be handed down to the normal pci hotplug event handler in acpiphp so that new bridges/devices can be enumerated. Because some dock stations do not have pci bridges or pci devices that need to be inserted after a dock, acpiphp will remain loaded to handle dock events even if no hotpluggable pci slots are discovered. You probably need to have the pci=assign-busses kernel parameter enabled to use these patches, and you may not allow ibm_acpi to handle docking notifications and use this patch. This patch incorporates feedback provided by many. Signed-off-by: Kristen Carlson Accardi Signed-off-by: Greg Kroah-Hartman

[PATCH] PCI Hotplug: rpaphp: Move VIO registration

2005-09-08T21:57:22Z

Currently, rpaphp registers Virtual I/O slots as hotplug slots. The only purpose of this registration is to ensure that the VIO subsystem is notified of new VIO buses during DLPAR adds. Similarly, rpaphp notifies the VIO subsystem when a VIO bus is DLPAR-removed. The rpaphp module has special case code to fake results for attributes like power, adapter status, etc. The VIO register/unregister functions could just as easily be made from the DLPAR module. This patch moves the VIO registration calls to the DLPAR module, and removes the VIO fluff from rpaphp altogether. Signed-off-by: John Rose Signed-off-by: Greg Kroah-Hartman

[ACPI] delete CONFIG_ACPI_BUS

2005-08-24T16:11:34Z

it is a synonym for CONFIG_ACPI Signed-off-by: Len Brown