summaryrefslogtreecommitdiffstats
path: root/include/acpi
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2015-08-27 04:36:14 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2015-09-15 01:47:34 +0200
commit445b0eb058f5f31c844a731cb82e7441d0d9e578 (patch)
treece7bc79930dbd23127e0126420fc5abf0fa3f3df /include/acpi
parentbd8191cc8a74018e255eb3efff5e02dc305a5ed1 (diff)
downloadlinux-445b0eb058f5f31c844a731cb82e7441d0d9e578.tar.bz2
ACPI / property: Add support for data-only subnodes
In some cases, the information expressed via device properties is hierarchical by nature. For example, the properties of a composite device consisting of multiple semi-dependent components may need to be represented in the form of a tree of property data sets corresponding to specific components of the device. Unfortunately, using ACPI device objects for this purpose turns out to be problematic, mostly due to the assumption made by some operating systems (that platform firmware generally needs to work with) that each device object in the ACPI namespace represents a device requiring a separate driver. That assumption leads to complications which reportedly are impractically difficult to overcome and a different approach is needed for the sake of interoperability. The approach implemented here is based on extending _DSD via pointers (links) to additional ACPI objects returning data packages formatted in accordance with the _DSD formatting rules defined by Section 6.2.5 of ACPI 6. Those additional objects are referred to as data-only subnodes of the device object containing the _DSD pointing to them. The links to them need to be located in a separate section of the _DSD data package following UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b referred to as the Hierarchical Data Extension UUID as defined in [1]. Each of them is represented by a package of two strings. The first string in that package (the key) is regarded as the name of the data-only subnode pointed to by the link. The second string in it (the target) is expected to hold the ACPI namespace path (possibly utilizing the usual ACPI namespace search rules) of an ACPI object evaluating to a data package extending the _DSD. The device properties initialization code follows those links, creates a struct acpi_data_node object for each of them to store the data returned by the ACPI object pointed to by it and processes those data recursively (which may lead to the creation of more struct acpi_data_node objects if the returned data package contains the Hierarchical Data Extension UUID section with more links in it). All of the struct acpi_data_node objects are present until the the ACPI device object containing the _DSD with links to them is deleted and they are deleted along with that object. [1]: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Diffstat (limited to 'include/acpi')
-rw-r--r--include/acpi/acpi_bus.h9
1 files changed, 9 insertions, 0 deletions
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 5ba8fb64f664..79cfee646d6b 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -343,6 +343,7 @@ struct acpi_device_data {
const union acpi_object *pointer;
const union acpi_object *properties;
const union acpi_object *of_compatible;
+ struct list_head subnodes;
};
struct acpi_gpio_mapping;
@@ -378,6 +379,14 @@ struct acpi_device {
void (*remove)(struct acpi_device *);
};
+/* Non-device subnode */
+struct acpi_data_node {
+ const char *name;
+ struct fwnode_handle fwnode;
+ struct acpi_device_data data;
+ struct list_head sibling;
+};
+
static inline bool acpi_check_dma(struct acpi_device *adev, bool *coherent)
{
bool ret = false;