06 Nov, 2014
1 commit
-
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
Acked-by: Grant Likely
Acked-by: Mika Westerberg
Tested-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
05 Nov, 2014
3 commits
-
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
Acked-by: Grant Likely
Signed-off-by: Rafael 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
Signed-off-by: Mika Westerberg
Acked-by: Greg Kroah-Hartman
Acked-by: Grant Likely
Signed-off-by: Rafael J. Wysocki -
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", },
Package () {"name2", },
...
}
})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.pdfReviewed-by: Hanjun Guo
Reviewed-by: Josh Triplett
Reviewed-by: Grant Likely
Signed-off-by: Darren Hart
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
