2019-06-04 11:11:33 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
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 15:33:55 +04:00
|
|
|
/*
|
|
|
|
* ACPI device specific properties support.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2014, Intel Corporation
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Authors: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
|
|
* Darren Hart <dvhart@linux.intel.com>
|
|
|
|
* Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/export.h>
|
|
|
|
|
|
|
|
#include "internal.h"
|
|
|
|
|
2017-07-21 14:39:34 +03:00
|
|
|
static int acpi_data_get_property_array(const struct acpi_device_data *data,
|
2015-08-27 05:40:05 +03:00
|
|
|
const char *name,
|
|
|
|
acpi_object_type type,
|
|
|
|
const union acpi_object **obj);
|
|
|
|
|
2018-08-16 12:28:48 +03:00
|
|
|
/*
|
|
|
|
* The GUIDs here are made equivalent to each other in order to avoid extra
|
|
|
|
* complexity in the properties handling code, with the caveat that the
|
|
|
|
* kernel will accept certain combinations of GUID and properties that are
|
|
|
|
* not defined without a warning. For instance if any of the properties
|
|
|
|
* from different GUID appear in a property list of another, it will be
|
|
|
|
* accepted by the kernel. Firmware validation tools should catch these.
|
|
|
|
*/
|
2018-09-28 00:57:05 +03:00
|
|
|
static const guid_t prp_guids[] = {
|
|
|
|
/* ACPI _DSD device properties GUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
|
2017-07-19 21:28:57 +03:00
|
|
|
GUID_INIT(0xdaffd814, 0x6eba, 0x4d8c,
|
2018-09-28 00:57:05 +03:00
|
|
|
0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01),
|
2018-09-28 00:57:14 +03:00
|
|
|
/* Hotplug in D3 GUID: 6211e2c0-58a3-4af3-90e1-927a4e0c55a4 */
|
|
|
|
GUID_INIT(0x6211e2c0, 0x58a3, 0x4af3,
|
|
|
|
0x90, 0xe1, 0x92, 0x7a, 0x4e, 0x0c, 0x55, 0xa4),
|
2018-08-16 12:28:48 +03:00
|
|
|
/* External facing port GUID: efcc06cc-73ac-4bc3-bff0-76143807c389 */
|
|
|
|
GUID_INIT(0xefcc06cc, 0x73ac, 0x4bc3,
|
|
|
|
0xbf, 0xf0, 0x76, 0x14, 0x38, 0x07, 0xc3, 0x89),
|
2019-05-14 16:56:21 +03:00
|
|
|
/* Thunderbolt GUID for IMR_VALID: c44d002f-69f9-4e7d-a904-a7baabdf43f7 */
|
|
|
|
GUID_INIT(0xc44d002f, 0x69f9, 0x4e7d,
|
|
|
|
0xa9, 0x04, 0xa7, 0xba, 0xab, 0xdf, 0x43, 0xf7),
|
|
|
|
/* Thunderbolt GUID for WAKE_SUPPORTED: 6c501103-c189-4296-ba72-9bf5a26ebe5d */
|
|
|
|
GUID_INIT(0x6c501103, 0xc189, 0x4296,
|
|
|
|
0xba, 0x72, 0x9b, 0xf5, 0xa2, 0x6e, 0xbe, 0x5d),
|
2020-07-09 21:43:33 +03:00
|
|
|
/* Storage device needs D3 GUID: 5025030f-842f-4ab4-a561-99a5189762d0 */
|
|
|
|
GUID_INIT(0x5025030f, 0x842f, 0x4ab4,
|
|
|
|
0xa5, 0x61, 0x99, 0xa5, 0x18, 0x97, 0x62, 0xd0),
|
2018-09-28 00:57:05 +03:00
|
|
|
};
|
|
|
|
|
2019-04-01 11:26:35 +03:00
|
|
|
/* ACPI _DSD data subnodes GUID: dbb8e3e6-5886-4ba6-8795-1319f52a966b */
|
2017-07-19 21:28:57 +03:00
|
|
|
static const guid_t ads_guid =
|
|
|
|
GUID_INIT(0xdbb8e3e6, 0x5886, 0x4ba6,
|
|
|
|
0x87, 0x95, 0x13, 0x19, 0xf5, 0x2a, 0x96, 0x6b);
|
2015-08-27 05:36:14 +03:00
|
|
|
|
|
|
|
static bool acpi_enumerate_nondev_subnodes(acpi_handle scope,
|
|
|
|
const union acpi_object *desc,
|
2017-03-28 10:52:16 +03:00
|
|
|
struct acpi_device_data *data,
|
|
|
|
struct fwnode_handle *parent);
|
2015-08-27 05:36:14 +03:00
|
|
|
static bool acpi_extract_properties(const union acpi_object *desc,
|
|
|
|
struct acpi_device_data *data);
|
|
|
|
|
2016-11-22 02:02:19 +03:00
|
|
|
static bool acpi_nondev_subnode_extract(const union acpi_object *desc,
|
|
|
|
acpi_handle handle,
|
|
|
|
const union acpi_object *link,
|
2017-03-28 10:52:16 +03:00
|
|
|
struct list_head *list,
|
|
|
|
struct fwnode_handle *parent)
|
2015-08-27 05:36:14 +03:00
|
|
|
{
|
|
|
|
struct acpi_data_node *dn;
|
2016-11-22 02:02:19 +03:00
|
|
|
bool result;
|
2015-08-27 05:36:14 +03:00
|
|
|
|
|
|
|
dn = kzalloc(sizeof(*dn), GFP_KERNEL);
|
|
|
|
if (!dn)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
dn->name = link->package.elements[0].string.pointer;
|
2020-11-21 05:02:22 +03:00
|
|
|
fwnode_init(&dn->fwnode, &acpi_data_fwnode_ops);
|
2017-03-28 10:52:16 +03:00
|
|
|
dn->parent = parent;
|
2018-09-28 00:57:05 +03:00
|
|
|
INIT_LIST_HEAD(&dn->data.properties);
|
2015-08-27 05:36:14 +03:00
|
|
|
INIT_LIST_HEAD(&dn->data.subnodes);
|
|
|
|
|
2016-11-22 02:02:19 +03:00
|
|
|
result = acpi_extract_properties(desc, &dn->data);
|
2015-08-27 05:36:14 +03:00
|
|
|
|
2016-11-22 02:02:19 +03:00
|
|
|
if (handle) {
|
|
|
|
acpi_handle scope;
|
|
|
|
acpi_status status;
|
2015-08-27 05:36:14 +03:00
|
|
|
|
2016-11-22 02:02:19 +03:00
|
|
|
/*
|
|
|
|
* The scope for the subnode object lookup is the one of the
|
|
|
|
* namespace node (device) containing the object that has
|
|
|
|
* returned the package. That is, it's the scope of that
|
|
|
|
* object's parent.
|
|
|
|
*/
|
|
|
|
status = acpi_get_parent(handle, &scope);
|
|
|
|
if (ACPI_SUCCESS(status)
|
2017-03-28 10:52:16 +03:00
|
|
|
&& acpi_enumerate_nondev_subnodes(scope, desc, &dn->data,
|
|
|
|
&dn->fwnode))
|
2016-11-22 02:02:19 +03:00
|
|
|
result = true;
|
2017-03-28 10:52:16 +03:00
|
|
|
} else if (acpi_enumerate_nondev_subnodes(NULL, desc, &dn->data,
|
|
|
|
&dn->fwnode)) {
|
2016-11-22 02:02:19 +03:00
|
|
|
result = true;
|
|
|
|
}
|
2015-08-27 05:36:14 +03:00
|
|
|
|
2016-11-22 02:02:19 +03:00
|
|
|
if (result) {
|
2015-08-27 05:37:19 +03:00
|
|
|
dn->handle = handle;
|
2016-11-22 02:02:19 +03:00
|
|
|
dn->data.pointer = desc;
|
2015-08-27 05:36:14 +03:00
|
|
|
list_add_tail(&dn->sibling, list);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-11-22 02:02:19 +03:00
|
|
|
kfree(dn);
|
2015-08-27 05:36:14 +03:00
|
|
|
acpi_handle_debug(handle, "Invalid properties/subnodes data, skipping\n");
|
2016-11-22 02:02:19 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool acpi_nondev_subnode_data_ok(acpi_handle handle,
|
|
|
|
const union acpi_object *link,
|
2017-03-28 10:52:16 +03:00
|
|
|
struct list_head *list,
|
|
|
|
struct fwnode_handle *parent)
|
2016-11-22 02:02:19 +03:00
|
|
|
{
|
|
|
|
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_evaluate_object_typed(handle, NULL, NULL, &buf,
|
|
|
|
ACPI_TYPE_PACKAGE);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return false;
|
|
|
|
|
2017-03-28 10:52:16 +03:00
|
|
|
if (acpi_nondev_subnode_extract(buf.pointer, handle, link, list,
|
|
|
|
parent))
|
2016-11-22 02:02:19 +03:00
|
|
|
return true;
|
2015-08-27 05:36:14 +03:00
|
|
|
|
|
|
|
ACPI_FREE(buf.pointer);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-11-22 02:02:19 +03:00
|
|
|
static bool acpi_nondev_subnode_ok(acpi_handle scope,
|
|
|
|
const union acpi_object *link,
|
2017-03-28 10:52:16 +03:00
|
|
|
struct list_head *list,
|
|
|
|
struct fwnode_handle *parent)
|
2016-11-22 02:02:19 +03:00
|
|
|
{
|
|
|
|
acpi_handle handle;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
if (!scope)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
status = acpi_get_handle(scope, link->package.elements[1].string.pointer,
|
|
|
|
&handle);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return false;
|
|
|
|
|
2017-03-28 10:52:16 +03:00
|
|
|
return acpi_nondev_subnode_data_ok(handle, link, list, parent);
|
2016-11-22 02:02:19 +03:00
|
|
|
}
|
|
|
|
|
2015-08-27 05:36:14 +03:00
|
|
|
static int acpi_add_nondev_subnodes(acpi_handle scope,
|
|
|
|
const union acpi_object *links,
|
2017-03-28 10:52:16 +03:00
|
|
|
struct list_head *list,
|
|
|
|
struct fwnode_handle *parent)
|
2015-08-27 05:36:14 +03:00
|
|
|
{
|
|
|
|
bool ret = false;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < links->package.count; i++) {
|
2016-11-22 02:02:19 +03:00
|
|
|
const union acpi_object *link, *desc;
|
|
|
|
acpi_handle handle;
|
|
|
|
bool result;
|
2015-08-27 05:36:14 +03:00
|
|
|
|
|
|
|
link = &links->package.elements[i];
|
2016-11-22 02:02:19 +03:00
|
|
|
/* Only two elements allowed. */
|
|
|
|
if (link->package.count != 2)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* The first one must be a string. */
|
|
|
|
if (link->package.elements[0].type != ACPI_TYPE_STRING)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* The second one may be a string, a reference or a package. */
|
|
|
|
switch (link->package.elements[1].type) {
|
|
|
|
case ACPI_TYPE_STRING:
|
2017-03-28 10:52:16 +03:00
|
|
|
result = acpi_nondev_subnode_ok(scope, link, list,
|
|
|
|
parent);
|
2016-11-22 02:02:19 +03:00
|
|
|
break;
|
|
|
|
case ACPI_TYPE_LOCAL_REFERENCE:
|
|
|
|
handle = link->package.elements[1].reference.handle;
|
2017-03-28 10:52:16 +03:00
|
|
|
result = acpi_nondev_subnode_data_ok(handle, link, list,
|
|
|
|
parent);
|
2016-11-22 02:02:19 +03:00
|
|
|
break;
|
|
|
|
case ACPI_TYPE_PACKAGE:
|
|
|
|
desc = &link->package.elements[1];
|
2017-03-28 10:52:16 +03:00
|
|
|
result = acpi_nondev_subnode_extract(desc, NULL, link,
|
|
|
|
list, parent);
|
2016-11-22 02:02:19 +03:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
result = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
ret = ret || result;
|
2015-08-27 05:36:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool acpi_enumerate_nondev_subnodes(acpi_handle scope,
|
|
|
|
const union acpi_object *desc,
|
2017-03-28 10:52:16 +03:00
|
|
|
struct acpi_device_data *data,
|
|
|
|
struct fwnode_handle *parent)
|
2015-08-27 05:36:14 +03:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2017-07-19 21:28:57 +03:00
|
|
|
/* Look for the ACPI data subnodes GUID. */
|
2015-08-27 05:36:14 +03:00
|
|
|
for (i = 0; i < desc->package.count; i += 2) {
|
2017-07-19 21:28:57 +03:00
|
|
|
const union acpi_object *guid, *links;
|
2015-08-27 05:36:14 +03:00
|
|
|
|
2017-07-19 21:28:57 +03:00
|
|
|
guid = &desc->package.elements[i];
|
2015-08-27 05:36:14 +03:00
|
|
|
links = &desc->package.elements[i + 1];
|
|
|
|
|
|
|
|
/*
|
2017-07-19 21:28:57 +03:00
|
|
|
* The first element must be a GUID and the second one must be
|
2015-08-27 05:36:14 +03:00
|
|
|
* a package.
|
|
|
|
*/
|
2017-07-19 21:28:57 +03:00
|
|
|
if (guid->type != ACPI_TYPE_BUFFER ||
|
|
|
|
guid->buffer.length != 16 ||
|
|
|
|
links->type != ACPI_TYPE_PACKAGE)
|
2015-08-27 05:36:14 +03:00
|
|
|
break;
|
|
|
|
|
2017-07-19 21:28:57 +03:00
|
|
|
if (!guid_equal((guid_t *)guid->buffer.pointer, &ads_guid))
|
2015-08-27 05:36:14 +03:00
|
|
|
continue;
|
|
|
|
|
2017-03-28 10:52:16 +03:00
|
|
|
return acpi_add_nondev_subnodes(scope, links, &data->subnodes,
|
|
|
|
parent);
|
2015-08-27 05:36:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
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 15:33:55 +04:00
|
|
|
|
|
|
|
static bool acpi_property_value_ok(const union acpi_object *value)
|
|
|
|
{
|
|
|
|
int j;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The value must be an integer, a string, a reference, or a package
|
|
|
|
* whose every element must be an integer, a string, or a reference.
|
|
|
|
*/
|
|
|
|
switch (value->type) {
|
|
|
|
case ACPI_TYPE_INTEGER:
|
|
|
|
case ACPI_TYPE_STRING:
|
|
|
|
case ACPI_TYPE_LOCAL_REFERENCE:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
case ACPI_TYPE_PACKAGE:
|
|
|
|
for (j = 0; j < value->package.count; j++)
|
|
|
|
switch (value->package.elements[j].type) {
|
|
|
|
case ACPI_TYPE_INTEGER:
|
|
|
|
case ACPI_TYPE_STRING:
|
|
|
|
case ACPI_TYPE_LOCAL_REFERENCE:
|
|
|
|
continue;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool acpi_properties_format_valid(const union acpi_object *properties)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < properties->package.count; i++) {
|
|
|
|
const union acpi_object *property;
|
|
|
|
|
|
|
|
property = &properties->package.elements[i];
|
|
|
|
/*
|
|
|
|
* Only two elements allowed, the first one must be a string and
|
|
|
|
* the second one has to satisfy certain conditions.
|
|
|
|
*/
|
|
|
|
if (property->package.count != 2
|
|
|
|
|| property->package.elements[0].type != ACPI_TYPE_STRING
|
|
|
|
|| !acpi_property_value_ok(&property->package.elements[1]))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-10-21 15:33:56 +04:00
|
|
|
static void acpi_init_of_compatible(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
const union acpi_object *of_compatible;
|
|
|
|
int ret;
|
|
|
|
|
2015-08-27 05:40:05 +03:00
|
|
|
ret = acpi_data_get_property_array(&adev->data, "compatible",
|
|
|
|
ACPI_TYPE_STRING, &of_compatible);
|
2014-10-21 15:33:56 +04:00
|
|
|
if (ret) {
|
|
|
|
ret = acpi_dev_get_property(adev, "compatible",
|
|
|
|
ACPI_TYPE_STRING, &of_compatible);
|
|
|
|
if (ret) {
|
2015-05-05 16:43:07 +03:00
|
|
|
if (adev->parent
|
|
|
|
&& adev->parent->flags.of_compatible_ok)
|
|
|
|
goto out;
|
|
|
|
|
2014-10-21 15:33:56 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
adev->data.of_compatible = of_compatible;
|
2015-05-05 16:43:07 +03:00
|
|
|
|
|
|
|
out:
|
|
|
|
adev->flags.of_compatible_ok = 1;
|
2014-10-21 15:33:56 +04:00
|
|
|
}
|
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
static bool acpi_is_property_guid(const guid_t *guid)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(prp_guids); i++) {
|
|
|
|
if (guid_equal(guid, &prp_guids[i]))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct acpi_device_properties *
|
|
|
|
acpi_data_add_props(struct acpi_device_data *data, const guid_t *guid,
|
|
|
|
const union acpi_object *properties)
|
|
|
|
{
|
|
|
|
struct acpi_device_properties *props;
|
|
|
|
|
|
|
|
props = kzalloc(sizeof(*props), GFP_KERNEL);
|
|
|
|
if (props) {
|
|
|
|
INIT_LIST_HEAD(&props->list);
|
|
|
|
props->guid = guid;
|
|
|
|
props->properties = properties;
|
|
|
|
list_add_tail(&props->list, &data->properties);
|
|
|
|
}
|
|
|
|
|
|
|
|
return props;
|
|
|
|
}
|
|
|
|
|
2015-08-27 05:35:14 +03:00
|
|
|
static bool acpi_extract_properties(const union acpi_object *desc,
|
|
|
|
struct acpi_device_data *data)
|
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 15:33:55 +04:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (desc->package.count % 2)
|
2015-08-27 05:35:14 +03:00
|
|
|
return false;
|
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 15:33:55 +04:00
|
|
|
|
2017-07-19 21:28:57 +03:00
|
|
|
/* Look for the device properties GUID. */
|
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 15:33:55 +04:00
|
|
|
for (i = 0; i < desc->package.count; i += 2) {
|
2017-07-19 21:28:57 +03:00
|
|
|
const union acpi_object *guid, *properties;
|
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 15:33:55 +04:00
|
|
|
|
2017-07-19 21:28:57 +03:00
|
|
|
guid = &desc->package.elements[i];
|
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 15:33:55 +04:00
|
|
|
properties = &desc->package.elements[i + 1];
|
|
|
|
|
|
|
|
/*
|
2017-07-19 21:28:57 +03:00
|
|
|
* The first element must be a GUID and the second one must be
|
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 15:33:55 +04:00
|
|
|
* a package.
|
|
|
|
*/
|
2017-07-19 21:28:57 +03:00
|
|
|
if (guid->type != ACPI_TYPE_BUFFER ||
|
|
|
|
guid->buffer.length != 16 ||
|
|
|
|
properties->type != ACPI_TYPE_PACKAGE)
|
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 15:33:55 +04:00
|
|
|
break;
|
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
if (!acpi_is_property_guid((guid_t *)guid->buffer.pointer))
|
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 15:33:55 +04:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
2017-07-19 21:28:57 +03:00
|
|
|
* We found the matching GUID. Now validate the format of the
|
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 15:33:55 +04:00
|
|
|
* package immediately following it.
|
|
|
|
*/
|
|
|
|
if (!acpi_properties_format_valid(properties))
|
2018-09-28 00:57:05 +03:00
|
|
|
continue;
|
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 15:33:55 +04:00
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
acpi_data_add_props(data, (const guid_t *)guid->buffer.pointer,
|
|
|
|
properties);
|
2015-08-27 05:35:14 +03:00
|
|
|
}
|
2014-10-21 15:33:56 +04:00
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
return !list_empty(&data->properties);
|
2015-08-27 05:35:14 +03:00
|
|
|
}
|
2015-05-05 16:43:07 +03:00
|
|
|
|
2015-08-27 05:35:14 +03:00
|
|
|
void acpi_init_properties(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
|
|
|
|
struct acpi_hardware_id *hwid;
|
|
|
|
acpi_status status;
|
|
|
|
bool acpi_of = false;
|
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
INIT_LIST_HEAD(&adev->data.properties);
|
2015-08-27 05:36:14 +03:00
|
|
|
INIT_LIST_HEAD(&adev->data.subnodes);
|
|
|
|
|
2017-08-01 15:10:41 +03:00
|
|
|
if (!adev->handle)
|
|
|
|
return;
|
|
|
|
|
2015-08-27 05:35:14 +03:00
|
|
|
/*
|
|
|
|
* Check if ACPI_DT_NAMESPACE_HID is present and inthat case we fill in
|
|
|
|
* Device Tree compatible properties for this device.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(hwid, &adev->pnp.ids, list) {
|
|
|
|
if (!strcmp(hwid->id, ACPI_DT_NAMESPACE_HID)) {
|
|
|
|
acpi_of = true;
|
|
|
|
break;
|
|
|
|
}
|
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 15:33:55 +04:00
|
|
|
}
|
|
|
|
|
2015-08-27 05:35:14 +03:00
|
|
|
status = acpi_evaluate_object_typed(adev->handle, "_DSD", NULL, &buf,
|
|
|
|
ACPI_TYPE_PACKAGE);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (acpi_extract_properties(buf.pointer, &adev->data)) {
|
|
|
|
adev->data.pointer = buf.pointer;
|
|
|
|
if (acpi_of)
|
|
|
|
acpi_init_of_compatible(adev);
|
2015-08-27 05:36:14 +03:00
|
|
|
}
|
2017-03-28 10:52:16 +03:00
|
|
|
if (acpi_enumerate_nondev_subnodes(adev->handle, buf.pointer,
|
|
|
|
&adev->data, acpi_fwnode_handle(adev)))
|
2015-08-27 05:36:14 +03:00
|
|
|
adev->data.pointer = buf.pointer;
|
|
|
|
|
|
|
|
if (!adev->data.pointer) {
|
2015-08-27 05:35:14 +03:00
|
|
|
acpi_handle_debug(adev->handle, "Invalid _DSD data, skipping\n");
|
|
|
|
ACPI_FREE(buf.pointer);
|
|
|
|
}
|
2015-05-05 16:43:07 +03:00
|
|
|
|
|
|
|
out:
|
|
|
|
if (acpi_of && !adev->flags.of_compatible_ok)
|
|
|
|
acpi_handle_info(adev->handle,
|
2015-05-22 05:24:34 +03:00
|
|
|
ACPI_DT_NAMESPACE_HID " requires 'compatible' property\n");
|
ACPI / property: Support Apple _DSM properties
While the rest of the world has standardized on _DSD as the way to store
device properties in AML (introduced with ACPI 5.1 in 2014), Apple has
been using a custom _DSM to achieve the same for much longer (ever since
they switched from DeviceTree-based PowerPC to Intel in 2005, verified
with MacOS X 10.4.11).
The theory of operation on macOS is as follows: AppleACPIPlatform.kext
invokes mergeEFIproperties() and mergeDSMproperties() for each device to
merge properties conveyed by EFI drivers as well as properties stored in
AML into the I/O Kit registry from which they can be retrieved by
drivers. We've been supporting EFI properties since commit 58c5475aba67
("x86/efi: Retrieve and assign Apple device properties"). The present
commit adds support for _DSM properties, thereby completing our support
for Apple device properties. The _DSM properties are made available
under the primary fwnode, the EFI properties under the secondary fwnode.
So for devices which possess both property types, they can all be
elegantly accessed with the uniform API in <linux/property.h>.
Until recently we had no need to support _DSM properties, they contained
only uninteresting garbage. The situation has changed with MacBooks and
MacBook Pros introduced since 2015: Their keyboard is attached with SPI
instead of USB and the _CRS data which is necessary to initialize the
spi driver only contains valid information if OSPM responds "false" to
_OSI("Darwin"). If OSPM responds "true", _CRS is empty and the spi
driver fails to initialize. The rationale is very simple, Apple only
cares about macOS and Windows: On Windows, _CRS contains valid data,
whereas on macOS it is empty. Instead, macOS gleans the necessary data
from the _DSM properties.
Since Linux deliberately defaults to responding "true" to _OSI("Darwin"),
we need to emulate macOS' behaviour by initializing the spi driver with
data returned by the _DSM.
An out-of-tree driver for the SPI keyboard exists which currently binds
to the ACPI device, invokes the _DSM, parses the returned package and
instantiates an SPI device with the data gleaned from the _DSM:
https://github.com/cb22/macbook12-spi-driver/commit/9a416d699ef4
https://github.com/cb22/macbook12-spi-driver/commit/0c34936ed9a1
By adding support for Apple's _DSM properties in generic ACPI code, the
out-of-tree driver will be able to register as a regular SPI driver,
significantly reducing its amount of code and improving its chances to
be mainlined.
The SPI keyboard will not be the only user of this commit: E.g. on the
MacBook8,1, the UART-attached Bluetooth device likewise returns empty
_CRS data if OSPM returns "true" to _OSI("Darwin").
The _DSM returns a Package whose format unfortunately deviates slightly
from the _DSD spec: The properties are marshalled up in a single Package
as alternating key/value elements, unlike _DSD which stores them as a
Package of 2-element Packages. The present commit therefore converts
the Package to _DSD format and the ACPI core can then treat the data as
if Apple would follow the standard.
Well, except for one small annoyance: The properties returned by the
_DSM only ever have one of two types, Integer or Buffer. The former is
retrievable as usual with device_property_read_u64(), but the latter is
not part of the _DSD spec and it is not possible to retrieve Buffer
properties with the device_property_read_*() functions due to the type
checking performed in drivers/acpi/property.c. It is however possible
to retrieve them with acpi_dev_get_property(). Apple is using the
Buffer type somewhat sloppily to store null-terminated strings but also
integers. The real data type is not distinguishable by the ACPI core
and the onus is on the caller to use the contents of the Buffer in an
appropriate way.
In case Apple moves to _DSD in the future, this commit first checks for
_DSD and falls back to _DSM only if _DSD is not found.
Tested-by: Ronald Tschalär <ronald@innovation.ch>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-01 15:10:41 +03:00
|
|
|
|
|
|
|
if (!adev->data.pointer)
|
|
|
|
acpi_extract_apple_properties(adev);
|
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 15:33:55 +04:00
|
|
|
}
|
|
|
|
|
2015-08-27 05:36:14 +03:00
|
|
|
static void acpi_destroy_nondev_subnodes(struct list_head *list)
|
|
|
|
{
|
|
|
|
struct acpi_data_node *dn, *next;
|
|
|
|
|
|
|
|
if (list_empty(list))
|
|
|
|
return;
|
|
|
|
|
|
|
|
list_for_each_entry_safe_reverse(dn, next, list, sibling) {
|
|
|
|
acpi_destroy_nondev_subnodes(&dn->data.subnodes);
|
2015-08-27 05:37:19 +03:00
|
|
|
wait_for_completion(&dn->kobj_done);
|
2015-08-27 05:36:14 +03:00
|
|
|
list_del(&dn->sibling);
|
|
|
|
ACPI_FREE((void *)dn->data.pointer);
|
|
|
|
kfree(dn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 15:33:55 +04:00
|
|
|
void acpi_free_properties(struct acpi_device *adev)
|
|
|
|
{
|
2018-09-28 00:57:05 +03:00
|
|
|
struct acpi_device_properties *props, *tmp;
|
|
|
|
|
2015-08-27 05:36:14 +03:00
|
|
|
acpi_destroy_nondev_subnodes(&adev->data.subnodes);
|
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 15:33:55 +04:00
|
|
|
ACPI_FREE((void *)adev->data.pointer);
|
2014-10-21 15:33:56 +04:00
|
|
|
adev->data.of_compatible = NULL;
|
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 15:33:55 +04:00
|
|
|
adev->data.pointer = NULL;
|
2018-09-28 00:57:05 +03:00
|
|
|
list_for_each_entry_safe(props, tmp, &adev->data.properties, list) {
|
|
|
|
list_del(&props->list);
|
|
|
|
kfree(props);
|
|
|
|
}
|
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 15:33:55 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2015-08-27 05:40:05 +03:00
|
|
|
* acpi_data_get_property - return an ACPI property with given name
|
|
|
|
* @data: ACPI device deta object to get the property from
|
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 15:33:55 +04:00
|
|
|
* @name: Name of the property
|
|
|
|
* @type: Expected property type
|
|
|
|
* @obj: Location to store the property value (if not %NULL)
|
|
|
|
*
|
|
|
|
* Look up a property with @name and store a pointer to the resulting ACPI
|
|
|
|
* object at the location pointed to by @obj if found.
|
|
|
|
*
|
|
|
|
* Callers must not attempt to free the returned objects. These objects will be
|
2015-08-27 05:40:05 +03:00
|
|
|
* freed by the ACPI core automatically during the removal of @data.
|
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 15:33:55 +04:00
|
|
|
*
|
|
|
|
* Return: %0 if property with @name has been found (success),
|
|
|
|
* %-EINVAL if the arguments are invalid,
|
2015-11-30 18:11:35 +03:00
|
|
|
* %-EINVAL if the property doesn't exist,
|
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 15:33:55 +04:00
|
|
|
* %-EPROTO if the property value type doesn't match @type.
|
|
|
|
*/
|
2017-07-21 14:39:34 +03:00
|
|
|
static int acpi_data_get_property(const struct acpi_device_data *data,
|
2015-08-27 05:40:05 +03:00
|
|
|
const char *name, acpi_object_type type,
|
|
|
|
const union acpi_object **obj)
|
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 15:33:55 +04:00
|
|
|
{
|
2018-09-28 00:57:05 +03:00
|
|
|
const struct acpi_device_properties *props;
|
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 15:33:55 +04:00
|
|
|
|
2015-08-27 05:40:05 +03:00
|
|
|
if (!data || !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 15:33:55 +04:00
|
|
|
return -EINVAL;
|
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
if (!data->pointer || list_empty(&data->properties))
|
2015-11-30 18:11:35 +03:00
|
|
|
return -EINVAL;
|
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 15:33:55 +04:00
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
list_for_each_entry(props, &data->properties, list) {
|
|
|
|
const union acpi_object *properties;
|
|
|
|
unsigned int i;
|
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 15:33:55 +04:00
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
properties = props->properties;
|
|
|
|
for (i = 0; i < properties->package.count; i++) {
|
|
|
|
const union acpi_object *propname, *propvalue;
|
|
|
|
const union acpi_object *property;
|
|
|
|
|
|
|
|
property = &properties->package.elements[i];
|
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 15:33:55 +04:00
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
propname = &property->package.elements[0];
|
|
|
|
propvalue = &property->package.elements[1];
|
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 15:33:55 +04:00
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
if (!strcmp(name, propname->string.pointer)) {
|
|
|
|
if (type != ACPI_TYPE_ANY &&
|
|
|
|
propvalue->type != type)
|
|
|
|
return -EPROTO;
|
|
|
|
if (obj)
|
|
|
|
*obj = propvalue;
|
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 15:33:55 +04:00
|
|
|
|
2018-09-28 00:57:05 +03:00
|
|
|
return 0;
|
|
|
|
}
|
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 15:33:55 +04:00
|
|
|
}
|
|
|
|
}
|
2015-11-30 18:11:35 +03:00
|
|
|
return -EINVAL;
|
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 15:33:55 +04:00
|
|
|
}
|
2015-08-27 05:40:05 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_get_property - return an ACPI property with given name.
|
|
|
|
* @adev: ACPI device to get the property from.
|
|
|
|
* @name: Name of the property.
|
|
|
|
* @type: Expected property type.
|
|
|
|
* @obj: Location to store the property value (if not %NULL).
|
|
|
|
*/
|
2017-07-21 14:39:34 +03:00
|
|
|
int acpi_dev_get_property(const struct acpi_device *adev, const char *name,
|
2015-08-27 05:40:05 +03:00
|
|
|
acpi_object_type type, const union acpi_object **obj)
|
|
|
|
{
|
|
|
|
return adev ? acpi_data_get_property(&adev->data, name, type, obj) : -EINVAL;
|
|
|
|
}
|
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 15:33:55 +04:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_get_property);
|
|
|
|
|
2017-07-21 14:39:34 +03:00
|
|
|
static const struct acpi_device_data *
|
|
|
|
acpi_device_data_of_node(const struct fwnode_handle *fwnode)
|
2015-08-27 05:40:05 +03:00
|
|
|
{
|
2017-07-21 14:39:31 +03:00
|
|
|
if (is_acpi_device_node(fwnode)) {
|
2017-07-21 14:39:34 +03:00
|
|
|
const struct acpi_device *adev = to_acpi_device_node(fwnode);
|
2015-08-27 05:40:05 +03:00
|
|
|
return &adev->data;
|
2017-07-21 14:39:31 +03:00
|
|
|
} else if (is_acpi_data_node(fwnode)) {
|
2017-07-21 14:39:34 +03:00
|
|
|
const struct acpi_data_node *dn = to_acpi_data_node(fwnode);
|
2015-08-27 05:40:05 +03:00
|
|
|
return &dn->data;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
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 15:33:55 +04:00
|
|
|
/**
|
2015-08-27 05:40:05 +03:00
|
|
|
* acpi_node_prop_get - return an ACPI property with given name.
|
|
|
|
* @fwnode: Firmware node to get the property from.
|
|
|
|
* @propname: Name of the property.
|
|
|
|
* @valptr: Location to store a pointer to the property value (if not %NULL).
|
|
|
|
*/
|
2017-07-21 14:39:34 +03:00
|
|
|
int acpi_node_prop_get(const struct fwnode_handle *fwnode,
|
|
|
|
const char *propname, void **valptr)
|
2015-08-27 05:40:05 +03:00
|
|
|
{
|
|
|
|
return acpi_data_get_property(acpi_device_data_of_node(fwnode),
|
|
|
|
propname, ACPI_TYPE_ANY,
|
|
|
|
(const union acpi_object **)valptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_data_get_property_array - return an ACPI array property with given name
|
2021-02-12 17:11:19 +03:00
|
|
|
* @data: ACPI data object to get the property from
|
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 15:33:55 +04:00
|
|
|
* @name: Name of the property
|
|
|
|
* @type: Expected type of array elements
|
|
|
|
* @obj: Location to store a pointer to the property value (if not NULL)
|
|
|
|
*
|
|
|
|
* Look up an array property with @name and store a pointer to the resulting
|
|
|
|
* ACPI object at the location pointed to by @obj if found.
|
|
|
|
*
|
|
|
|
* Callers must not attempt to free the returned objects. Those objects will be
|
2015-08-27 05:40:05 +03:00
|
|
|
* freed by the ACPI core automatically during the removal of @data.
|
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 15:33:55 +04:00
|
|
|
*
|
|
|
|
* Return: %0 if array property (package) with @name has been found (success),
|
|
|
|
* %-EINVAL if the arguments are invalid,
|
2015-11-30 18:11:35 +03:00
|
|
|
* %-EINVAL if the property doesn't exist,
|
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 15:33:55 +04:00
|
|
|
* %-EPROTO if the property is not a package or the type of its elements
|
|
|
|
* doesn't match @type.
|
|
|
|
*/
|
2017-07-21 14:39:34 +03:00
|
|
|
static int acpi_data_get_property_array(const struct acpi_device_data *data,
|
2015-08-27 05:40:05 +03:00
|
|
|
const char *name,
|
|
|
|
acpi_object_type type,
|
|
|
|
const union acpi_object **obj)
|
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 15:33:55 +04:00
|
|
|
{
|
|
|
|
const union acpi_object *prop;
|
|
|
|
int ret, i;
|
|
|
|
|
2015-08-27 05:40:05 +03:00
|
|
|
ret = acpi_data_get_property(data, name, ACPI_TYPE_PACKAGE, &prop);
|
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 15:33:55 +04:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (type != ACPI_TYPE_ANY) {
|
|
|
|
/* Check that all elements are of correct type. */
|
|
|
|
for (i = 0; i < prop->package.count; i++)
|
|
|
|
if (prop->package.elements[i].type != type)
|
|
|
|
return -EPROTO;
|
|
|
|
}
|
|
|
|
if (obj)
|
|
|
|
*obj = prop;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-17 17:19:12 +03:00
|
|
|
static struct fwnode_handle *
|
|
|
|
acpi_fwnode_get_named_child_node(const struct fwnode_handle *fwnode,
|
|
|
|
const char *childname)
|
|
|
|
{
|
|
|
|
struct fwnode_handle *child;
|
2019-05-31 17:15:38 +03:00
|
|
|
|
|
|
|
fwnode_for_each_child_node(fwnode, child) {
|
|
|
|
if (is_acpi_data_node(child)) {
|
|
|
|
if (acpi_data_node_match(child, childname))
|
|
|
|
return child;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2020-06-09 16:22:39 +03:00
|
|
|
if (!strncmp(acpi_device_bid(to_acpi_device_node(child)),
|
|
|
|
childname, ACPI_NAMESEG_SIZE))
|
2018-07-17 17:19:12 +03:00
|
|
|
return child;
|
2019-05-31 17:15:38 +03:00
|
|
|
}
|
2018-07-17 17:19:12 +03:00
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
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 15:33:55 +04: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 16:39:41 +03:00
|
|
|
* __acpi_node_get_property_reference - returns handle to the referenced object
|
|
|
|
* @fwnode: Firmware node to get the property from
|
2015-08-27 05:42:33 +03:00
|
|
|
* @propname: Name of the property
|
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 15:33:55 +04:00
|
|
|
* @index: Index of the reference to return
|
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 16:39:41 +03:00
|
|
|
* @num_args: Maximum number of arguments after each reference
|
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 15:33:55 +04:00
|
|
|
* @args: Location to store the returned reference with optional arguments
|
|
|
|
*
|
|
|
|
* Find property with @name, verifify that it is a package containing at least
|
|
|
|
* one object reference and if so, store the ACPI device object pointer to the
|
2014-11-05 02:29:07 +03:00
|
|
|
* target object in @args->adev. If the reference includes arguments, store
|
|
|
|
* them in the @args->args[] array.
|
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 15:33:55 +04:00
|
|
|
*
|
2014-11-05 02:29:07 +03:00
|
|
|
* If there's more than one reference in the property value package, @index is
|
|
|
|
* used to select the one to return.
|
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 15:33:55 +04: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 16:39:41 +03:00
|
|
|
* It is possible to leave holes in the property value set like in the
|
|
|
|
* example below:
|
|
|
|
*
|
|
|
|
* Package () {
|
|
|
|
* "cs-gpios",
|
|
|
|
* Package () {
|
|
|
|
* ^GPIO, 19, 0, 0,
|
|
|
|
* ^GPIO, 20, 0, 0,
|
|
|
|
* 0,
|
|
|
|
* ^GPIO, 21, 0, 0,
|
|
|
|
* }
|
|
|
|
* }
|
|
|
|
*
|
2017-09-26 12:08:27 +03:00
|
|
|
* Calling this function with index %2 or index %3 return %-ENOENT. If the
|
|
|
|
* property does not contain any more values %-ENOENT is returned. The NULL
|
|
|
|
* entry must be single integer and preferably contain value %0.
|
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 16:39:41 +03:00
|
|
|
*
|
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 15:33:55 +04:00
|
|
|
* Return: %0 on success, negative error code on failure.
|
|
|
|
*/
|
2017-07-21 14:39:34 +03: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 16:39:41 +03:00
|
|
|
const char *propname, size_t index, size_t num_args,
|
2018-07-17 17:19:11 +03: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 15:33:55 +04:00
|
|
|
{
|
|
|
|
const union acpi_object *element, *end;
|
|
|
|
const union acpi_object *obj;
|
2017-07-21 14:39:34 +03:00
|
|
|
const struct acpi_device_data *data;
|
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 15:33:55 +04:00
|
|
|
struct acpi_device *device;
|
|
|
|
int ret, idx = 0;
|
|
|
|
|
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 16:39:41 +03:00
|
|
|
data = acpi_device_data_of_node(fwnode);
|
|
|
|
if (!data)
|
2017-09-26 12:08:27 +03:00
|
|
|
return -ENOENT;
|
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 16:39:41 +03:00
|
|
|
|
2015-08-27 05:42:33 +03:00
|
|
|
ret = acpi_data_get_property(data, propname, ACPI_TYPE_ANY, &obj);
|
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 15:33:55 +04:00
|
|
|
if (ret)
|
2017-10-11 11:06:13 +03:00
|
|
|
return ret == -EINVAL ? -ENOENT : -EINVAL;
|
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 15:33:55 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The simplest case is when the value is a single reference. Just
|
|
|
|
* return that reference then.
|
|
|
|
*/
|
|
|
|
if (obj->type == ACPI_TYPE_LOCAL_REFERENCE) {
|
2014-11-05 02:29:07 +03:00
|
|
|
if (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 15:33:55 +04:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ret = acpi_bus_get_device(obj->reference.handle, &device);
|
|
|
|
if (ret)
|
2017-10-11 11:06:13 +03:00
|
|
|
return ret == -ENODEV ? -EINVAL : ret;
|
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 15:33:55 +04:00
|
|
|
|
2018-07-17 17:19:11 +03:00
|
|
|
args->fwnode = acpi_fwnode_handle(device);
|
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 15:33:55 +04:00
|
|
|
args->nargs = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If it is not a single reference, then it is a package of
|
|
|
|
* references followed by number of ints as follows:
|
|
|
|
*
|
|
|
|
* Package () { REF, INT, REF, INT, INT }
|
|
|
|
*
|
|
|
|
* The index argument is then used to determine which reference
|
|
|
|
* the caller wants (along with the arguments).
|
|
|
|
*/
|
2017-10-11 11:06:13 +03:00
|
|
|
if (obj->type != ACPI_TYPE_PACKAGE)
|
|
|
|
return -EINVAL;
|
|
|
|
if (index >= obj->package.count)
|
|
|
|
return -ENOENT;
|
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 15:33:55 +04:00
|
|
|
|
|
|
|
element = obj->package.elements;
|
|
|
|
end = element + obj->package.count;
|
|
|
|
|
|
|
|
while (element < end) {
|
|
|
|
u32 nargs, i;
|
|
|
|
|
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 16:39:41 +03:00
|
|
|
if (element->type == ACPI_TYPE_LOCAL_REFERENCE) {
|
2018-07-17 17:19:12 +03:00
|
|
|
struct fwnode_handle *ref_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 16:39:41 +03:00
|
|
|
ret = acpi_bus_get_device(element->reference.handle,
|
|
|
|
&device);
|
|
|
|
if (ret)
|
2017-09-26 12:08:27 +03:00
|
|
|
return -EINVAL;
|
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 16:39:41 +03:00
|
|
|
|
|
|
|
nargs = 0;
|
|
|
|
element++;
|
|
|
|
|
2018-07-17 17:19:12 +03:00
|
|
|
/*
|
|
|
|
* Find the referred data extension node under the
|
|
|
|
* referred device node.
|
|
|
|
*/
|
|
|
|
for (ref_fwnode = acpi_fwnode_handle(device);
|
|
|
|
element < end && element->type == ACPI_TYPE_STRING;
|
|
|
|
element++) {
|
|
|
|
ref_fwnode = acpi_fwnode_get_named_child_node(
|
|
|
|
ref_fwnode, element->string.pointer);
|
|
|
|
if (!ref_fwnode)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
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 16:39:41 +03:00
|
|
|
/* assume following integer elements are all args */
|
|
|
|
for (i = 0; element + i < end && i < num_args; i++) {
|
|
|
|
int type = element[i].type;
|
|
|
|
|
|
|
|
if (type == ACPI_TYPE_INTEGER)
|
|
|
|
nargs++;
|
|
|
|
else if (type == ACPI_TYPE_LOCAL_REFERENCE)
|
|
|
|
break;
|
|
|
|
else
|
2017-09-26 12:08:27 +03:00
|
|
|
return -EINVAL;
|
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 16:39:41 +03:00
|
|
|
}
|
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 15:33:55 +04:00
|
|
|
|
2018-07-17 17:19:11 +03:00
|
|
|
if (nargs > NR_FWNODE_REFERENCE_ARGS)
|
2017-09-26 12:08:27 +03:00
|
|
|
return -EINVAL;
|
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 15:33:55 +04: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 16:39:41 +03:00
|
|
|
if (idx == index) {
|
2018-07-17 17:19:12 +03:00
|
|
|
args->fwnode = ref_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 16:39:41 +03:00
|
|
|
args->nargs = nargs;
|
|
|
|
for (i = 0; i < nargs; i++)
|
|
|
|
args->args[i] = element[i].integer.value;
|
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 15:33:55 +04: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 16:39:41 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
element += nargs;
|
|
|
|
} else if (element->type == ACPI_TYPE_INTEGER) {
|
|
|
|
if (idx == index)
|
|
|
|
return -ENOENT;
|
|
|
|
element++;
|
|
|
|
} else {
|
2017-09-26 12:08:27 +03:00
|
|
|
return -EINVAL;
|
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 15:33:55 +04: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 16:39:41 +03:00
|
|
|
idx++;
|
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 15:33:55 +04:00
|
|
|
}
|
|
|
|
|
2017-09-26 12:08:27 +03:00
|
|
|
return -ENOENT;
|
2015-08-27 05:42:33 +03: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 16:39:41 +03:00
|
|
|
EXPORT_SYMBOL_GPL(__acpi_node_get_property_reference);
|
2014-11-04 03:28:56 +03:00
|
|
|
|
2017-07-21 14:39:34 +03:00
|
|
|
static int acpi_data_prop_read_single(const struct acpi_device_data *data,
|
2015-08-27 05:40:05 +03:00
|
|
|
const char *propname,
|
|
|
|
enum dev_prop_type proptype, void *val)
|
2014-11-04 03:28:56 +03:00
|
|
|
{
|
|
|
|
const union acpi_object *obj;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (proptype >= DEV_PROP_U8 && proptype <= DEV_PROP_U64) {
|
2015-08-27 05:40:05 +03:00
|
|
|
ret = acpi_data_get_property(data, propname, ACPI_TYPE_INTEGER, &obj);
|
2014-11-04 03:28:56 +03:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
switch (proptype) {
|
|
|
|
case DEV_PROP_U8:
|
|
|
|
if (obj->integer.value > U8_MAX)
|
|
|
|
return -EOVERFLOW;
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
|
|
|
|
if (val)
|
|
|
|
*(u8 *)val = obj->integer.value;
|
|
|
|
|
2014-11-04 03:28:56 +03:00
|
|
|
break;
|
|
|
|
case DEV_PROP_U16:
|
|
|
|
if (obj->integer.value > U16_MAX)
|
|
|
|
return -EOVERFLOW;
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
|
|
|
|
if (val)
|
|
|
|
*(u16 *)val = obj->integer.value;
|
|
|
|
|
2014-11-04 03:28:56 +03:00
|
|
|
break;
|
|
|
|
case DEV_PROP_U32:
|
|
|
|
if (obj->integer.value > U32_MAX)
|
|
|
|
return -EOVERFLOW;
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
|
|
|
|
if (val)
|
|
|
|
*(u32 *)val = obj->integer.value;
|
|
|
|
|
2014-11-04 03:28:56 +03:00
|
|
|
break;
|
|
|
|
default:
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
if (val)
|
|
|
|
*(u64 *)val = obj->integer.value;
|
|
|
|
|
2014-11-04 03:28:56 +03:00
|
|
|
break;
|
|
|
|
}
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
|
|
|
|
if (!val)
|
|
|
|
return 1;
|
2014-11-04 03:28:56 +03:00
|
|
|
} else if (proptype == DEV_PROP_STRING) {
|
2015-08-27 05:40:05 +03:00
|
|
|
ret = acpi_data_get_property(data, propname, ACPI_TYPE_STRING, &obj);
|
2014-11-04 03:28:56 +03:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
if (val)
|
|
|
|
*(char **)val = obj->string.pointer;
|
2017-03-28 15:22:19 +03:00
|
|
|
|
|
|
|
return 1;
|
2014-11-04 03:28:56 +03:00
|
|
|
} else {
|
|
|
|
ret = -EINVAL;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_copy_property_array_u8(const union acpi_object *items, u8 *val,
|
|
|
|
size_t nval)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < nval; i++) {
|
|
|
|
if (items[i].type != ACPI_TYPE_INTEGER)
|
|
|
|
return -EPROTO;
|
|
|
|
if (items[i].integer.value > U8_MAX)
|
|
|
|
return -EOVERFLOW;
|
|
|
|
|
|
|
|
val[i] = items[i].integer.value;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_copy_property_array_u16(const union acpi_object *items,
|
|
|
|
u16 *val, size_t nval)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < nval; i++) {
|
|
|
|
if (items[i].type != ACPI_TYPE_INTEGER)
|
|
|
|
return -EPROTO;
|
|
|
|
if (items[i].integer.value > U16_MAX)
|
|
|
|
return -EOVERFLOW;
|
|
|
|
|
|
|
|
val[i] = items[i].integer.value;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_copy_property_array_u32(const union acpi_object *items,
|
|
|
|
u32 *val, size_t nval)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < nval; i++) {
|
|
|
|
if (items[i].type != ACPI_TYPE_INTEGER)
|
|
|
|
return -EPROTO;
|
|
|
|
if (items[i].integer.value > U32_MAX)
|
|
|
|
return -EOVERFLOW;
|
|
|
|
|
|
|
|
val[i] = items[i].integer.value;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_copy_property_array_u64(const union acpi_object *items,
|
|
|
|
u64 *val, size_t nval)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < nval; i++) {
|
|
|
|
if (items[i].type != ACPI_TYPE_INTEGER)
|
|
|
|
return -EPROTO;
|
|
|
|
|
|
|
|
val[i] = items[i].integer.value;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_copy_property_array_string(const union acpi_object *items,
|
|
|
|
char **val, size_t nval)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < nval; i++) {
|
|
|
|
if (items[i].type != ACPI_TYPE_STRING)
|
|
|
|
return -EPROTO;
|
|
|
|
|
|
|
|
val[i] = items[i].string.pointer;
|
|
|
|
}
|
2017-03-28 15:22:19 +03:00
|
|
|
return nval;
|
2014-11-04 03:28:56 +03:00
|
|
|
}
|
|
|
|
|
2017-07-21 14:39:34 +03:00
|
|
|
static int acpi_data_prop_read(const struct acpi_device_data *data,
|
2015-08-27 05:40:05 +03:00
|
|
|
const char *propname,
|
|
|
|
enum dev_prop_type proptype,
|
|
|
|
void *val, size_t nval)
|
2014-11-04 03:28:56 +03:00
|
|
|
{
|
|
|
|
const union acpi_object *obj;
|
|
|
|
const union acpi_object *items;
|
|
|
|
int ret;
|
|
|
|
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
if (nval == 1 || !val) {
|
2015-08-27 05:40:05 +03:00
|
|
|
ret = acpi_data_prop_read_single(data, propname, proptype, val);
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
/*
|
|
|
|
* The overflow error means that the property is there and it is
|
|
|
|
* single-value, but its type does not match, so return.
|
|
|
|
*/
|
|
|
|
if (ret >= 0 || ret == -EOVERFLOW)
|
2014-11-04 03:28:56 +03:00
|
|
|
return ret;
|
ACPI: property: Fix fwnode string properties matching
Property matching does not work for ACPI fwnodes if the value of the
given property is not represented as a package in the _DSD package
containing it. For example, the "compatible" property in the _DSD
below
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
will not be found by fwnode_property_match_string(), because the ACPI
code handling device properties does not regard the single value as a
"list" in that case.
Namely, fwnode_property_match_string() invoked to match a given
string property value first calls fwnode_property_read_string_array()
with the last two arguments equal to NULL and 0, respectively, in
order to count the items in the value of the given property, with the
assumption that this value may be an array. For ACPI fwnodes, that
operation is carried out by acpi_node_prop_read() which calls
acpi_data_prop_read() for this purpose. However, when the return
(val) pointer is NULL, that function only looks for a property whose
value is a package without checking the single-value case at all.
To fix that, make acpi_data_prop_read() check the single-value
case if its return pointer argument is NULL and modify
acpi_data_prop_read_single() handling that case to attempt to
read the value of the property if the return pointer is NULL
and return 1 if that succeeds.
Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files")
Reported-by: Calvin Johnson <calvin.johnson@oss.nxp.com>
Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-02-11 21:30:01 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Reading this property as a single-value one failed, but its
|
|
|
|
* value may still be represented as one-element array, so
|
|
|
|
* continue.
|
|
|
|
*/
|
2014-11-04 03:28:56 +03:00
|
|
|
}
|
|
|
|
|
2015-08-27 05:40:05 +03:00
|
|
|
ret = acpi_data_get_property_array(data, propname, ACPI_TYPE_ANY, &obj);
|
2014-11-04 03:28:56 +03:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (!val)
|
|
|
|
return obj->package.count;
|
|
|
|
|
2017-03-28 15:22:19 +03:00
|
|
|
if (proptype != DEV_PROP_STRING && nval > obj->package.count)
|
2014-11-04 03:28:56 +03:00
|
|
|
return -EOVERFLOW;
|
2015-08-10 19:56:48 +03:00
|
|
|
else if (nval <= 0)
|
|
|
|
return -EINVAL;
|
2014-11-04 03:28:56 +03:00
|
|
|
|
|
|
|
items = obj->package.elements;
|
2015-08-10 19:56:48 +03:00
|
|
|
|
2014-11-04 03:28:56 +03:00
|
|
|
switch (proptype) {
|
|
|
|
case DEV_PROP_U8:
|
|
|
|
ret = acpi_copy_property_array_u8(items, (u8 *)val, nval);
|
|
|
|
break;
|
|
|
|
case DEV_PROP_U16:
|
|
|
|
ret = acpi_copy_property_array_u16(items, (u16 *)val, nval);
|
|
|
|
break;
|
|
|
|
case DEV_PROP_U32:
|
|
|
|
ret = acpi_copy_property_array_u32(items, (u32 *)val, nval);
|
|
|
|
break;
|
|
|
|
case DEV_PROP_U64:
|
|
|
|
ret = acpi_copy_property_array_u64(items, (u64 *)val, nval);
|
|
|
|
break;
|
|
|
|
case DEV_PROP_STRING:
|
2017-03-28 15:22:19 +03:00
|
|
|
ret = acpi_copy_property_array_string(
|
|
|
|
items, (char **)val,
|
|
|
|
min_t(u32, nval, obj->package.count));
|
2014-11-04 03:28:56 +03:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
2015-08-27 05:40:05 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_node_prop_read - retrieve the value of an ACPI property with given name.
|
|
|
|
* @fwnode: Firmware node to get the property from.
|
|
|
|
* @propname: Name of the property.
|
|
|
|
* @proptype: Expected property type.
|
|
|
|
* @val: Location to store the property value (if not %NULL).
|
|
|
|
* @nval: Size of the array pointed to by @val.
|
|
|
|
*
|
|
|
|
* If @val is %NULL, return the number of array elements comprising the value
|
|
|
|
* of the property. Otherwise, read at most @nval values to the array at the
|
|
|
|
* location pointed to by @val.
|
|
|
|
*/
|
2021-02-12 17:11:18 +03:00
|
|
|
static int acpi_node_prop_read(const struct fwnode_handle *fwnode,
|
|
|
|
const char *propname, enum dev_prop_type proptype,
|
|
|
|
void *val, size_t nval)
|
2015-08-27 05:40:05 +03:00
|
|
|
{
|
|
|
|
return acpi_data_prop_read(acpi_device_data_of_node(fwnode),
|
|
|
|
propname, proptype, val, nval);
|
|
|
|
}
|
2015-08-27 05:42:33 +03:00
|
|
|
|
|
|
|
/**
|
2017-03-28 10:52:18 +03:00
|
|
|
* acpi_get_next_subnode - Return the next child node handle for a fwnode
|
|
|
|
* @fwnode: Firmware node to find the next child node for.
|
2015-08-27 05:42:33 +03:00
|
|
|
* @child: Handle to one of the device's child nodes or a null handle.
|
|
|
|
*/
|
2017-07-21 14:39:36 +03:00
|
|
|
struct fwnode_handle *acpi_get_next_subnode(const struct fwnode_handle *fwnode,
|
2015-08-27 05:42:33 +03:00
|
|
|
struct fwnode_handle *child)
|
|
|
|
{
|
2017-07-21 14:39:32 +03:00
|
|
|
const struct acpi_device *adev = to_acpi_device_node(fwnode);
|
|
|
|
const struct list_head *head;
|
|
|
|
struct list_head *next;
|
2015-08-27 05:42:33 +03:00
|
|
|
|
2017-07-21 14:39:31 +03:00
|
|
|
if (!child || is_acpi_device_node(child)) {
|
2017-09-08 12:24:41 +03:00
|
|
|
struct acpi_device *child_adev;
|
|
|
|
|
2017-03-28 10:52:18 +03:00
|
|
|
if (adev)
|
|
|
|
head = &adev->children;
|
|
|
|
else
|
|
|
|
goto nondev;
|
|
|
|
|
2015-08-27 05:42:33 +03:00
|
|
|
if (list_empty(head))
|
|
|
|
goto nondev;
|
|
|
|
|
|
|
|
if (child) {
|
2017-09-08 12:24:41 +03:00
|
|
|
adev = to_acpi_device_node(child);
|
|
|
|
next = adev->node.next;
|
2015-08-27 05:42:33 +03:00
|
|
|
if (next == head) {
|
|
|
|
child = NULL;
|
|
|
|
goto nondev;
|
|
|
|
}
|
2017-07-21 14:39:32 +03:00
|
|
|
child_adev = list_entry(next, struct acpi_device, node);
|
2015-08-27 05:42:33 +03:00
|
|
|
} else {
|
2017-07-21 14:39:32 +03:00
|
|
|
child_adev = list_first_entry(head, struct acpi_device,
|
|
|
|
node);
|
2015-08-27 05:42:33 +03:00
|
|
|
}
|
2017-07-21 14:39:32 +03:00
|
|
|
return acpi_fwnode_handle(child_adev);
|
2015-08-27 05:42:33 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
nondev:
|
2017-07-21 14:39:31 +03:00
|
|
|
if (!child || is_acpi_data_node(child)) {
|
2017-07-21 14:39:32 +03:00
|
|
|
const struct acpi_data_node *data = to_acpi_data_node(fwnode);
|
2015-08-27 05:42:33 +03:00
|
|
|
struct acpi_data_node *dn;
|
|
|
|
|
2019-04-30 18:52:29 +03:00
|
|
|
/*
|
|
|
|
* We can have a combination of device and data nodes, e.g. with
|
|
|
|
* hierarchical _DSD properties. Make sure the adev pointer is
|
|
|
|
* restored before going through data nodes, otherwise we will
|
|
|
|
* be looking for data_nodes below the last device found instead
|
|
|
|
* of the common fwnode shared by device_nodes and data_nodes.
|
|
|
|
*/
|
|
|
|
adev = to_acpi_device_node(fwnode);
|
2017-09-08 12:24:41 +03:00
|
|
|
if (adev)
|
|
|
|
head = &adev->data.subnodes;
|
2017-03-28 10:52:18 +03:00
|
|
|
else if (data)
|
|
|
|
head = &data->data.subnodes;
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
|
2015-08-27 05:42:33 +03:00
|
|
|
if (list_empty(head))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (child) {
|
|
|
|
dn = to_acpi_data_node(child);
|
|
|
|
next = dn->sibling.next;
|
|
|
|
if (next == head)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
dn = list_entry(next, struct acpi_data_node, sibling);
|
|
|
|
} else {
|
|
|
|
dn = list_first_entry(head, struct acpi_data_node, sibling);
|
|
|
|
}
|
|
|
|
return &dn->fwnode;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
2017-03-28 10:52:16 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_node_get_parent - Return parent fwnode of this fwnode
|
|
|
|
* @fwnode: Firmware node whose parent to get
|
|
|
|
*
|
|
|
|
* Returns parent node of an ACPI device or data firmware node or %NULL if
|
|
|
|
* not available.
|
|
|
|
*/
|
2017-07-21 14:39:36 +03:00
|
|
|
struct fwnode_handle *acpi_node_get_parent(const struct fwnode_handle *fwnode)
|
2017-03-28 10:52:16 +03:00
|
|
|
{
|
|
|
|
if (is_acpi_data_node(fwnode)) {
|
|
|
|
/* All data nodes have parent pointer so just return that */
|
|
|
|
return to_acpi_data_node(fwnode)->parent;
|
|
|
|
} else if (is_acpi_device_node(fwnode)) {
|
|
|
|
acpi_handle handle, parent_handle;
|
|
|
|
|
|
|
|
handle = to_acpi_device_node(fwnode)->handle;
|
|
|
|
if (ACPI_SUCCESS(acpi_get_parent(handle, &parent_handle))) {
|
|
|
|
struct acpi_device *adev;
|
|
|
|
|
|
|
|
if (!acpi_bus_get_device(parent_handle, &adev))
|
|
|
|
return acpi_fwnode_handle(adev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
2017-03-28 10:52:20 +03:00
|
|
|
|
2018-07-17 17:19:16 +03:00
|
|
|
/*
|
|
|
|
* Return true if the node is an ACPI graph node. Called on either ports
|
|
|
|
* or endpoints.
|
|
|
|
*/
|
|
|
|
static bool is_acpi_graph_node(struct fwnode_handle *fwnode,
|
|
|
|
const char *str)
|
|
|
|
{
|
|
|
|
unsigned int len = strlen(str);
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
if (!len || !is_acpi_data_node(fwnode))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
name = to_acpi_data_node(fwnode)->name;
|
|
|
|
|
|
|
|
return (fwnode_property_present(fwnode, "reg") &&
|
|
|
|
!strncmp(name, str, len) && name[len] == '@') ||
|
|
|
|
fwnode_property_present(fwnode, str);
|
|
|
|
}
|
|
|
|
|
2017-03-28 10:52:20 +03:00
|
|
|
/**
|
|
|
|
* acpi_graph_get_next_endpoint - Get next endpoint ACPI firmware node
|
|
|
|
* @fwnode: Pointer to the parent firmware node
|
|
|
|
* @prev: Previous endpoint node or %NULL to get the first
|
|
|
|
*
|
|
|
|
* Looks up next endpoint ACPI firmware node below a given @fwnode. Returns
|
2018-07-17 17:19:14 +03:00
|
|
|
* %NULL if there is no next endpoint or in case of error. In case of success
|
|
|
|
* the next endpoint is returned.
|
2017-03-28 10:52:20 +03:00
|
|
|
*/
|
2018-07-17 17:19:14 +03:00
|
|
|
static struct fwnode_handle *acpi_graph_get_next_endpoint(
|
2017-07-21 14:39:36 +03:00
|
|
|
const struct fwnode_handle *fwnode, struct fwnode_handle *prev)
|
2017-03-28 10:52:20 +03:00
|
|
|
{
|
|
|
|
struct fwnode_handle *port = NULL;
|
|
|
|
struct fwnode_handle *endpoint;
|
|
|
|
|
|
|
|
if (!prev) {
|
|
|
|
do {
|
|
|
|
port = fwnode_get_next_child_node(fwnode, port);
|
2018-07-17 17:19:16 +03:00
|
|
|
/*
|
|
|
|
* The names of the port nodes begin with "port@"
|
|
|
|
* followed by the number of the port node and they also
|
|
|
|
* have a "reg" property that also has the number of the
|
|
|
|
* port node. For compatibility reasons a node is also
|
|
|
|
* recognised as a port node from the "port" property.
|
|
|
|
*/
|
|
|
|
if (is_acpi_graph_node(port, "port"))
|
2017-03-28 10:52:20 +03:00
|
|
|
break;
|
|
|
|
} while (port);
|
|
|
|
} else {
|
|
|
|
port = fwnode_get_parent(prev);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!port)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
endpoint = fwnode_get_next_child_node(port, prev);
|
|
|
|
while (!endpoint) {
|
|
|
|
port = fwnode_get_next_child_node(fwnode, port);
|
|
|
|
if (!port)
|
|
|
|
break;
|
2018-07-17 17:19:16 +03:00
|
|
|
if (is_acpi_graph_node(port, "port"))
|
2017-03-28 10:52:20 +03:00
|
|
|
endpoint = fwnode_get_next_child_node(port, NULL);
|
|
|
|
}
|
|
|
|
|
2018-07-17 17:19:16 +03:00
|
|
|
/*
|
|
|
|
* The names of the endpoint nodes begin with "endpoint@" followed by
|
|
|
|
* the number of the endpoint node and they also have a "reg" property
|
|
|
|
* that also has the number of the endpoint node. For compatibility
|
|
|
|
* reasons a node is also recognised as an endpoint node from the
|
|
|
|
* "endpoint" property.
|
|
|
|
*/
|
|
|
|
if (!is_acpi_graph_node(endpoint, "endpoint"))
|
2018-07-17 17:19:14 +03:00
|
|
|
return NULL;
|
2017-03-28 10:52:20 +03:00
|
|
|
|
|
|
|
return endpoint;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_graph_get_child_prop_value - Return a child with a given property value
|
|
|
|
* @fwnode: device fwnode
|
|
|
|
* @prop_name: The name of the property to look for
|
|
|
|
* @val: the desired property value
|
|
|
|
*
|
|
|
|
* Return the port node corresponding to a given port number. Returns
|
|
|
|
* the child node on success, NULL otherwise.
|
|
|
|
*/
|
|
|
|
static struct fwnode_handle *acpi_graph_get_child_prop_value(
|
2017-07-21 14:39:36 +03:00
|
|
|
const struct fwnode_handle *fwnode, const char *prop_name,
|
|
|
|
unsigned int val)
|
2017-03-28 10:52:20 +03:00
|
|
|
{
|
|
|
|
struct fwnode_handle *child;
|
|
|
|
|
|
|
|
fwnode_for_each_child_node(fwnode, child) {
|
|
|
|
u32 nr;
|
|
|
|
|
2017-08-22 23:39:58 +03:00
|
|
|
if (fwnode_property_read_u32(child, prop_name, &nr))
|
2017-03-28 10:52:20 +03:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (val == nr)
|
|
|
|
return child;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
2019-08-30 18:09:23 +03:00
|
|
|
* acpi_graph_get_remote_endpoint - Parses and returns remote end of an endpoint
|
2021-02-12 17:11:20 +03:00
|
|
|
* @__fwnode: Endpoint firmware node pointing to a remote device
|
2017-03-28 10:52:20 +03:00
|
|
|
*
|
2018-07-17 17:19:14 +03:00
|
|
|
* Returns the remote endpoint corresponding to @__fwnode. NULL on error.
|
2017-03-28 10:52:20 +03:00
|
|
|
*/
|
2018-07-17 17:19:14 +03:00
|
|
|
static struct fwnode_handle *
|
|
|
|
acpi_graph_get_remote_endpoint(const struct fwnode_handle *__fwnode)
|
2017-03-28 10:52:20 +03:00
|
|
|
{
|
2017-07-21 14:39:36 +03:00
|
|
|
struct fwnode_handle *fwnode;
|
2017-03-28 10:52:20 +03:00
|
|
|
unsigned int port_nr, endpoint_nr;
|
2018-07-17 17:19:11 +03:00
|
|
|
struct fwnode_reference_args args;
|
2017-03-28 10:52:20 +03:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
memset(&args, 0, sizeof(args));
|
2017-07-21 14:39:36 +03:00
|
|
|
ret = acpi_node_get_property_reference(__fwnode, "remote-endpoint", 0,
|
2017-03-28 10:52:20 +03:00
|
|
|
&args);
|
|
|
|
if (ret)
|
2018-07-17 17:19:14 +03:00
|
|
|
return NULL;
|
2017-03-28 10:52:20 +03:00
|
|
|
|
2018-07-17 17:19:15 +03:00
|
|
|
/* Direct endpoint reference? */
|
2018-07-17 17:19:11 +03:00
|
|
|
if (!is_acpi_device_node(args.fwnode))
|
2018-07-17 17:19:15 +03:00
|
|
|
return args.nargs ? NULL : args.fwnode;
|
2018-07-17 17:19:11 +03:00
|
|
|
|
2017-03-28 10:52:20 +03:00
|
|
|
/*
|
|
|
|
* Always require two arguments with the reference: port and
|
|
|
|
* endpoint indices.
|
|
|
|
*/
|
|
|
|
if (args.nargs != 2)
|
2018-07-17 17:19:14 +03:00
|
|
|
return NULL;
|
2017-03-28 10:52:20 +03:00
|
|
|
|
2018-07-17 17:19:11 +03:00
|
|
|
fwnode = args.fwnode;
|
2017-03-28 10:52:20 +03:00
|
|
|
port_nr = args.args[0];
|
|
|
|
endpoint_nr = args.args[1];
|
|
|
|
|
|
|
|
fwnode = acpi_graph_get_child_prop_value(fwnode, "port", port_nr);
|
|
|
|
|
2018-07-17 17:19:16 +03:00
|
|
|
return acpi_graph_get_child_prop_value(fwnode, "endpoint", endpoint_nr);
|
2017-03-28 10:52:20 +03:00
|
|
|
}
|
2017-06-06 12:37:37 +03:00
|
|
|
|
2017-07-21 14:39:36 +03:00
|
|
|
static bool acpi_fwnode_device_is_available(const struct fwnode_handle *fwnode)
|
2017-06-06 12:37:39 +03:00
|
|
|
{
|
|
|
|
if (!is_acpi_device_node(fwnode))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return acpi_device_is_present(to_acpi_device_node(fwnode));
|
|
|
|
}
|
|
|
|
|
2017-07-21 14:39:36 +03:00
|
|
|
static bool acpi_fwnode_property_present(const struct fwnode_handle *fwnode,
|
2017-06-06 12:37:37 +03:00
|
|
|
const char *propname)
|
|
|
|
{
|
|
|
|
return !acpi_node_prop_get(fwnode, propname, NULL);
|
|
|
|
}
|
|
|
|
|
2017-07-21 14:39:36 +03:00
|
|
|
static int
|
|
|
|
acpi_fwnode_property_read_int_array(const struct fwnode_handle *fwnode,
|
|
|
|
const char *propname,
|
|
|
|
unsigned int elem_size, void *val,
|
|
|
|
size_t nval)
|
2017-06-06 12:37:37 +03:00
|
|
|
{
|
|
|
|
enum dev_prop_type type;
|
|
|
|
|
|
|
|
switch (elem_size) {
|
|
|
|
case sizeof(u8):
|
|
|
|
type = DEV_PROP_U8;
|
|
|
|
break;
|
|
|
|
case sizeof(u16):
|
|
|
|
type = DEV_PROP_U16;
|
|
|
|
break;
|
|
|
|
case sizeof(u32):
|
|
|
|
type = DEV_PROP_U32;
|
|
|
|
break;
|
|
|
|
case sizeof(u64):
|
|
|
|
type = DEV_PROP_U64;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
return acpi_node_prop_read(fwnode, propname, type, val, nval);
|
|
|
|
}
|
|
|
|
|
2017-07-21 14:39:36 +03:00
|
|
|
static int
|
|
|
|
acpi_fwnode_property_read_string_array(const struct fwnode_handle *fwnode,
|
|
|
|
const char *propname, const char **val,
|
|
|
|
size_t nval)
|
2017-06-06 12:37:37 +03:00
|
|
|
{
|
|
|
|
return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
|
|
|
|
val, nval);
|
|
|
|
}
|
|
|
|
|
2017-07-21 15:11:49 +03:00
|
|
|
static int
|
|
|
|
acpi_fwnode_get_reference_args(const struct fwnode_handle *fwnode,
|
|
|
|
const char *prop, const char *nargs_prop,
|
|
|
|
unsigned int args_count, unsigned int index,
|
|
|
|
struct fwnode_reference_args *args)
|
|
|
|
{
|
2018-07-17 17:19:11 +03:00
|
|
|
return __acpi_node_get_property_reference(fwnode, prop, index,
|
|
|
|
args_count, args);
|
2017-07-21 15:11:49 +03:00
|
|
|
}
|
|
|
|
|
2019-10-03 15:32:12 +03:00
|
|
|
static const char *acpi_fwnode_get_name(const struct fwnode_handle *fwnode)
|
|
|
|
{
|
|
|
|
const struct acpi_device *adev;
|
|
|
|
struct fwnode_handle *parent;
|
|
|
|
|
|
|
|
/* Is this the root node? */
|
|
|
|
parent = fwnode_get_parent(fwnode);
|
|
|
|
if (!parent)
|
|
|
|
return "\\";
|
|
|
|
|
|
|
|
fwnode_handle_put(parent);
|
|
|
|
|
|
|
|
if (is_acpi_data_node(fwnode)) {
|
|
|
|
const struct acpi_data_node *dn = to_acpi_data_node(fwnode);
|
|
|
|
|
|
|
|
return dn->name;
|
|
|
|
}
|
|
|
|
|
|
|
|
adev = to_acpi_device_node(fwnode);
|
|
|
|
if (WARN_ON(!adev))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return acpi_device_bid(adev);
|
|
|
|
}
|
|
|
|
|
2019-10-03 15:32:13 +03:00
|
|
|
static const char *
|
|
|
|
acpi_fwnode_get_name_prefix(const struct fwnode_handle *fwnode)
|
|
|
|
{
|
|
|
|
struct fwnode_handle *parent;
|
|
|
|
|
|
|
|
/* Is this the root node? */
|
|
|
|
parent = fwnode_get_parent(fwnode);
|
|
|
|
if (!parent)
|
|
|
|
return "";
|
|
|
|
|
|
|
|
/* Is this 2nd node from the root? */
|
|
|
|
parent = fwnode_get_next_parent(parent);
|
|
|
|
if (!parent)
|
|
|
|
return "";
|
|
|
|
|
|
|
|
fwnode_handle_put(parent);
|
|
|
|
|
|
|
|
/* ACPI device or data node. */
|
|
|
|
return ".";
|
|
|
|
}
|
|
|
|
|
2017-07-21 14:39:36 +03:00
|
|
|
static struct fwnode_handle *
|
|
|
|
acpi_fwnode_get_parent(struct fwnode_handle *fwnode)
|
|
|
|
{
|
|
|
|
return acpi_node_get_parent(fwnode);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
|
2017-06-06 12:37:38 +03:00
|
|
|
struct fwnode_endpoint *endpoint)
|
|
|
|
{
|
|
|
|
struct fwnode_handle *port_fwnode = fwnode_get_parent(fwnode);
|
|
|
|
|
|
|
|
endpoint->local_fwnode = fwnode;
|
|
|
|
|
2018-07-17 17:19:16 +03:00
|
|
|
if (fwnode_property_read_u32(port_fwnode, "reg", &endpoint->port))
|
|
|
|
fwnode_property_read_u32(port_fwnode, "port", &endpoint->port);
|
|
|
|
if (fwnode_property_read_u32(fwnode, "reg", &endpoint->id))
|
|
|
|
fwnode_property_read_u32(fwnode, "endpoint", &endpoint->id);
|
2017-06-06 12:37:38 +03:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-09 18:38:36 +03:00
|
|
|
static const void *
|
2017-12-13 10:20:51 +03:00
|
|
|
acpi_fwnode_device_get_match_data(const struct fwnode_handle *fwnode,
|
|
|
|
const struct device *dev)
|
|
|
|
{
|
2018-02-09 18:38:35 +03:00
|
|
|
return acpi_device_get_match_data(dev);
|
2017-12-13 10:20:51 +03:00
|
|
|
}
|
|
|
|
|
2017-07-21 14:39:31 +03:00
|
|
|
#define DECLARE_ACPI_FWNODE_OPS(ops) \
|
|
|
|
const struct fwnode_operations ops = { \
|
|
|
|
.device_is_available = acpi_fwnode_device_is_available, \
|
2017-12-13 10:20:51 +03:00
|
|
|
.device_get_match_data = acpi_fwnode_device_get_match_data, \
|
2017-07-21 14:39:31 +03:00
|
|
|
.property_present = acpi_fwnode_property_present, \
|
|
|
|
.property_read_int_array = \
|
|
|
|
acpi_fwnode_property_read_int_array, \
|
|
|
|
.property_read_string_array = \
|
|
|
|
acpi_fwnode_property_read_string_array, \
|
|
|
|
.get_parent = acpi_node_get_parent, \
|
|
|
|
.get_next_child_node = acpi_get_next_subnode, \
|
|
|
|
.get_named_child_node = acpi_fwnode_get_named_child_node, \
|
2019-10-03 15:32:12 +03:00
|
|
|
.get_name = acpi_fwnode_get_name, \
|
2019-10-03 15:32:13 +03:00
|
|
|
.get_name_prefix = acpi_fwnode_get_name_prefix, \
|
2017-07-21 15:11:49 +03:00
|
|
|
.get_reference_args = acpi_fwnode_get_reference_args, \
|
2017-07-21 14:39:31 +03:00
|
|
|
.graph_get_next_endpoint = \
|
2018-07-17 17:19:14 +03:00
|
|
|
acpi_graph_get_next_endpoint, \
|
2017-07-21 14:39:31 +03:00
|
|
|
.graph_get_remote_endpoint = \
|
2018-07-17 17:19:14 +03:00
|
|
|
acpi_graph_get_remote_endpoint, \
|
2017-07-21 14:39:36 +03:00
|
|
|
.graph_get_port_parent = acpi_fwnode_get_parent, \
|
2017-07-21 14:39:31 +03:00
|
|
|
.graph_parse_endpoint = acpi_fwnode_graph_parse_endpoint, \
|
|
|
|
}; \
|
|
|
|
EXPORT_SYMBOL_GPL(ops)
|
|
|
|
|
|
|
|
DECLARE_ACPI_FWNODE_OPS(acpi_device_fwnode_ops);
|
|
|
|
DECLARE_ACPI_FWNODE_OPS(acpi_data_fwnode_ops);
|
|
|
|
const struct fwnode_operations acpi_static_fwnode_ops;
|
ACPI / bus: Make ACPI_HANDLE() work for non-GPL code again
Due to commit db3e50f3234b (device property: Get rid of struct
fwnode_handle type field), ACPI_HANDLE() inadvertently became
a GPL-only call. The call path that led to that was:
ACPI_HANDLE()
ACPI_COMPANION()
to_acpi_device_node()
is_acpi_device_node()
acpi_device_fwnode_ops
DECLARE_ACPI_FWNODE_OPS(acpi_device_fwnode_ops);
...and the new DECLARE_ACPI_FWNODE_OPS() includes
EXPORT_SYMBOL_GPL, whereas previously it was a static struct.
In order to avoid changing any of that, let's instead provide ever
so slightly better encapsulation of those struct fwnode_operations
instances. Those do not really need to be directly used in
inline function calls in header files. Simply moving two small
functions (is_acpi_device_node and is_acpi_data_node) out of
acpi_bus.h, and into a .c file, does that.
That leaves the internals of struct fwnode_operations as GPL-only
(which I think was the intent all along), but un-breaks any driver
code out there that relies on the ACPI subsystem's being (historically)
an EXPORT_SYMBOL-usable system. By that, I mean, ACPI_HANDLE() and
other basic ACPI calls were non-GPL-protected.
Also, while I'm there, remove a tiny bit of redundancy that was missed
in the earlier commit, by having is_acpi_node() use the other two
routines, instead of checking fwnode directly.
Fixes: db3e50f3234b (device property: Get rid of struct fwnode_handle type field)
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-09-16 03:35:27 +03:00
|
|
|
|
|
|
|
bool is_acpi_device_node(const struct fwnode_handle *fwnode)
|
|
|
|
{
|
|
|
|
return !IS_ERR_OR_NULL(fwnode) &&
|
|
|
|
fwnode->ops == &acpi_device_fwnode_ops;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(is_acpi_device_node);
|
|
|
|
|
|
|
|
bool is_acpi_data_node(const struct fwnode_handle *fwnode)
|
|
|
|
{
|
|
|
|
return !IS_ERR_OR_NULL(fwnode) && fwnode->ops == &acpi_data_fwnode_ops;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(is_acpi_data_node);
|