aboutsummaryrefslogtreecommitdiff
path: root/arch/s390
diff options
context:
space:
mode:
authorrajesh.shah@intel.com <rajesh.shah@intel.com>2005-10-31 16:20:12 -0800
committerGreg Kroah-Hartman <gregkh@suse.de>2005-11-10 16:09:15 -0800
commita3a45ec8f8edaf088449e37fe81c99cbf580b9bd (patch)
treea6aaadb26ee068609b9520755e58a0fcdff588fd /arch/s390
parent427bf532b5ad6db5addc2bce675d13f874397c0c (diff)
[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 <rajesh.shah@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'arch/s390')
0 files changed, 0 insertions, 0 deletions