summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/bus.c
Commit message (Collapse)AuthorAgeFilesLines
*-. Merge branches 'battery-2.6.34', 'bugzilla-10805', 'bugzilla-14668', ↵Len Brown2010-03-141-6/+11
|\ \ | | | | | | | | | 'bugzilla-531916-power-state', 'ht-warn-2.6.34', 'pnp', 'processor-rename', 'sony-2.6.34', 'suse-bugzilla-531547', 'tz-check', 'video' and 'misc-2.6.34' into release
| | * ACPI: Disable explicit power state retrieval on fansZhang Rui2009-12-281-5/+5
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the ACPI power state can be got both directly and indirectly, we prefer to get it indirectly. https://bugzilla.redhat.com/show_bug.cgi?id=531916 describes a system with a _PSC method for the fan that always returns "on". There's no benefit in us always requesting the state of the fan when performing transitions - we want to do everything we can to ensure that the fan turns on when it should do, not risk hardware damage by believing the hardware when it tells us the fan is already on. Given that the Leading Other OS(tm) works fine on this machine, it seems likely that it behaves in much this way. inspired-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: Advertise to BIOS in _OSC: _OST on _PPC changesZhao Yakui2010-01-151-1/+6
|/ | | | | | | | | | | | | If the BIOS pokes the system-wide OSC bits to see if Linux supports evaluating _OST after a _PPC change notification, answer yes. Also, fix an oversight where we neglected to set the OSC bit advertising processor aggregator device support when acpi-pad is compiled as a module. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
*-. Merge branches 'bugzilla-14446', 'bugzilla-14753' and 'bugzilla-14824' into ↵Len Brown2009-12-241-0/+2
|\ \ | | | | | | | | | release
| | * ACPI: processor: call _PDC earlyAlex Chiang2009-12-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We discovered that at least one machine (HP Envy), methods in the DSDT attempt to call external methods defined in a dynamically loaded SSDT. Unfortunately, the DSDT methods we are trying to call are part of the EC initialization, which happens very early, and the the dynamic SSDT is only loaded when a processor _PDC method runs much later. This results in namespace lookup errors for the (as of yet) undefined methods. Since Windows doesn't have any issues with this machine, we take it as a hint that they must be evaluating _PDC much earlier than we are. Thus, the proper thing for Linux to do should be to match the Windows implementation more closely. Provide a mechanism to call _PDC before we enable the EC. Doing so loads the dynamic tables, and allows the EC to be enabled correctly. The ACPI processor driver will still evaluate _PDC in its .add() method to cover the hotplug case. Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824 Cc: ming.m.lin@intel.com Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | ACPI: fix OSC regression that caused aer and pciehp not to loadShaohua Li2009-12-231-8/+18
| |/ |/| | | | | | | | | | | | | | | | | | | Executing _OSC returns a buffer, which has an acpi object in it. Don't directly returns the buffer, instead, we return the acpi object's buffer. This fixes a regression since caller of acpi_run_osc expects an acpi object's buffer returned. Tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: Add platform-wide _OSC support.Shaohua Li2009-12-161-0/+26
| | | | | | | | | | Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: Add a generic API for _OSC -v2Shaohua Li2009-12-161-0/+122
|/ | | | | | | | | | | | v2->v1: .improve debug info as suggedted by Bjorn,Kenji .API is using uuid string as suggested by Alexey Add an API to execute _OSC. A lot of devices can have this method, so add a generic API. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: add acpi_bus_get_status_handle()Bjorn Helgaas2009-09-251-27/+22
| | | | | | | | | | | | Add acpi_bus_get_status_handle() so we can get the status of a namespace object before building a struct acpi_device. This removes a use of "device->flags.dynamic_status", a cached indicator of whether _STA exists. It seems simpler and more reliable to just evaluate _STA and catch AE_NOT_FOUND errors. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'misc-2.6.32' into releaseLen Brown2009-09-191-0/+1
|\ | | | | | | | | | | | | Conflicts: drivers/pci/dmar.c Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: linux/acpi.h should not include linux/dmi.hLen Brown2009-09-191-0/+1
| | | | | | | | | | | | users of acpi.h that need dmi.h should include it directly. Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPICA: Fix several acpi_attach_data problemsBob Moore2009-08-271-1/+1
|/ | | | | | | | | | | | | Handler was never invoked. Now invoked if/when host node is deleted. Data object was not automatically deleted when host node was deleted. Interface to handler had an unused parameter, removed it. ACPICA BZ 778. http://acpica.org/bugzilla/show_bug.cgi?id=778 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: use handle, not device, in system notification pathBjorn Helgaas2009-06-181-15/+15
| | | | | | | | | | | | | | This patch changes the global system notification path so it uses the acpi_handle, not the acpi_device. System notifications often deal with device presence and status change. In these cases, we may not have an acpi_device. For example, we may get a Device Check notification on an object that previously was not present. Since the object was not present, we would not have had an acpi_device for it. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: remove unused return values from Bus Check & Device Check handlingBjorn Helgaas2009-06-181-21/+11
| | | | | | | | Remove return values from acpi_bus_check_device() and acpi_bus_check_scope() since nobody looks at them. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: remove unused "status_changed" return value from Check Device handlingBjorn Helgaas2009-06-181-19/+3
| | | | | | | | Remove "status_changed" return from acpi_bus_check_device(). Nobody does anything useful based on its value. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: simplify notification debug messagesBjorn Helgaas2009-06-181-24/+3
| | | | | | | | | | This replaces several messages that depend on the acpi_device struct with a single message that uses just the acpi_handle. We should be able to deal with notifications to objects that do not yet have an acpi_device struct. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: allow drivers to request both device and system notify eventsBjorn Helgaas2009-06-181-1/+5
| | | | | | | | | | | | | | | System notify events (0x00-0x7f) are common across all device types and should be handled in Linux/ACPI, not in drivers. However, some BIOSes use system notify events in device-specific ways that require the driver to be involved. This patch adds a ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag. When a driver sets this flag and supplies a .notify method, Linux/ACPI calls the .notify method for ALL notify events on the device, not just the device-specific (0x80-0xff) events. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: power: update error messageLen Brown2009-05-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | "Transitioning device [%s] to D%d" is not correct. We print this line when we attempted to transition the device, and it failed. So instead, print "Device [%s] failed to transition to D%d\n" This can happen under two conditions: 1. acpi_power_transition() fails when trying to handle the _ON/_OFF for associated power resource. 2. acpi_evaluate_object() on the explicit _PS0/_PS3 for that actual device could fail. this change clarifies, but doesn't fix http://bugzilla.kernel.org/show_bug.cgi?id=13243 Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'bjorn-initcall-cleanup' into releaseLen Brown2009-04-051-0/+15
|\
| * ACPI: call acpi_wakeup_device_init() explicitly rather than as initcallBjorn Helgaas2009-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes acpi_init() call acpi_wakeup_device_init() directly. Previously, acpi_wakeup_device_init() was a late_initcall (sequence 7). acpi_wakeup_device_init() depends on acpi_wakeup_device_list, which is populated when ACPI devices are enumerated by acpi_init() -> acpi_scan_init(). Using late_initcall is certainly enough to make sure acpi_wakeup_device_list is populated, but it is more than necessary. We can just as easily call acpi_wakeup_device_init() directly from acpi_init(), which avoids the initcall magic. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Li Shaohua <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: call acpi_sleep_proc_init() explicitly rather than as initcallBjorn Helgaas2009-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes acpi_init() call acpi_sleep_proc_init() directly. Previously, acpi_sleep_proc_init() was a late_initcall (sequence 7), apparently to make sure that the /proc hierarchy already exists: 2003/02/13 12:38:03-06:00 mochel acpi sleep: demote sleep proc file creation. - Make acpi_sleep_proc_init() a late_initcall(), and not called from acpi_sleep_init(). This guarantees that the acpi proc hierarchy is at least there when we create the dang file. This should no longer be an issue because acpi_bus_init() (called early in acpi_init()) creates acpi_root_dir (/proc/acpi). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: call init_acpi_device_notify() explicitly rather than as initcallBjorn Helgaas2009-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes acpi_init() call init_acpi_device_notify() directly. Previously, init_acpi_device_notify() was an arch_initcall (sequence 3), so it was called before acpi_init() (a subsys_initcall at sequence 4). init_acpi_device_notify() sets the platform_notify and platform_notify_remove function pointers. These pointers are not used until acpi_init() enumerates ACPI devices in this path: acpi_init() acpi_scan_init() acpi_bus_scan() acpi_add_single_object() acpi_device_register() device_add() <use platform_notify> So it is sufficient to have acpi_init() call init_acpi_device_notify() directly before it enumerates devices. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: call acpi_debug_init() explicitly rather than as initcallBjorn Helgaas2009-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | This patch makes acpi_init() call acpi_debug_init() directly. Previously, both were subsys_initcalls. acpi_debug_init() must happen after acpi_init(), and it's better to call it explicitly rather than rely on link ordering. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: call acpi_system_init() explicitly rather than as initcallBjorn Helgaas2009-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | This patch makes acpi_init() call acpi_system_init() directly. Previously, both were subsys_initcalls. acpi_system_init() must happen after acpi_init(), and it's better to call it explicitly rather than rely on link ordering. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: call acpi_power_init() explicitly rather than as initcallBjorn Helgaas2009-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | This patch makes acpi_init() call acpi_power_init() directly. Previously, both were subsys_initcalls. acpi_power_init() must happen after acpi_init(), and it's better to call it explicitly rather than rely on link ordering. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: call acpi_ec_init() explicitly rather than as initcallBjorn Helgaas2009-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | This patch makes acpi_init() call acpi_ec_init() directly. Previously, both were subsys_initcalls. acpi_ec_init() must happen after acpi_init(), and it's better to call it explicitly rather than rely on link ordering. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: call acpi_scan_init() explicitly rather than as initcallBjorn Helgaas2009-03-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes acpi_init() call acpi_scan_init() directly. Previously, both acpi_init() and acpi_scan_init() were subsys_initcalls, and acpi_init() was called first based on the link order from the makefile (bus.o before scan.o). acpi_scan_init() registers the ACPI bus type, creates the root device, and enumerates fixed-feature and namespace devices. All of this must be done after acpi_init(), and it's better to call acpi_scan_init() explicitly rather than rely on the link ordering. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: skip DMI power state check when ACPI disabledBjorn Helgaas2009-03-271-0/+4
| | | | | | | | | | | | | | | | | | This patch makes acpi_init() exit early when ACPI is disabled. This skips a DMI check that affects ACPI power management. The DMI check prints a notice that is misleading when ACPI is disabled. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: move private declarations to internal.hBjorn Helgaas2009-03-171-0/+2
| | | | | | | | | | | | | | | | | | | | A number of things that shouldn't be exposed outside the ACPI core were declared in include/acpi/acpi_drivers.h, where anybody can see them. This patch moves those declarations to a new "internal.h" inside drivers/acpi. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: remove doubled status checkingJiri Slaby2009-03-161-8/+1
|/ | | | | | | | | | | There was a misplaced status test (two consequent tests without a statement in between) in acpi_bus_init for ages. Remove it, since the function which should be checked (acpi_os_initialize1) has BUG_ONs on failure paths. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: fix 2.6.28 acpi.debug_level regressionBjorn Helgaas2008-12-191-8/+0
| | | | | | | | | | | | | | | acpi_early_init() was changed to over-write the cmdline param, making it really inconvenient to set debug flags at boot-time. Also, This sets the default level to "info", which is what all the ACPI drivers use. So to enable messages from drivers, you only have to supply the "layer" (a.k.a. "component"). For non-"info" ACPI core and ACPI interpreter messages, you have to supply both level and layer masks, as before. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: turn off all debug output by defaultBjorn Helgaas2008-11-071-0/+8
| | | | | | | | | | | | | When CONFIG_ACPI_DEBUG=y, the default acpi_dbg_layer and acpi_dbg_level values built into the ACPI CA have some debug output enabled. We'd rather be quiet unless the user actually specified the acpi.debug_level argument. This enables distros to ship with CONFIG_ACPI_DEBUG=y without inundating users with debug output. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: remove CONFIG_ACPI_ECBjorn Helgaas2008-11-061-2/+1
| | | | | | | | | | | | | | | | | | | | Remove CONFIG_ACPI_EC. It was always set the same as CONFIG_ACPI, and it had no menu label, so there was no way to set it to anything other than "y". Per section 6.5.4 of the ACPI 3.0b specification, OSPM must make Embedded Controller operation regions, accessed via the Embedded Controllers described in ECDT, available before executing any control method. The ECDT table is optional, but if it is present, the above text means that the EC it describes is a required part of the ACPI subsystem, so CONFIG_ACPI_EC=n wouldn't make sense. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'ull' into testLen Brown2008-10-221-2/+2
|\ | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/bay.c drivers/acpi/dock.c drivers/ata/libata-acpi.c Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernelsMatthew Wilcox2008-10-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | As of version 2.0, ACPI can return 64-bit integers. The current acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms. Change the argument to take a pointer to an acpi_integer so we support 64-bit integers on all platforms. lenb: replaced use of "acpi_integer" with "unsigned long long" lenb: fixed bug in acpi_thermal_trips_update() Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'ec' into testLen Brown2008-10-221-0/+6
|\ \
| * | ACPI: Enable EC device immediately after ACPI full initializationZhao Yakui2008-10-111-0/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when there is no ECDT table and no _INI object for EC device, it will be enabled before scanning ACPI device. But it is too late after the following the commit is merged. >commit 7752d5cfe3d11ca0bb9c673ec38bd78ba6578f8e > Author: Robert Hancock <hancockr@shaw.ca> > Date: Fri Feb 15 01:27:20 2008 -0800 >x86: validate against acpi motherboard resources After the above commit is merged, OS will check whether MCFG area is reserved in ACPI motherboard resources by calling the function of acpi_get_devices when there exists MCFG table. In the acpi_get_devices the _STA object will be evaluated to check the status of the ACPI device. On some broken BIOS the MYEC object of EC device is initialized as one, which indicates that EC operation region is already accessible before enabling EC device.So on these broken BIOS the EC operation region will be accessed in course of evaluating the _STA object before enabling EC device, which causes that OS will print the following warning messages: >ACPI Error (evregion-0315): No handler for Region [EC__] (ffff88007f8145e8) [EmbeddedControl] [20080609] >ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321] >ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG. EC__.BAT1._STA] (Node ffff81013fc17a00), AE_NOT_EXIST >ACPI Error (uteval-0233): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1. _STA] (Node ffff81013fc17a00), AE_NOT_EXIST Although the above warning message is harmless, it looks confusing. So it is necessary to enable EC device as early as possible.Maybe it is appropriate to enable it immediately after ACPI full initialization. http://bugzilla.kernel.org/show_bug.cgi?id=11255 http://bugzilla.kernel.org/show_bug.cgi?id=11374 http://bugzilla.kernel.org/show_bug.cgi?id=11660 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'dock' into testLen Brown2008-10-221-0/+15
|\ \ | | | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/osl.c Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: introduce notifier change to avoid duplicatesShaohua Li2008-09-231-0/+15
| |/ | | | | | | | | | | | | | | | | | | The battery driver already registers notification handler. To avoid registering notification handler again, introduce a notifier chain in global system notifier handler and use it in dock driver. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI : Load device driver according to the status of acpi deviceZhao Yakui2008-10-221-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to ACPI spec when the status of some device is not present but functional, the device is valid and the children of this device should be enumerated. It means that the device should be added to linux acpi device tree. But the device driver for this device should not be loaded. The detailed info can be found in the section 6.3.7 of ACPI 3.0b spec. _STA may return bit 0 clear (not present) with bit 3 set (device is functional). This case is used to indicate a valid device for which no device driver should be loaded (for example, a bridge device.). Children of this device may be present and valid. OS should continue enumeration below a device whose _STA returns this bit combination http://bugzilla.kernel.org/show_bug.cgi?id=3358 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Li Shaohua <shaohua.li@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: Add DMI check to disable power state check in power transitionZhao Yakui2008-10-221-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | Add the DMI check to disable power check in the course of device power transistion. http://bugzilla.kernel.org/show_bug.cgi?id=11000 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Li Shaohua <shaohua.li@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: Add "acpi.power_nocheck=1" to disable power state check in power ↵Zhao Yakui2008-10-221-1/+13
|/ | | | | | | | | | | | | | | | | | | | | | | transition Maybe the incorrect power state is returned on the bogus bios, which is different with the real power state. For example: the bios returns D0 state and the real power state is D3. OS expects to set the device to D0 state. In such case if OS uses the power state returned by the BIOS and checks the device power state very strictly in power transition, the device can't be transited to the correct power state. So the boot option of "acpi.power_nocheck=1" is added to avoid checking the device power in the course of device power transition. http://bugzilla.kernel.org/show_bug.cgi?id=8049 http://bugzilla.kernel.org/show_bug.cgi?id=11000 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Li Shaohua <shaohua.li@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'linux-next' of ↵Linus Torvalds2008-07-161-0/+22
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (72 commits) Revert "x86/PCI: ACPI based PCI gap calculation" PCI: remove unnecessary volatile in PCIe hotplug struct controller x86/PCI: ACPI based PCI gap calculation PCI: include linux/pm_wakeup.h for device_set_wakeup_capable PCI PM: Fix pci_prepare_to_sleep x86/PCI: Fix PCI config space for domains > 0 Fix acpi_pm_device_sleep_wake() by providing a stub for CONFIG_PM_SLEEP=n PCI: Simplify PCI device PM code PCI PM: Introduce pci_prepare_to_sleep and pci_back_from_sleep PCI ACPI: Rework PCI handling of wake-up ACPI: Introduce new device wakeup flag 'prepared' ACPI: Introduce acpi_device_sleep_wake function PCI: rework pci_set_power_state function to call platform first PCI: Introduce platform_pci_power_manageable function ACPI: Introduce acpi_bus_power_manageable function PCI: make pci_name use dev_name PCI: handle pci_name() being const PCI: add stub for pci_set_consistent_dma_mask() PCI: remove unused arch pcibios_update_resource() functions PCI: fix pci_setup_device()'s sprinting into a const buffer ... Fixed up conflicts in various files (arch/x86/kernel/setup_64.c, arch/x86/pci/irq.c, arch/x86/pci/pci.h, drivers/acpi/sleep/main.c, drivers/pci/pci.c, drivers/pci/pci.h, include/acpi/acpi_bus.h) from x86 and ACPI updates manually.
| * PCI ACPI: Rework PCI handling of wake-upRafael J. Wysocki2008-07-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Introduce function acpi_pm_device_sleep_wake() for enabling and disabling the system wake-up capability of devices that are power manageable by ACPI. * Introduce function acpi_bus_can_wakeup() allowing other (dependent) subsystems to check if ACPI is able to enable the system wake-up capability of given device. * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake(). * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and for the ACPI 'driver' make it use acpi_bus_can_wakeup(). * Move the PME# handlig code out of pci_enable_wake() and split it into two functions, pci_pme_capable() and pci_pme_active(), allowing the caller to check if given device is capable of generating PME# from given power state and to enable/disable the device's PME# functionality, respectively. * Modify pci_enable_wake() to use the new ACPI callbacks and the new PME#-related functions. * Drop the generic .platform_enable_wakeup() callback that is not used any more. * Introduce device_set_wakeup_capable() that will set the power.can_wakeup flag of given device. * Rework PCI device PM initialization so that, if given device is capable of generating wake-up events, either natively through the PME# mechanism, or with the help of the platform, its power.can_wakeup flag is set and its power.should_wakeup flag is unset as appropriate. * Make ACPI set the power.can_wakeup flag for devices found to be wake-up capable by it. * Make the ACPI wake-up code enable/disable GPEs for devices that have the wakeup.flags.prepared flag set (which means that their wake-up power has been enabled). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * ACPI: Introduce acpi_bus_power_manageable functionRafael J. Wysocki2008-07-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | Introduce function acpi_bus_power_manageable() allowing other (dependent) subsystems to check if ACPI is able to power manage given device. This may be useful, for example, for PCI device power management. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | ACPICA: Eliminate acpi_native_uint type v2Bob Moore2008-07-161-1/+1
|/ | | | | | | | | | | | | | No longer needed; replaced mostly with u32, but also acpi_size where a type that changes 32/64 bit on 32/64-bit platforms is required. v2: Fix a cast of a 32-bit int to a pointer in ACPI to avoid a compiler warning. from David Howells Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* x86: validate against acpi motherboard resourcesRobert Hancock2008-04-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This path adds validation of the MMCONFIG table against the ACPI reserved motherboard resources. If the MMCONFIG table is found to be reserved in ACPI, we don't bother checking the E820 table. The PCI Express firmware spec apparently tells BIOS developers that reservation in ACPI is required and E820 reservation is optional, so checking against ACPI first makes sense. Many BIOSes don't reserve the MMCONFIG region in E820 even though it is perfectly functional, the existing check needlessly disables MMCONFIG in these cases. In order to do this, MMCONFIG setup has been split into two phases. If PCI configuration type 1 is not available then MMCONFIG is enabled early as before. Otherwise, it is enabled later after the ACPI interpreter is enabled, since we need to be able to execute control methods in order to check the ACPI reserved resources. Presently this is just triggered off the end of ACPI interpreter initialization. There are a few other behavioral changes here: - Validate all MMCONFIG configurations provided, not just the first one. - Validate the entire required length of each configuration according to the provided ending bus number is reserved, not just the minimum required allocation. - Validate that the area is reserved even if we read it from the chipset directly and not from the MCFG table. This catches the case where the BIOS didn't set the location properly in the chipset and has mapped it over other things it shouldn't have. This also cleans up the MMCONFIG initialization functions so that they simply do nothing if MMCONFIG is not compiled in. Based on an original patch by Rajesh Shah from Intel. [akpm@linux-foundation.org: many fixes and cleanups] Signed-off-by: Robert Hancock <hancockr@shaw.ca> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Andi Kleen <ak@suse.de> Cc: Rajesh Shah <rajesh.shah@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andi Kleen <ak@suse.de> Cc: Greg KH <greg@kroah.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* acpi: bus: check once more for an empty list after locking itChuck Ebbert2008-04-151-3/+4
| | | | | | | | | | | | | List could have become empty after the unlocked check that was made earlier, so check again inside the lock. Should fix https://bugzilla.redhat.com/show_bug.cgi?id=427765 Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Cc: <stable@kernel.org> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ACPI: replace remaining __FUNCTION__ occurrencesHarvey Harrison2008-03-111-1/+1
| | | | | | | __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* x86: fix sparse warnings in acpi/bus.cHarvey Harrison2008-02-091-6/+1
| | | | | | | | | | | | | | | | | Add function definition and extern variables to asm-x86/acpi.h. All of these are used in bus.c in ifdef(CONFIG_X86) sections, so are only added to the x86 include headers. boot.c already includes acpi.h so no changes are needed there. Fixes the following: arch/x86/kernel/acpi/boot.c:83:4: warning: symbol 'acpi_sci_flags' was not declared. Should it be static? arch/x86/kernel/acpi/boot.c:84:5: warning: symbol 'acpi_sci_override_gsi' was not declared. Should it be static? arch/x86/kernel/acpi/boot.c:421:13: warning: symbol 'acpi_pic_sci_set_trigger' was not declared. Should it be static? Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
OpenPOWER on IntegriCloud