kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-26 18:16:26 +00:00
Code Issues Releases Packages Activity
linux/drivers/base/property.c

1417 lines
42 KiB
Raw Permalink Normal View History

driver core: add SPDX identifiers to all driver core files It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the driver core files files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org> Cc: William Breathitt Gray <vilhelm.gray@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-07 17:30:07 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Introduces device_dma_is_coherent() 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: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-10 11:08:54 -05:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Introduce fwnode_irq_get() Until now there were two very similar functions allowing to get Linux IRQ number from ACPI handle (acpi_irq_get()) and OF node (of_irq_get()). The first one appeared to be used only as a subroutine of platform_irq_get(), which (in the generic code) limited IRQ obtaining from _CRS method only to nodes associated to kernel's struct platform_device. This patch introduces a new helper routine - fwnode_irq_get(), which allows to get the IRQ number directly from the fwnode to be used as common for OF/ACPI worlds. It is usable not only for the parents fwnodes, but also for the child nodes comprising their own _CRS methods with interrupts description. In order to be able o satisfy compilation with !CONFIG_ACPI and also simplify the new code, introduce a helper macro (ACPI_HANDLE_FWNODE), with which it is possible to reach an ACPI handle directly from its fwnode. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:40 +01:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Track owner device of device property Deletion of subdevice will remove device properties associated to parent when they share the same firmware node after commit 478573c93abd (driver core: Don't leak secondary fwnode on device removal). This was observed with a driver adding subdevice that driver wasn't able to read device properties after rmmod/modprobe cycle. Consider the lifecycle of it: parent device registration ACPI_COMPANION_SET() device_add_properties() pset_copy_set() set_secondary_fwnode(dev, &p->fwnode) device_add() parent probe read device properties ACPI_COMPANION_SET(subdevice, ACPI_COMPANION(parent)) device_add(subdevice) parent remove device_del(subdevice) device_remove_properties() set_secondary_fwnode(dev, NULL); pset_free() Parent device will have its primary firmware node pointing to an ACPI node and secondary firmware node point to device properties. ACPI_COMPANION_SET() call in parent probe will set the subdevice's firmware node to point to the same 'struct fwnode_handle' and the associated secondary firmware node, i.e. the device properties as the parent. When subdevice is deleted in parent remove that will remove those device properties and attempt to read device properties in next parent probe call will fail. Fix this by tracking the owner device of device properties and delete them only when owner device is being deleted. Fixes: 478573c93abd (driver core: Don't leak secondary fwnode on device removal) Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-09 16:28:37 +03:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Get rid of struct fwnode_handle type field Instead of relying on the struct fwnode_handle type field, define fwnode_operations structs for all separate types of fwnodes. To find out the type, compare to the ops field to relevant ops structs. This change has two benefits: 1. it avoids adding the type field to each and every instance of struct fwnode_handle, thus saving memory and 2. makes the ops field the single factor that defines both the types of the fwnode as well as defines the implementation of its operations, decreasing the possibility of bugs when developing code dealing with fwnode internals. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:31 +03:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
device property: Get rid of struct fwnode_handle type field Instead of relying on the struct fwnode_handle type field, define fwnode_operations structs for all separate types of fwnodes. To find out the type, compare to the ops field to relevant ops structs. This change has two benefits: 1. it avoids adding the type field to each and every instance of struct fwnode_handle, thus saving memory and 2. makes the ops field the single factor that defines both the types of the fwnode as well as defines the implementation of its operations, decreasing the possibility of bugs when developing code dealing with fwnode internals. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:31 +03:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: keep single value inplace We may save a lot of lines of code and space by keeping single values inside the struct property_entry. Refactor the implementation to do so. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:32 +02:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Constify argument to pset fwnode backend Internally constify pset fwnode backend. Do not touch the pset fwnode operations yet. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:35 +03:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Fix reading pset strings using array access functions The length field value of non-array string properties is the length of the string itself. Non-array string properties thus require specific handling. Fix this. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:22:18 +03:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: Fix reading pset strings using array access functions The length field value of non-array string properties is the length of the string itself. Non-array string properties thus require specific handling. Fix this. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:22:18 +03:00
device property: refactor built-in properties support Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:31 +02:00
device property: Fix reading pset strings using array access functions The length field value of non-array string properties is the length of the string itself. Non-array string properties thus require specific handling. Fix this. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:22:18 +03:00
device property: fwnode_property_read_string_array() returns nr of strings Functionally fwnode_property_read_string_array() should match of_property_read_string_array() and work as a drop-in substitute for the latter. of_property_read_string_array() returns the number of strings read if the target string pointer array is non-NULL. Make fwnode_property_read_string_array() do the same. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:22:19 +03:00
device property: Introduce firmware node type for platform data 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-03 16:05:11 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Make dev_fwnode() public The function to obtain a fwnode related to a struct device is useful for drivers that use the fwnode property API: it allows not being aware of the underlying firmware implementation. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:24 +03:00
driver core: Implement device property accessors through fwnode ones 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 00:24:16 +01:00
device property: Make dev_fwnode() public The function to obtain a fwnode related to a struct device is useful for drivers that use the fwnode property API: it allows not being aware of the underlying firmware implementation. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:24 +03:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Implement device property accessors through fwnode ones 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 00:24:16 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Fallback to secondary fwnode if primary misses the property The struct fwnode has notion of secondary fwnode. This is supposed to used as fallback if the primary firmware interface (DT, ACPI) does not have the property in question. However, the current implementation never checks the secondary node which prevents one to add default "built-in" properties to devices. This patch adds fallback to the secondary fwnode if the primary fwnode returns that the property does not exists. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:36 +02:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Fallback to secondary fwnode if primary misses the property The struct fwnode has notion of secondary fwnode. This is supposed to used as fallback if the primary firmware interface (DT, ACPI) does not have the property in question. However, the current implementation never checks the secondary node which prevents one to add default "built-in" properties to devices. This patch adds fallback to the secondary fwnode if the primary fwnode returns that the property does not exists. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:36 +02:00
device property: Introduce fwnode_call_bool_op() for ops that return bool fwnode_call_int_op() isn't suitable for calling ops that return bool since it effectively causes the result returned to the user to be true when an op hasn't been defined or the fwnode is NULL. Address this by introducing fwnode_call_bool_op() for calling ops that return bool. Fixes: 3708184afc77 "device property: Move FW type specific functionality to FW specific files" Fixes: 2294b3af05e9 "device property: Introduce fwnode_device_is_available()" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-11 18:20:20 +03:00
device property: fix for a case of use-after-free In device_remove_property_set(), the secondary fwnode needs to be cleared before the pset is freed. This fixes a use-after-free when a property set is providing the primary fwnode. As a result of the fix, the primary fwnode may end up containing ERR_PTR(-ENODEV), so also adding checks for it to the property handling code. Reported-by: John Youn <John.Youn@synopsys.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-10 13:03:18 +02:00
device property: Introduce fwnode_call_bool_op() for ops that return bool fwnode_call_int_op() isn't suitable for calling ops that return bool since it effectively causes the result returned to the user to be true when an op hasn't been defined or the fwnode is NULL. Address this by introducing fwnode_call_bool_op() for calling ops that return bool. Fixes: 3708184afc77 "device property: Move FW type specific functionality to FW specific files" Fixes: 2294b3af05e9 "device property: Introduce fwnode_device_is_available()" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-11 18:20:20 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Fallback to secondary fwnode if primary misses the property The struct fwnode has notion of secondary fwnode. This is supposed to used as fallback if the primary firmware interface (DT, ACPI) does not have the property in question. However, the current implementation never checks the secondary node which prevents one to add default "built-in" properties to devices. This patch adds fallback to the secondary fwnode if the primary fwnode returns that the property does not exists. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:36 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Return -ENXIO if there is no suitable FW interface Return -ENXIO if device property array access functions don't find a suitable firmware interface. This lets drivers decide if they should use available platform data instead. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-26 20:27:04 -07:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Implement device property accessors through fwnode ones 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 00:24:16 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Return -ENXIO if there is no suitable FW interface Return -ENXIO if device property array access functions don't find a suitable firmware interface. This lets drivers decide if they should use available platform data instead. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-26 20:27:04 -07:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Implement device property accessors through fwnode ones 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 00:24:16 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Return -ENXIO if there is no suitable FW interface Return -ENXIO if device property array access functions don't find a suitable firmware interface. This lets drivers decide if they should use available platform data instead. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-26 20:27:04 -07:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Implement device property accessors through fwnode ones 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 00:24:16 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Return -ENXIO if there is no suitable FW interface Return -ENXIO if device property array access functions don't find a suitable firmware interface. This lets drivers decide if they should use available platform data instead. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-26 20:27:04 -07:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Implement device property accessors through fwnode ones 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 00:24:16 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: fwnode_property_read_string_array() returns nr of strings Functionally fwnode_property_read_string_array() should match of_property_read_string_array() and work as a drop-in substitute for the latter. of_property_read_string_array() returns the number of strings read if the target string pointer array is non-NULL. Make fwnode_property_read_string_array() do the same. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:22:19 +03:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Return -ENXIO if there is no suitable FW interface Return -ENXIO if device property array access functions don't find a suitable firmware interface. This lets drivers decide if they should use available platform data instead. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-26 20:27:04 -07:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Implement device property accessors through fwnode ones 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 00:24:16 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
device property: Return -ENXIO if there is no suitable FW interface Return -ENXIO if device property array access functions don't find a suitable firmware interface. This lets drivers decide if they should use available platform data instead. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-26 20:27:04 -07:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
driver core: Implement device property accessors through fwnode ones 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 00:24:16 +01:00
Driver core: Unified device properties interface for platform firmware 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-04 01:28:56 +01:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Add fwnode_property_match_string() Sometimes it is useful to be able to extract an index of certain string value from an array of strings. A typical use case is to give a name to a DMA channel, PWM, clock and so on. Provide an implementation using unified device property accessors that follows of_property_match_string() but works for all supported fwnodes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-14 17:37:35 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Fallback to secondary fwnode if primary misses the property The struct fwnode has notion of secondary fwnode. This is supposed to used as fallback if the primary firmware interface (DT, ACPI) does not have the property in question. However, the current implementation never checks the secondary node which prevents one to add default "built-in" properties to devices. This patch adds fallback to the secondary fwnode if the primary fwnode returns that the property does not exists. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:36 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
driver core: Add comments about returning array counts 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: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-17 09:58:58 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: fwnode_property_read_string_array() returns nr of strings Functionally fwnode_property_read_string_array() should match of_property_read_string_array() and work as a drop-in substitute for the latter. of_property_read_string_array() returns the number of strings read if the target string pointer array is non-NULL. Make fwnode_property_read_string_array() do the same. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:22:19 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: fwnode_property_read_string_array() may return -EILSEQ fwnode_property_read_string_array() may return -EILSEQ through of_property_read_string_array(). Document this. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:22:17 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Fallback to secondary fwnode if primary misses the property The struct fwnode has notion of secondary fwnode. This is supposed to used as fallback if the primary firmware interface (DT, ACPI) does not have the property in question. However, the current implementation never checks the secondary node which prevents one to add default "built-in" properties to devices. This patch adds fallback to the secondary fwnode if the primary fwnode returns that the property does not exists. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:36 +02:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: fix for a case of use-after-free In device_remove_property_set(), the secondary fwnode needs to be cleared before the pset is freed. This fixes a use-after-free when a property set is providing the primary fwnode. As a result of the fix, the primary fwnode may end up containing ERR_PTR(-ENODEV), so also adding checks for it to the property handling code. Reported-by: John Youn <John.Youn@synopsys.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-10 13:03:18 +02:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Fallback to secondary fwnode if primary misses the property The struct fwnode has notion of secondary fwnode. This is supposed to used as fallback if the primary firmware interface (DT, ACPI) does not have the property in question. However, the current implementation never checks the secondary node which prevents one to add default "built-in" properties to devices. This patch adds fallback to the secondary fwnode if the primary fwnode returns that the property does not exists. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:36 +02:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Read strings using string array reading functions Always read strings using of_property_read_string_array() instead of of_property_read_string(). This allows using a single operation struct callback for accessing strings. Same for pset_prop_read_string_array() and pset_prop_read_string(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:26:22 +03:00
device property: Fallback to secondary fwnode if primary misses the property The struct fwnode has notion of secondary fwnode. This is supposed to used as fallback if the primary firmware interface (DT, ACPI) does not have the property in question. However, the current implementation never checks the secondary node which prevents one to add default "built-in" properties to devices. This patch adds fallback to the secondary fwnode if the primary fwnode returns that the property does not exists. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:36 +02:00
device property: fwnode_property_read_string_array() returns nr of strings Functionally fwnode_property_read_string_array() should match of_property_read_string_array() and work as a drop-in substitute for the latter. of_property_read_string_array() returns the number of strings read if the target string pointer array is non-NULL. Make fwnode_property_read_string_array() do the same. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 15:22:19 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Add fwnode_property_match_string() Sometimes it is useful to be able to extract an index of certain string value from an array of strings. A typical use case is to give a name to a DMA channel, PWM, clock and so on. Provide an implementation using unified device property accessors that follows of_property_match_string() but works for all supported fwnodes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-14 17:37:35 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add fwnode_property_match_string() Sometimes it is useful to be able to extract an index of certain string value from an array of strings. A typical use case is to give a name to a DMA channel, PWM, clock and so on. Provide an implementation using unified device property accessors that follows of_property_match_string() but works for all supported fwnodes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-14 17:37:35 +03:00
device property: convert to use match_string() helper The new helper returns index of the mathing string in an array. We would use it here. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-03-17 14:22:17 -07:00
device property: Add fwnode_property_match_string() Sometimes it is useful to be able to extract an index of certain string value from an array of strings. A typical use case is to give a name to a DMA channel, PWM, clock and so on. Provide an implementation using unified device property accessors that follows of_property_match_string() but works for all supported fwnodes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-14 17:37:35 +03:00
device property: avoid allocations of 0 length Arrays can not have zero elements by definition of the unified device properties. If such property comes from outside we should not allow it to pass. Otherwise memory allocation on 0 length will return non-NULL value, which we currently don't check. Prevent memory allocations of 0 length. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-29 13:07:50 +02:00
device property: Add fwnode_property_match_string() Sometimes it is useful to be able to extract an index of certain string value from an array of strings. A typical use case is to give a name to a DMA channel, PWM, clock and so on. Provide an implementation using unified device property accessors that follows of_property_match_string() but works for all supported fwnodes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-14 17:37:35 +03:00
device property: convert to use match_string() helper The new helper returns index of the mathing string in an array. We would use it here. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-03-17 14:22:17 -07:00
device property: Add fwnode_property_match_string() Sometimes it is useful to be able to extract an index of certain string value from an array of strings. A typical use case is to give a name to a DMA channel, PWM, clock and so on. Provide an implementation using unified device property accessors that follows of_property_match_string() but works for all supported fwnodes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-14 17:37:35 +03:00
device property: Introduce fwnode_property_get_reference_args The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be explicitly obtained from the firmware interface. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 15:11:49 +03:00
ACPI: properties: Align return codes of __acpi_node_get_property_reference() acpi_fwnode_get_reference_args(), the function implementing ACPI support for fwnode_property_get_reference_args(), returns directly error codes from __acpi_node_get_property_reference(). The latter uses different error codes than the OF implementation. In particular, the OF implementation uses -ENOENT to indicate that the property is not found, a reference entry is empty and there are no more references. Document and align the error codes for property for fwnode_property_get_reference_args() so that they match with of_parse_phandle_with_args(). Fixes: 3e3119d3088f (device property: Introduce fwnode_property_get_reference_args) Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-09-26 12:08:27 +03:00
device property: Introduce fwnode_property_get_reference_args The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be explicitly obtained from the firmware interface. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 15:11:49 +03:00
device property: Move property_entry_free_data() upper It's just a preparatory patch to use property_entry_free_data() later on. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-22 16:21:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Reuse property_entry_free_data() Reuse property_entry_free_data() in property_entry_copy_data() to make code slightly cleaner. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-22 16:21:38 +02:00
device property: avoid allocations of 0 length Arrays can not have zero elements by definition of the unified device properties. If such property comes from outside we should not allow it to pass. Otherwise memory allocation on 0 length will return non-NULL value, which we currently don't check. Prevent memory allocations of 0 length. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-29 13:07:50 +02:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Reuse property_entry_free_data() Reuse property_entry_free_data() in property_entry_copy_data() to make code slightly cleaner. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-22 16:21:38 +02:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Reuse property_entry_free_data() Reuse property_entry_free_data() in property_entry_copy_data() to make code slightly cleaner. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-22 16:21:38 +02:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Reuse property_entry_free_data() Reuse property_entry_free_data() in property_entry_copy_data() to make code slightly cleaner. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-22 16:21:38 +02:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Reuse property_entry_free_data() Reuse property_entry_free_data() in property_entry_copy_data() to make code slightly cleaner. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-22 16:21:38 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Reuse property_entry_free_data() Reuse property_entry_free_data() in property_entry_copy_data() to make code slightly cleaner. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-22 16:21:38 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: export code duplicating array of property entries When augmenting ACPI-enumerated devices with additional property data based on DMI info, a module has often several potential property sets, with only one being active on a given box. In order to save memory it should be possible to mark everything and __initdata or __initconst, execute DMI match early, and duplicate relevant properties. Then kernel will discard the rest of them. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:27 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Track owner device of device property Deletion of subdevice will remove device properties associated to parent when they share the same firmware node after commit 478573c93abd (driver core: Don't leak secondary fwnode on device removal). This was observed with a driver adding subdevice that driver wasn't able to read device properties after rmmod/modprobe cycle. Consider the lifecycle of it: parent device registration ACPI_COMPANION_SET() device_add_properties() pset_copy_set() set_secondary_fwnode(dev, &p->fwnode) device_add() parent probe read device properties ACPI_COMPANION_SET(subdevice, ACPI_COMPANION(parent)) device_add(subdevice) parent remove device_del(subdevice) device_remove_properties() set_secondary_fwnode(dev, NULL); pset_free() Parent device will have its primary firmware node pointing to an ACPI node and secondary firmware node point to device properties. ACPI_COMPANION_SET() call in parent probe will set the subdevice's firmware node to point to the same 'struct fwnode_handle' and the associated secondary firmware node, i.e. the device properties as the parent. When subdevice is deleted in parent remove that will remove those device properties and attempt to read device properties in next parent probe call will fail. Fix this by tracking the owner device of device properties and delete them only when owner device is being deleted. Fixes: 478573c93abd (driver core: Don't leak secondary fwnode on device removal) Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-09 16:28:37 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Track owner device of device property Deletion of subdevice will remove device properties associated to parent when they share the same firmware node after commit 478573c93abd (driver core: Don't leak secondary fwnode on device removal). This was observed with a driver adding subdevice that driver wasn't able to read device properties after rmmod/modprobe cycle. Consider the lifecycle of it: parent device registration ACPI_COMPANION_SET() device_add_properties() pset_copy_set() set_secondary_fwnode(dev, &p->fwnode) device_add() parent probe read device properties ACPI_COMPANION_SET(subdevice, ACPI_COMPANION(parent)) device_add(subdevice) parent remove device_del(subdevice) device_remove_properties() set_secondary_fwnode(dev, NULL); pset_free() Parent device will have its primary firmware node pointing to an ACPI node and secondary firmware node point to device properties. ACPI_COMPANION_SET() call in parent probe will set the subdevice's firmware node to point to the same 'struct fwnode_handle' and the associated secondary firmware node, i.e. the device properties as the parent. When subdevice is deleted in parent remove that will remove those device properties and attempt to read device properties in next parent probe call will fail. Fix this by tracking the owner device of device properties and delete them only when owner device is being deleted. Fixes: 478573c93abd (driver core: Don't leak secondary fwnode on device removal) Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-09 16:28:37 +03:00
device property: fix for a case of use-after-free In device_remove_property_set(), the secondary fwnode needs to be cleared before the pset is freed. This fixes a use-after-free when a property set is providing the primary fwnode. As a result of the fix, the primary fwnode may end up containing ERR_PTR(-ENODEV), so also adding checks for it to the property handling code. Reported-by: John Youn <John.Youn@synopsys.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-10 13:03:18 +02:00
device property: Track owner device of device property Deletion of subdevice will remove device properties associated to parent when they share the same firmware node after commit 478573c93abd (driver core: Don't leak secondary fwnode on device removal). This was observed with a driver adding subdevice that driver wasn't able to read device properties after rmmod/modprobe cycle. Consider the lifecycle of it: parent device registration ACPI_COMPANION_SET() device_add_properties() pset_copy_set() set_secondary_fwnode(dev, &p->fwnode) device_add() parent probe read device properties ACPI_COMPANION_SET(subdevice, ACPI_COMPANION(parent)) device_add(subdevice) parent remove device_del(subdevice) device_remove_properties() set_secondary_fwnode(dev, NULL); pset_free() Parent device will have its primary firmware node pointing to an ACPI node and secondary firmware node point to device properties. ACPI_COMPANION_SET() call in parent probe will set the subdevice's firmware node to point to the same 'struct fwnode_handle' and the associated secondary firmware node, i.e. the device properties as the parent. When subdevice is deleted in parent remove that will remove those device properties and attempt to read device properties in next parent probe call will fail. Fix this by tracking the owner device of device properties and delete them only when owner device is being deleted. Fixes: 478573c93abd (driver core: Don't leak secondary fwnode on device removal) Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-09 16:28:37 +03:00
device property: fix for a case of use-after-free In device_remove_property_set(), the secondary fwnode needs to be cleared before the pset is freed. This fixes a use-after-free when a property set is providing the primary fwnode. As a result of the fix, the primary fwnode may end up containing ERR_PTR(-ENODEV), so also adding checks for it to the property handling code. Reported-by: John Youn <John.Youn@synopsys.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-10 13:03:18 +02:00
device property: Track owner device of device property Deletion of subdevice will remove device properties associated to parent when they share the same firmware node after commit 478573c93abd (driver core: Don't leak secondary fwnode on device removal). This was observed with a driver adding subdevice that driver wasn't able to read device properties after rmmod/modprobe cycle. Consider the lifecycle of it: parent device registration ACPI_COMPANION_SET() device_add_properties() pset_copy_set() set_secondary_fwnode(dev, &p->fwnode) device_add() parent probe read device properties ACPI_COMPANION_SET(subdevice, ACPI_COMPANION(parent)) device_add(subdevice) parent remove device_del(subdevice) device_remove_properties() set_secondary_fwnode(dev, NULL); pset_free() Parent device will have its primary firmware node pointing to an ACPI node and secondary firmware node point to device properties. ACPI_COMPANION_SET() call in parent probe will set the subdevice's firmware node to point to the same 'struct fwnode_handle' and the associated secondary firmware node, i.e. the device properties as the parent. When subdevice is deleted in parent remove that will remove those device properties and attempt to read device properties in next parent probe call will fail. Fix this by tracking the owner device of device properties and delete them only when owner device is being deleted. Fixes: 478573c93abd (driver core: Don't leak secondary fwnode on device removal) Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-09 16:28:37 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: allow to constify properties There is no reason why statically defined properties should be modifiable, so let's make device_add_properties() and the rest of pset_*() functions to take const pointers to properties. This will allow us to mark properties as const/__initconst at definition sites. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-02 17:41:25 -08:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Track owner device of device property Deletion of subdevice will remove device properties associated to parent when they share the same firmware node after commit 478573c93abd (driver core: Don't leak secondary fwnode on device removal). This was observed with a driver adding subdevice that driver wasn't able to read device properties after rmmod/modprobe cycle. Consider the lifecycle of it: parent device registration ACPI_COMPANION_SET() device_add_properties() pset_copy_set() set_secondary_fwnode(dev, &p->fwnode) device_add() parent probe read device properties ACPI_COMPANION_SET(subdevice, ACPI_COMPANION(parent)) device_add(subdevice) parent remove device_del(subdevice) device_remove_properties() set_secondary_fwnode(dev, NULL); pset_free() Parent device will have its primary firmware node pointing to an ACPI node and secondary firmware node point to device properties. ACPI_COMPANION_SET() call in parent probe will set the subdevice's firmware node to point to the same 'struct fwnode_handle' and the associated secondary firmware node, i.e. the device properties as the parent. When subdevice is deleted in parent remove that will remove those device properties and attempt to read device properties in next parent probe call will fail. Fix this by tracking the owner device of device properties and delete them only when owner device is being deleted. Fixes: 478573c93abd (driver core: Don't leak secondary fwnode on device removal) Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-09 16:28:37 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: don't bother the drivers with struct property_set Since device_add_property_set() now always takes a copy of the property_set, and also since the fwnode type is always hard coded to be FWNODE_PDATA, there is no need for the drivers to deliver the entire struct property_set. The function can just create the instance of it on its own and bind the properties from the drivers to it on the spot. This renames device_add_property_set() to device_add_properties(). The function now takes struct property_entry as its parameter instead of struct property_set. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-29 14:52:23 +03:00
device property: Take a copy of the property set It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30 17:11:37 +02:00
device property: Add fwnode_get_next_parent() In order to differentiate the functionality between dropping a reference to the node (or not) for the benefit of OF, introduce fwnode_get_next_parent(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:26 +03:00
device property: Add fwnode_get_parent() Now that ACPI has support for returning parent firmware node for both types of nodes we can expose this to others as well. This adds a new function fwnode_get_parent() that can be used for DT and ACPI nodes to retrieve the parent firmware node. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:17 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add fwnode_get_parent() Now that ACPI has support for returning parent firmware node for both types of nodes we can expose this to others as well. This adds a new function fwnode_get_parent() that can be used for DT and ACPI nodes to retrieve the parent firmware node. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:17 +03:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Add fwnode_get_parent() Now that ACPI has support for returning parent firmware node for both types of nodes we can expose this to others as well. This adds a new function fwnode_get_parent() that can be used for DT and ACPI nodes to retrieve the parent firmware node. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:17 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
ACPI / property: Add fwnode_get_next_child_node() The ACPI _DSD hierarchical data extension makes it possible to have hierarchies deeper than one level in similar way than DT allows. These "subsubnodes" have not been accessible because device property implementation only provides device_get_next_child_node() that is limited to direct descendants of a device. We need this ability in order support things like remote endpoints currently supported in DT with of_graph_* APIs. Modify acpi_get_next_subnode() to accept fwnode handle instead and update callers accordingly. Also add a new function fwnode_get_next_child_node() that works directly with fwnodes and modify device_get_next_child_node() to call it directly. While there add a macro fwnode_for_each_child_node() analogous to the current device_for_each_child_node() but it works with fwnodes instead of devices. Link: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:18 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
ACPI / property: Add fwnode_get_next_child_node() The ACPI _DSD hierarchical data extension makes it possible to have hierarchies deeper than one level in similar way than DT allows. These "subsubnodes" have not been accessible because device property implementation only provides device_get_next_child_node() that is limited to direct descendants of a device. We need this ability in order support things like remote endpoints currently supported in DT with of_graph_* APIs. Modify acpi_get_next_subnode() to accept fwnode handle instead and update callers accordingly. Also add a new function fwnode_get_next_child_node() that works directly with fwnodes and modify device_get_next_child_node() to call it directly. While there add a macro fwnode_for_each_child_node() analogous to the current device_for_each_child_node() but it works with fwnodes instead of devices. Link: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:18 +03:00
device property: Allow iterating over available child fwnodes Implement a new helper function fwnode_get_next_available_child_node(), which enables obtaining next enabled child fwnode, which works on a similar basis to OF's of_get_next_available_child(). This commit also introduces a macro, thanks to which it is possible to iterate over the available fwnodes, using the new function described above. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:41 +01:00
ACPI / property: Add fwnode_get_next_child_node() The ACPI _DSD hierarchical data extension makes it possible to have hierarchies deeper than one level in similar way than DT allows. These "subsubnodes" have not been accessible because device property implementation only provides device_get_next_child_node() that is limited to direct descendants of a device. We need this ability in order support things like remote endpoints currently supported in DT with of_graph_* APIs. Modify acpi_get_next_subnode() to accept fwnode handle instead and update callers accordingly. Also add a new function fwnode_get_next_child_node() that works directly with fwnodes and modify device_get_next_child_node() to call it directly. While there add a macro fwnode_for_each_child_node() analogous to the current device_for_each_child_node() but it works with fwnodes instead of devices. Link: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:18 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Add function to search for named child of device For device nodes in both DT and ACPI, it possible to have named child nodes which contain properties (an existing example being gpio-leds). This adds a function to find a named child node for a device which can be used by drivers for property retrieval. For DT data node name matching, of_node_cmp() and similar functions are made available outside of CONFIG_OF block so the new function can reference these for DT and non-DT builds. For ACPI data node name matching, a helper function is also added which returns false if CONFIG_ACPI is not set, otherwise it performs a string comparison on the data node name. This avoids using the acpi_data_node struct for non CONFIG_ACPI builds, which would otherwise cause a build failure. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Acked-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-21 18:50:20 +01:00
device property: Add fwnode_get_named_child_node() Since now we have means to enumerate all children of any fwnode even in ACPI we can implement fwnode_get_named_child_node(). This is similar than device_get_named_child_node() with the exception that it can be called to any fwnode handle. Make device_get_named_child_node() call directly this new function. This is useful in cases where we need to be able to find child nodes which are not direct descendants of the parent device. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:19 +03:00
device property: Add function to search for named child of device For device nodes in both DT and ACPI, it possible to have named child nodes which contain properties (an existing example being gpio-leds). This adds a function to find a named child node for a device which can be used by drivers for property retrieval. For DT data node name matching, of_node_cmp() and similar functions are made available outside of CONFIG_OF block so the new function can reference these for DT and non-DT builds. For ACPI data node name matching, a helper function is also added which returns false if CONFIG_ACPI is not set, otherwise it performs a string comparison on the data node name. This avoids using the acpi_data_node struct for non CONFIG_ACPI builds, which would otherwise cause a build failure. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Acked-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-21 18:50:20 +01:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add function to search for named child of device For device nodes in both DT and ACPI, it possible to have named child nodes which contain properties (an existing example being gpio-leds). This adds a function to find a named child node for a device which can be used by drivers for property retrieval. For DT data node name matching, of_node_cmp() and similar functions are made available outside of CONFIG_OF block so the new function can reference these for DT and non-DT builds. For ACPI data node name matching, a helper function is also added which returns false if CONFIG_ACPI is not set, otherwise it performs a string comparison on the data node name. This avoids using the acpi_data_node struct for non CONFIG_ACPI builds, which would otherwise cause a build failure. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Acked-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-21 18:50:20 +01:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
device property: Add function to search for named child of device For device nodes in both DT and ACPI, it possible to have named child nodes which contain properties (an existing example being gpio-leds). This adds a function to find a named child node for a device which can be used by drivers for property retrieval. For DT data node name matching, of_node_cmp() and similar functions are made available outside of CONFIG_OF block so the new function can reference these for DT and non-DT builds. For ACPI data node name matching, a helper function is also added which returns false if CONFIG_ACPI is not set, otherwise it performs a string comparison on the data node name. This avoids using the acpi_data_node struct for non CONFIG_ACPI builds, which would otherwise cause a build failure. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Acked-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-21 18:50:20 +01:00
device property: Add fwnode_get_named_child_node() Since now we have means to enumerate all children of any fwnode even in ACPI we can implement fwnode_get_named_child_node(). This is similar than device_get_named_child_node() with the exception that it can be called to any fwnode handle. Make device_get_named_child_node() call directly this new function. This is useful in cases where we need to be able to find child nodes which are not direct descendants of the parent device. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:19 +03:00
device property: Add function to search for named child of device For device nodes in both DT and ACPI, it possible to have named child nodes which contain properties (an existing example being gpio-leds). This adds a function to find a named child node for a device which can be used by drivers for property retrieval. For DT data node name matching, of_node_cmp() and similar functions are made available outside of CONFIG_OF block so the new function can reference these for DT and non-DT builds. For ACPI data node name matching, a helper function is also added which returns false if CONFIG_ACPI is not set, otherwise it performs a string comparison on the data node name. This avoids using the acpi_data_node struct for non CONFIG_ACPI builds, which would otherwise cause a build failure. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Acked-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-21 18:50:20 +01:00
device property: Add fwnode_handle_get() fwnode_handle_get() is used to obtain a reference to a fwnode_handle container. In this case this is OF specific struct device_node. This complements fwnode_handle_put() which is already implemented. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:22 +03:00
device property: Make fwnode_handle_get() return the fwnode The fwnode_handle_get() function is used to obtain a reference to an fwnode. A common usage pattern for the OF equivalent of the function is: mynode = of_node_get(node); Similarly make fwnode_handle_get() return the fwnode to which the reference was obtained. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-09-19 12:39:11 +03:00
device property: Add fwnode_handle_get() fwnode_handle_get() is used to obtain a reference to a fwnode_handle container. In this case this is OF specific struct device_node. This complements fwnode_handle_put() which is already implemented. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:22 +03:00
device property: Make fwnode_handle_get() return the fwnode The fwnode_handle_get() function is used to obtain a reference to an fwnode. A common usage pattern for the OF equivalent of the function is: mynode = of_node_get(node); Similarly make fwnode_handle_get() return the fwnode to which the reference was obtained. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-09-19 12:39:11 +03:00
device property: Add fwnode_handle_get() fwnode_handle_get() is used to obtain a reference to a fwnode_handle container. In this case this is OF specific struct device_node. This complements fwnode_handle_put() which is already implemented. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:22 +03:00
device property: Make fwnode_handle_get() return the fwnode The fwnode_handle_get() function is used to obtain a reference to an fwnode. A common usage pattern for the OF equivalent of the function is: mynode = of_node_get(node); Similarly make fwnode_handle_get() return the fwnode to which the reference was obtained. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-09-19 12:39:11 +03:00
device property: Add fwnode_handle_get() fwnode_handle_get() is used to obtain a reference to a fwnode_handle container. In this case this is OF specific struct device_node. This complements fwnode_handle_put() which is already implemented. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:22 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Move FW type specific functionality to FW specific files The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:37 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Introduce fwnode_device_is_available() Add fwnode_device_is_available() to tell whether the device corresponding to a certain fwnode_handle is available for use. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:39 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Introduce fwnode_device_is_available() Add fwnode_device_is_available() to tell whether the device corresponding to a certain fwnode_handle is available for use. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:39 +03:00
device property: Introduce fwnode_call_bool_op() for ops that return bool fwnode_call_int_op() isn't suitable for calling ops that return bool since it effectively causes the result returned to the user to be true when an op hasn't been defined or the fwnode is NULL. Address this by introducing fwnode_call_bool_op() for calling ops that return bool. Fixes: 3708184afc77 "device property: Move FW type specific functionality to FW specific files" Fixes: 2294b3af05e9 "device property: Introduce fwnode_device_is_available()" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-11 18:20:20 +03:00
device property: Introduce fwnode_device_is_available() Add fwnode_device_is_available() to tell whether the device corresponding to a certain fwnode_handle is available for use. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:39 +03:00
Driver core: Unified interface for firmware node properties 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: Grant Likely <grant.likely@linaro.org> 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-04 14:03:59 +01:00
device property: Introduces device_dma_is_coherent() 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: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-10 11:08:54 -05:00
device property: Adding DMA Attribute APIs for Generic Devices The function device_dma_is_coherent() does not sufficiently communicate device DMA attributes. Instead, this patch introduces device_get_dma_attr(), which returns enum dev_dma_attr. It replaces the acpi_check_dma(), which will be removed in subsequent patch. This also provides a convenient function, device_dma_supported(), to check DMA support of the specified device. Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-28 15:50:49 -07:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_phy_mode() Until now there were two almost identical functions for obtaining network PHY mode - of_get_phy_mode() and, more generic, device_get_phy_mode(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the PHY mode for children nodes in the ACPI world by introducing a new function - fwnode_get_phy_mode(). This commit also changes device_get_phy_mode() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:39 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_phy_mode() Until now there were two almost identical functions for obtaining network PHY mode - of_get_phy_mode() and, more generic, device_get_phy_mode(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the PHY mode for children nodes in the ACPI world by introducing a new function - fwnode_get_phy_mode(). This commit also changes device_get_phy_mode() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:39 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_phy_mode() Until now there were two almost identical functions for obtaining network PHY mode - of_get_phy_mode() and, more generic, device_get_phy_mode(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the PHY mode for children nodes in the ACPI world by introducing a new function - fwnode_get_phy_mode(). This commit also changes device_get_phy_mode() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:39 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_phy_mode() Until now there were two almost identical functions for obtaining network PHY mode - of_get_phy_mode() and, more generic, device_get_phy_mode(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the PHY mode for children nodes in the ACPI world by introducing a new function - fwnode_get_phy_mode(). This commit also changes device_get_phy_mode() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:39 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_phy_mode() Until now there were two almost identical functions for obtaining network PHY mode - of_get_phy_mode() and, more generic, device_get_phy_mode(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the PHY mode for children nodes in the ACPI world by introducing a new function - fwnode_get_phy_mode(). This commit also changes device_get_phy_mode() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:39 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_mac_address() Until now there were two almost identical functions for obtaining MAC address - of_get_mac_address() and, more generic, device_get_mac_address(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the MAC address for children nodes in the ACPI world by introducing a new function - fwnode_get_mac_address(). This commit also changes device_get_mac_address() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:38 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_mac_address() Until now there were two almost identical functions for obtaining MAC address - of_get_mac_address() and, more generic, device_get_mac_address(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the MAC address for children nodes in the ACPI world by introducing a new function - fwnode_get_mac_address(). This commit also changes device_get_mac_address() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:38 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Add ETH_ALEN check, update comments. This patch adds MAC address length check back into the device_get_mac_addr() function before calling is_valid_ether_addr() similar to the way the OF routine does it. Update the comments for the two new functions. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-19 11:46:42 -05:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_mac_address() Until now there were two almost identical functions for obtaining MAC address - of_get_mac_address() and, more generic, device_get_mac_address(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the MAC address for children nodes in the ACPI world by introducing a new function - fwnode_get_mac_address(). This commit also changes device_get_mac_address() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:38 +01:00
device property: Add ETH_ALEN check, update comments. This patch adds MAC address length check back into the device_get_mac_addr() function before calling is_valid_ether_addr() similar to the way the OF routine does it. Update the comments for the two new functions. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-19 11:46:42 -05:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Add ETH_ALEN check, update comments. This patch adds MAC address length check back into the device_get_mac_addr() function before calling is_valid_ether_addr() similar to the way the OF routine does it. Update the comments for the two new functions. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-19 11:46:42 -05:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_mac_address() Until now there were two almost identical functions for obtaining MAC address - of_get_mac_address() and, more generic, device_get_mac_address(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the MAC address for children nodes in the ACPI world by introducing a new function - fwnode_get_mac_address(). This commit also changes device_get_mac_address() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:38 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Don't overwrite addr when failing in device_get_mac_address The function device_get_mac_address is trying different property names in order to get the mac address. To check the return value, the variable addr (which contain the buffer pass by the caller) will be re-used. This means that if the previous property is not found, the next property will be read using a NULL buffer. Therefore it's only possible to retrieve the mac if node contains a property "mac-address". Fix it by using a temporary buffer for the return value. This has been introduced by commit 4c96b7dc0d393f12c17e0d81db15aa4a820a6ab3 "Add a matching set of device_ functions for determining mac/phy" Signed-off-by: Julien Grall <julien.grall@citrix.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: David S. Miller <davem@davemloft.net> Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-03 23:59:50 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_mac_address() Until now there were two almost identical functions for obtaining MAC address - of_get_mac_address() and, more generic, device_get_mac_address(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the MAC address for children nodes in the ACPI world by introducing a new function - fwnode_get_mac_address(). This commit also changes device_get_mac_address() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:38 +01:00
device property: Don't overwrite addr when failing in device_get_mac_address The function device_get_mac_address is trying different property names in order to get the mac address. To check the return value, the variable addr (which contain the buffer pass by the caller) will be re-used. This means that if the previous property is not found, the next property will be read using a NULL buffer. Therefore it's only possible to retrieve the mac if node contains a property "mac-address". Fix it by using a temporary buffer for the return value. This has been introduced by commit 4c96b7dc0d393f12c17e0d81db15aa4a820a6ab3 "Add a matching set of device_ functions for determining mac/phy" Signed-off-by: Julien Grall <julien.grall@citrix.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: David S. Miller <davem@davemloft.net> Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-03 23:59:50 +01:00
device property: Introduce fwnode_get_mac_address() Until now there were two almost identical functions for obtaining MAC address - of_get_mac_address() and, more generic, device_get_mac_address(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the MAC address for children nodes in the ACPI world by introducing a new function - fwnode_get_mac_address(). This commit also changes device_get_mac_address() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:38 +01:00
device property: Don't overwrite addr when failing in device_get_mac_address The function device_get_mac_address is trying different property names in order to get the mac address. To check the return value, the variable addr (which contain the buffer pass by the caller) will be re-used. This means that if the previous property is not found, the next property will be read using a NULL buffer. Therefore it's only possible to retrieve the mac if node contains a property "mac-address". Fix it by using a temporary buffer for the return value. This has been introduced by commit 4c96b7dc0d393f12c17e0d81db15aa4a820a6ab3 "Add a matching set of device_ functions for determining mac/phy" Signed-off-by: Julien Grall <julien.grall@citrix.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: David S. Miller <davem@davemloft.net> Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-09-03 23:59:50 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Introduce fwnode_get_mac_address() Until now there were two almost identical functions for obtaining MAC address - of_get_mac_address() and, more generic, device_get_mac_address(). However it is not uncommon, that the network interface is represented as a child of the actual controller, hence it is not associated directly to any struct device, required by the latter routine. This commit allows for getting the MAC address for children nodes in the ACPI world by introducing a new function - fwnode_get_mac_address(). This commit also changes device_get_mac_address() routine to be its wrapper, in order to prevent unnecessary duplication. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:38 +01:00
Add a matching set of device_ functions for determining mac/phy 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: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-12 17:06:26 -05:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Introduce fwnode_irq_get() Until now there were two very similar functions allowing to get Linux IRQ number from ACPI handle (acpi_irq_get()) and OF node (of_irq_get()). The first one appeared to be used only as a subroutine of platform_irq_get(), which (in the generic code) limited IRQ obtaining from _CRS method only to nodes associated to kernel's struct platform_device. This patch introduces a new helper routine - fwnode_irq_get(), which allows to get the IRQ number directly from the fwnode to be used as common for OF/ACPI worlds. It is usable not only for the parents fwnodes, but also for the child nodes comprising their own _CRS methods with interrupts description. In order to be able o satisfy compilation with !CONFIG_ACPI and also simplify the new code, introduce a helper macro (ACPI_HANDLE_FWNODE), with which it is possible to reach an ACPI handle directly from its fwnode. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18 13:31:40 +01:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Add fwnode_graph_get_port_parent Provide a helper to obtain the parent device fwnode without first parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:41 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add fwnode_graph_get_port_parent Provide a helper to obtain the parent device fwnode without first parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:41 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Add fwnode_graph_get_port_parent Provide a helper to obtain the parent device fwnode without first parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:41 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Add fwnode_graph_get_port_parent Provide a helper to obtain the parent device fwnode without first parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:41 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Add fwnode_graph_get_port_parent Provide a helper to obtain the parent device fwnode without first parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:41 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Add support for remote endpoints This follows DT implementation of of_graph_* APIs but we call them fwnode_graph_* instead. For DT nodes the existing of_graph_* implementation will be used. For ACPI we use the new ACPI graph implementation instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:21 +03:00
device property: Add support for fwnode endpoints Similar to OF endpoints, endpoint type nodes can be also supported on ACPI. In order to make it possible for drivers to ignore the matter, add a type for fwnode_endpoint and a function to parse them. On ACPI, find the child node index instead of relying on the "endpoint" property. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:25 +03:00
device property: Add FW type agnostic fwnode_graph_get_remote_node Add fwnode_graph_get_remote_node() function which is equivalent to of_graph_get_remote_node() on OF. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:40 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add FW type agnostic fwnode_graph_get_remote_node Add fwnode_graph_get_remote_node() function which is equivalent to of_graph_get_remote_node() on OF. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:40 +03:00
device property: Add support for fwnode endpoints Similar to OF endpoints, endpoint type nodes can be also supported on ACPI. In order to make it possible for drivers to ignore the matter, add a type for fwnode_endpoint and a function to parse them. On ACPI, find the child node index instead of relying on the "endpoint" property. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:25 +03:00
device property: Constify fwnode property API Make fwnode arguments to the fwnode property API const. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-21 14:39:36 +03:00
device property: Add support for fwnode endpoints Similar to OF endpoints, endpoint type nodes can be also supported on ACPI. In order to make it possible for drivers to ignore the matter, add a type for fwnode_endpoint and a function to parse them. On ACPI, find the child node index instead of relying on the "endpoint" property. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:25 +03:00
device property: Move fwnode graph ops to firmware specific locations Move firmware specific implementations of the fwnode graph operations to firmware specific locations. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-06 12:37:38 +03:00
device property: Add support for fwnode endpoints Similar to OF endpoints, endpoint type nodes can be also supported on ACPI. In order to make it possible for drivers to ignore the matter, add a type for fwnode_endpoint and a function to parse them. On ACPI, find the child node index instead of relying on the "endpoint" property. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-03-28 10:52:25 +03:00
device property: Introduce a common API to fetch device match data There is an OF/ACPI function to obtain the driver data. We want to hide OF/ACPI details from the device drivers and abstract following the device family of functions. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-12-13 02:20:49 -05:00
device property: Constify device_get_match_data() Constify device_get_match_data() as OF and ACPI variants return constant value. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> 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>
2018-02-09 17:38:36 +02:00
device property: Introduce a common API to fetch device match data There is an OF/ACPI function to obtain the driver data. We want to hide OF/ACPI details from the device drivers and abstract following the device family of functions. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-12-13 02:20:49 -05:00
device property: Constify device_get_match_data() Constify device_get_match_data() as OF and ACPI variants return constant value. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> 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>
2018-02-09 17:38:36 +02:00
device property: Introduce a common API to fetch device match data There is an OF/ACPI function to obtain the driver data. We want to hide OF/ACPI details from the device drivers and abstract following the device family of functions. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-12-13 02:20:49 -05:00