summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/utils.c
AgeCommit message (Collapse)AuthorFilesLines
2013-10-10ACPI: improve acpi_extract_package() utilityAl Stone1-4/+13
The current version requires one to know the size of the package a priori; this is almost impossible if the package is composed of strings of variable length. This change allows the utility to allocate a buffer of the proper size if asked. Signed-off-by: Al Stone <al.stone@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI: introduce two helper functions for _EJ0 and _LCKJiang Liu1-0/+43
Introduce two helper functions, acpi_evaluate_ej0() and acpi_evaluate_lck(), that will execute the _EJ0 and _LCK ACPI control methods, respectively, and use them to simplify the ACPI scan code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI: introduce helper function acpi_execute_simple_method()Jiang Liu1-0/+12
Introduce helper function acpi_execute_simple_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI: introduce helper function acpi_has_method()Jiang Liu1-0/+15
Introduce helper function acpi_has_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-21ACPI: Add acpi_handle_<level>() interfacesToshi Kani1-0/+38
This patch introduces acpi_handle_<level>(), where <level> is a kernel message level such as err/warn/info, to support improved logging messages for ACPI, esp. hot-plug operations. acpi_handle_<level>() appends "ACPI" prefix and ACPI object path to the messages. This improves diagnosis of hotplug operations since an error message in a log file identifies an object that caused an issue. This interface acquires the global namespace mutex to obtain an object path. In interrupt context, it shows the object path as <n/a>. acpi_handle_<level>() takes acpi_handle as an argument, which is passed to ACPI hotplug notify handlers from the ACPICA. Therefore, it is always available unlike other kernel objects, such as device. For example: acpi_handle_err(handle, "Device don't exist, dropping EJECT\n"); logs an error message like this at KERN_ERR. ACPI: \_SB_.SCK4.CPU4: Device don't exist, dropping EJECT ACPI hot-plug drivers can use acpi_handle_<level>() when they need to identify a target ACPI object path in their messages, such as error cases. The usage model is similar to dev_<level>(). acpi_handle_<level>() can be used when a device is not created or is invalid during hot-plug operations. ACPI object path is also consistent on the platform, unlike device name that gets incremented over hotplug operations. ACPI drivers should use dev_<level>() when a device object is valid. Device name provides more user friendly information, and avoids acquiring the global ACPI namespace mutex. ACPI drivers also continue to use pr_<level>() when they do not need to specify device information, such as boot-up messages. Note: ACPI_[WARNING|INFO|ERROR]() are intended for the ACPICA and are not associated with the kernel message level. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Tested-by: Vijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-09-21ACPI: Use ACPICA native way to decode the PLD bufferFeng Tang1-4/+7
This patch is on top of the ACPICA 20120816 release, which implemented a native way to decode PLD buffer, so use it instead of leting upper level users do the decoding. v2: Modify the check for PLD buffer length to reject buffers whose length < 16 Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-06-04ACPI: Add an interface to evaluate _OSTToshi Kani1-0/+42
Added acpi_evaluate_hotplug_opt(). All ACPI hotplug handlers must call this function when evaluating _OST for hotplug operations. If the platform does not support _OST, this function returns AE_NOT_FOUND and has no effect on the platform. ACPI_HOTPLUG_OST is defined when all relevant ACPI hotplug operations, such as CPU, memory and container hotplug, are enabled. This assures consistent behavior among the hotplug operations with regarding the _OST support. When ACPI_HOTPLUG_OST is not defined, this function is a no-op. ACPI PCI hotplug is not enhanced to support _OST at this time since it is a legacy method being replaced by PCIe native hotplug. _OST support for ACPI PCI hotplug may be added in future if necessary. Some platforms may require the OS to support _OST in order to support ACPI hotplug operations. For example, if a platform has the management console where user can request a hotplug operation from, this _OST support would be required for the management console to show the result of the hotplug request to user. Added macro definitions of _OST source events and status codes. Also renamed OSC_SB_CPUHP_OST_SUPPORT to OSC_SB_HOTPLUG_OST_SUPPORT since this _OSC bit is not specific to CPU hotplug. This bit is defined in Table 6-147 of ACPI 5.0 as follows. Bits: 3 Field Name: Insertion / Ejection _OST Processing Support Definition: This bit is set if OSPM will evaluate the _OST object defined under a device when processing insertion and ejection source event codes. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-05-11ACPI: Add _PLD supportMatthew Garrett1-0/+30
Add a simple helper function to allow drivers to obtain the physical device location data. Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo1-0/+1
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 Brown1-53/+8
'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-02-16ACPI: delete unused acpi_evaluate_string()Len Brown1-45/+0
Roel found a logic issue in the #if 0 acpi_evaluate_string(): - || (element->type != ACPI_TYPE_BUFFER) + && (element->type != ACPI_TYPE_BUFFER) delete the dead code. pointed-out-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-28ACPI: replace acpi_integer by u64Lin Ming1-8/+8
acpi_integer is now obsolete and removed from the ACPICA code base, replaced by u64. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28ACPI: Move definition of PREFIX from acpi_bus.h to internal..hLen Brown1-0/+2
Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own. Add GPL commment to internal.h while we are there. This does not change any actual console output, asside from a whitespace fix. Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-26ACPI: scheduling in atomic via acpi_evaluate_integer ()Pavel Machek1-12/+4
Now I know why I had strange "scheduling in atomic" problems: acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL)... which is (of course) broken. There's no way to reliably tell if we need GFP_ATOMIC or not from code, this one for example fails to detect spinlocks held. Fortunately, allocation seems small enough to be done on stack. Signed-off-by: Pavel Machek <pavel@suse.cz> Acked-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-11ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernelsMatthew Wilcox1-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>
2008-04-22ACPICA: Fixes for external Reference ObjectsBob Moore1-1/+1
All Reference Objects returned via the AcpiEvaluteObject interface are now marked as type "REFERENCE" instead of "ANY". The type ANY is now reservered for NULL objects - either NULL package elements or unresolved named references. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-03-11ACPICA: Warn if packages with invalid references are evaluatedThomas Renninger1-0/+6
And return an error to avoid NULL pointer access by the caller Lin Ming's patch avoids corrupted mem access when BIOS has invalid references included, the handle is now zero instead of corrupted. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-02-16ACPI: sparse fix, replace macro with static functionHarvey Harrison1-7/+11
replace acpi_util_eval_error macro with static function. Avoid these sparse warnings due to using buffer within the macro. drivers/acpi/utils.c:273:3: warning: symbol 'buffer' shadows an earlier one drivers/acpi/utils.c:259:21: originally declared here drivers/acpi/utils.c:279:3: warning: symbol 'buffer' shadows an earlier one drivers/acpi/utils.c:259:21: originally declared here drivers/acpi/utils.c:368:3: warning: symbol 'buffer' shadows an earlier one drivers/acpi/utils.c:348:21: originally declared here drivers/acpi/utils.c:375:3: warning: symbol 'buffer' shadows an earlier one drivers/acpi/utils.c:348:21: originally declared here drivers/acpi/utils.c:382:3: warning: symbol 'buffer' shadows an earlier one drivers/acpi/utils.c:348:21: originally declared here drivers/acpi/utils.c:402:4: warning: symbol 'buffer' shadows an earlier one drivers/acpi/utils.c:348:21: originally declared here Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-12ACPI: clean up ACPI_MODULE_NAME() useLen Brown1-1/+1
cosmetic only Make "module name" actually match the file name. Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care. Fix indentation where Lindent did get confused. Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-20ACPI: replace kmalloc+memset with kzallocBurman Yan1-4/+2
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-10-14ACPI: Remove unnecessary from/to-void* and to-void casts in drivers/acpiJan Engelhardt1-2/+2
Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Len Brown <len.brown@intel.com>
2006-08-16ACPI: avoid irqrouter_resume might_sleep oops on resume from S4Len Brown1-1/+1
__might_sleep+0x8e/0x93 acpi_os_wait_semaphore+0x50/0xa3 acpi_ut_acquire_mutex+0x28/0x6a acpi_ns_get_node+0x46/0x88 acpi_ns_evaluate+0x2d/0xfc acpi_rs_set_srs_method_data+0xc5/0xe1 acpi_set_current_resources+0x31/0x3f acpi_pci_link_set+0xfc/0x1a5 irqrouter_resume+0x48/0x5f and __might_sleep+0x8e/0x93 kmem_cache_alloc+0x2a/0x8f acpi_evaluate_integer+0x32/0x96 acpi_bus_get_status+0x30/0x84 acpi_pci_link_set+0x12a/0x1a5 irqrouter_resume+0x48/0x5f http://bugzilla.kernel.org/show_bug.cgi?id=6810 Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-30ACPI: delete acpi_os_free(), use kfree() directlyLen Brown1-2/+2
Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27ACPI: delete tracing macros from drivers/acpi/*.cPatrick Mochel1-29/+25
Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...)Len Brown1-10/+10
Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-27ACPI: un-export ACPI_WARNING() -- use printk(KERN_WARNING...)Len Brown1-12/+12
Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-26ACPI: Enable ACPI error messages w/o CONFIG_ACPI_DEBUGThomas Renninger1-26/+24
Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2006-05-13ACPI: fix potential memory leak in acpi_evaluate_integer() error pathVasily Averin1-0/+2
Signed-off-by: Vasily Averin <vvs@sw.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05[ACPI] Lindent all ACPI filesLen Brown1-94/+101
Signed-off-by: Len Brown <len.brown@intel.com>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+423
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!