kernel/linux.git/drivers/acpi/property.c, branch v4.9.331

ACPI / property: Allow holes in reference properties

2016-10-11T20:44:00+00:00

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 Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki

ACPI / property: fix data node parsing in acpi_get_next_subnode()

2016-03-17T02:06:38+00:00

When an ACPI node has both ACPI device nodes and ACPI data nodes, acpi_get_next_subnode() will return the ACPI data nodes of its last parsed child. To avoid that, make acpi_get_next_subnode() go back to the original ACPI device object when all of the device node children of it have been found already. Signed-off-by: Irina Tirdea [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki

device property: return -EINVAL when property isn't found in ACPI

2015-12-07T01:29:23+00:00

Change return code to be in align with OF and built-in device properties error codes. In particular -EINVAL means property is not found. Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki

ACPI / property: Fix subnode lookup scope for data-only subnodes

2015-10-21T22:54:03+00:00

The correct scope for looking up the objects to generate data packages for data-only subnodes pointed to by another data-only subnode is the scope of the parent of that subnode and not the scope containing the _DSD object at the top of the hierarchy (the latter works only if all of the objects returning data-only subnode packages in a given hierarchy are in the same scope). Fix the code to work as expected. Fixes: 445b0eb058f5 (ACPI / property: Add support for data-only subnodes) Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Tested-by: Mika Westerberg

ACPI / property: Extend device_get_next_child_node() to data-only nodes

2015-09-14T23:47:34+00:00

Make device_get_next_child_node() work with ACPI data-only subnodes introduced previously. Namely, replace acpi_get_next_child() with acpi_get_next_subnode() that can handle (and return) child device objects as well as child data-only subnodes of the given device and modify the ACPI part of the GPIO subsystem to handle data-only subnodes returned by it. To that end, introduce acpi_node_get_gpiod() taking a struct fwnode_handle pointer as the first argument. That argument may point to an ACPI device object as well as to a data-only subnode and the function should do the right thing (ie. look for the matching GPIO descriptor correctly) in either case. Next, modify fwnode_get_named_gpiod() to use acpi_node_get_gpiod() instead of acpi_get_gpiod_by_index() which automatically causes devm_get_gpiod_from_child() to work with ACPI data-only subnodes that may be returned by device_get_next_child_node() which in turn is required by the users of that function (the gpio_keys_polled and gpio-leds drivers). Signed-off-by: Rafael J. Wysocki Tested-by: Mika Westerberg Acked-by: Linus Walleij

ACPI / property: Extend fwnode_property_* to data-only subnodes

2015-09-14T23:47:34+00:00

Modify is_acpi_node() to return "true" for ACPI data-only subnodes as well as for ACPI device objects and change the name of to_acpi_node() to to_acpi_device_node() so it is clear that it covers ACPI device objects only. Accordingly, introduce to_acpi_data_node() to cover data-only subnodes in an analogous way. With that, make the fwnode_property_* family of functions work with ACPI data-only subnodes introduced previously. Signed-off-by: Rafael J. Wysocki Tested-by: Mika Westerberg

ACPI / property: Expose data-only subnodes via sysfs

2015-09-14T23:47:34+00:00

Add infrastructure needed to expose data-only subnodes of ACPI device objects introduced previously via sysfs. Each data-only subnode is represented as a sysfs directory under the directory corresponding to its parent object (a device or a data-only subnode). Each of them has a "path" attribute (containing the full ACPI namespace path to the object the subnode data come from) at this time. Signed-off-by: Rafael J. Wysocki Tested-by: Mika Westerberg

ACPI / property: Add support for data-only subnodes

2015-09-14T23:47:34+00:00

In some cases, the information expressed via device properties is hierarchical by nature. For example, the properties of a composite device consisting of multiple semi-dependent components may need to be represented in the form of a tree of property data sets corresponding to specific components of the device. Unfortunately, using ACPI device objects for this purpose turns out to be problematic, mostly due to the assumption made by some operating systems (that platform firmware generally needs to work with) that each device object in the ACPI namespace represents a device requiring a separate driver. That assumption leads to complications which reportedly are impractically difficult to overcome and a different approach is needed for the sake of interoperability. The approach implemented here is based on extending _DSD via pointers (links) to additional ACPI objects returning data packages formatted in accordance with the _DSD formatting rules defined by Section 6.2.5 of ACPI 6. Those additional objects are referred to as data-only subnodes of the device object containing the _DSD pointing to them. The links to them need to be located in a separate section of the _DSD data package following UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b referred to as the Hierarchical Data Extension UUID as defined in [1]. Each of them is represented by a package of two strings. The first string in that package (the key) is regarded as the name of the data-only subnode pointed to by the link. The second string in it (the target) is expected to hold the ACPI namespace path (possibly utilizing the usual ACPI namespace search rules) of an ACPI object evaluating to a data package extending the _DSD. The device properties initialization code follows those links, creates a struct acpi_data_node object for each of them to store the data returned by the ACPI object pointed to by it and processes those data recursively (which may lead to the creation of more struct acpi_data_node objects if the returned data package contains the Hierarchical Data Extension UUID section with more links in it). All of the struct acpi_data_node objects are present until the the ACPI device object containing the _DSD with links to them is deleted and they are deleted along with that object. [1]: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf Signed-off-by: Rafael J. Wysocki Tested-by: Mika Westerberg

ACPI / property: Add routine for extraction of _DSD properties

2015-09-14T23:47:33+00:00

Move the extraction of _DSD properties from acpi_init_properties() to a separate routine called acpi_extract_properties() to make the subsequent changes more straightforward. Signed-off-by: Rafael J. Wysocki Tested-by: Mika Westerberg

device property: attach 'else if' to the proper 'if'

2015-08-25T23:46:39+00:00

Obviously in the current place the 'else' keyword is redundant, though it seems quite correct when we check if nval is in allowed range. Reattach the condition branch there. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki