summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/glue.c
AgeCommit message (Collapse)Author
2005-11-10[PATCH] pciehp: clean-up how we request control of hotplug hardwarerajesh.shah@intel.com
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>
2005-10-19[PATCH] `unaligned access' in acpi get_root_bridge_busnr()Peter Chubb
In drivers/acpi/glue.c the address of an integer is cast to the address of an unsigned long. This breaks on systems where a long is larger than an int --- for a start the int can be misaligned; for a second the assignment through the pointer will overwrite part of the next variable. Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au> Acked-by: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-12[ACPI] don't complain about PCI root bridges without _SEGBjorn Helgaas
There are lots of single-PCI-segment machines that don't supply _SEG for the root bridges. The PCI root bridge driver silently assumes the segment to be zero in this case, so glue.c shouldn't complain either. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05[ACPI] Lindent all ACPI filesLen Brown
Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-12[ACPI] quiet dmesg related to ACPI PM of PCI devicesDavid Shaohua Li
DBG("No ACPI bus support for %s\n", dev->bus_id); http://bugzilla.kernel.org/show_bug.cgi?id=4277 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-11[ACPI] Bind PCI devices with ACPI devicesDavid Shaohua Li
Implement the framework for binding physical devices with ACPI devices. A physical bus like PCI bus should create a 'acpi_bus_type', with: .find_device: For device which has parent such as normal PCI devices. .find_bridge: It's for special devices, such as PCI root bridge or IDE controller. Such devices generally haven't a parent or ->bus. We use the special method to get an ACPI handle. Uses new field in struct device: firmware_data http://bugzilla.kernel.org/show_bug.cgi?id=4277 Signed-off-by: David Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>