From a3a45ec8f8edaf088449e37fe81c99cbf580b9bd Mon Sep 17 00:00:00 2001 From: "rajesh.shah@intel.com" Date: Mon, 31 Oct 2005 16:20:12 -0800 Subject: [PATCH] pciehp: clean-up how we request control of hotplug hardware This patch further tweaks how we request control of hotplug controller hardware from BIOS. We first search the ACPI namespace corresponding to a specific hotplug controller looking for an _OSC or OSHP method. On failure, we successively move to the ACPI parent object, till we hit the highest level host bridge in the hierarchy. This allows for different types of BIOS's which place the _OSC/OSHP methods at various places in the acpi namespace, while still not encroaching on the namespace of some other root level host bridge. This patch also introduces a new load time option (pciehp_force) that allows us to bypass all _OSC/OSHP checking. Not supporting these methods seems to be be the most common ACPI firmware problem we've run into. This will still _not_ allow the pciehp driver to work correctly if the BIOS really doesn't support pciehp (i.e. if it doesn't generate a hotplug interrupt). Use this option with caution. Some BIOS's may deliberately not build any _OSC/OSHP methods to make sure it retains control the hotplug hardware. Using the pciehp_force parameter for such systems can lead to two separate entities trying to control the same hardware. Signed-off-by: Rajesh Shah Signed-off-by: Greg Kroah-Hartman --- drivers/acpi/glue.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/acpi/glue.c') diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index 3937adf4e5e..aa993715d64 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -203,6 +203,7 @@ acpi_handle acpi_get_pci_rootbridge_handle(unsigned int seg, unsigned int bus) acpi_get_devices(PCI_ROOT_HID_STRING, find_pci_rootbridge, &find, NULL); return find.handle; } +EXPORT_SYMBOL_GPL(acpi_get_pci_rootbridge_handle); /* Get device's handler per its address under its parent */ struct acpi_find_child { -- cgit v1.2.3-18-g5258