2019-05-27 14:55:06 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* acpi.h - ACPI Interface
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#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 */
|
acpi/irq: Implement helper to create hierachical domains
ACPI permits arbitrary producer->consumer interrupt links to be
described in AML, which means a topology such as the following
is perfectly legal:
Device (EXIU) {
Name (_HID, "SCX0008")
Name (_UID, Zero)
Name (_CRS, ResourceTemplate () {
...
})
}
Device (GPIO) {
Name (_HID, "SCX0007")
Name (_UID, Zero)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, SYNQUACER_GPIO_BASE, SYNQUACER_GPIO_SIZE)
Interrupt (ResourceConsumer, Edge, ActiveHigh, ExclusiveAndWake, 0, "\\_SB.EXIU") {
7,
}
})
...
}
The EXIU in this example is the external interrupt unit as can be found
on Socionext SynQuacer based platforms, which converts a block of 32 SPIs
from arbitrary polarity/trigger into level-high, with a separate set
of config/mask/unmask/clear controls.
The existing DT based driver in drivers/irqchip/irq-sni-exiu.c models
this as a hierarchical domain stacked on top of the GIC's irqdomain.
Since the GIC is modeled as a DT node as well, obtaining a reference
to this irqdomain is easily done by going through the parent link.
On ACPI systems, however, the GIC is not modeled as an object in the
namespace, and so device objects cannot refer to it directly. So in
order to obtain the irqdomain reference when driving the EXIU in ACPI
mode, we need a helper that implicitly grabs the default domain as the
parent of the hierarchy for interrupts allocated out of the global GSI
pool.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-05-28 21:36:44 +08:00
|
|
|
#include <linux/irqdomain.h>
|
2015-02-05 13:44:43 +08:00
|
|
|
#include <linux/resource_ext.h>
|
2012-11-01 05:44:41 +08:00
|
|
|
#include <linux/device.h>
|
2014-11-04 08:28:56 +08:00
|
|
|
#include <linux/property.h>
|
2017-06-08 15:02:20 +08:00
|
|
|
#include <linux/uuid.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>
|
2015-12-03 10:43:14 +08:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/mutex.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;
|
|
|
|
}
|
|
|
|
|
2015-08-27 10:40:05 +08:00
|
|
|
#define ACPI_COMPANION(dev) to_acpi_device_node((dev)->fwnode)
|
2015-04-04 05:23:37 +08:00
|
|
|
#define ACPI_COMPANION_SET(dev, adev) set_primary_fwnode(dev, (adev) ? \
|
|
|
|
acpi_fwnode_handle(adev) : NULL)
|
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_HANDLE(dev) acpi_device_handle(ACPI_COMPANION(dev))
|
2018-01-18 20:31:40 +08:00
|
|
|
#define ACPI_HANDLE_FWNODE(fwnode) \
|
|
|
|
acpi_device_handle(to_acpi_device_node(fwnode))
|
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
|
|
|
|
2016-11-21 18:01:33 +08:00
|
|
|
static inline struct fwnode_handle *acpi_alloc_fwnode_static(void)
|
|
|
|
{
|
|
|
|
struct fwnode_handle *fwnode;
|
|
|
|
|
|
|
|
fwnode = kzalloc(sizeof(struct fwnode_handle), GFP_KERNEL);
|
|
|
|
if (!fwnode)
|
|
|
|
return NULL;
|
|
|
|
|
2020-12-12 04:26:29 +08:00
|
|
|
fwnode_init(fwnode, &acpi_static_fwnode_ops);
|
2016-11-21 18:01:33 +08:00
|
|
|
|
|
|
|
return fwnode;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void acpi_free_fwnode_static(struct fwnode_handle *fwnode)
|
|
|
|
{
|
2017-07-21 19:39:31 +08:00
|
|
|
if (WARN_ON(!is_acpi_static_node(fwnode)))
|
2016-11-21 18:01:33 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
kfree(fwnode);
|
|
|
|
}
|
|
|
|
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 07:55:20 +08:00
|
|
|
/**
|
|
|
|
* ACPI_DEVICE_CLASS - macro used to describe an ACPI device with
|
|
|
|
* the PCI-defined class-code information
|
|
|
|
*
|
|
|
|
* @_cls : the class, subclass, prog-if triple for this device
|
|
|
|
* @_msk : the class mask for this device
|
|
|
|
*
|
|
|
|
* This macro is used to create a struct acpi_device_id that matches a
|
|
|
|
* specific PCI class. The .id and .driver_data fields will be left
|
|
|
|
* initialized with the default value.
|
|
|
|
*/
|
|
|
|
#define ACPI_DEVICE_CLASS(_cls, _msk) .cls = (_cls), .cls_msk = (_msk),
|
|
|
|
|
2015-03-17 06:49:08 +08:00
|
|
|
static inline bool has_acpi_companion(struct device *dev)
|
|
|
|
{
|
2015-08-27 10:40:05 +08:00
|
|
|
return is_acpi_device_node(dev->fwnode);
|
2015-03-17 06:49:08 +08:00
|
|
|
}
|
|
|
|
|
2013-11-29 06:58:28 +08:00
|
|
|
static inline void acpi_preset_companion(struct device *dev,
|
|
|
|
struct acpi_device *parent, u64 addr)
|
|
|
|
{
|
2018-11-24 04:07:14 +08:00
|
|
|
ACPI_COMPANION_SET(dev, acpi_find_child_device(parent, addr, false));
|
2013-11-29 06:58:28 +08:00
|
|
|
}
|
|
|
|
|
2013-11-14 20:03:51 +08:00
|
|
|
static inline const char *acpi_dev_name(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
return dev_name(&adev->dev);
|
|
|
|
}
|
|
|
|
|
ACPI / bus: Make acpi_get_first_physical_node() public
Following the fwnode of a device is currently a one-way road: We provide
ACPI_COMPANION() to obtain the fwnode but there's no (public) method to
do the reverse. Granted, there may be multiple physical_nodes, but often
the first one in the list is sufficient.
A handy function to obtain it was introduced with commit 3b95bd160547
("ACPI: introduce a function to find the first physical device"), but
currently it's only available internally.
We're about to add an EFI Device Path parser which needs this function.
Consider the following device path: ACPI(PNP0A03,0)/PCI(28,2)/PCI(0,0)
The PCI root is encoded as an ACPI device in the path, so the parser
has to find the corresponding ACPI device, then find its physical node,
find the PCI bridge in slot 1c (decimal 28), function 2 below it and
finally find the PCI device in slot 0, function 0.
To this end, make acpi_get_first_physical_node() public.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-28 08:25:41 +08:00
|
|
|
struct device *acpi_get_first_physical_node(struct acpi_device *adev);
|
|
|
|
|
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,
|
2015-03-24 22:02:48 +08:00
|
|
|
ACPI_IRQ_MODEL_GIC,
|
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 */
|
2019-03-12 04:55:57 +08:00
|
|
|
union acpi_subtable_headers {
|
|
|
|
struct acpi_subtable_header common;
|
2019-03-12 04:55:58 +08:00
|
|
|
struct acpi_hmat_structure hmat;
|
ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype
Platform Runtime Mechanism (PRM) is a firmware interface that exposes
a set of binary executables that can either be called from the AML
interpreter or device drivers by bypassing the AML interpreter.
This change implements the AML interpreter path.
According to the specification [1], PRM services are listed in an
ACPI table called the PRMT. This patch parses module and handler
information listed in the PRMT and registers the PlatformRtMechanism
OpRegion handler before ACPI tables are loaded.
Each service is defined by a 16-byte GUID and called from writing a
26-byte ASL buffer containing the identifier to a FieldUnit object
defined inside a PlatformRtMechanism OperationRegion.
OperationRegion (PRMR, PlatformRtMechanism, 0, 26)
Field (PRMR, BufferAcc, NoLock, Preserve)
{
PRMF, 208 // Write to this field to invoke the OperationRegion Handler
}
The 26-byte ASL buffer is defined as the following:
Byte Offset Byte Length Description
=============================================================
0 1 PRM OperationRegion handler status
1 8 PRM service status
9 1 PRM command
10 16 PRM handler GUID
The ASL caller fills out a 26-byte buffer containing the PRM command
and the PRM handler GUID like so:
/* Local0 is the PRM data buffer */
Local0 = buffer (26){}
/* Create byte fields over the buffer */
CreateByteField (Local0, 0x9, CMD)
CreateField (Local0, 0x50, 0x80, GUID)
/* Fill in the command and data fields of the data buffer */
CMD = 0 // run command
GUID = ToUUID("xxxx-xx-xxx-xxxx")
/*
* Invoke PRM service with an ID that matches GUID and save the
* result.
*/
Local0 = (\_SB.PRMT.PRMF = Local0)
Byte offset 0 - 8 are written by the handler as a status passed back to AML
and used by ASL like so:
/* Create byte fields over the buffer */
CreateByteField (Local0, 0x0, PSTA)
CreateQWordField (Local0, 0x1, USTA)
In this ASL code, PSTA contains a status from the OperationRegion and
USTA contains a status from the PRM service.
The 26-byte buffer is recieved by acpi_platformrt_space_handler. This
handler will look at the command value and the handler guid and take
the approperiate actions.
Command value Action
=====================================================================
0 Run the PRM service indicated by the PRM handler
GUID (bytes 10-26)
1 Prevent PRM runtime updates from happening to the
service's parent module
2 Allow PRM updates from happening to the service's parent module
This patch enables command value 0.
Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1]
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-10 11:41:52 +08:00
|
|
|
struct acpi_prmt_module_header prmt;
|
2019-03-12 04:55:57 +08:00
|
|
|
};
|
2005-04-17 06:20:36 +08:00
|
|
|
|
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
|
|
|
|
2019-03-12 04:55:57 +08:00
|
|
|
typedef int (*acpi_tbl_entry_handler)(union acpi_subtable_headers *header,
|
2013-01-12 23:29:38 +08:00
|
|
|
const unsigned long end);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-12-03 10:43:14 +08:00
|
|
|
/* Debugger support */
|
|
|
|
|
|
|
|
struct acpi_debugger_ops {
|
|
|
|
int (*create_thread)(acpi_osd_exec_callback function, void *context);
|
|
|
|
ssize_t (*write_log)(const char *msg);
|
|
|
|
ssize_t (*read_cmd)(char *buffer, size_t length);
|
|
|
|
int (*wait_command_ready)(bool single_step, char *buffer, size_t length);
|
|
|
|
int (*notify_command_complete)(void);
|
|
|
|
};
|
|
|
|
|
|
|
|
struct acpi_debugger {
|
|
|
|
const struct acpi_debugger_ops *ops;
|
|
|
|
struct module *owner;
|
|
|
|
struct mutex lock;
|
|
|
|
};
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_DEBUGGER
|
|
|
|
int __init acpi_debugger_init(void);
|
|
|
|
int acpi_register_debugger(struct module *owner,
|
|
|
|
const struct acpi_debugger_ops *ops);
|
|
|
|
void acpi_unregister_debugger(const struct acpi_debugger_ops *ops);
|
|
|
|
int acpi_debugger_create_thread(acpi_osd_exec_callback function, void *context);
|
|
|
|
ssize_t acpi_debugger_write_log(const char *msg);
|
|
|
|
ssize_t acpi_debugger_read_cmd(char *buffer, size_t buffer_length);
|
|
|
|
int acpi_debugger_wait_command_ready(void);
|
|
|
|
int acpi_debugger_notify_command_complete(void);
|
|
|
|
#else
|
|
|
|
static inline int acpi_debugger_init(void)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int acpi_register_debugger(struct module *owner,
|
|
|
|
const struct acpi_debugger_ops *ops)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void acpi_unregister_debugger(const struct acpi_debugger_ops *ops)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int acpi_debugger_create_thread(acpi_osd_exec_callback function,
|
|
|
|
void *context)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int acpi_debugger_write_log(const char *msg)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int acpi_debugger_read_cmd(char *buffer, u32 buffer_length)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int acpi_debugger_wait_command_ready(void)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int acpi_debugger_notify_command_complete(void)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
#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))
|
|
|
|
|
2015-09-09 21:47:28 +08:00
|
|
|
struct acpi_subtable_proc {
|
|
|
|
int id;
|
|
|
|
acpi_tbl_entry_handler handler;
|
|
|
|
int count;
|
|
|
|
};
|
|
|
|
|
2017-07-18 23:04:17 +08:00
|
|
|
void __iomem *__acpi_map_table(unsigned long phys, unsigned long size);
|
|
|
|
void __acpi_unmap_table(void __iomem *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);
|
2021-03-24 03:26:52 +08:00
|
|
|
void acpi_boot_table_prepare (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);
|
|
|
|
|
2021-03-24 03:26:52 +08:00
|
|
|
int acpi_locate_initial_tables (void);
|
|
|
|
void acpi_reserve_initial_tables (void);
|
|
|
|
void acpi_table_init_complete (void);
|
2005-04-17 06:20:36 +08:00
|
|
|
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,
|
2015-09-09 21:47:28 +08:00
|
|
|
int entry_id,
|
|
|
|
acpi_tbl_entry_handler handler,
|
|
|
|
unsigned int max_entries);
|
|
|
|
int __init acpi_table_parse_entries_array(char *id, unsigned long table_size,
|
|
|
|
struct acpi_subtable_proc *proc, int proc_num,
|
|
|
|
unsigned int max_entries);
|
2013-01-12 23:29:38 +08:00
|
|
|
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
|
|
|
|
2016-06-17 11:53:02 +08:00
|
|
|
/* the following numa functions are architecture-dependent */
|
2005-04-17 06:20:36 +08:00
|
|
|
void acpi_numa_slit_init (struct acpi_table_slit *slit);
|
2016-06-17 11:53:02 +08:00
|
|
|
|
|
|
|
#if defined(CONFIG_X86) || defined(CONFIG_IA64)
|
2007-02-03 00:48:22 +08:00
|
|
|
void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
|
2016-06-17 11:53:02 +08:00
|
|
|
#else
|
|
|
|
static inline void
|
|
|
|
acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa) { }
|
|
|
|
#endif
|
|
|
|
|
2009-03-31 05:55:30 +08:00
|
|
|
void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
|
2016-06-17 11:53:02 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_ARM64
|
|
|
|
void acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa);
|
|
|
|
#else
|
|
|
|
static inline void
|
|
|
|
acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
|
2015-03-24 22:02:46 +08:00
|
|
|
#ifndef PHYS_CPUID_INVALID
|
|
|
|
typedef u32 phys_cpuid_t;
|
|
|
|
#define PHYS_CPUID_INVALID (phys_cpuid_t)(-1)
|
|
|
|
#endif
|
|
|
|
|
2015-05-11 12:17:13 +08:00
|
|
|
static inline bool invalid_logical_cpuid(u32 cpuid)
|
|
|
|
{
|
|
|
|
return (int)cpuid < 0;
|
|
|
|
}
|
|
|
|
|
2015-05-13 16:19:30 +08:00
|
|
|
static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id)
|
|
|
|
{
|
|
|
|
return phys_id == PHYS_CPUID_INVALID;
|
|
|
|
}
|
|
|
|
|
2016-08-25 16:35:20 +08:00
|
|
|
/* Validate the processor object's proc_id */
|
2017-03-03 16:02:27 +08:00
|
|
|
bool acpi_duplicate_processor_id(int proc_id);
|
2019-12-13 16:55:14 +08:00
|
|
|
/* Processor _CTS control */
|
2019-12-13 16:55:42 +08:00
|
|
|
struct acpi_processor_power;
|
|
|
|
|
2019-12-13 16:55:14 +08:00
|
|
|
#ifdef CONFIG_ACPI_PROCESSOR_CSTATE
|
|
|
|
bool acpi_processor_claim_cst_control(void);
|
2019-12-13 16:55:42 +08:00
|
|
|
int acpi_processor_evaluate_cst(acpi_handle handle, u32 cpu,
|
|
|
|
struct acpi_processor_power *info);
|
2019-12-13 16:55:14 +08:00
|
|
|
#else
|
|
|
|
static inline bool acpi_processor_claim_cst_control(void) { return false; }
|
2019-12-13 16:55:42 +08:00
|
|
|
static inline int acpi_processor_evaluate_cst(acpi_handle handle, u32 cpu,
|
|
|
|
struct acpi_processor_power *info)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2019-12-13 16:55:14 +08:00
|
|
|
#endif
|
2016-08-25 16:35:20 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#ifdef CONFIG_ACPI_HOTPLUG_CPU
|
|
|
|
/* Arch dependent functions for cpu hotplug support */
|
2017-02-07 01:01:51 +08:00
|
|
|
int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 acpi_id,
|
|
|
|
int *pcpu);
|
2015-01-04 18:55:03 +08:00
|
|
|
int acpi_unmap_cpu(int cpu);
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
|
|
|
|
|
2015-02-05 13:44:48 +08:00
|
|
|
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
|
|
|
|
int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
|
|
|
|
#endif
|
|
|
|
|
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);
|
2014-10-27 13:21:47 +08:00
|
|
|
int acpi_ioapic_registered(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;
|
2015-10-25 01:02:19 +08:00
|
|
|
extern unsigned int acpi_sci_irq;
|
2016-03-22 08:51:10 +08:00
|
|
|
extern bool acpi_no_s5;
|
2015-10-25 01:02:19 +08:00
|
|
|
#define INVALID_ACPI_IRQ ((unsigned)-1)
|
|
|
|
static inline bool acpi_sci_irq_valid(void)
|
|
|
|
{
|
|
|
|
return acpi_sci_irq != INVALID_ACPI_IRQ;
|
|
|
|
}
|
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
|
|
|
|
2015-10-13 19:51:38 +08:00
|
|
|
void acpi_set_irq_model(enum acpi_irq_model_id model,
|
|
|
|
struct fwnode_handle *fwnode);
|
|
|
|
|
acpi/irq: Implement helper to create hierachical domains
ACPI permits arbitrary producer->consumer interrupt links to be
described in AML, which means a topology such as the following
is perfectly legal:
Device (EXIU) {
Name (_HID, "SCX0008")
Name (_UID, Zero)
Name (_CRS, ResourceTemplate () {
...
})
}
Device (GPIO) {
Name (_HID, "SCX0007")
Name (_UID, Zero)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, SYNQUACER_GPIO_BASE, SYNQUACER_GPIO_SIZE)
Interrupt (ResourceConsumer, Edge, ActiveHigh, ExclusiveAndWake, 0, "\\_SB.EXIU") {
7,
}
})
...
}
The EXIU in this example is the external interrupt unit as can be found
on Socionext SynQuacer based platforms, which converts a block of 32 SPIs
from arbitrary polarity/trigger into level-high, with a separate set
of config/mask/unmask/clear controls.
The existing DT based driver in drivers/irqchip/irq-sni-exiu.c models
this as a hierarchical domain stacked on top of the GIC's irqdomain.
Since the GIC is modeled as a DT node as well, obtaining a reference
to this irqdomain is easily done by going through the parent link.
On ACPI systems, however, the GIC is not modeled as an object in the
namespace, and so device objects cannot refer to it directly. So in
order to obtain the irqdomain reference when driving the EXIU in ACPI
mode, we need a helper that implicitly grabs the default domain as the
parent of the hierarchy for interrupts allocated out of the global GSI
pool.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-05-28 21:36:44 +08:00
|
|
|
struct irq_domain *acpi_irq_create_hierarchy(unsigned int flags,
|
|
|
|
unsigned int size,
|
|
|
|
struct fwnode_handle *fwnode,
|
|
|
|
const struct irq_domain_ops *ops,
|
|
|
|
void *host_data);
|
|
|
|
|
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
|
2019-07-12 17:01:21 +08:00
|
|
|
static inline int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity)
|
|
|
|
{
|
|
|
|
return -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);
|
2015-09-17 14:02:45 +08:00
|
|
|
bool acpi_isa_irq_available(int irq);
|
2018-12-20 06:46:56 +08:00
|
|
|
#ifdef CONFIG_PCI
|
ACPI/PCI: pci_link: penalize SCI correctly
Ondrej reported that IRQs stopped working in v4.7 on several
platforms. A typical scenario, from Ondrej's VT82C694X/694X, is:
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: No IRQ available for PCI Interrupt Link [LNKA]
8139too 0000:00:0f.0: PCI INT A: no GSI
We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already
active at IRQ 11. In that case, acpi_pci_link_allocate() only tries
to use the active IRQ (IRQ 11) which also happens to be the SCI.
We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but
irq_get_trigger_type(11) returns something other than
IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS
instead, which makes acpi_pci_link_allocate() assume the IRQ isn't
available and give up.
Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ,
trigger, and polarity directly and we don't have to depend on
irq_get_trigger_type().
Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
Link: http://lkml.kernel.org/r/201609251512.05657.linux@rainbow-software.org
Reported-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-10-24 12:31:31 +08:00
|
|
|
void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
|
2018-12-20 06:46:56 +08:00
|
|
|
#else
|
|
|
|
static inline void acpi_penalize_sci_irq(int irq, int trigger,
|
|
|
|
int polarity)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
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);
|
2019-05-15 02:59:01 +08:00
|
|
|
extern char *wmi_get_acpi_device_uid(const char *guid);
|
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
|
|
|
|
|
|
|
#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
|
|
|
|
|
2015-06-16 22:27:47 +08:00
|
|
|
extern char acpi_video_backlight_string[];
|
2013-03-05 05:30:41 +08:00
|
|
|
extern long acpi_is_video_device(acpi_handle handle);
|
2005-04-17 06:20:36 +08:00
|
|
|
extern int acpi_blacklisted(void);
|
2010-12-09 16:50:52 +08:00
|
|
|
extern void acpi_osi_setup(char *str);
|
2015-06-16 22:27:46 +08:00
|
|
|
extern bool acpi_osi_is_win8(void);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_NUMA
|
2018-11-10 04:43:07 +08:00
|
|
|
int acpi_map_pxm_to_node(int pxm);
|
2014-01-25 06:25:10 +08:00
|
|
|
int acpi_get_node(acpi_handle handle);
|
2020-02-17 04:00:48 +08:00
|
|
|
|
|
|
|
/**
|
2020-08-18 22:24:28 +08:00
|
|
|
* pxm_to_online_node - Map proximity ID to online node
|
2020-02-17 04:00:48 +08:00
|
|
|
* @pxm: ACPI proximity ID
|
|
|
|
*
|
2020-08-18 22:24:28 +08:00
|
|
|
* This is similar to pxm_to_node(), but always returns an online
|
2020-02-17 04:00:48 +08:00
|
|
|
* node. When the mapped node from a given proximity ID is offline, it
|
|
|
|
* looks up the node distance table and returns the nearest online node.
|
|
|
|
*
|
|
|
|
* ACPI device drivers, which are called after the NUMA initialization has
|
|
|
|
* completed in the kernel, can call this interface to obtain their device
|
|
|
|
* NUMA topology from ACPI tables. Such drivers do not have to deal with
|
2020-08-18 22:24:27 +08:00
|
|
|
* offline nodes. A node may be offline when SRAT memory entry does not exist,
|
|
|
|
* or NUMA is disabled, ex. "numa=off" on x86.
|
2020-02-17 04:00:48 +08:00
|
|
|
*/
|
2020-08-18 22:24:28 +08:00
|
|
|
static inline int pxm_to_online_node(int pxm)
|
2020-02-17 04:00:48 +08:00
|
|
|
{
|
2020-08-18 22:24:27 +08:00
|
|
|
int node = pxm_to_node(pxm);
|
2020-02-17 04:00:48 +08:00
|
|
|
|
|
|
|
return numa_map_to_online_node(node);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
#else
|
2020-08-18 22:24:28 +08:00
|
|
|
static inline int pxm_to_online_node(int pxm)
|
acpi: Add acpi_map_pxm_to_online_node()
The kernel initializes CPU & memory's NUMA topology from ACPI
SRAT table. Some other ACPI tables, such as NFIT and DMAR, also
contain proximity IDs for their device's NUMA topology. This
information can be used to improve performance of these devices.
This patch introduces acpi_map_pxm_to_online_node(), which is
similar to acpi_map_pxm_to_node(), but always returns an online
node. When the mapped node from a given proximity ID is offline,
it looks up the node distance table and returns the nearest
online node.
ACPI device drivers, which are called after the NUMA initialization
has completed in the kernel, can call this interface to obtain their
device NUMA topology from ACPI tables. Such drivers do not have to
deal with offline nodes. A node may be offline when a device
proximity ID is unique, SRAT memory entry does not exist, or NUMA is
disabled, ex. "numa=off" on x86.
This patch also moves the pxm range check from acpi_get_node() to
acpi_map_pxm_to_node().
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-20 07:14:15 +08:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2018-11-10 04:43:07 +08:00
|
|
|
static inline int acpi_map_pxm_to_node(int pxm)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
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,
|
2015-02-02 10:42:58 +08:00
|
|
|
struct resource_win *win);
|
2012-11-15 07:30:01 +08:00
|
|
|
bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
|
2015-02-02 10:42:58 +08:00
|
|
|
struct resource_win *win);
|
2012-11-15 07:30:01 +08:00
|
|
|
unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable);
|
2015-12-24 06:25:33 +08:00
|
|
|
unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
|
2012-11-15 07:30:01 +08:00
|
|
|
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
|
|
|
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);
|
2017-08-07 18:29:48 +08:00
|
|
|
int acpi_dev_get_dma_resources(struct acpi_device *adev,
|
|
|
|
struct list_head *list);
|
2015-02-02 10:43:01 +08:00
|
|
|
int acpi_dev_filter_resource_type(struct acpi_resource *ares,
|
|
|
|
unsigned long types);
|
|
|
|
|
|
|
|
static inline int acpi_dev_filter_resource_type_cb(struct acpi_resource *ares,
|
|
|
|
void *arg)
|
|
|
|
{
|
|
|
|
return acpi_dev_filter_resource_type(ares, (unsigned long)arg);
|
|
|
|
}
|
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
|
|
|
|
2016-12-01 04:47:13 +08:00
|
|
|
struct acpi_device *acpi_resource_consumer(struct resource *res);
|
|
|
|
|
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);
|
|
|
|
|
2018-06-21 21:43:17 +08:00
|
|
|
acpi_status acpi_release_memory(acpi_handle handle, struct resource *res,
|
|
|
|
u32 level);
|
|
|
|
|
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);
|
2017-11-15 09:16:55 +08:00
|
|
|
void __init acpi_sleep_no_blacklist(void);
|
2008-06-13 05:24:06 +08:00
|
|
|
#endif /* CONFIG_PM_SLEEP */
|
2009-02-09 15:00:04 +08:00
|
|
|
|
2020-04-03 23:48:33 +08:00
|
|
|
int acpi_register_wakeup_handler(
|
|
|
|
int wake_irq, bool (*wakeup)(void *context), void *context);
|
|
|
|
void acpi_unregister_wakeup_handler(
|
|
|
|
bool (*wakeup)(void *context), void *context);
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
|
|
|
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
|
2016-07-22 00:18:07 +08:00
|
|
|
#define OSC_SB_CPCV2_SUPPORT 0x00000040
|
|
|
|
#define OSC_SB_PCLPI_SUPPORT 0x00000080
|
|
|
|
#define OSC_SB_OSLPI_SUPPORT 0x00000100
|
2016-11-23 04:23:59 +08:00
|
|
|
#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000
|
2020-09-30 22:05:44 +08:00
|
|
|
#define OSC_SB_GENERIC_INITIATOR_SUPPORT 0x00002000
|
2020-02-18 22:02:45 +08:00
|
|
|
#define OSC_SB_NATIVE_USB4_SUPPORT 0x00040000
|
2009-10-29 11:05:05 +08:00
|
|
|
|
2011-07-13 13:14:20 +08:00
|
|
|
extern bool osc_sb_apei_support_acked;
|
2016-07-22 00:18:07 +08:00
|
|
|
extern bool osc_pc_lpi_support_confirmed;
|
2020-02-18 22:02:45 +08:00
|
|
|
extern bool osc_sb_native_usb4_support_confirmed;
|
|
|
|
|
|
|
|
/* USB4 Capabilities */
|
|
|
|
#define OSC_USB_USB3_TUNNELING 0x00000001
|
|
|
|
#define OSC_USB_DP_TUNNELING 0x00000002
|
|
|
|
#define OSC_USB_PCIE_TUNNELING 0x00000004
|
|
|
|
#define OSC_USB_XDOMAIN 0x00000008
|
|
|
|
|
|
|
|
extern u32 osc_sb_native_usb4_control;
|
2011-07-13 13:14:20 +08:00
|
|
|
|
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
|
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 08:26:07 +08:00
|
|
|
#define OSC_PCI_EDR_SUPPORT 0x00000080
|
2019-03-16 03:29:40 +08:00
|
|
|
#define OSC_PCI_HPX_TYPE_3_SUPPORT 0x00000100
|
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 08:26:07 +08:00
|
|
|
#define OSC_PCI_SUPPORT_MASKS 0x0000019f
|
2013-09-06 05:05:53 +08:00
|
|
|
|
|
|
|
/* 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
|
2018-04-17 23:58:09 +08:00
|
|
|
#define OSC_PCI_EXPRESS_LTR_CONTROL 0x00000020
|
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 08:26:07 +08:00
|
|
|
#define OSC_PCI_EXPRESS_DPC_CONTROL 0x00000080
|
|
|
|
#define OSC_PCI_CONTROL_MASKS 0x000000bf
|
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
|
|
|
|
|
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
|
|
|
|
|
2017-08-24 06:54:43 +08:00
|
|
|
enum acpi_predicate {
|
|
|
|
all_versions,
|
|
|
|
less_than_or_equal,
|
|
|
|
equal,
|
|
|
|
greater_than_or_equal,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Table must be terminted by a NULL entry */
|
|
|
|
struct acpi_platform_list {
|
|
|
|
char oem_id[ACPI_OEM_ID_SIZE+1];
|
|
|
|
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE+1];
|
|
|
|
u32 oem_revision;
|
|
|
|
char *table;
|
|
|
|
enum acpi_predicate pred;
|
|
|
|
char *reason;
|
|
|
|
u32 data;
|
|
|
|
};
|
|
|
|
int acpi_match_platform_list(const struct acpi_platform_list *plat);
|
|
|
|
|
2009-06-13 08:42:08 +08:00
|
|
|
extern void acpi_early_init(void);
|
ACPI / init: Switch over platform to the ACPI mode later
Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".
However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.
To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.
That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
2015-06-10 07:33:36 +08:00
|
|
|
extern void acpi_subsystem_init(void);
|
2018-05-06 04:36:03 +08:00
|
|
|
extern void arch_post_acpi_subsys_init(void);
|
2009-06-13 08:42:08 +08:00
|
|
|
|
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);
|
|
|
|
|
2018-02-09 23:38:36 +08:00
|
|
|
const void *acpi_device_get_match_data(const struct device *dev);
|
2014-10-21 19:33:56 +08:00
|
|
|
extern bool acpi_driver_match_device(struct device *dev,
|
|
|
|
const struct device_driver *drv);
|
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);
|
2014-11-23 21:22:54 +08:00
|
|
|
void acpi_walk_dep_device_list(acpi_handle handle);
|
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
|
|
|
|
2016-11-03 22:21:26 +08:00
|
|
|
struct platform_device *acpi_create_platform_device(struct acpi_device *,
|
|
|
|
struct property_entry *);
|
2012-11-01 05:44:41 +08:00
|
|
|
#define ACPI_PTR(_ptr) (_ptr)
|
|
|
|
|
2016-07-09 00:13:08 +08:00
|
|
|
static inline void acpi_device_set_enumerated(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
adev->flags.visited = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void acpi_device_clear_enumerated(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
adev->flags.visited = false;
|
|
|
|
}
|
|
|
|
|
2016-07-09 00:13:09 +08:00
|
|
|
enum acpi_reconfig_event {
|
|
|
|
ACPI_RECONFIG_DEVICE_ADD = 0,
|
|
|
|
ACPI_RECONFIG_DEVICE_REMOVE,
|
|
|
|
};
|
|
|
|
|
|
|
|
int acpi_reconfig_notifier_register(struct notifier_block *nb);
|
|
|
|
int acpi_reconfig_notifier_unregister(struct notifier_block *nb);
|
|
|
|
|
2017-04-01 01:51:01 +08:00
|
|
|
#ifdef CONFIG_ACPI_GTDT
|
|
|
|
int acpi_gtdt_init(struct acpi_table_header *table, int *platform_timer_count);
|
|
|
|
int acpi_gtdt_map_ppi(int type);
|
|
|
|
bool acpi_gtdt_c3stop(int type);
|
2017-04-01 01:51:03 +08:00
|
|
|
int acpi_arch_timer_mem_init(struct arch_timer_mem *timer_mem, int *timer_count);
|
2017-04-01 01:51:01 +08:00
|
|
|
#endif
|
|
|
|
|
2019-08-20 08:17:51 +08:00
|
|
|
#ifndef ACPI_HAVE_ARCH_SET_ROOT_POINTER
|
|
|
|
static inline void acpi_arch_set_root_pointer(u64 addr)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2018-02-19 18:09:04 +08:00
|
|
|
#ifndef ACPI_HAVE_ARCH_GET_ROOT_POINTER
|
|
|
|
static inline u64 acpi_arch_get_root_pointer(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
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)
|
2018-01-18 20:31:40 +08:00
|
|
|
#define ACPI_HANDLE_FWNODE(fwnode) (NULL)
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 07:55:20 +08:00
|
|
|
#define ACPI_DEVICE_CLASS(_cls, _msk) .cls = (0), .cls_msk = (0),
|
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
|
|
|
|
2020-10-14 07:49:02 +08:00
|
|
|
#include <acpi/acpi_numa.h>
|
|
|
|
|
2014-11-04 21:03:59 +08:00
|
|
|
struct fwnode_handle;
|
|
|
|
|
2016-06-03 10:55:09 +08:00
|
|
|
static inline bool acpi_dev_found(const char *hid)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-04-19 20:02:08 +08:00
|
|
|
static inline bool acpi_dev_present(const char *hid, const char *uid, s64 hrv)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-10-01 22:27:22 +08:00
|
|
|
struct acpi_device;
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
acpi_dev_hid_uid_match(struct acpi_device *adev, const char *hid2, const char *uid2)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-03-19 04:00:54 +08:00
|
|
|
static inline struct acpi_device *
|
|
|
|
acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2021-04-08 01:58:20 +08:00
|
|
|
static inline bool acpi_reduced_hardware(void)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-04-12 23:19:11 +08:00
|
|
|
static inline void acpi_dev_put(struct acpi_device *adev) {}
|
|
|
|
|
2021-03-02 21:35:48 +08:00
|
|
|
static inline bool is_acpi_node(const struct fwnode_handle *fwnode)
|
2014-11-04 21:03:59 +08:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2021-03-02 21:35:48 +08:00
|
|
|
static inline bool is_acpi_device_node(const struct fwnode_handle *fwnode)
|
2015-08-27 10:40:05 +08:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct acpi_device *to_acpi_device_node(struct fwnode_handle *fwnode)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2021-03-02 21:35:48 +08:00
|
|
|
static inline bool is_acpi_data_node(const struct fwnode_handle *fwnode)
|
2015-08-27 10:40:05 +08:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct acpi_data_node *to_acpi_data_node(struct fwnode_handle *fwnode)
|
2014-11-04 21:03:59 +08:00
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-06-22 01:50:20 +08:00
|
|
|
static inline bool acpi_data_node_match(struct fwnode_handle *fwnode,
|
|
|
|
const char *name)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-11-04 21:03:59 +08:00
|
|
|
static inline struct fwnode_handle *acpi_fwnode_handle(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2015-03-17 06:49:08 +08:00
|
|
|
static inline bool has_acpi_companion(struct device *dev)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-10-24 03:27:06 +08:00
|
|
|
static inline void acpi_preset_companion(struct device *dev,
|
|
|
|
struct acpi_device *parent, u64 addr)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2013-11-14 20:03:51 +08:00
|
|
|
static inline const char *acpi_dev_name(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
ACPI / bus: Make acpi_get_first_physical_node() public
Following the fwnode of a device is currently a one-way road: We provide
ACPI_COMPANION() to obtain the fwnode but there's no (public) method to
do the reverse. Granted, there may be multiple physical_nodes, but often
the first one in the list is sufficient.
A handy function to obtain it was introduced with commit 3b95bd160547
("ACPI: introduce a function to find the first physical device"), but
currently it's only available internally.
We're about to add an EFI Device Path parser which needs this function.
Consider the following device path: ACPI(PNP0A03,0)/PCI(28,2)/PCI(0,0)
The PCI root is encoded as an ACPI device in the path, so the parser
has to find the corresponding ACPI device, then find its physical node,
find the PCI bridge in slot 1c (decimal 28), function 2 below it and
finally find the PCI device in slot 0, function 0.
To this end, make acpi_get_first_physical_node() public.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-28 08:25:41 +08:00
|
|
|
static inline struct device *acpi_get_first_physical_node(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2009-06-13 08:42:08 +08:00
|
|
|
static inline void acpi_early_init(void) { }
|
ACPI / init: Switch over platform to the ACPI mode later
Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".
However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.
To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.
That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
2015-06-10 07:33:36 +08:00
|
|
|
static inline void acpi_subsystem_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;
|
|
|
|
}
|
|
|
|
|
2021-03-24 03:26:52 +08:00
|
|
|
static inline void acpi_boot_table_prepare(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2010-01-07 05:11:06 +08:00
|
|
|
static inline void acpi_boot_table_init(void)
|
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)
|
2017-12-13 15:20:48 +08:00
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-02-09 23:38:36 +08:00
|
|
|
static inline const void *acpi_device_get_match_data(const struct device *dev)
|
2012-11-01 05:44:41 +08:00
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool acpi_driver_match_device(struct device *dev,
|
|
|
|
const struct device_driver *drv)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-06-03 10:55:10 +08:00
|
|
|
static inline union acpi_object *acpi_evaluate_dsm(acpi_handle handle,
|
2017-06-06 00:40:46 +08:00
|
|
|
const guid_t *guid,
|
2020-09-30 20:43:50 +08:00
|
|
|
u64 rev, u64 func,
|
2016-06-03 10:55:10 +08:00
|
|
|
union acpi_object *argv4)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2020-12-31 19:35:25 +08:00
|
|
|
static inline struct platform_device *
|
|
|
|
acpi_create_platform_device(struct acpi_device *adev,
|
|
|
|
struct property_entry *properties)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2015-10-29 06:50:48 +08:00
|
|
|
static inline bool acpi_dma_supported(struct acpi_device *adev)
|
2015-06-11 00:08:52 +08:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-10-29 06:50:48 +08:00
|
|
|
static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
return DEV_DMA_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
2017-08-07 18:29:48 +08:00
|
|
|
static inline int acpi_dma_get_range(struct device *dev, u64 *dma_addr,
|
|
|
|
u64 *offset, u64 *size)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2017-04-10 19:21:03 +08:00
|
|
|
static inline int acpi_dma_configure(struct device *dev,
|
|
|
|
enum dev_dma_attr attr)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2016-11-21 18:01:39 +08:00
|
|
|
|
2020-06-19 16:20:06 +08:00
|
|
|
static inline int acpi_dma_configure_id(struct device *dev,
|
|
|
|
enum dev_dma_attr attr,
|
|
|
|
const u32 *input_id)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-11-01 05:44:41 +08:00
|
|
|
#define ACPI_PTR(_ptr) (NULL)
|
|
|
|
|
2016-07-09 00:13:08 +08:00
|
|
|
static inline void acpi_device_set_enumerated(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void acpi_device_clear_enumerated(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2016-07-09 00:13:09 +08:00
|
|
|
static inline int acpi_reconfig_notifier_register(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int acpi_reconfig_notifier_unregister(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-12-01 04:47:13 +08:00
|
|
|
static inline struct acpi_device *acpi_resource_consumer(struct resource *res)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2011-12-08 11:25:49 +08:00
|
|
|
#endif /* !CONFIG_ACPI */
|
2011-01-13 05:03:20 +08:00
|
|
|
|
2016-08-17 16:00:33 +08:00
|
|
|
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
|
|
|
|
int acpi_ioapic_add(acpi_handle root);
|
|
|
|
#else
|
|
|
|
static inline int acpi_ioapic_add(acpi_handle root) { return 0; }
|
|
|
|
#endif
|
|
|
|
|
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);
|
|
|
|
|
2020-09-29 21:25:22 +08:00
|
|
|
#ifndef CONFIG_IA64
|
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
|
|
|
|
|
2014-11-28 05:38:23 +08:00
|
|
|
#if defined(CONFIG_ACPI) && defined(CONFIG_PM)
|
2017-10-14 23:43:15 +08:00
|
|
|
int acpi_dev_suspend(struct device *dev, bool wakeup);
|
2017-10-11 00:49:22 +08:00
|
|
|
int acpi_dev_resume(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_runtime_suspend(struct device *dev);
|
|
|
|
int acpi_subsys_runtime_resume(struct device *dev);
|
2014-11-28 05:38:23 +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
|
|
|
|
static inline int acpi_subsys_runtime_suspend(struct device *dev) { return 0; }
|
|
|
|
static inline int acpi_subsys_runtime_resume(struct device *dev) { return 0; }
|
2014-11-28 05:38:23 +08:00
|
|
|
static inline int acpi_dev_pm_attach(struct device *dev, bool power_on)
|
|
|
|
{
|
2018-05-09 18:17:52 +08:00
|
|
|
return 0;
|
2014-11-28 05:38:23 +08:00
|
|
|
}
|
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
|
|
|
|
|
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_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);
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 16:10:16 +08:00
|
|
|
int acpi_subsys_suspend_noirq(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);
|
2019-07-01 18:54:29 +08:00
|
|
|
int acpi_subsys_poweroff(struct device *dev);
|
2019-07-30 17:55:59 +08:00
|
|
|
void acpi_ec_mark_gpe_for_wake(void);
|
|
|
|
void acpi_ec_set_gpe_wake_mask(u8 action);
|
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_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; }
|
ACPI / PM: Take SMART_SUSPEND driver flag into account
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.
[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().
Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.
In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-27 16:10:16 +08:00
|
|
|
static inline int acpi_subsys_suspend_noirq(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; }
|
2019-07-01 18:54:29 +08:00
|
|
|
static inline int acpi_subsys_poweroff(struct device *dev) { return 0; }
|
2019-07-30 17:55:59 +08:00
|
|
|
static inline void acpi_ec_mark_gpe_for_wake(void) {}
|
|
|
|
static inline void acpi_ec_set_gpe_wake_mask(u8 action) {}
|
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, ...);
|
2021-03-06 02:41:44 +08:00
|
|
|
void acpi_evaluation_failure_warn(acpi_handle handle, const char *name,
|
|
|
|
acpi_status status);
|
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
|
|
|
#else /* !CONFIG_ACPI */
|
|
|
|
static inline __printf(3, 4) void
|
|
|
|
acpi_handle_printk(const char *level, void *handle, const char *fmt, ...) {}
|
2021-03-06 02:41:44 +08:00
|
|
|
static inline void acpi_evaluation_failure_warn(acpi_handle handle,
|
|
|
|
const char *name,
|
|
|
|
acpi_status status) {}
|
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
|
|
|
#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, ...);
|
|
|
|
#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, ...) \
|
2019-03-08 08:28:10 +08:00
|
|
|
_dynamic_func_call(fmt, __acpi_handle_debug, \
|
|
|
|
handle, pr_fmt(fmt), ##__VA_ARGS__)
|
2014-05-22 18:47:47 +08:00
|
|
|
#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
|
|
|
|
ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.
To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of line data
(struct acpi_gpio_params) objects and the size of that array.
Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, respectively.
Next, the mapping table needs to be passed as the second
argument to acpi_dev_add_driver_gpios() that will register it with
the ACPI device object pointed to by its first argument. That
should be done in the driver's .probe() routine.
On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.
Included are fixes from Mika Westerberg.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 06:39:41 +08:00
|
|
|
#if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
|
2017-05-24 01:03:24 +08:00
|
|
|
bool acpi_gpio_get_irq_resource(struct acpi_resource *ares,
|
|
|
|
struct acpi_resource_gpio **agpio);
|
2021-02-26 00:33:19 +08:00
|
|
|
int acpi_dev_gpio_irq_get_by(struct acpi_device *adev, const char *name, int index);
|
ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.
To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of line data
(struct acpi_gpio_params) objects and the size of that array.
Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, respectively.
Next, the mapping table needs to be passed as the second
argument to acpi_dev_add_driver_gpios() that will register it with
the ACPI device object pointed to by its first argument. That
should be done in the driver's .probe() routine.
On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.
Included are fixes from Mika Westerberg.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 06:39:41 +08:00
|
|
|
#else
|
2017-05-24 01:03:24 +08:00
|
|
|
static inline bool acpi_gpio_get_irq_resource(struct acpi_resource *ares,
|
|
|
|
struct acpi_resource_gpio **agpio)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2021-02-26 00:33:19 +08:00
|
|
|
static inline int acpi_dev_gpio_irq_get_by(struct acpi_device *adev,
|
|
|
|
const char *name, int index)
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
{
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.
To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of line data
(struct acpi_gpio_params) objects and the size of that array.
Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, respectively.
Next, the mapping table needs to be passed as the second
argument to acpi_dev_add_driver_gpios() that will register it with
the ACPI device object pointed to by its first argument. That
should be done in the driver's .probe() routine.
On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.
Included are fixes from Mika Westerberg.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 06:39:41 +08:00
|
|
|
#endif
|
|
|
|
|
2021-02-26 00:33:19 +08:00
|
|
|
static inline int acpi_dev_gpio_irq_get(struct acpi_device *adev, int index)
|
|
|
|
{
|
|
|
|
return acpi_dev_gpio_irq_get_by(adev, NULL, index);
|
|
|
|
}
|
|
|
|
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 19:33:55 +08:00
|
|
|
/* Device properties */
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI
|
2017-07-21 19:39:34 +08:00
|
|
|
int acpi_dev_get_property(const struct acpi_device *adev, const char *name,
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 19:33:55 +08:00
|
|
|
acpi_object_type type, const union acpi_object **obj);
|
2017-07-21 19:39:34 +08:00
|
|
|
int __acpi_node_get_property_reference(const struct fwnode_handle *fwnode,
|
ACPI / property: Allow holes in reference properties
DT allows holes or empty phandles for references. This is used for example
in SPI subsystem where some chip selects are native and others are regular
GPIOs. In ACPI _DSD we currently do not support this but instead the
preceding reference consumes all following integer arguments.
For example we would like to support something like the below ASL fragment
for SPI:
Package () {
"cs-gpios",
Package () {
^GPIO, 19, 0, 0, // GPIO CS0
0, // Native CS
^GPIO, 20, 0, 0, // GPIO CS1
}
}
The zero in the middle means "no entry" or NULL reference. To support this
we change acpi_data_get_property_reference() to take firmware node and
num_args as argument and rename it to __acpi_node_get_property_reference().
The function returns -ENOENT if the given index resolves to "no entry"
reference and -ENODATA when there are no more entries in the property.
We then add static inline wrapper acpi_node_get_property_reference() that
passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
behaviour which some drivers have been relying on.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-29 21:39:41 +08:00
|
|
|
const char *name, size_t index, size_t num_args,
|
2018-07-17 22:19:11 +08:00
|
|
|
struct fwnode_reference_args *args);
|
ACPI / property: Allow holes in reference properties
DT allows holes or empty phandles for references. This is used for example
in SPI subsystem where some chip selects are native and others are regular
GPIOs. In ACPI _DSD we currently do not support this but instead the
preceding reference consumes all following integer arguments.
For example we would like to support something like the below ASL fragment
for SPI:
Package () {
"cs-gpios",
Package () {
^GPIO, 19, 0, 0, // GPIO CS0
0, // Native CS
^GPIO, 20, 0, 0, // GPIO CS1
}
}
The zero in the middle means "no entry" or NULL reference. To support this
we change acpi_data_get_property_reference() to take firmware node and
num_args as argument and rename it to __acpi_node_get_property_reference().
The function returns -ENOENT if the given index resolves to "no entry"
reference and -ENODATA when there are no more entries in the property.
We then add static inline wrapper acpi_node_get_property_reference() that
passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
behaviour which some drivers have been relying on.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-29 21:39:41 +08:00
|
|
|
|
2017-07-21 19:39:34 +08:00
|
|
|
static inline int acpi_node_get_property_reference(
|
|
|
|
const struct fwnode_handle *fwnode,
|
ACPI / property: Allow holes in reference properties
DT allows holes or empty phandles for references. This is used for example
in SPI subsystem where some chip selects are native and others are regular
GPIOs. In ACPI _DSD we currently do not support this but instead the
preceding reference consumes all following integer arguments.
For example we would like to support something like the below ASL fragment
for SPI:
Package () {
"cs-gpios",
Package () {
^GPIO, 19, 0, 0, // GPIO CS0
0, // Native CS
^GPIO, 20, 0, 0, // GPIO CS1
}
}
The zero in the middle means "no entry" or NULL reference. To support this
we change acpi_data_get_property_reference() to take firmware node and
num_args as argument and rename it to __acpi_node_get_property_reference().
The function returns -ENOENT if the given index resolves to "no entry"
reference and -ENODATA when there are no more entries in the property.
We then add static inline wrapper acpi_node_get_property_reference() that
passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
behaviour which some drivers have been relying on.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-29 21:39:41 +08:00
|
|
|
const char *name, size_t index,
|
2018-07-17 22:19:11 +08:00
|
|
|
struct fwnode_reference_args *args)
|
ACPI / property: Allow holes in reference properties
DT allows holes or empty phandles for references. This is used for example
in SPI subsystem where some chip selects are native and others are regular
GPIOs. In ACPI _DSD we currently do not support this but instead the
preceding reference consumes all following integer arguments.
For example we would like to support something like the below ASL fragment
for SPI:
Package () {
"cs-gpios",
Package () {
^GPIO, 19, 0, 0, // GPIO CS0
0, // Native CS
^GPIO, 20, 0, 0, // GPIO CS1
}
}
The zero in the middle means "no entry" or NULL reference. To support this
we change acpi_data_get_property_reference() to take firmware node and
num_args as argument and rename it to __acpi_node_get_property_reference().
The function returns -ENOENT if the given index resolves to "no entry"
reference and -ENODATA when there are no more entries in the property.
We then add static inline wrapper acpi_node_get_property_reference() that
passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
behaviour which some drivers have been relying on.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-29 21:39:41 +08:00
|
|
|
{
|
|
|
|
return __acpi_node_get_property_reference(fwnode, name, index,
|
2018-07-17 22:19:11 +08:00
|
|
|
NR_FWNODE_REFERENCE_ARGS, args);
|
ACPI / property: Allow holes in reference properties
DT allows holes or empty phandles for references. This is used for example
in SPI subsystem where some chip selects are native and others are regular
GPIOs. In ACPI _DSD we currently do not support this but instead the
preceding reference consumes all following integer arguments.
For example we would like to support something like the below ASL fragment
for SPI:
Package () {
"cs-gpios",
Package () {
^GPIO, 19, 0, 0, // GPIO CS0
0, // Native CS
^GPIO, 20, 0, 0, // GPIO CS1
}
}
The zero in the middle means "no entry" or NULL reference. To support this
we change acpi_data_get_property_reference() to take firmware node and
num_args as argument and rename it to __acpi_node_get_property_reference().
The function returns -ENOENT if the given index resolves to "no entry"
reference and -ENODATA when there are no more entries in the property.
We then add static inline wrapper acpi_node_get_property_reference() that
passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
behaviour which some drivers have been relying on.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-29 21:39:41 +08:00
|
|
|
}
|
2014-11-04 08:28:56 +08:00
|
|
|
|
2018-09-28 05:57:05 +08:00
|
|
|
static inline bool acpi_dev_has_props(const struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
return !list_empty(&adev->data.properties);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct acpi_device_properties *
|
|
|
|
acpi_data_add_props(struct acpi_device_data *data, const guid_t *guid,
|
|
|
|
const union acpi_object *properties);
|
|
|
|
|
2017-07-21 19:39:34 +08:00
|
|
|
int acpi_node_prop_get(const struct fwnode_handle *fwnode, const char *propname,
|
2015-08-27 10:40:05 +08:00
|
|
|
void **valptr);
|
2014-11-04 21:03:59 +08:00
|
|
|
|
2017-07-21 19:39:36 +08:00
|
|
|
struct fwnode_handle *acpi_get_next_subnode(const struct fwnode_handle *fwnode,
|
2017-03-28 15:52:18 +08:00
|
|
|
struct fwnode_handle *child);
|
2017-07-21 19:39:36 +08:00
|
|
|
struct fwnode_handle *acpi_node_get_parent(const struct fwnode_handle *fwnode);
|
2015-09-28 22:49:12 +08:00
|
|
|
|
|
|
|
struct acpi_probe_entry;
|
|
|
|
typedef bool (*acpi_probe_entry_validate_subtbl)(struct acpi_subtable_header *,
|
|
|
|
struct acpi_probe_entry *);
|
|
|
|
|
|
|
|
#define ACPI_TABLE_ID_LEN 5
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct acpi_probe_entry - boot-time probing entry
|
|
|
|
* @id: ACPI table name
|
|
|
|
* @type: Optional subtable type to match
|
|
|
|
* (if @id contains subtables)
|
|
|
|
* @subtable_valid: Optional callback to check the validity of
|
|
|
|
* the subtable
|
|
|
|
* @probe_table: Callback to the driver being probed when table
|
|
|
|
* match is successful
|
|
|
|
* @probe_subtbl: Callback to the driver being probed when table and
|
|
|
|
* subtable match (and optional callback is successful)
|
|
|
|
* @driver_data: Sideband data provided back to the driver
|
|
|
|
*/
|
|
|
|
struct acpi_probe_entry {
|
|
|
|
__u8 id[ACPI_TABLE_ID_LEN];
|
|
|
|
__u8 type;
|
|
|
|
acpi_probe_entry_validate_subtbl subtable_valid;
|
|
|
|
union {
|
|
|
|
acpi_tbl_table_handler probe_table;
|
|
|
|
acpi_tbl_entry_handler probe_subtbl;
|
|
|
|
};
|
|
|
|
kernel_ulong_t driver_data;
|
|
|
|
};
|
|
|
|
|
2020-05-30 22:34:30 +08:00
|
|
|
#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, subtable, \
|
|
|
|
valid, data, fn) \
|
2015-09-28 22:49:12 +08:00
|
|
|
static const struct acpi_probe_entry __acpi_probe_##name \
|
2020-10-22 10:36:07 +08:00
|
|
|
__used __section("__" #table "_acpi_probe_table") = { \
|
2015-09-28 22:49:12 +08:00
|
|
|
.id = table_id, \
|
|
|
|
.type = subtable, \
|
|
|
|
.subtable_valid = valid, \
|
2020-05-30 22:34:30 +08:00
|
|
|
.probe_table = fn, \
|
|
|
|
.driver_data = data, \
|
|
|
|
}
|
2015-09-28 22:49:12 +08:00
|
|
|
|
2020-05-30 22:34:28 +08:00
|
|
|
#define ACPI_DECLARE_SUBTABLE_PROBE_ENTRY(table, name, table_id, \
|
|
|
|
subtable, valid, data, fn) \
|
|
|
|
static const struct acpi_probe_entry __acpi_probe_##name \
|
2020-10-22 10:36:07 +08:00
|
|
|
__used __section("__" #table "_acpi_probe_table") = { \
|
2020-05-30 22:34:28 +08:00
|
|
|
.id = table_id, \
|
|
|
|
.type = subtable, \
|
|
|
|
.subtable_valid = valid, \
|
|
|
|
.probe_subtbl = fn, \
|
|
|
|
.driver_data = data, \
|
|
|
|
}
|
2015-09-28 22:49:12 +08:00
|
|
|
|
|
|
|
#define ACPI_PROBE_TABLE(name) __##name##_acpi_probe_table
|
|
|
|
#define ACPI_PROBE_TABLE_END(name) __##name##_acpi_probe_table_end
|
|
|
|
|
|
|
|
int __acpi_probe_device_table(struct acpi_probe_entry *start, int nr);
|
|
|
|
|
|
|
|
#define acpi_probe_device_table(t) \
|
|
|
|
({ \
|
|
|
|
extern struct acpi_probe_entry ACPI_PROBE_TABLE(t), \
|
|
|
|
ACPI_PROBE_TABLE_END(t); \
|
|
|
|
__acpi_probe_device_table(&ACPI_PROBE_TABLE(t), \
|
|
|
|
(&ACPI_PROBE_TABLE_END(t) - \
|
|
|
|
&ACPI_PROBE_TABLE(t))); \
|
|
|
|
})
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 19:33:55 +08:00
|
|
|
#else
|
|
|
|
static inline int acpi_dev_get_property(struct acpi_device *adev,
|
|
|
|
const char *name, acpi_object_type type,
|
|
|
|
const union acpi_object **obj)
|
|
|
|
{
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
2015-08-27 10:40:05 +08:00
|
|
|
|
ACPI / property: Allow holes in reference properties
DT allows holes or empty phandles for references. This is used for example
in SPI subsystem where some chip selects are native and others are regular
GPIOs. In ACPI _DSD we currently do not support this but instead the
preceding reference consumes all following integer arguments.
For example we would like to support something like the below ASL fragment
for SPI:
Package () {
"cs-gpios",
Package () {
^GPIO, 19, 0, 0, // GPIO CS0
0, // Native CS
^GPIO, 20, 0, 0, // GPIO CS1
}
}
The zero in the middle means "no entry" or NULL reference. To support this
we change acpi_data_get_property_reference() to take firmware node and
num_args as argument and rename it to __acpi_node_get_property_reference().
The function returns -ENOENT if the given index resolves to "no entry"
reference and -ENODATA when there are no more entries in the property.
We then add static inline wrapper acpi_node_get_property_reference() that
passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
behaviour which some drivers have been relying on.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-29 21:39:41 +08:00
|
|
|
static inline int
|
2017-07-21 19:39:34 +08:00
|
|
|
__acpi_node_get_property_reference(const struct fwnode_handle *fwnode,
|
ACPI / property: Allow holes in reference properties
DT allows holes or empty phandles for references. This is used for example
in SPI subsystem where some chip selects are native and others are regular
GPIOs. In ACPI _DSD we currently do not support this but instead the
preceding reference consumes all following integer arguments.
For example we would like to support something like the below ASL fragment
for SPI:
Package () {
"cs-gpios",
Package () {
^GPIO, 19, 0, 0, // GPIO CS0
0, // Native CS
^GPIO, 20, 0, 0, // GPIO CS1
}
}
The zero in the middle means "no entry" or NULL reference. To support this
we change acpi_data_get_property_reference() to take firmware node and
num_args as argument and rename it to __acpi_node_get_property_reference().
The function returns -ENOENT if the given index resolves to "no entry"
reference and -ENODATA when there are no more entries in the property.
We then add static inline wrapper acpi_node_get_property_reference() that
passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
behaviour which some drivers have been relying on.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-29 21:39:41 +08:00
|
|
|
const char *name, size_t index, size_t num_args,
|
2018-07-17 22:19:11 +08:00
|
|
|
struct fwnode_reference_args *args)
|
ACPI / property: Allow holes in reference properties
DT allows holes or empty phandles for references. This is used for example
in SPI subsystem where some chip selects are native and others are regular
GPIOs. In ACPI _DSD we currently do not support this but instead the
preceding reference consumes all following integer arguments.
For example we would like to support something like the below ASL fragment
for SPI:
Package () {
"cs-gpios",
Package () {
^GPIO, 19, 0, 0, // GPIO CS0
0, // Native CS
^GPIO, 20, 0, 0, // GPIO CS1
}
}
The zero in the middle means "no entry" or NULL reference. To support this
we change acpi_data_get_property_reference() to take firmware node and
num_args as argument and rename it to __acpi_node_get_property_reference().
The function returns -ENOENT if the given index resolves to "no entry"
reference and -ENODATA when there are no more entries in the property.
We then add static inline wrapper acpi_node_get_property_reference() that
passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
behaviour which some drivers have been relying on.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-29 21:39:41 +08:00
|
|
|
{
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
2017-07-21 19:39:34 +08:00
|
|
|
static inline int
|
|
|
|
acpi_node_get_property_reference(const struct fwnode_handle *fwnode,
|
|
|
|
const char *name, size_t index,
|
2018-07-17 22:19:11 +08:00
|
|
|
struct fwnode_reference_args *args)
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 19:33:55 +08:00
|
|
|
{
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
2014-11-04 08:28:56 +08:00
|
|
|
|
2017-07-21 19:39:34 +08:00
|
|
|
static inline int acpi_node_prop_get(const struct fwnode_handle *fwnode,
|
2015-08-27 10:40:05 +08:00
|
|
|
const char *propname,
|
|
|
|
void **valptr)
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 19:33:55 +08:00
|
|
|
{
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
2014-11-04 08:28:56 +08:00
|
|
|
|
2017-03-28 15:52:18 +08:00
|
|
|
static inline struct fwnode_handle *
|
2017-07-21 19:39:36 +08:00
|
|
|
acpi_get_next_subnode(const struct fwnode_handle *fwnode,
|
|
|
|
struct fwnode_handle *child)
|
2014-11-04 21:03:59 +08:00
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-03-28 15:52:16 +08:00
|
|
|
static inline struct fwnode_handle *
|
2017-07-21 19:39:36 +08:00
|
|
|
acpi_node_get_parent(const struct fwnode_handle *fwnode)
|
2017-03-28 15:52:16 +08:00
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-03-28 15:52:20 +08:00
|
|
|
static inline struct fwnode_handle *
|
2017-07-21 19:39:36 +08:00
|
|
|
acpi_graph_get_next_endpoint(const struct fwnode_handle *fwnode,
|
2017-03-28 15:52:20 +08:00
|
|
|
struct fwnode_handle *prev)
|
|
|
|
{
|
|
|
|
return ERR_PTR(-ENXIO);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int
|
2017-07-21 19:39:36 +08:00
|
|
|
acpi_graph_get_remote_endpoint(const struct fwnode_handle *fwnode,
|
2017-03-28 15:52:20 +08:00
|
|
|
struct fwnode_handle **remote,
|
|
|
|
struct fwnode_handle **port,
|
|
|
|
struct fwnode_handle **endpoint)
|
|
|
|
{
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
2016-08-16 23:59:52 +08:00
|
|
|
#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, subtable, valid, data, fn) \
|
2015-09-28 22:49:12 +08:00
|
|
|
static const void * __acpi_table_##name[] \
|
|
|
|
__attribute__((unused)) \
|
|
|
|
= { (void *) table_id, \
|
|
|
|
(void *) subtable, \
|
|
|
|
(void *) valid, \
|
|
|
|
(void *) fn, \
|
|
|
|
(void *) data }
|
|
|
|
|
|
|
|
#define acpi_probe_device_table(t) ({ int __r = 0; __r;})
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 19:33:55 +08:00
|
|
|
#endif
|
|
|
|
|
2016-06-20 18:56:10 +08:00
|
|
|
#ifdef CONFIG_ACPI_TABLE_UPGRADE
|
|
|
|
void acpi_table_upgrade(void);
|
|
|
|
#else
|
|
|
|
static inline void acpi_table_upgrade(void) { }
|
|
|
|
#endif
|
|
|
|
|
2016-09-20 20:30:51 +08:00
|
|
|
#if defined(CONFIG_ACPI) && defined(CONFIG_ACPI_WATCHDOG)
|
|
|
|
extern bool acpi_has_watchdog(void);
|
|
|
|
#else
|
|
|
|
static inline bool acpi_has_watchdog(void) { return false; }
|
|
|
|
#endif
|
|
|
|
|
2016-09-28 04:54:13 +08:00
|
|
|
#ifdef CONFIG_ACPI_SPCR_TABLE
|
2017-07-28 05:15:52 +08:00
|
|
|
extern bool qdf2400_e44_present;
|
2018-01-18 23:09:51 +08:00
|
|
|
int acpi_parse_spcr(bool enable_earlycon, bool enable_console);
|
2016-09-28 04:54:13 +08:00
|
|
|
#else
|
2018-01-18 23:09:51 +08:00
|
|
|
static inline int acpi_parse_spcr(bool enable_earlycon, bool enable_console)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2016-09-28 04:54:13 +08:00
|
|
|
#endif
|
|
|
|
|
2017-02-03 07:23:58 +08:00
|
|
|
#if IS_ENABLED(CONFIG_ACPI_GENERIC_GSI)
|
|
|
|
int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res);
|
|
|
|
#else
|
|
|
|
static inline
|
|
|
|
int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-10-06 07:24:03 +08:00
|
|
|
#ifdef CONFIG_ACPI_LPIT
|
|
|
|
int lpit_read_residency_count_address(u64 *address);
|
|
|
|
#else
|
|
|
|
static inline int lpit_read_residency_count_address(u64 *address)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2018-06-05 22:35:03 +08:00
|
|
|
#ifdef CONFIG_ACPI_PPTT
|
2019-08-09 04:40:06 +08:00
|
|
|
int acpi_pptt_cpu_is_thread(unsigned int cpu);
|
2018-05-12 07:58:00 +08:00
|
|
|
int find_acpi_cpu_topology(unsigned int cpu, int level);
|
|
|
|
int find_acpi_cpu_topology_package(unsigned int cpu);
|
2019-06-27 05:37:16 +08:00
|
|
|
int find_acpi_cpu_topology_hetero_id(unsigned int cpu);
|
2018-05-12 07:58:00 +08:00
|
|
|
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
|
2018-06-05 22:35:03 +08:00
|
|
|
#else
|
2019-08-09 04:40:06 +08:00
|
|
|
static inline int acpi_pptt_cpu_is_thread(unsigned int cpu)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-06-05 22:35:03 +08:00
|
|
|
static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
static inline int find_acpi_cpu_topology_package(unsigned int cpu)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2019-06-27 05:37:16 +08:00
|
|
|
static inline int find_acpi_cpu_topology_hetero_id(unsigned int cpu)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-06-05 22:35:03 +08:00
|
|
|
static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
#endif
|
2018-05-12 07:58:00 +08:00
|
|
|
|
2018-11-09 22:21:35 +08:00
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
extern int acpi_platform_notify(struct device *dev, enum kobject_action action);
|
|
|
|
#else
|
|
|
|
static inline int
|
|
|
|
acpi_platform_notify(struct device *dev, enum kobject_action action)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-05-27 16:21:50 +08:00
|
|
|
#endif /*_LINUX_ACPI_H*/
|