summaryrefslogtreecommitdiff
path: root/drivers/acpi/property.c
AgeCommit message (Collapse)Author
2016-10-11ACPI / property: Allow holes in reference propertiesMika Westerberg
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-03-17ACPI / property: fix data node parsing in acpi_get_next_subnode()Irina Tirdea
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 <irina.tirdea@intel.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-07device property: return -EINVAL when property isn't found in ACPIAndy Shevchenko
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 <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-22ACPI / property: Fix subnode lookup scope for data-only subnodesRafael J. Wysocki
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 <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-09-15ACPI / property: Extend device_get_next_child_node() to data-only nodesRafael J. Wysocki
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 <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2015-09-15ACPI / property: Extend fwnode_property_* to data-only subnodesRafael J. Wysocki
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 <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-09-15ACPI / property: Expose data-only subnodes via sysfsRafael J. Wysocki
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 <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-09-15ACPI / property: Add support for data-only subnodesRafael J. Wysocki
In some cases, the information expressed via device properties is hierarchical by nature. For example, the properties of a composite device consisting of multiple semi-dependent components may need to be represented in the form of a tree of property data sets corresponding to specific components of the device. Unfortunately, using ACPI device objects for this purpose turns out to be problematic, mostly due to the assumption made by some operating systems (that platform firmware generally needs to work with) that each device object in the ACPI namespace represents a device requiring a separate driver. That assumption leads to complications which reportedly are impractically difficult to overcome and a different approach is needed for the sake of interoperability. The approach implemented here is based on extending _DSD via pointers (links) to additional ACPI objects returning data packages formatted in accordance with the _DSD formatting rules defined by Section 6.2.5 of ACPI 6. Those additional objects are referred to as data-only subnodes of the device object containing the _DSD pointing to them. The links to them need to be located in a separate section of the _DSD data package following UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b referred to as the Hierarchical Data Extension UUID as defined in [1]. Each of them is represented by a package of two strings. The first string in that package (the key) is regarded as the name of the data-only subnode pointed to by the link. The second string in it (the target) is expected to hold the ACPI namespace path (possibly utilizing the usual ACPI namespace search rules) of an ACPI object evaluating to a data package extending the _DSD. The device properties initialization code follows those links, creates a struct acpi_data_node object for each of them to store the data returned by the ACPI object pointed to by it and processes those data recursively (which may lead to the creation of more struct acpi_data_node objects if the returned data package contains the Hierarchical Data Extension UUID section with more links in it). All of the struct acpi_data_node objects are present until the the ACPI device object containing the _DSD with links to them is deleted and they are deleted along with that object. [1]: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-09-15ACPI / property: Add routine for extraction of _DSD propertiesRafael J. Wysocki
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 <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-08-26device property: attach 'else if' to the proper 'if'Andy Shevchenko
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 <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-22ACPI / property: Define a symbol for PRP0001Rafael J. Wysocki
Use a #defined symbol ACPI_DT_NAMESPACE_HID instead of the PRP0001 string. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
2015-05-05ACPI / property: Refine consistency check for PRP0001Rafael J. Wysocki
Refine the check for the presence of the "compatible" property if the PRP0001 device ID is present in the device's list of ACPI/PNP IDs to also print the message if _DSD is missing entirely or the format of it is incorrect. One special case to take into accout is that the "compatible" property need not be provided for devices having the PRP0001 device ID in their lists of ACPI/PNP IDs if they are ancestors of PRP0001 devices with the "compatible" property present. This is to cover heriarchies of device objects where the kernel is only supposed to use a struct device representation for the topmost one and the others represent, for example, functional blocks of a composite device. While at it, reduce the log level of the message to "info" and reduce the log level of the "broken _DSD" message to "debug" (noise reduction). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-11-05ACPI / property: Drop size_prop from acpi_dev_get_property_reference()Rafael J. Wysocki
The size_prop argument of the recently added function acpi_dev_get_property_reference() is not used by the only current caller of that function and is very unlikely to be used at any time going forward. Namely, for a property whose value is a list of items each containing a references to a device object possibly accompanied by some integers, the number of items in the list can always be computed as the number of elements of type ACPI_TYPE_LOCAL_REFERENCE in the property package. Thus it should never be necessary to provide an additional "cells" property with a value equal to the number of items in that list. It also should never be necessary to provide a "cells" property specifying how many integers are supposed to be following each reference. For this reason, drop the size_prop argument from acpi_dev_get_property_reference() and update its caller accordingly. Link: http://marc.info/?l=linux-kernel&m=141511255610556&w=2 Suggested-by: Grant Likely <grant.likely@linaro.org> Acked-by: Grant Likely <grant.likely@linaro.org> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04ACPI: Allow drivers to match using Device Tree compatible propertyMika Westerberg
We have lots of existing Device Tree enabled drivers and allocating separate _HID for each is not feasible. Instead we allocate special _HID "PRP0001" that means that the match should be done using Device Tree compatible property using driver's .of_match_table instead if the driver is missing .acpi_match_table. If there is a need to distinguish from where the device is enumerated (DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04Driver core: Unified device properties interface for platform firmwareRafael J. Wysocki
Add a uniform interface by which device drivers can request device properties from the platform firmware by providing a property name and the corresponding data type. The purpose of it is to help to write portable code that won't depend on any particular platform firmware interface. The following general helper functions are added: device_property_present() device_property_read_u8() device_property_read_u16() device_property_read_u32() device_property_read_u64() device_property_read_string() device_property_read_u8_array() device_property_read_u16_array() device_property_read_u32_array() device_property_read_u64_array() device_property_read_string_array() The first one allows the caller to check if the given property is present. The next 5 of them allow single-valued properties of various types to be retrieved in a uniform way. The remaining 5 are for reading properties with multiple values (arrays of either numbers or strings). The interface covers both ACPI and Device Trees. This change set includes material from Mika Westerberg and Aaron Lu. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04ACPI: Add support for device specific propertiesMika Westerberg
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>