summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/bus.c
AgeCommit message (Collapse)Author
2011-01-12ACPI / PM: Drop acpi_power_nocheckRafael J. Wysocki
Since acpi_bus_set_power() should not use __acpi_bus_get_power() to update the device's device->power.state field before changing its power state (this may cause device->power.state to be inconsistent with the device power resources' reference counters), remove this call from it. In consequence, the acpi_power_nocheck variable is not necessary any more, so it can be dropped along with the DMI table used for setting that variable for HP Pavilion 05. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / PM: Drop acpi_bus_get_power()Rafael J. Wysocki
There are no more users of acpi_bus_get_power(), so it can be dropped. Moreover, it should be dropped, because it modifies the device->power.state field of an ACPI device without updating the reference counters of the device's power resources, which is wrong. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / Fan: Rework the handling of power resourcesRafael J. Wysocki
Use the new function acpi_bus_update_power() for manipulating power resources used by ACPI fan devices, which allows them to be put into the right state during initialization and resume. Consequently, remove the flags.force_power_state field from struct acpi_device, which is not necessary any more. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / PM: Register acpi_power_driver earlyRafael J. Wysocki
The ACPI device driver used for handling power resources, acpi_power_driver, creates a struct acpi_power_resource object for each ACPI device representing a power resource. These objects are then used when setting and reading the power states of devices using the corresponding power resources. Unfortunately, acpi_power_driver is registered after acpi_scan_init() that may add devices using the power resources before acpi_power_driver has a chance to create struct acpi_power_resource objects for them (specifically, the power resources may be referred to during the scanning process through acpi_bus_get_power() before they have been initialized). As the first step towards fixing this issue, move the registration of acpi_power_driver into acpi_scan_init() so that power resource devices can be initialized by it as soon as they have been found in the namespace. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / PM: Add function for updating device power state consistentlyRafael J. Wysocki
Add function acpi_bus_update_power() for reading the actual power state of an ACPI device and updating its device->power.state field in such a way that its power resources' reference counters will remain consistent with that field. For this purpose introduce __acpi_bus_set_power() setting the power state of an ACPI device without updating its device->power.state field and make acpi_bus_set_power() and acpi_bus_update_power() use it (acpi_bus_set_power() retains the current behavior for now). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / PM: Add function for device power state initializationRafael J. Wysocki
Add function acpi_bus_init_power() for getting the initial power state of an ACPI device and reference counting its power resources as appropriate. Make acpi_bus_get_power_flags() use the new function instead of acpi_bus_get_power() that updates device->power.state without reference counting the device's power resources. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / PM: Introduce __acpi_bus_get_power()Rafael J. Wysocki
It sometimes is necessary to get the power state of an ACPI device without updating its device->power.state field, for example to avoid inconsistencies between device->power.state and the reference counters of the device's power resources. For this purpose introduce __acpi_bus_get_power() that will return the given device's power state via a pointer (instead of modifying device->power.state) and make acpi_bus_get_power() use it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / PM: Prevent acpi_power_get_inferred_state() from making changesRafael J. Wysocki
acpi_power_get_inferred_state() should not update device->power.state behind the back of its caller, so make it return the state via a pointer instead. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-26ACPI: install ACPI table handler before any dynamic tables being loadedZhang Rui
ACPI table sysfs I/F is broken by commit 78f1699659963fff97975df44db6d5dbe7218e55 Author: Alex Chiang <achiang@hp.com> Date: Sun Dec 20 12:19:09 2009 -0700 ACPI: processor: call _PDC early because dynamic SSDT tables may be loaded in _PDC, before installing the ACPI table handler. As a result, the sysfs I/F of these dynamic tables are located at /sys/firmware/acpi/tables instead of /sys/firmware/acpi/tables/dynamic, which is not true. Invoke acpi_sysfs_init() before acpi_early_processor_set_pdc(), so that the table handler is installed before any dynamic tables loaded. https://bugzilla.kernel.org/show_bug.cgi?id=21142 CC: Dennis Jansen <dennis.jansen@web.de> CC: Alex Chiang <achiang@hp.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-09-29Merge branches 'apei', 'battery-mwh-fix', 'bugzilla-10807', ↵Len Brown
'bugzilla-14736', 'bugzilla-14679', 'bugzilla-16396', 'launchpad-613381' and 'misc' into release
2010-09-29ACPI: invoke DSDT corruption workaround on all Toshiba SatelliteLen Brown
Our list of Toshiba Satellite models that require this workaround is growing -- so invoke the workaround for the entire product line. https://bugzilla.kernel.org/show_bug.cgi?id=14679 Signed-off-by: Len Brown <len.brown@intel.com>
2010-09-28ACPI: Fix typosLucas De Marchi
Signed-off-by: Len Brown <len.brown@intel.com>
2010-08-15ACPI: remove deprecated ACPI procfs I/FZhang Rui
Rmove deprecated ACPI procfs I/F, including /proc/acpi/debug_layer /proc/acpi/debug_level /proc/acpi/info /proc/acpi/dsdt /proc/acpi/fadt /proc/acpi/sleep because the sysfs I/F is already available and has been working well for years. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-08-15ACPI: introduce drivers/acpi/sysfs.cZhang Rui
Introduce drivers/acpi/sysfs.c. code for ACPI sysfs I/F, including #ifdef ACPI_DEBUG /sys/module/acpi/parameters/debug_layer /sys/module/acpi/parameters/debug_level /sys/module/acpi/parameters/trace_method_name /sys/module/acpi/parameters/trace_debug_layer /sys/module/acpi/parameters/trace_debug_level /sys/module/acpi/parameters/trace_state #endif /sys/module/acpi/parameters/acpica_version /sys/firmware/acpi/tables/ /sys/firmware/acpi/interrupts/ is moved to this file. No function change in this patch. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-08-14ACPI: introduce drivers/acpi/debugfs.cZhang Rui
Introduce drivers/acpi/debugfs.c. Code for ACPI debugfs I/F, i.e. /sys/kernel/debug/acpi/custom_method, is moved to this file. And make ACPI debugfs always built in, even if CONFIG_ACPI_DEBUG is cleared. BTW:this adds about 400bytes code to ACPI, when CONFIG_ACPI_DEBUG is cleared. [uaccess.h build fix from Andrew Morton <akpm@linux-foundation.org>] Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-25drivers: acpi: don't use own implementation of hex_to_bin()Andy Shevchenko
Remove own implementation of hex_to_bin(). Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-20Merge branch 'acpica' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (22 commits) ACPI: fix early DSDT dmi check warnings on ia64 ACPICA: Update version to 20100428. ACPICA: Update/clarify some parameter names associated with acpi_handle ACPICA: Rename acpi_ex_system_do_suspend->acpi_ex_system_do_sleep ACPICA: Prevent possible allocation overrun during object copy ACPICA: Split large file, evgpeblk ACPICA: Add GPE support for dynamically loaded ACPI tables ACPICA: Clarify/rename some root table descriptor fields ACPICA: Update version to 20100331. ACPICA: Minimize the differences between linux GPE code and ACPICA code base ACPI: add boot option acpi=copy_dsdt to fix corrupt DSDT ACPICA: Update DSDT copy/detection. ACPICA: Add subsystem option to force copy of DSDT to local memory ACPICA: Add detection of corrupted/replaced DSDT ACPICA: Add write support for DataTable operation regions ACPICA: Fix for acpi_reallocate_root_table for incorrect root table copy ACPICA: Update comments/headers, no functional change ACPICA: Update version to 20100304 ACPICA: Fix for possible fault in acpi_ex_release_mutex ACPICA: Standardize integer output for ACPICA warnings/errors ...
2010-05-19ACPI: fix early DSDT dmi check warnings on ia64Lin Ming
WARNING: at drivers/firmware/dmi_scan.c:423 dmi_matches+0x70/0x160() dmi check: not initialized yet. This is caused by commit aa2110c (ACPI: add boot option acpi=copy_dsdt to fix corrupt DSDT). DMI is not initialized yet in acpi_early_init on ia64. The DSDT DMI check table is x86 specific, so make it empty on other archs. And this fixes the warnings on ia64. Reported-and-tested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-27ACPI: silence kmemcheck false positiveDan Carpenter
This addresses: https://bugzilla.kernel.org/show_bug.cgi?id=14998 We copy some strings into "event" but we leave the space after the NULL terminators uninitialized. Later in acpi_bus_receive_event() we copy the whole struct to another buffer with memcpy(). If the new buffer is stored on the stack, kmemcheck prints a warning about the unitialized space after the NULL terminators. It's true that the space is uninitialized, but it's harmless. The buffer is only used in acpi_system_read_event() and we don't read past the NULL terminators. This patch changes the kmalloc() to kzalloc() so that we initialize the memory and silence the kmemcheck warning. Reported-by: Christian Casteyde <casteyde.christian@free.fr> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-20ACPI: add boot option acpi=copy_dsdt to fix corrupt DSDTLin Ming
Some BIOS on Toshiba machines corrupt the DSDT, so add a new boot option acpi=copy_dsdt to workaround it. Add warning message to ask users to use this option if corrupt DSDT detected. Also build a DMI blacklist to check it and automatically copy DSDT. https://bugzilla.kernel.org/show_bug.cgi?id=14679 Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-14Merge branches 'battery-2.6.34', 'bugzilla-10805', 'bugzilla-14668', ↵Len Brown
'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
2010-01-15ACPI: Advertise to BIOS in _OSC: _OST on _PPC changesZhao Yakui
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>
2009-12-28ACPI: Disable explicit power state retrieval on fansZhang Rui
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>
2009-12-24Merge branches 'bugzilla-14446', 'bugzilla-14753' and 'bugzilla-14824' into ↵Len Brown
release
2009-12-23ACPI: fix OSC regression that caused aer and pciehp not to loadShaohua Li
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>
2009-12-22ACPI: processor: call _PDC earlyAlex Chiang
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>
2009-12-16ACPI: Add platform-wide _OSC support.Shaohua Li
Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-16ACPI: Add a generic API for _OSC -v2Shaohua Li
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>
2009-09-25ACPI: add acpi_bus_get_status_handle()Bjorn Helgaas
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>
2009-09-19Merge branch 'misc-2.6.32' into releaseLen Brown
Conflicts: drivers/pci/dmar.c Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-19ACPI: linux/acpi.h should not include linux/dmi.hLen Brown
users of acpi.h that need dmi.h should include it directly. Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-27ACPICA: Fix several acpi_attach_data problemsBob Moore
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>
2009-06-18ACPI: use handle, not device, in system notification pathBjorn Helgaas
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>
2009-06-18ACPI: remove unused return values from Bus Check & Device Check handlingBjorn Helgaas
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>
2009-06-18ACPI: remove unused "status_changed" return value from Check Device handlingBjorn Helgaas
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>
2009-06-18ACPI: simplify notification debug messagesBjorn Helgaas
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>
2009-06-18ACPI: allow drivers to request both device and system notify eventsBjorn Helgaas
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>
2009-05-08ACPI: power: update error messageLen Brown
"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>
2009-04-05Merge branch 'bjorn-initcall-cleanup' into releaseLen Brown
2009-03-27ACPI: call acpi_wakeup_device_init() explicitly rather than as initcallBjorn Helgaas
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>
2009-03-27ACPI: call acpi_sleep_proc_init() explicitly rather than as initcallBjorn Helgaas
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>
2009-03-27ACPI: call init_acpi_device_notify() explicitly rather than as initcallBjorn Helgaas
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>
2009-03-27ACPI: call acpi_debug_init() explicitly rather than as initcallBjorn Helgaas
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>
2009-03-27ACPI: call acpi_system_init() explicitly rather than as initcallBjorn Helgaas
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>
2009-03-27ACPI: call acpi_power_init() explicitly rather than as initcallBjorn Helgaas
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>
2009-03-27ACPI: call acpi_ec_init() explicitly rather than as initcallBjorn Helgaas
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>
2009-03-27ACPI: call acpi_scan_init() explicitly rather than as initcallBjorn Helgaas
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>
2009-03-27ACPI: skip DMI power state check when ACPI disabledBjorn Helgaas
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>
2009-03-17ACPI: move private declarations to internal.hBjorn Helgaas
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>