- 14 8月, 2015 1 次提交
-
-
由 Jeremy Linton 提交于
OF has some helper functions for parsing MAC and PHY settings. In cases where the platform is providing this information rather than the device itself, there needs to be similar functions for ACPI. These functions are slightly modified versions of the ones in of_net which can use information provided via DT or ACPI. Signed-off-by: NJeremy Linton <jeremy.linton@arm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 25 6月, 2015 1 次提交
-
-
由 Alexander Sverdlin 提交于
Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace but there were already ~63 of_node local variables or function parameters (no single acpi_node though, but anyway). After debugging undefined but used of_node local varible (which turned out to reference static function of_node() instead) it became clear that the names for the functions are too short and too generic for global scope. Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 6月, 2015 1 次提交
-
-
由 Suthikulpanit, Suravee 提交于
Currently, device drivers, which support both OF and ACPI, need to call two separate APIs, of_dma_is_coherent() and acpi_dma_is_coherent()) to determine device coherency attribute. This patch simplifies this process by introducing a new device property API, device_dma_is_coherent(), which calls the appropriate interface based on the booting architecture. Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 04 4月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Introduce data structures and code allowing "built-in" properties to be associated with devices in such a way that they will be used by the device_property_* API if no proper firmware node (neither DT nor ACPI) is present for the given device. Each property is to be represented by a property_entry structure. An array of property_entry structures (terminated with a null entry) can be pointed to by the properties field of struct property_set that can be added as a firmware node to a struct device using device_add_property_set(). That will cause the device_property_* API to use that property_set as the source of properties if the given device does not have a DT node or an ACPI companion device object associated with it. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 26 3月, 2015 2 次提交
-
-
由 Rafael J. Wysocki 提交于
Now that the ACPI companions of devices are pointed to by the fwnode field in struct device, the device_property_*() accessor functions can be modified to use their fwnode_property_*() counterparts internally with minimum extra overhead in the IS_ENABLED(CONFIG_OF) case, so make those changes. This allows us to get rid of the rather ugly DEV_PROP_READ_ARRAY() macro among other things. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Rafael J. Wysocki 提交于
Commit 5c0acf3b (driver core: Add comments about returning array counts) forgot to update fwnode_property_read_string_array() along the lines of device_property_read_string_array(), although it did change the kerneldoc comment of it. Fix that. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 3月, 2015 1 次提交
-
-
由 Florin Papa 提交于
Found this using checkpatch.pl. Signed-off-by: NFlorin Papa <florin.papa192@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 3月, 2015 1 次提交
-
-
由 Adrian Hunter 提交于
The "read array" variants of the device property functions can be used to return the number of values in an array. Update the comments to reflect that. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 05 11月, 2014 2 次提交
-
-
由 Rafael J. Wysocki 提交于
Add new generic routines are provided for retrieving properties from device description objects in the platform firmware in case there are no struct device objects for them (either those objects have not been created yet or they do not exist at all). The following functions are provided: fwnode_property_present() fwnode_property_read_u8() fwnode_property_read_u16() fwnode_property_read_u32() fwnode_property_read_u64() fwnode_property_read_string() fwnode_property_read_u8_array() fwnode_property_read_u16_array() fwnode_property_read_u32_array() fwnode_property_read_u64_array() fwnode_property_read_string_array() in analogy with the corresponding functions for struct device added previously. For all of them, the first argument is a pointer to struct fwnode_handle (new type) that allows a device description object (depending on what platform firmware interface is in use) to be obtained. Add a new macro device_for_each_child_node() for iterating over the children of the device description object associated with a given device and a new function device_get_child_node_count() returning the number of a given device's child nodes. The interface covers both ACPI and Device Trees. Suggested-by: NGrant Likely <grant.likely@linaro.org> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NGrant Likely <grant.likely@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 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: NAaron Lu <aaron.lu@intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NGrant Likely <grant.likely@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-