2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-23 04:34:11 +08:00
linux-next/drivers/acpi/utils.c

753 lines
19 KiB
C
Raw Normal View History

/*
* acpi_utils.c - ACPI Utility Functions ($Revision: 10 $)
*
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
*
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or (at
* your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
#include <linux/kernel.h>
#include <linux/module.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking 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-24 16:04:11 +08:00
#include <linux/slab.h>
#include <linux/init.h>
#include <linux/types.h>
ACPI: Add acpi_handle_<level>() interfaces 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-11-21 09:36:28 +08:00
#include <linux/hardirq.h>
#include <linux/acpi.h>
#include <linux/dynamic_debug.h>
#include "internal.h"
#include "sleep.h"
#define _COMPONENT ACPI_BUS_COMPONENT
ACPI_MODULE_NAME("utils");
/* --------------------------------------------------------------------------
Object Evaluation Helpers
-------------------------------------------------------------------------- */
static void
acpi_util_eval_error(acpi_handle h, acpi_string p, acpi_status s)
{
#ifdef ACPI_DEBUG_OUTPUT
char prefix[80] = {'\0'};
struct acpi_buffer buffer = {sizeof(prefix), prefix};
acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluate [%s.%s]: %s\n",
(char *) prefix, p, acpi_format_exception(s)));
#else
return;
#endif
}
acpi_status
acpi_extract_package(union acpi_object *package,
struct acpi_buffer *format, struct acpi_buffer *buffer)
{
u32 size_required = 0;
u32 tail_offset = 0;
char *format_string = NULL;
u32 format_count = 0;
u32 i = 0;
u8 *head = NULL;
u8 *tail = NULL;
if (!package || (package->type != ACPI_TYPE_PACKAGE)
|| (package->package.count < 1)) {
printk(KERN_WARNING PREFIX "Invalid package argument\n");
return AE_BAD_PARAMETER;
}
if (!format || !format->pointer || (format->length < 1)) {
printk(KERN_WARNING PREFIX "Invalid format argument\n");
return AE_BAD_PARAMETER;
}
if (!buffer) {
printk(KERN_WARNING PREFIX "Invalid buffer argument\n");
return AE_BAD_PARAMETER;
}
format_count = (format->length / sizeof(char)) - 1;
if (format_count > package->package.count) {
printk(KERN_WARNING PREFIX "Format specifies more objects [%d]"
" than exist in package [%d].\n",
format_count, package->package.count);
return AE_BAD_DATA;
}
format_string = format->pointer;
/*
* Calculate size_required.
*/
for (i = 0; i < format_count; i++) {
union acpi_object *element = &(package->package.elements[i]);
switch (element->type) {
case ACPI_TYPE_INTEGER:
switch (format_string[i]) {
case 'N':
size_required += sizeof(u64);
tail_offset += sizeof(u64);
break;
case 'S':
size_required +=
sizeof(char *) + sizeof(u64) +
sizeof(char);
tail_offset += sizeof(char *);
break;
default:
printk(KERN_WARNING PREFIX "Invalid package element"
" [%d]: got number, expecting"
" [%c]\n",
i, format_string[i]);
return AE_BAD_DATA;
break;
}
break;
case ACPI_TYPE_STRING:
case ACPI_TYPE_BUFFER:
switch (format_string[i]) {
case 'S':
size_required +=
sizeof(char *) +
(element->string.length * sizeof(char)) +
sizeof(char);
tail_offset += sizeof(char *);
break;
case 'B':
size_required +=
sizeof(u8 *) + element->buffer.length;
tail_offset += sizeof(u8 *);
break;
default:
printk(KERN_WARNING PREFIX "Invalid package element"
" [%d] got string/buffer,"
" expecting [%c]\n",
i, format_string[i]);
return AE_BAD_DATA;
break;
}
break;
case ACPI_TYPE_LOCAL_REFERENCE:
switch (format_string[i]) {
case 'R':
size_required += sizeof(void *);
tail_offset += sizeof(void *);
break;
default:
printk(KERN_WARNING PREFIX "Invalid package element"
" [%d] got reference,"
" expecting [%c]\n",
i, format_string[i]);
return AE_BAD_DATA;
break;
}
break;
case ACPI_TYPE_PACKAGE:
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Found unsupported element at index=%d\n",
i));
/* TBD: handle nested packages... */
return AE_SUPPORT;
break;
}
}
/*
* Validate output buffer.
*/
if (buffer->length == ACPI_ALLOCATE_BUFFER) {
buffer->pointer = ACPI_ALLOCATE_ZEROED(size_required);
if (!buffer->pointer)
return AE_NO_MEMORY;
buffer->length = size_required;
} else {
if (buffer->length < size_required) {
buffer->length = size_required;
return AE_BUFFER_OVERFLOW;
} else if (buffer->length != size_required ||
!buffer->pointer) {
return AE_BAD_PARAMETER;
}
}
head = buffer->pointer;
tail = buffer->pointer + tail_offset;
/*
* Extract package data.
*/
for (i = 0; i < format_count; i++) {
u8 **pointer = NULL;
union acpi_object *element = &(package->package.elements[i]);
switch (element->type) {
case ACPI_TYPE_INTEGER:
switch (format_string[i]) {
case 'N':
*((u64 *) head) =
element->integer.value;
head += sizeof(u64);
break;
case 'S':
pointer = (u8 **) head;
*pointer = tail;
*((u64 *) tail) =
element->integer.value;
head += sizeof(u64 *);
tail += sizeof(u64);
/* NULL terminate string */
*tail = (char)0;
tail += sizeof(char);
break;
default:
/* Should never get here */
break;
}
break;
case ACPI_TYPE_STRING:
case ACPI_TYPE_BUFFER:
switch (format_string[i]) {
case 'S':
pointer = (u8 **) head;
*pointer = tail;
memcpy(tail, element->string.pointer,
element->string.length);
head += sizeof(char *);
tail += element->string.length * sizeof(char);
/* NULL terminate string */
*tail = (char)0;
tail += sizeof(char);
break;
case 'B':
pointer = (u8 **) head;
*pointer = tail;
memcpy(tail, element->buffer.pointer,
element->buffer.length);
head += sizeof(u8 *);
tail += element->buffer.length;
break;
default:
/* Should never get here */
break;
}
break;
case ACPI_TYPE_LOCAL_REFERENCE:
switch (format_string[i]) {
case 'R':
*(void **)head =
(void *)element->reference.handle;
head += sizeof(void *);
break;
default:
/* Should never get here */
break;
}
break;
case ACPI_TYPE_PACKAGE:
/* TBD: handle nested packages... */
default:
/* Should never get here */
break;
}
}
return AE_OK;
}
EXPORT_SYMBOL(acpi_extract_package);
acpi_status
acpi_evaluate_integer(acpi_handle handle,
acpi_string pathname,
struct acpi_object_list *arguments, unsigned long long *data)
{
acpi_status status = AE_OK;
union acpi_object element;
struct acpi_buffer buffer = { 0, NULL };
if (!data)
return AE_BAD_PARAMETER;
buffer.length = sizeof(union acpi_object);
buffer.pointer = &element;
status = acpi_evaluate_object(handle, pathname, arguments, &buffer);
if (ACPI_FAILURE(status)) {
acpi_util_eval_error(handle, pathname, status);
return status;
}
if (element.type != ACPI_TYPE_INTEGER) {
acpi_util_eval_error(handle, pathname, AE_BAD_DATA);
return AE_BAD_DATA;
}
*data = element.integer.value;
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Return value [%llu]\n", *data));
return AE_OK;
}
EXPORT_SYMBOL(acpi_evaluate_integer);
acpi_status
acpi_evaluate_reference(acpi_handle handle,
acpi_string pathname,
struct acpi_object_list *arguments,
struct acpi_handle_list *list)
{
acpi_status status = AE_OK;
union acpi_object *package = NULL;
union acpi_object *element = NULL;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
u32 i = 0;
if (!list) {
return AE_BAD_PARAMETER;
}
/* Evaluate object. */
status = acpi_evaluate_object(handle, pathname, arguments, &buffer);
if (ACPI_FAILURE(status))
goto end;
package = buffer.pointer;
if ((buffer.length == 0) || !package) {
status = AE_BAD_DATA;
acpi_util_eval_error(handle, pathname, status);
goto end;
}
if (package->type != ACPI_TYPE_PACKAGE) {
status = AE_BAD_DATA;
acpi_util_eval_error(handle, pathname, status);
goto end;
}
if (!package->package.count) {
status = AE_BAD_DATA;
acpi_util_eval_error(handle, pathname, status);
goto end;
}
if (package->package.count > ACPI_MAX_HANDLES) {
return AE_NO_MEMORY;
}
list->count = package->package.count;
/* Extract package data. */
for (i = 0; i < list->count; i++) {
element = &(package->package.elements[i]);
if (element->type != ACPI_TYPE_LOCAL_REFERENCE) {
status = AE_BAD_DATA;
acpi_util_eval_error(handle, pathname, status);
break;
}
if (!element->reference.handle) {
status = AE_NULL_ENTRY;
acpi_util_eval_error(handle, pathname, status);
break;
}
/* Get the acpi_handle. */
list->handles[i] = element->reference.handle;
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found reference [%p]\n",
list->handles[i]));
}
end:
if (ACPI_FAILURE(status)) {
list->count = 0;
//kfree(list->handles);
}
kfree(buffer.pointer);
return status;
}
EXPORT_SYMBOL(acpi_evaluate_reference);
acpi_status
acpi_get_physical_device_location(acpi_handle handle, struct acpi_pld_info **pld)
{
acpi_status status;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *output;
status = acpi_evaluate_object(handle, "_PLD", NULL, &buffer);
if (ACPI_FAILURE(status))
return status;
output = buffer.pointer;
if (!output || output->type != ACPI_TYPE_PACKAGE
|| !output->package.count
|| output->package.elements[0].type != ACPI_TYPE_BUFFER
|| output->package.elements[0].buffer.length < ACPI_PLD_REV1_BUFFER_SIZE) {
status = AE_TYPE;
goto out;
}
status = acpi_decode_pld_buffer(
output->package.elements[0].buffer.pointer,
output->package.elements[0].buffer.length,
pld);
out:
kfree(buffer.pointer);
return status;
}
EXPORT_SYMBOL(acpi_get_physical_device_location);
ACPI: Add an interface to evaluate _OST 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-24 10:25:19 +08:00
/**
* acpi_evaluate_ost: Evaluate _OST for hotplug operations
ACPI: Add an interface to evaluate _OST 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-24 10:25:19 +08:00
* @handle: ACPI device handle
* @source_event: source event code
* @status_code: status code
* @status_buf: optional detailed information (NULL if none)
*
* Evaluate _OST for hotplug operations. All ACPI hotplug handlers
* must call this function when evaluating _OST for hotplug operations.
* When the platform does not support _OST, this function has no effect.
*/
acpi_status
acpi_evaluate_ost(acpi_handle handle, u32 source_event, u32 status_code,
struct acpi_buffer *status_buf)
ACPI: Add an interface to evaluate _OST 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-24 10:25:19 +08:00
{
union acpi_object params[3] = {
{.type = ACPI_TYPE_INTEGER,},
{.type = ACPI_TYPE_INTEGER,},
{.type = ACPI_TYPE_BUFFER,}
};
struct acpi_object_list arg_list = {3, params};
params[0].integer.value = source_event;
params[1].integer.value = status_code;
if (status_buf != NULL) {
params[2].buffer.pointer = status_buf->pointer;
params[2].buffer.length = status_buf->length;
} else {
params[2].buffer.pointer = NULL;
params[2].buffer.length = 0;
}
return acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
ACPI: Add an interface to evaluate _OST 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-24 10:25:19 +08:00
}
EXPORT_SYMBOL(acpi_evaluate_ost);
ACPI: Add acpi_handle_<level>() interfaces 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-11-21 09:36:28 +08:00
/**
* acpi_handle_path: Return the object path of handle
*
* Caller must free the returned buffer
*/
static char *acpi_handle_path(acpi_handle handle)
{
struct acpi_buffer buffer = {
.length = ACPI_ALLOCATE_BUFFER,
.pointer = NULL
};
if (in_interrupt() ||
acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer) != AE_OK)
return NULL;
return buffer.pointer;
}
ACPI: Add acpi_handle_<level>() interfaces 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-11-21 09:36:28 +08:00
/**
* acpi_handle_printk: Print message with ACPI prefix and object path
*
* This function is called through acpi_handle_<level> macros and prints
* a message with ACPI prefix and object path. This function acquires
* the global namespace mutex to obtain an object path. In interrupt
* context, it shows the object path as <n/a>.
*/
void
acpi_handle_printk(const char *level, acpi_handle handle, const char *fmt, ...)
{
struct va_format vaf;
va_list args;
const char *path;
va_start(args, fmt);
vaf.fmt = fmt;
vaf.va = &args;
path = acpi_handle_path(handle);
printk("%sACPI: %s: %pV", level, path ? path : "<n/a>" , &vaf);
ACPI: Add acpi_handle_<level>() interfaces 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-11-21 09:36:28 +08:00
va_end(args);
kfree(path);
ACPI: Add acpi_handle_<level>() interfaces 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-11-21 09:36:28 +08:00
}
EXPORT_SYMBOL(acpi_handle_printk);
#if defined(CONFIG_DYNAMIC_DEBUG)
/**
* __acpi_handle_debug: pr_debug with ACPI prefix and object path
*
* This function is called through acpi_handle_debug macro and debug
* prints a message with ACPI prefix and object path. This function
* acquires the global namespace mutex to obtain an object path. In
* interrupt context, it shows the object path as <n/a>.
*/
void
__acpi_handle_debug(struct _ddebug *descriptor, acpi_handle handle,
const char *fmt, ...)
{
struct va_format vaf;
va_list args;
const char *path;
va_start(args, fmt);
vaf.fmt = fmt;
vaf.va = &args;
path = acpi_handle_path(handle);
__dynamic_pr_debug(descriptor, "ACPI: %s: %pV", path ? path : "<n/a>", &vaf);
va_end(args);
kfree(path);
}
EXPORT_SYMBOL(__acpi_handle_debug);
#endif
/**
* acpi_has_method: Check whether @handle has a method named @name
* @handle: ACPI device handle
* @name: name of object or method
*
* Check whether @handle has a method named @name.
*/
bool acpi_has_method(acpi_handle handle, char *name)
{
acpi_handle tmp;
return ACPI_SUCCESS(acpi_get_handle(handle, name, &tmp));
}
EXPORT_SYMBOL(acpi_has_method);
acpi_status acpi_execute_simple_method(acpi_handle handle, char *method,
u64 arg)
{
union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
struct acpi_object_list arg_list = { .count = 1, .pointer = &obj, };
obj.integer.value = arg;
return acpi_evaluate_object(handle, method, &arg_list, NULL);
}
EXPORT_SYMBOL(acpi_execute_simple_method);
/**
* acpi_evaluate_ej0: Evaluate _EJ0 method for hotplug operations
* @handle: ACPI device handle
*
* Evaluate device's _EJ0 method for hotplug operations.
*/
acpi_status acpi_evaluate_ej0(acpi_handle handle)
{
acpi_status status;
status = acpi_execute_simple_method(handle, "_EJ0", 1);
if (status == AE_NOT_FOUND)
acpi_handle_warn(handle, "No _EJ0 support for device\n");
else if (ACPI_FAILURE(status))
acpi_handle_warn(handle, "Eject failed (0x%x)\n", status);
return status;
}
/**
* acpi_evaluate_lck: Evaluate _LCK method to lock/unlock device
* @handle: ACPI device handle
* @lock: lock device if non-zero, otherwise unlock device
*
* Evaluate device's _LCK method if present to lock/unlock device
*/
acpi_status acpi_evaluate_lck(acpi_handle handle, int lock)
{
acpi_status status;
status = acpi_execute_simple_method(handle, "_LCK", !!lock);
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
if (lock)
acpi_handle_warn(handle,
"Locking device failed (0x%x)\n", status);
else
acpi_handle_warn(handle,
"Unlocking device failed (0x%x)\n", status);
}
return status;
}
/**
* acpi_evaluate_dsm - evaluate device's _DSM method
* @handle: ACPI device handle
* @uuid: UUID of requested functions, should be 16 bytes
* @rev: revision number of requested function
* @func: requested function number
* @argv4: the function specific parameter
*
* Evaluate device's _DSM method with specified UUID, revision id and
* function number. Caller needs to free the returned object.
*
* Though ACPI defines the fourth parameter for _DSM should be a package,
* some old BIOSes do expect a buffer or an integer etc.
*/
union acpi_object *
acpi_evaluate_dsm(acpi_handle handle, const u8 *uuid, int rev, int func,
union acpi_object *argv4)
{
acpi_status ret;
struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
union acpi_object params[4];
struct acpi_object_list input = {
.count = 4,
.pointer = params,
};
params[0].type = ACPI_TYPE_BUFFER;
params[0].buffer.length = 16;
params[0].buffer.pointer = (char *)uuid;
params[1].type = ACPI_TYPE_INTEGER;
params[1].integer.value = rev;
params[2].type = ACPI_TYPE_INTEGER;
params[2].integer.value = func;
if (argv4) {
params[3] = *argv4;
} else {
params[3].type = ACPI_TYPE_PACKAGE;
params[3].package.count = 0;
params[3].package.elements = NULL;
}
ret = acpi_evaluate_object(handle, "_DSM", &input, &buf);
if (ACPI_SUCCESS(ret))
return (union acpi_object *)buf.pointer;
if (ret != AE_NOT_FOUND)
acpi_handle_warn(handle,
"failed to evaluate _DSM (0x%x)\n", ret);
return NULL;
}
EXPORT_SYMBOL(acpi_evaluate_dsm);
/**
* acpi_check_dsm - check if _DSM method supports requested functions.
* @handle: ACPI device handle
* @uuid: UUID of requested functions, should be 16 bytes at least
* @rev: revision number of requested functions
* @funcs: bitmap of requested functions
*
* Evaluate device's _DSM method to check whether it supports requested
* functions. Currently only support 64 functions at maximum, should be
* enough for now.
*/
bool acpi_check_dsm(acpi_handle handle, const u8 *uuid, int rev, u64 funcs)
{
int i;
u64 mask = 0;
union acpi_object *obj;
if (funcs == 0)
return false;
obj = acpi_evaluate_dsm(handle, uuid, rev, 0, NULL);
if (!obj)
return false;
/* For compatibility, old BIOSes may return an integer */
if (obj->type == ACPI_TYPE_INTEGER)
mask = obj->integer.value;
else if (obj->type == ACPI_TYPE_BUFFER)
for (i = 0; i < obj->buffer.length && i < 8; i++)
mask |= (((u8)obj->buffer.pointer[i]) << (i * 8));
ACPI_FREE(obj);
/*
* Bit 0 indicates whether there's support for any functions other than
* function 0 for the specified UUID and revision.
*/
if ((mask & 0x1) && (mask & funcs) == funcs)
return true;
return false;
}
EXPORT_SYMBOL(acpi_check_dsm);
acpi-video-detect: video: Make video_detect code part of the video module This is a preparation patch for the backlight interface selection logic cleanup, there are 2 reasons to not always build the video_detect code into the kernel: 1) In order for the video_detect.c to also deal with / select native backlight interfaces on win8 systems, instead of doing this in video.c where it does not belong, video_detect.c needs to call into the backlight class code. Which cannot be done if it is builtin and the blacklight class is not. 2) Currently all the platform/x86 drivers which have quirks to prefer the vendor driver over acpi-video call acpi_video_unregister_backlight() to remove the acpi-video backlight interface, this logic really belongs in video_detect.c, which will cause video_detect.c to depend on symbols of video.c and video.c already depends on video_detect.c symbols, so they really need to be a single module. Note that this commits make 2 changes so as to maintain 100% kernel commandline compatibility: 1) The __setup call for the acpi_backlight= handling is moved to acpi/util.c as __setup may only be used by code which is alwasy builtin 2) video.c is renamed to acpi_video.c so that it can be combined with video_detect.c into video.ko This commit also makes changes to drivers/platform/x86/Kconfig to ensure that drivers which use acpi_video_backlight_support() from video_detect.c, will not be built-in when acpi_video is not built in. This also changes some "select" uses to "depends on" to avoid dependency loops. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-16 22:27:47 +08:00
/**
* acpi_dev_present - Detect presence of a given ACPI device in the system.
* @hid: Hardware ID of the device.
*
* Return %true if the device was present at the moment of invocation.
* Note that if the device is pluggable, it may since have disappeared.
*
* For this function to work, acpi_bus_scan() must have been executed
* which happens in the subsys_initcall() subsection. Hence, do not
* call from a subsys_initcall() or earlier (use acpi_get_devices()
* instead). Calling from module_init() is fine (which is synonymous
* with device_initcall()).
*/
bool acpi_dev_present(const char *hid)
{
struct acpi_device_bus_id *acpi_device_bus_id;
bool found = false;
mutex_lock(&acpi_device_lock);
list_for_each_entry(acpi_device_bus_id, &acpi_bus_id_list, node)
if (!strcmp(acpi_device_bus_id->bus_id, hid)) {
found = true;
break;
}
mutex_unlock(&acpi_device_lock);
return found;
}
EXPORT_SYMBOL(acpi_dev_present);
acpi-video-detect: video: Make video_detect code part of the video module This is a preparation patch for the backlight interface selection logic cleanup, there are 2 reasons to not always build the video_detect code into the kernel: 1) In order for the video_detect.c to also deal with / select native backlight interfaces on win8 systems, instead of doing this in video.c where it does not belong, video_detect.c needs to call into the backlight class code. Which cannot be done if it is builtin and the blacklight class is not. 2) Currently all the platform/x86 drivers which have quirks to prefer the vendor driver over acpi-video call acpi_video_unregister_backlight() to remove the acpi-video backlight interface, this logic really belongs in video_detect.c, which will cause video_detect.c to depend on symbols of video.c and video.c already depends on video_detect.c symbols, so they really need to be a single module. Note that this commits make 2 changes so as to maintain 100% kernel commandline compatibility: 1) The __setup call for the acpi_backlight= handling is moved to acpi/util.c as __setup may only be used by code which is alwasy builtin 2) video.c is renamed to acpi_video.c so that it can be combined with video_detect.c into video.ko This commit also makes changes to drivers/platform/x86/Kconfig to ensure that drivers which use acpi_video_backlight_support() from video_detect.c, will not be built-in when acpi_video is not built in. This also changes some "select" uses to "depends on" to avoid dependency loops. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-16 22:27:47 +08:00
/*
* acpi_backlight= handling, this is done here rather then in video_detect.c
* because __setup cannot be used in modules.
*/
char acpi_video_backlight_string[16];
EXPORT_SYMBOL(acpi_video_backlight_string);
static int __init acpi_backlight(char *str)
{
strlcpy(acpi_video_backlight_string, str,
sizeof(acpi_video_backlight_string));
return 1;
}
__setup("acpi_backlight=", acpi_backlight);