2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* acpi.h - ACPI Interface
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2001 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.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
|
*
|
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _LINUX_ACPI_H
|
|
|
|
|
#define _LINUX_ACPI_H
|
|
|
|
|
|
2012-11-15 20:15:37 +08:00
|
|
|
#include <linux/errno.h>
|
2008-02-05 15:31:23 +08:00
|
|
|
#include <linux/ioport.h> /* for struct resource */
|
2012-11-01 05:44:41 +08:00
|
|
|
#include <linux/device.h>
|
2005-06-07 06:50:09 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#ifndef _LINUX
|
|
|
|
|
#define _LINUX
|
|
|
|
|
#endif
|
2014-07-16 16:58:30 +08:00
|
|
|
#include <acpi/acpi.h>
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#include <linux/list.h>
|
2007-07-23 20:43:51 +08:00
|
|
|
#include <linux/mod_devicetable.h>
|
2014-05-22 18:47:47 +08:00
|
|
|
#include <linux/dynamic_debug.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#include <acpi/acpi_bus.h>
|
|
|
|
|
#include <acpi/acpi_drivers.h>
|
2006-06-23 17:03:19 +08:00
|
|
|
#include <acpi/acpi_numa.h>
|
2013-12-06 16:52:05 +08:00
|
|
|
#include <acpi/acpi_io.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/acpi.h>
|
|
|
|
|
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-12 05:41:56 +08:00
|
|
|
static inline acpi_handle acpi_device_handle(struct acpi_device *adev)
|
|
|
|
|
{
|
|
|
|
|
return adev ? adev->handle : NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define ACPI_COMPANION(dev) ((dev)->acpi_node.companion)
|
|
|
|
|
#define ACPI_COMPANION_SET(dev, adev) ACPI_COMPANION(dev) = (adev)
|
|
|
|
|
#define ACPI_HANDLE(dev) acpi_device_handle(ACPI_COMPANION(dev))
|
|
|
|
|
|
2013-11-29 06:58:28 +08:00
|
|
|
static inline void acpi_preset_companion(struct device *dev,
|
|
|
|
|
struct acpi_device *parent, u64 addr)
|
|
|
|
|
{
|
|
|
|
|
ACPI_COMPANION_SET(dev, acpi_find_child_device(parent, addr, NULL));
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-14 20:03:51 +08:00
|
|
|
static inline const char *acpi_dev_name(struct acpi_device *adev)
|
|
|
|
|
{
|
|
|
|
|
return dev_name(&adev->dev);
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
enum acpi_irq_model_id {
|
|
|
|
|
ACPI_IRQ_MODEL_PIC = 0,
|
|
|
|
|
ACPI_IRQ_MODEL_IOAPIC,
|
|
|
|
|
ACPI_IRQ_MODEL_IOSAPIC,
|
2006-12-23 01:50:04 +08:00
|
|
|
ACPI_IRQ_MODEL_PLATFORM,
|
2005-04-17 06:20:36 +08:00
|
|
|
ACPI_IRQ_MODEL_COUNT
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern enum acpi_irq_model_id acpi_irq_model;
|
|
|
|
|
|
|
|
|
|
enum acpi_interrupt_id {
|
|
|
|
|
ACPI_INTERRUPT_PMI = 1,
|
|
|
|
|
ACPI_INTERRUPT_INIT,
|
|
|
|
|
ACPI_INTERRUPT_CPEI,
|
|
|
|
|
ACPI_INTERRUPT_COUNT
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define ACPI_SPACE_MEM 0
|
|
|
|
|
|
|
|
|
|
enum acpi_address_range_id {
|
|
|
|
|
ACPI_ADDRESS_RANGE_MEMORY = 1,
|
|
|
|
|
ACPI_ADDRESS_RANGE_RESERVED = 2,
|
|
|
|
|
ACPI_ADDRESS_RANGE_ACPI = 3,
|
|
|
|
|
ACPI_ADDRESS_RANGE_NVS = 4,
|
|
|
|
|
ACPI_ADDRESS_RANGE_COUNT
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Table Handlers */
|
|
|
|
|
|
2013-01-12 23:29:38 +08:00
|
|
|
typedef int (*acpi_tbl_table_handler)(struct acpi_table_header *table);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-01-12 23:29:38 +08:00
|
|
|
typedef int (*acpi_tbl_entry_handler)(struct acpi_subtable_header *header,
|
|
|
|
|
const unsigned long end);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-10-01 06:23:54 +08:00
|
|
|
#ifdef CONFIG_ACPI_INITRD_TABLE_OVERRIDE
|
|
|
|
|
void acpi_initrd_override(void *data, size_t size);
|
|
|
|
|
#else
|
|
|
|
|
static inline void acpi_initrd_override(void *data, size_t size)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2014-02-19 00:23:57 +08:00
|
|
|
#define BAD_MADT_ENTRY(entry, end) ( \
|
|
|
|
|
(!entry) || (unsigned long)entry + sizeof(*entry) > end || \
|
|
|
|
|
((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
char * __acpi_map_table (unsigned long phys_addr, unsigned long size);
|
2009-02-16 06:06:13 +08:00
|
|
|
void __acpi_unmap_table(char *map, unsigned long size);
|
2008-02-19 19:21:06 +08:00
|
|
|
int early_acpi_boot_init(void);
|
2005-04-17 06:20:36 +08:00
|
|
|
int acpi_boot_init (void);
|
2010-01-07 05:11:06 +08:00
|
|
|
void acpi_boot_table_init (void);
|
2008-06-21 07:11:20 +08:00
|
|
|
int acpi_mps_check (void);
|
2005-04-17 06:20:36 +08:00
|
|
|
int acpi_numa_init (void);
|
|
|
|
|
|
|
|
|
|
int acpi_table_init (void);
|
2013-01-12 23:29:38 +08:00
|
|
|
int acpi_table_parse(char *id, acpi_tbl_table_handler handler);
|
2007-02-11 11:17:07 +08:00
|
|
|
int __init acpi_table_parse_entries(char *id, unsigned long table_size,
|
2013-01-12 23:29:38 +08:00
|
|
|
int entry_id,
|
|
|
|
|
acpi_tbl_entry_handler handler,
|
|
|
|
|
unsigned int max_entries);
|
|
|
|
|
int acpi_table_parse_madt(enum acpi_madt_type id,
|
|
|
|
|
acpi_tbl_entry_handler handler,
|
|
|
|
|
unsigned int max_entries);
|
2007-02-03 00:48:22 +08:00
|
|
|
int acpi_parse_mcfg (struct acpi_table_header *header);
|
2007-02-03 00:48:22 +08:00
|
|
|
void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/* the following four functions are architecture-dependent */
|
|
|
|
|
void acpi_numa_slit_init (struct acpi_table_slit *slit);
|
2007-02-03 00:48:22 +08:00
|
|
|
void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
|
2009-03-31 05:55:30 +08:00
|
|
|
void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
|
2012-07-31 23:41:09 +08:00
|
|
|
int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
|
2005-04-17 06:20:36 +08:00
|
|
|
void acpi_numa_arch_fixup(void);
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_HOTPLUG_CPU
|
|
|
|
|
/* Arch dependent functions for cpu hotplug support */
|
2013-09-02 11:57:35 +08:00
|
|
|
int acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu);
|
2005-04-17 06:20:36 +08:00
|
|
|
int acpi_unmap_lsapic(int cpu);
|
|
|
|
|
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
|
|
|
|
|
|
2005-04-28 15:25:58 +08:00
|
|
|
int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base);
|
|
|
|
|
int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base);
|
2008-02-06 14:26:55 +08:00
|
|
|
void acpi_irq_stats_init(void);
|
|
|
|
|
extern u32 acpi_irq_handled;
|
2009-04-21 12:35:47 +08:00
|
|
|
extern u32 acpi_irq_not_handled;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-02-21 10:27:58 +08:00
|
|
|
extern int sbf_port;
|
2007-07-19 16:47:41 +08:00
|
|
|
extern unsigned long acpi_realmode_flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-04-28 09:01:20 +08:00
|
|
|
int acpi_register_gsi (struct device *dev, u32 gsi, int triggering, int polarity);
|
2005-04-17 06:20:36 +08:00
|
|
|
int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
|
2010-03-30 16:07:02 +08:00
|
|
|
int acpi_isa_irq_to_gsi (unsigned isa_irq, u32 *gsi);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-11-17 14:05:28 +08:00
|
|
|
#ifdef CONFIG_X86_IO_APIC
|
2010-03-30 16:07:03 +08:00
|
|
|
extern int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity);
|
2007-11-17 14:05:28 +08:00
|
|
|
#else
|
2010-03-30 16:07:03 +08:00
|
|
|
#define acpi_get_override_irq(gsi, trigger, polarity) (-1)
|
2007-11-17 14:05:28 +08:00
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* This function undoes the effect of one call to acpi_register_gsi().
|
|
|
|
|
* If this matches the last registration, any IRQ resources for gsi
|
|
|
|
|
* are freed.
|
|
|
|
|
*/
|
|
|
|
|
void acpi_unregister_gsi (u32 gsi);
|
|
|
|
|
|
|
|
|
|
struct pci_dev;
|
|
|
|
|
|
|
|
|
|
int acpi_pci_irq_enable (struct pci_dev *dev);
|
2005-04-01 13:07:31 +08:00
|
|
|
void acpi_penalize_isa_irq(int irq, int active);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
void acpi_pci_irq_disable (struct pci_dev *dev);
|
|
|
|
|
|
|
|
|
|
extern int ec_read(u8 addr, u8 *val);
|
|
|
|
|
extern int ec_write(u8 addr, u8 val);
|
2006-09-06 00:12:24 +08:00
|
|
|
extern int ec_transaction(u8 command,
|
|
|
|
|
const u8 *wdata, unsigned wdata_len,
|
2011-03-31 19:36:38 +08:00
|
|
|
u8 *rdata, unsigned rdata_len);
|
2012-01-19 03:44:08 +08:00
|
|
|
extern acpi_handle ec_get_handle(void);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
ACPI / PNP: use device ID list for PNPACPI device enumeration
ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently. Namely, if an ACPI device
object
1. Has a _CRS method,
2. Has an identification of
"three capital characters followed by four hex digits",
3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it). This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.
However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them). As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices. That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.
To address that problem it is better to enumerate _HID devices
as platform devices by default. To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.
The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers. Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 10:23:01 +08:00
|
|
|
extern bool acpi_is_pnp_device(struct acpi_device *);
|
|
|
|
|
|
ACPI: WMI: Add ACPI-WMI mapping driver
The following is an implementation of the Windows Management
Instrumentation (WMI) ACPI interface mapper (PNP0C14).
What it does:
Parses the _WDG method and exports functions to process WMI method calls,
data block query/ set commands (both based on GUID) and does basic event
handling.
How: WMI presents an in kernel interface here (essentially, a minimal
wrapper around ACPI)
(const char *guid assume the 36 character ASCII representation of
a GUID - e.g. 67C3371D-95A3-4C37-BB61-DD47B491DAAB)
wmi_evaluate_method(const char *guid, u8 instance, u32 method_id,
const struct acpi_buffer *in, struct acpi_buffer *out)
wmi_query_block(const char *guid, u8 instance,
struct acpi_buffer *out)
wmi_set_block(const char *guid, u38 instance,
const struct acpi_buffer *in)
wmi_install_notify_handler(acpi_notify_handler handler);
wmi_remove_notify_handler(void);
wmi_get_event_data(u32 event, struct acpi_buffer *out)
wmi_has_guid(const char guid*)
wmi_has_guid() is a helper function to find if a GUID exists or not on the
system (a quick and easy way for WMI dependant drivers to see if the
the method/ block they want exists, since GUIDs are supposed to be unique).
Event handling - allow a WMI based driver to register a notifier handler
for each GUID with WMI. When a notification is sent to a GUID in WMI, the
handler registered with WMI is then called (it is left to the caller to
ask for the WMI event data associated with the GUID, if needed).
What it won't do:
Unicode - The MS article[1] calls for converting between ASCII and Unicode (or
vice versa) if a GUID is marked as "string". This is left up to the calling
driver.
Handle a MOF[1] - the WMI mapper just exports methods, data and events to
userspace. MOF handling is down to userspace.
Userspace interface - this will be added later.
[1] http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx
===
ChangeLog
==
v1 (2007-10-02):
* Initial release
v2 (2007-10-05):
* Cleaned up code - split up super "wmi_evaluate_block" -> each external
symbol now handles its own ACPI calls, rather than handing off to
a "super" method (and in turn, is a lot simpler to read)
* Added a find_guid() symbol - return true if a given GUID exists on
the system
* wmi_* functions now return type acpi_status (since they are just
fancy wrappers around acpi_evaluate_object())
* Removed extra debug code
v3 (2007-10-27)
* More code clean up - now passes checkpatch.pl
* Change data block calls - ref MS spec, method ID is not required for
them, so drop it from the function parameters.
* Const'ify guid in the function call parameters.
* Fix _WDG buffer handling - copy the data to our own private structure.
* Change WMI from tristate to bool - otherwise the external functions are
not exported in linux/acpi.h if you try to build WMI as a module.
* Fix more flag comparisons.
* Add a maintainers entry - since I wrote this, I should take the blame
for it.
v4 (2007-10-30)
* Add missing brace from after fixing checkpatch errors.
* Rewrote event handling - allow external drivers to register with WMI to
handle WMI events
* Clean up flags and sanitise flag handling
v5 (2007-11-03)
* Add sysfs interface for userspace. Export events over netlink again.
* Remove module left overs, fully convert to built-in driver.
* Tweak in-kernel API to use u8 for instance, since this is what the GUID
blocks use (so instance cannot be greater than u8).
* Export wmi_get_event_data() for in kernel WMI drivers.
v6 (2007-11-07)
* Split out userspace into a different patch
v7 (2007-11-20)
* Fix driver to handle multiple PNP0C14 devices - store all GUIDs using
the kernel's built in list functions, and just keep adding to the list
every time we handle a PNP0C14 devices - GUIDs will always be unique,
and WMI callers do not know or care about different devices.
* Change WMI event handler registration to use its' own event handling
struct; we should not pass an acpi_handle down to any WMI based drivers
- they should be able to function with only the calls provided in WMI.
* Update my e-mail address
v8 (2007-11-28)
* Convert back to a module.
* Update Kconfig to default to building as a module.
* Remove an erroneous printk.
* Simply comments for string flag (since we now leave the handling to the
caller).
v9 (2007-12-07)
* Add back missing MODULE_DEVICE_TABLE for autoloading
* Checkpatch fixes
v10 (2007-12-12)
* Workaround broken GUIDs declared expensive without a WCxx method.
* Minor cleanups
v11 (2007-12-17)
* More fixing for broken GUIDs declared expensive without a WCxx method.
* Add basic EmbeddedControl region handling.
v12 (2007-12-18)
* Changed EC region handling code, as per Alexey's comments.
v13 (2007-12-27)
* Changed event handling so that we can have one event handler registered
per GUID, as per Matthew Garrett's suggestion.
v14 (2008-01-12)
* Remove ACPI debug statements
v15 (2008-02-01)
* Replace two remaining 'x == NULL' type tests with '!x'
v16 (2008-02-05)
* Change MAINTAINERS entry, as I am not, and never have been, paid to work
on WMI
* Remove 'default' line from Kconfig
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
CC: Matthew Garrett <mjg59@srcf.ucam.org>
CC: Alexey Starikovskiy <aystarik@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-02-05 10:17:04 +08:00
|
|
|
#if defined(CONFIG_ACPI_WMI) || defined(CONFIG_ACPI_WMI_MODULE)
|
|
|
|
|
|
|
|
|
|
typedef void (*wmi_notify_handler) (u32 value, void *context);
|
|
|
|
|
|
|
|
|
|
extern acpi_status wmi_evaluate_method(const char *guid, u8 instance,
|
|
|
|
|
u32 method_id,
|
|
|
|
|
const struct acpi_buffer *in,
|
|
|
|
|
struct acpi_buffer *out);
|
|
|
|
|
extern acpi_status wmi_query_block(const char *guid, u8 instance,
|
|
|
|
|
struct acpi_buffer *out);
|
|
|
|
|
extern acpi_status wmi_set_block(const char *guid, u8 instance,
|
|
|
|
|
const struct acpi_buffer *in);
|
|
|
|
|
extern acpi_status wmi_install_notify_handler(const char *guid,
|
|
|
|
|
wmi_notify_handler handler, void *data);
|
|
|
|
|
extern acpi_status wmi_remove_notify_handler(const char *guid);
|
|
|
|
|
extern acpi_status wmi_get_event_data(u32 event, struct acpi_buffer *out);
|
|
|
|
|
extern bool wmi_has_guid(const char *guid);
|
|
|
|
|
|
|
|
|
|
#endif /* CONFIG_ACPI_WMI */
|
|
|
|
|
|
2008-08-01 23:37:55 +08:00
|
|
|
#define ACPI_VIDEO_OUTPUT_SWITCHING 0x0001
|
|
|
|
|
#define ACPI_VIDEO_DEVICE_POSTING 0x0002
|
|
|
|
|
#define ACPI_VIDEO_ROM_AVAILABLE 0x0004
|
|
|
|
|
#define ACPI_VIDEO_BACKLIGHT 0x0008
|
|
|
|
|
#define ACPI_VIDEO_BACKLIGHT_FORCE_VENDOR 0x0010
|
|
|
|
|
#define ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO 0x0020
|
|
|
|
|
#define ACPI_VIDEO_OUTPUT_SWITCHING_FORCE_VENDOR 0x0040
|
|
|
|
|
#define ACPI_VIDEO_OUTPUT_SWITCHING_FORCE_VIDEO 0x0080
|
|
|
|
|
#define ACPI_VIDEO_BACKLIGHT_DMI_VENDOR 0x0100
|
|
|
|
|
#define ACPI_VIDEO_BACKLIGHT_DMI_VIDEO 0x0200
|
|
|
|
|
#define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VENDOR 0x0400
|
|
|
|
|
#define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VIDEO 0x0800
|
|
|
|
|
|
|
|
|
|
#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
|
|
|
|
|
|
|
|
|
|
extern long acpi_video_get_capabilities(acpi_handle graphics_dev_handle);
|
2013-03-05 05:30:41 +08:00
|
|
|
extern long acpi_is_video_device(acpi_handle handle);
|
2012-06-13 15:32:01 +08:00
|
|
|
extern void acpi_video_dmi_promote_vendor(void);
|
|
|
|
|
extern void acpi_video_dmi_demote_vendor(void);
|
2008-08-01 23:37:55 +08:00
|
|
|
extern int acpi_video_backlight_support(void);
|
|
|
|
|
extern int acpi_video_display_switch_support(void);
|
|
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
static inline long acpi_video_get_capabilities(acpi_handle graphics_dev_handle)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-05 05:30:41 +08:00
|
|
|
static inline long acpi_is_video_device(acpi_handle handle)
|
2008-08-01 23:37:55 +08:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-13 15:32:01 +08:00
|
|
|
static inline void acpi_video_dmi_promote_vendor(void)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void acpi_video_dmi_demote_vendor(void)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2008-08-01 23:37:55 +08:00
|
|
|
static inline int acpi_video_backlight_support(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int acpi_video_display_switch_support(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif /* defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) */
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
extern int acpi_blacklisted(void);
|
2008-01-24 09:50:56 +08:00
|
|
|
extern void acpi_dmi_osi_linux(int enable, const struct dmi_system_id *d);
|
2010-12-09 16:50:52 +08:00
|
|
|
extern void acpi_osi_setup(char *str);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_NUMA
|
2014-01-25 06:25:10 +08:00
|
|
|
int acpi_get_node(acpi_handle handle);
|
2005-04-17 06:20:36 +08:00
|
|
|
#else
|
2014-01-25 06:25:10 +08:00
|
|
|
static inline int acpi_get_node(acpi_handle handle)
|
2006-06-27 17:53:31 +08:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif
|
2006-06-27 17:53:31 +08:00
|
|
|
extern int acpi_paddr_to_node(u64 start_addr, u64 size);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
extern int pnpacpi_disabled;
|
|
|
|
|
|
2007-07-21 23:10:32 +08:00
|
|
|
#define PXM_INVAL (-1)
|
|
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res);
|
|
|
|
|
bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res);
|
|
|
|
|
bool acpi_dev_resource_address_space(struct acpi_resource *ares,
|
|
|
|
|
struct resource *res);
|
|
|
|
|
bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
|
|
|
|
|
struct resource *res);
|
|
|
|
|
unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable);
|
|
|
|
|
bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
|
|
|
|
|
struct resource *res);
|
|
|
|
|
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
struct resource_list_entry {
|
|
|
|
|
struct list_head node;
|
|
|
|
|
struct resource res;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void acpi_dev_free_resource_list(struct list_head *list);
|
|
|
|
|
int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
|
|
|
|
|
int (*preproc)(struct acpi_resource *, void *),
|
|
|
|
|
void *preproc_data);
|
|
|
|
|
|
2009-11-11 22:22:15 +08:00
|
|
|
int acpi_check_resource_conflict(const struct resource *res);
|
2008-02-05 15:31:23 +08:00
|
|
|
|
2008-02-05 15:31:22 +08:00
|
|
|
int acpi_check_region(resource_size_t start, resource_size_t n,
|
|
|
|
|
const char *name);
|
|
|
|
|
|
2010-05-28 01:58:37 +08:00
|
|
|
int acpi_resources_are_enforced(void);
|
|
|
|
|
|
2012-10-26 19:39:24 +08:00
|
|
|
#ifdef CONFIG_HIBERNATION
|
2008-07-24 12:28:41 +08:00
|
|
|
void __init acpi_no_s4_hw_signature(void);
|
2012-10-26 19:39:24 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM_SLEEP
|
2008-06-13 05:24:06 +08:00
|
|
|
void __init acpi_old_suspend_ordering(void);
|
2010-07-24 04:59:09 +08:00
|
|
|
void __init acpi_nvs_nosave(void);
|
2012-10-26 19:39:15 +08:00
|
|
|
void __init acpi_nvs_nosave_s3(void);
|
2008-06-13 05:24:06 +08:00
|
|
|
#endif /* CONFIG_PM_SLEEP */
|
2009-02-09 15:00:04 +08:00
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
struct acpi_osc_context {
|
2013-09-06 05:05:55 +08:00
|
|
|
char *uuid_str; /* UUID string */
|
2009-10-29 11:04:28 +08:00
|
|
|
int rev;
|
2013-09-06 05:05:55 +08:00
|
|
|
struct acpi_buffer cap; /* list of DWORD capabilities */
|
|
|
|
|
struct acpi_buffer ret; /* free by caller if success */
|
2009-10-29 11:04:28 +08:00
|
|
|
};
|
|
|
|
|
|
2013-10-22 05:29:25 +08:00
|
|
|
acpi_status acpi_str_to_uuid(char *str, u8 *uuid);
|
2009-10-29 11:04:28 +08:00
|
|
|
acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
|
|
|
|
|
|
2013-09-06 05:05:54 +08:00
|
|
|
/* Indexes into _OSC Capabilities Buffer (DWORDs 2 & 3 are device-specific) */
|
|
|
|
|
#define OSC_QUERY_DWORD 0 /* DWORD 1 */
|
|
|
|
|
#define OSC_SUPPORT_DWORD 1 /* DWORD 2 */
|
|
|
|
|
#define OSC_CONTROL_DWORD 2 /* DWORD 3 */
|
2009-02-09 15:00:04 +08:00
|
|
|
|
2013-09-06 05:05:53 +08:00
|
|
|
/* _OSC Capabilities DWORD 1: Query/Control and Error Returns (generic) */
|
|
|
|
|
#define OSC_QUERY_ENABLE 0x00000001 /* input */
|
|
|
|
|
#define OSC_REQUEST_ERROR 0x00000002 /* return */
|
|
|
|
|
#define OSC_INVALID_UUID_ERROR 0x00000004 /* return */
|
|
|
|
|
#define OSC_INVALID_REVISION_ERROR 0x00000008 /* return */
|
|
|
|
|
#define OSC_CAPABILITIES_MASK_ERROR 0x00000010 /* return */
|
2009-02-09 15:00:04 +08:00
|
|
|
|
2013-09-06 05:05:53 +08:00
|
|
|
/* Platform-Wide Capabilities _OSC: Capabilities DWORD 2: Support Field */
|
|
|
|
|
#define OSC_SB_PAD_SUPPORT 0x00000001
|
|
|
|
|
#define OSC_SB_PPC_OST_SUPPORT 0x00000002
|
|
|
|
|
#define OSC_SB_PR3_SUPPORT 0x00000004
|
|
|
|
|
#define OSC_SB_HOTPLUG_OST_SUPPORT 0x00000008
|
|
|
|
|
#define OSC_SB_APEI_SUPPORT 0x00000010
|
|
|
|
|
#define OSC_SB_CPC_SUPPORT 0x00000020
|
2009-10-29 11:05:05 +08:00
|
|
|
|
2011-07-13 13:14:20 +08:00
|
|
|
extern bool osc_sb_apei_support_acked;
|
|
|
|
|
|
2013-09-06 05:05:53 +08:00
|
|
|
/* PCI Host Bridge _OSC: Capabilities DWORD 2: Support Field */
|
2013-09-06 05:07:39 +08:00
|
|
|
#define OSC_PCI_EXT_CONFIG_SUPPORT 0x00000001
|
|
|
|
|
#define OSC_PCI_ASPM_SUPPORT 0x00000002
|
|
|
|
|
#define OSC_PCI_CLOCK_PM_SUPPORT 0x00000004
|
2013-09-06 05:05:53 +08:00
|
|
|
#define OSC_PCI_SEGMENT_GROUPS_SUPPORT 0x00000008
|
2013-09-06 05:07:39 +08:00
|
|
|
#define OSC_PCI_MSI_SUPPORT 0x00000010
|
2013-09-06 05:05:53 +08:00
|
|
|
#define OSC_PCI_SUPPORT_MASKS 0x0000001f
|
|
|
|
|
|
|
|
|
|
/* PCI Host Bridge _OSC: Capabilities DWORD 3: Control Field */
|
|
|
|
|
#define OSC_PCI_EXPRESS_NATIVE_HP_CONTROL 0x00000001
|
2013-09-06 05:07:39 +08:00
|
|
|
#define OSC_PCI_SHPC_NATIVE_HP_CONTROL 0x00000002
|
2013-09-06 05:05:53 +08:00
|
|
|
#define OSC_PCI_EXPRESS_PME_CONTROL 0x00000004
|
|
|
|
|
#define OSC_PCI_EXPRESS_AER_CONTROL 0x00000008
|
2013-09-06 05:07:39 +08:00
|
|
|
#define OSC_PCI_EXPRESS_CAPABILITY_CONTROL 0x00000010
|
2013-09-06 05:24:24 +08:00
|
|
|
#define OSC_PCI_CONTROL_MASKS 0x0000001f
|
2011-11-07 06:11:28 +08:00
|
|
|
|
I2C/ACPI: Add i2c ACPI operation region support
ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation region.
It allows ACPI aml code able to access such kind of devices to implement
some ACPI standard method.
ACPI Spec defines some access attribute to associate with i2c protocol.
AttribQuick Read/Write Quick Protocol
AttribSendReceive Send/Receive Byte Protocol
AttribByte Read/Write Byte Protocol
AttribWord Read/Write Word Protocol
AttribBlock Read/Write Block Protocol
AttribBytes Read/Write N-Bytes Protocol
AttribProcessCall Process Call Protocol
AttribBlockProcessCall Write Block-Read Block Process Call Protocol
AttribRawBytes Raw Read/Write N-BytesProtocol
AttribRawProcessBytes Raw Process Call Protocol
On the Asus T100TA, Bios use GenericSerialBus operation region to access
i2c device to get battery info.
Sample code From Asus T100TA
Scope (_SB.I2C1)
{
Name (UMPC, ResourceTemplate ()
{
I2cSerialBus (0x0066, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C1",
0x00, ResourceConsumer, ,
)
})
...
OperationRegion (DVUM, GenericSerialBus, Zero, 0x0100)
Field (DVUM, BufferAcc, NoLock, Preserve)
{
Connection (UMPC),
Offset (0x81),
AccessAs (BufferAcc, AttribBytes (0x3E)),
FGC0, 8
}
...
}
Device (BATC)
{
Name (_HID, EisaId ("PNP0C0A")) // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
...
Method (_BST, 0, NotSerialized) // _BST: Battery Status
{
If (LEqual (AVBL, One))
{
Store (FGC0, BFFG)
If (LNotEqual (STAT, One))
{
ShiftRight (CHST, 0x04, Local0)
And (Local0, 0x03, Local0)
If (LOr (LEqual (Local0, One), LEqual (Local0, 0x02)))
{
Store (0x02, Local1)
}
...
}
The i2c operation region is defined under I2C1 scope. _BST method under
battery device BATC read battery status from the field "FCG0". The request
would be sent to i2c operation region handler.
This patch is to add i2c ACPI operation region support. Due to there are
only "Byte" and "Bytes" protocol access on the Asus T100TA, other protocols
have not been tested.
About RawBytes and RawProcessBytes protocol, they needs specific drivers to interpret
reference data from AML code according ACPI 5.0 SPEC(5.5.2.4.5.3.9 and 5.5.2.4.5.3.10).
So far, not found such case and will add when find real case.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-05-20 20:59:23 +08:00
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_QUICK 0x00000002
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_SEND_RCV 0x00000004
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_BYTE 0x00000006
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_WORD 0x00000008
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_BLOCK 0x0000000A
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_MULTIBYTE 0x0000000B
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_WORD_CALL 0x0000000C
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_BLOCK_CALL 0x0000000D
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_RAW_BYTES 0x0000000E
|
|
|
|
|
#define ACPI_GSB_ACCESS_ATTRIB_RAW_PROCESS 0x0000000F
|
|
|
|
|
|
2010-08-24 05:53:11 +08:00
|
|
|
extern acpi_status acpi_pci_osc_control_set(acpi_handle handle,
|
|
|
|
|
u32 *mask, u32 req);
|
2012-05-24 10:25:19 +08:00
|
|
|
|
|
|
|
|
/* Enable _OST when all relevant hotplug operations are enabled */
|
|
|
|
|
#if defined(CONFIG_ACPI_HOTPLUG_CPU) && \
|
2013-06-19 05:06:45 +08:00
|
|
|
defined(CONFIG_ACPI_HOTPLUG_MEMORY) && \
|
2013-02-12 06:33:20 +08:00
|
|
|
defined(CONFIG_ACPI_CONTAINER)
|
2012-05-24 10:25:19 +08:00
|
|
|
#define ACPI_HOTPLUG_OST
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* _OST Source Event Code (OSPM Action) */
|
|
|
|
|
#define ACPI_OST_EC_OSPM_SHUTDOWN 0x100
|
|
|
|
|
#define ACPI_OST_EC_OSPM_EJECT 0x103
|
|
|
|
|
#define ACPI_OST_EC_OSPM_INSERTION 0x200
|
|
|
|
|
|
|
|
|
|
/* _OST General Processing Status Code */
|
|
|
|
|
#define ACPI_OST_SC_SUCCESS 0x0
|
|
|
|
|
#define ACPI_OST_SC_NON_SPECIFIC_FAILURE 0x1
|
|
|
|
|
#define ACPI_OST_SC_UNRECOGNIZED_NOTIFY 0x2
|
|
|
|
|
|
|
|
|
|
/* _OST OS Shutdown Processing (0x100) Status Code */
|
|
|
|
|
#define ACPI_OST_SC_OS_SHUTDOWN_DENIED 0x80
|
|
|
|
|
#define ACPI_OST_SC_OS_SHUTDOWN_IN_PROGRESS 0x81
|
|
|
|
|
#define ACPI_OST_SC_OS_SHUTDOWN_COMPLETED 0x82
|
|
|
|
|
#define ACPI_OST_SC_OS_SHUTDOWN_NOT_SUPPORTED 0x83
|
|
|
|
|
|
|
|
|
|
/* _OST Ejection Request (0x3, 0x103) Status Code */
|
|
|
|
|
#define ACPI_OST_SC_EJECT_NOT_SUPPORTED 0x80
|
|
|
|
|
#define ACPI_OST_SC_DEVICE_IN_USE 0x81
|
|
|
|
|
#define ACPI_OST_SC_DEVICE_BUSY 0x82
|
|
|
|
|
#define ACPI_OST_SC_EJECT_DEPENDENCY_BUSY 0x83
|
|
|
|
|
#define ACPI_OST_SC_EJECT_IN_PROGRESS 0x84
|
|
|
|
|
|
|
|
|
|
/* _OST Insertion Request (0x200) Status Code */
|
|
|
|
|
#define ACPI_OST_SC_INSERT_IN_PROGRESS 0x80
|
|
|
|
|
#define ACPI_OST_SC_DRIVER_LOAD_FAILURE 0x81
|
|
|
|
|
#define ACPI_OST_SC_INSERT_NOT_SUPPORTED 0x82
|
|
|
|
|
|
2009-06-13 08:42:08 +08:00
|
|
|
extern void acpi_early_init(void);
|
|
|
|
|
|
2011-12-08 11:25:49 +08:00
|
|
|
extern int acpi_nvs_register(__u64 start, __u64 size);
|
|
|
|
|
|
|
|
|
|
extern int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
|
|
|
|
|
void *data);
|
|
|
|
|
|
2012-11-01 05:44:41 +08:00
|
|
|
const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
|
|
|
|
|
const struct device *dev);
|
|
|
|
|
|
|
|
|
|
static inline bool acpi_driver_match_device(struct device *dev,
|
|
|
|
|
const struct device_driver *drv)
|
|
|
|
|
{
|
|
|
|
|
return !!acpi_match_device(drv->acpi_match_table, dev);
|
|
|
|
|
}
|
|
|
|
|
|
ACPI: add module autoloading support for ACPI enumerated devices
An ACPI enumerated device may have its compatible id strings.
To support the compatible ACPI ids (acpi_device->pnp.ids),
we introduced acpi_driver_match_device() to match
the driver->acpi_match_table and acpi_device->pnp.ids.
For those drivers, MODULE_DEVICE_TABLE(acpi, xxx) is used to
exports the driver module alias in the format of
"acpi:device_compatible_ids".
But in the mean time, the current code does not export the
ACPI compatible strings as part of the module_alias for the
ACPI enumerated devices, which will break the module autoloading.
Take the following piece of code for example,
static const struct acpi_device_id xxx_acpi_match[] = {
{ "INTABCD", 0 },
{ }
};
MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);
If this piece of code is used in a platform driver for
an ACPI enumerated platform device, the platform driver module_alias
is "acpi:INTABCD", but the uevent attribute of its platform device node
is "platform:INTABCD:00" (PREFIX:platform_device->name).
If this piece of code is used in an i2c driver for an ACPI enumerated
i2c device, the i2c driver module_alias is "acpi:INTABCD", but
the uevent of its i2c device node is "i2c:INTABCD:00" (PREFIX:i2c_client->name).
If this piece of code is used in an spi driver for an ACPI enumerated
spi device, the spi driver module_alias is "acpi:INTABCD", but
the uevent of its spi device node is "spi:INTABCD" (PREFIX:spi_device->modalias).
The reason why the module autoloading is not broken for now is that
the uevent file of the ACPI device node is "acpi:INTABCD".
Thus it is the ACPI device node creation that loads the platform/i2c/spi driver.
So this is a problem that will affect us the day when the ACPI bus
is removed from device model.
This patch introduces two new APIs,
one for exporting ACPI ids in uevent MODALIAS field,
and another for exporting ACPI ids in device' modalias sysfs attribute.
For any bus that supports ACPI enumerated devices, it needs to invoke
these two functions for their uevent and modalias attribute.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-14 16:46:36 +08:00
|
|
|
int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
|
|
|
|
|
int acpi_device_modalias(struct device *, char *, int);
|
|
|
|
|
|
2012-11-01 05:44:41 +08:00
|
|
|
#define ACPI_PTR(_ptr) (_ptr)
|
|
|
|
|
|
2009-07-28 17:41:53 +08:00
|
|
|
#else /* !CONFIG_ACPI */
|
|
|
|
|
|
|
|
|
|
#define acpi_disabled 1
|
|
|
|
|
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-12 05:41:56 +08:00
|
|
|
#define ACPI_COMPANION(dev) (NULL)
|
|
|
|
|
#define ACPI_COMPANION_SET(dev, adev) do { } while (0)
|
|
|
|
|
#define ACPI_HANDLE(dev) (NULL)
|
|
|
|
|
|
2013-11-14 20:03:51 +08:00
|
|
|
static inline const char *acpi_dev_name(struct acpi_device *adev)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-13 08:42:08 +08:00
|
|
|
static inline void acpi_early_init(void) { }
|
2005-07-30 16:18:00 +08:00
|
|
|
|
2008-02-19 19:21:06 +08:00
|
|
|
static inline int early_acpi_boot_init(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2005-07-30 16:18:00 +08:00
|
|
|
static inline int acpi_boot_init(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-07 05:11:06 +08:00
|
|
|
static inline void acpi_boot_table_init(void)
|
2005-07-30 16:18:00 +08:00
|
|
|
{
|
2010-01-07 05:11:06 +08:00
|
|
|
return;
|
2005-07-30 16:18:00 +08:00
|
|
|
}
|
|
|
|
|
|
2008-06-21 07:11:20 +08:00
|
|
|
static inline int acpi_mps_check(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-02-05 15:31:23 +08:00
|
|
|
static inline int acpi_check_resource_conflict(struct resource *res)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-02-05 15:31:22 +08:00
|
|
|
static inline int acpi_check_region(resource_size_t start, resource_size_t n,
|
|
|
|
|
const char *name)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-28 17:41:53 +08:00
|
|
|
struct acpi_table_header;
|
|
|
|
|
static inline int acpi_table_parse(char *id,
|
|
|
|
|
int (*handler)(struct acpi_table_header *))
|
|
|
|
|
{
|
2014-01-06 16:47:59 +08:00
|
|
|
return -ENODEV;
|
2009-07-28 17:41:53 +08:00
|
|
|
}
|
2011-01-13 05:03:20 +08:00
|
|
|
|
2011-12-08 11:25:49 +08:00
|
|
|
static inline int acpi_nvs_register(__u64 start, __u64 size)
|
2011-01-13 05:03:20 +08:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2011-12-08 11:25:49 +08:00
|
|
|
|
|
|
|
|
static inline int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-01 05:44:41 +08:00
|
|
|
struct acpi_device_id;
|
|
|
|
|
|
|
|
|
|
static inline const struct acpi_device_id *acpi_match_device(
|
|
|
|
|
const struct acpi_device_id *ids, const struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool acpi_driver_match_device(struct device *dev,
|
|
|
|
|
const struct device_driver *drv)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
ACPI: add module autoloading support for ACPI enumerated devices
An ACPI enumerated device may have its compatible id strings.
To support the compatible ACPI ids (acpi_device->pnp.ids),
we introduced acpi_driver_match_device() to match
the driver->acpi_match_table and acpi_device->pnp.ids.
For those drivers, MODULE_DEVICE_TABLE(acpi, xxx) is used to
exports the driver module alias in the format of
"acpi:device_compatible_ids".
But in the mean time, the current code does not export the
ACPI compatible strings as part of the module_alias for the
ACPI enumerated devices, which will break the module autoloading.
Take the following piece of code for example,
static const struct acpi_device_id xxx_acpi_match[] = {
{ "INTABCD", 0 },
{ }
};
MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);
If this piece of code is used in a platform driver for
an ACPI enumerated platform device, the platform driver module_alias
is "acpi:INTABCD", but the uevent attribute of its platform device node
is "platform:INTABCD:00" (PREFIX:platform_device->name).
If this piece of code is used in an i2c driver for an ACPI enumerated
i2c device, the i2c driver module_alias is "acpi:INTABCD", but
the uevent of its i2c device node is "i2c:INTABCD:00" (PREFIX:i2c_client->name).
If this piece of code is used in an spi driver for an ACPI enumerated
spi device, the spi driver module_alias is "acpi:INTABCD", but
the uevent of its spi device node is "spi:INTABCD" (PREFIX:spi_device->modalias).
The reason why the module autoloading is not broken for now is that
the uevent file of the ACPI device node is "acpi:INTABCD".
Thus it is the ACPI device node creation that loads the platform/i2c/spi driver.
So this is a problem that will affect us the day when the ACPI bus
is removed from device model.
This patch introduces two new APIs,
one for exporting ACPI ids in uevent MODALIAS field,
and another for exporting ACPI ids in device' modalias sysfs attribute.
For any bus that supports ACPI enumerated devices, it needs to invoke
these two functions for their uevent and modalias attribute.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-14 16:46:36 +08:00
|
|
|
static inline int acpi_device_uevent_modalias(struct device *dev,
|
|
|
|
|
struct kobj_uevent_env *env)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int acpi_device_modalias(struct device *dev,
|
|
|
|
|
char *buf, int size)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-01 05:44:41 +08:00
|
|
|
#define ACPI_PTR(_ptr) (NULL)
|
|
|
|
|
|
2011-12-08 11:25:49 +08:00
|
|
|
#endif /* !CONFIG_ACPI */
|
2011-01-13 05:03:20 +08:00
|
|
|
|
2011-12-09 10:05:54 +08:00
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
|
void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
|
|
|
|
|
u32 pm1a_ctrl, u32 pm1b_ctrl));
|
|
|
|
|
|
|
|
|
|
acpi_status acpi_os_prepare_sleep(u8 sleep_state,
|
|
|
|
|
u32 pm1a_control, u32 pm1b_control);
|
2013-07-30 20:24:52 +08:00
|
|
|
|
|
|
|
|
void acpi_os_set_prepare_extended_sleep(int (*func)(u8 sleep_state,
|
|
|
|
|
u32 val_a, u32 val_b));
|
|
|
|
|
|
|
|
|
|
acpi_status acpi_os_prepare_extended_sleep(u8 sleep_state,
|
|
|
|
|
u32 val_a, u32 val_b);
|
|
|
|
|
|
2012-10-06 06:05:34 +08:00
|
|
|
#ifdef CONFIG_X86
|
2012-10-01 06:23:53 +08:00
|
|
|
void arch_reserve_mem_area(acpi_physical_address addr, size_t size);
|
|
|
|
|
#else
|
|
|
|
|
static inline void arch_reserve_mem_area(acpi_physical_address addr,
|
|
|
|
|
size_t size)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
#endif /* CONFIG_X86 */
|
2011-12-09 10:05:54 +08:00
|
|
|
#else
|
|
|
|
|
#define acpi_os_set_prepare_sleep(func, pm1a_ctrl, pm1b_ctrl) do { } while (0)
|
|
|
|
|
#endif
|
|
|
|
|
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 08:41:01 +08:00
|
|
|
#if defined(CONFIG_ACPI) && defined(CONFIG_PM_RUNTIME)
|
|
|
|
|
int acpi_dev_runtime_suspend(struct device *dev);
|
|
|
|
|
int acpi_dev_runtime_resume(struct device *dev);
|
|
|
|
|
int acpi_subsys_runtime_suspend(struct device *dev);
|
|
|
|
|
int acpi_subsys_runtime_resume(struct device *dev);
|
|
|
|
|
#else
|
|
|
|
|
static inline int acpi_dev_runtime_suspend(struct device *dev) { return 0; }
|
|
|
|
|
static inline int acpi_dev_runtime_resume(struct device *dev) { return 0; }
|
|
|
|
|
static inline int acpi_subsys_runtime_suspend(struct device *dev) { return 0; }
|
|
|
|
|
static inline int acpi_subsys_runtime_resume(struct device *dev) { return 0; }
|
|
|
|
|
#endif
|
|
|
|
|
|
2013-01-19 21:29:31 +08:00
|
|
|
#if defined(CONFIG_ACPI) && defined(CONFIG_PM_SLEEP)
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 08:41:01 +08:00
|
|
|
int acpi_dev_suspend_late(struct device *dev);
|
|
|
|
|
int acpi_dev_resume_early(struct device *dev);
|
|
|
|
|
int acpi_subsys_prepare(struct device *dev);
|
2014-05-15 21:40:23 +08:00
|
|
|
void acpi_subsys_complete(struct device *dev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 08:41:01 +08:00
|
|
|
int acpi_subsys_suspend_late(struct device *dev);
|
|
|
|
|
int acpi_subsys_resume_early(struct device *dev);
|
2014-05-15 21:40:23 +08:00
|
|
|
int acpi_subsys_suspend(struct device *dev);
|
|
|
|
|
int acpi_subsys_freeze(struct device *dev);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 08:41:01 +08:00
|
|
|
#else
|
|
|
|
|
static inline int acpi_dev_suspend_late(struct device *dev) { return 0; }
|
|
|
|
|
static inline int acpi_dev_resume_early(struct device *dev) { return 0; }
|
|
|
|
|
static inline int acpi_subsys_prepare(struct device *dev) { return 0; }
|
2014-05-15 21:40:23 +08:00
|
|
|
static inline void acpi_subsys_complete(struct device *dev) {}
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 08:41:01 +08:00
|
|
|
static inline int acpi_subsys_suspend_late(struct device *dev) { return 0; }
|
|
|
|
|
static inline int acpi_subsys_resume_early(struct device *dev) { return 0; }
|
2014-05-15 21:40:23 +08:00
|
|
|
static inline int acpi_subsys_suspend(struct device *dev) { return 0; }
|
|
|
|
|
static inline int acpi_subsys_freeze(struct device *dev) { return 0; }
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 08:41:01 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if defined(CONFIG_ACPI) && defined(CONFIG_PM)
|
2012-12-23 07:02:44 +08:00
|
|
|
struct acpi_device *acpi_dev_pm_get_node(struct device *dev);
|
2012-11-26 17:03:06 +08:00
|
|
|
int acpi_dev_pm_attach(struct device *dev, bool power_on);
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 08:41:01 +08:00
|
|
|
#else
|
2012-12-23 07:02:44 +08:00
|
|
|
static inline struct acpi_device *acpi_dev_pm_get_node(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2012-11-26 17:03:06 +08:00
|
|
|
static inline int acpi_dev_pm_attach(struct device *dev, bool power_on)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
ACPI / PM: Provide ACPI PM callback routines for subsystems
Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform). If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.
For this reason, provide a set of routines that may be used as power
management callbacks for such devices. This may be done in three
different ways.
(1) Device drivers handling the devices in question may run
acpi_dev_pm_attach() in their .probe() routines, which (on
success) will cause the devices to be added to the general ACPI
PM domain and ACPI power management will be used for them going
forward. Then, acpi_dev_pm_detach() may be used to remove the
devices from the general ACPI PM domain if ACPI power management
is not necessary for them any more.
(2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
power management callbacks in the same way as the general ACPI
PM domain does that.
(3) The devices' drivers may execute acpi_dev_suspend_late(),
acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
acpi_dev_runtime_resume() from their power management callbacks
as appropriate, if that's absolutely necessary, but it is not
recommended to do that, because such drivers may not work
without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-02 08:41:01 +08:00
|
|
|
#endif
|
|
|
|
|
|
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
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
|
__printf(3, 4)
|
|
|
|
|
void acpi_handle_printk(const char *level, acpi_handle handle,
|
|
|
|
|
const char *fmt, ...);
|
|
|
|
|
#else /* !CONFIG_ACPI */
|
|
|
|
|
static inline __printf(3, 4) void
|
|
|
|
|
acpi_handle_printk(const char *level, void *handle, const char *fmt, ...) {}
|
|
|
|
|
#endif /* !CONFIG_ACPI */
|
|
|
|
|
|
2014-05-22 18:47:47 +08:00
|
|
|
#if defined(CONFIG_ACPI) && defined(CONFIG_DYNAMIC_DEBUG)
|
|
|
|
|
__printf(3, 4)
|
|
|
|
|
void __acpi_handle_debug(struct _ddebug *descriptor, acpi_handle handle, const char *fmt, ...);
|
|
|
|
|
#else
|
|
|
|
|
#define __acpi_handle_debug(descriptor, handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__);
|
|
|
|
|
#endif
|
|
|
|
|
|
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_<level>: Print message with ACPI prefix and object path
|
|
|
|
|
*
|
|
|
|
|
* These interfaces acquire the global namespace mutex to obtain an object
|
|
|
|
|
* path. In interrupt context, it shows the object path as <n/a>.
|
|
|
|
|
*/
|
|
|
|
|
#define acpi_handle_emerg(handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_EMERG, handle, fmt, ##__VA_ARGS__)
|
|
|
|
|
#define acpi_handle_alert(handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_ALERT, handle, fmt, ##__VA_ARGS__)
|
|
|
|
|
#define acpi_handle_crit(handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_CRIT, handle, fmt, ##__VA_ARGS__)
|
|
|
|
|
#define acpi_handle_err(handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_ERR, handle, fmt, ##__VA_ARGS__)
|
|
|
|
|
#define acpi_handle_warn(handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_WARNING, handle, fmt, ##__VA_ARGS__)
|
|
|
|
|
#define acpi_handle_notice(handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_NOTICE, handle, fmt, ##__VA_ARGS__)
|
|
|
|
|
#define acpi_handle_info(handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_INFO, handle, fmt, ##__VA_ARGS__)
|
|
|
|
|
|
2014-05-22 18:47:47 +08:00
|
|
|
#if defined(DEBUG)
|
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
|
|
|
#define acpi_handle_debug(handle, fmt, ...) \
|
|
|
|
|
acpi_handle_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__)
|
|
|
|
|
#else
|
2014-05-22 18:47:47 +08:00
|
|
|
#if defined(CONFIG_DYNAMIC_DEBUG)
|
|
|
|
|
#define acpi_handle_debug(handle, fmt, ...) \
|
|
|
|
|
do { \
|
|
|
|
|
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
|
|
|
|
|
if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT)) \
|
|
|
|
|
__acpi_handle_debug(&descriptor, handle, pr_fmt(fmt), \
|
|
|
|
|
##__VA_ARGS__); \
|
|
|
|
|
} while (0)
|
|
|
|
|
#else
|
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
|
|
|
#define acpi_handle_debug(handle, fmt, ...) \
|
|
|
|
|
({ \
|
|
|
|
|
if (0) \
|
|
|
|
|
acpi_handle_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__); \
|
|
|
|
|
0; \
|
|
|
|
|
})
|
|
|
|
|
#endif
|
2014-05-22 18:47:47 +08:00
|
|
|
#endif
|
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
|
|
|
|
2005-05-27 16:21:50 +08:00
|
|
|
#endif /*_LINUX_ACPI_H*/
|