12 Oct, 2017
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
10 Oct, 2017
1 commit
-
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+ # 4.9+
Signed-off-by: Jarkko Nikula
Signed-off-by: Rafael J. Wysocki
22 Jul, 2017
4 commits
-
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
Signed-off-by: Rafael J. Wysocki -
Make fwnode arguments to the fwnode property API const.
Signed-off-by: Sakari Ailus
Reviewed-by: Rob Herring
Signed-off-by: Rafael J. Wysocki -
Internally constify pset fwnode backend. Do not touch the pset fwnode
operations yet.Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
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 and2. 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
Signed-off-by: Sakari Ailus
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
12 Jul, 2017
1 commit
-
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
Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki
22 Jun, 2017
5 commits
-
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
Signed-off-by: Sakari Ailus
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
Add fwnode_graph_get_remote_node() function which is equivalent to
of_graph_get_remote_node() on OF.Signed-off-by: Sakari Ailus
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
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
Reviewed-by: Mika Westerberg
Acked-by: Rob Herring
Signed-off-by: Rafael J. Wysocki -
Move firmware specific implementations of the fwnode graph operations to
firmware specific locations.Signed-off-by: Sakari Ailus
Reviewed-by: Mika Westerberg
Acked-by: Rob Herring
Signed-off-by: Rafael J. Wysocki -
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
Reviewed-by: Mika Westerberg
Acked-by: Rob Herring
Signed-off-by: Rafael J. Wysocki
30 Mar, 2017
1 commit
-
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
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
29 Mar, 2017
11 commits
-
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
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
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
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
fwnode_property_read_string_array() may return -EILSEQ through
of_property_read_string_array(). Document this.Signed-off-by: Sakari Ailus
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
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
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
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
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
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
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
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
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Rafael J. Wysocki
07 Feb, 2017
3 commits
-
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
Signed-off-by: Rafael J. Wysocki -
Data that is fed into property arrays should not be modified, so let's mark
relevant pointers as const. This will allow us making source arrays as
const/__initconst.Signed-off-by: Dmitry Torokhov
Signed-off-by: Rafael J. Wysocki -
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
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
26 Jun, 2016
1 commit
-
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
Acked-by: Sathyanarayana Nujella
Acked-by: Rob Herring
Acked-by: Rafael J. Wysocki
Signed-off-by: Mark Brown
07 May, 2016
1 commit
28 Apr, 2016
1 commit
-
Since fwnode may hold ERR_PTR(-ENODEV) or it may be NULL,
the fwnode type checks is_of_node(), is_acpi_node() and is
is_pset_node() need to consider it. Using IS_ERR_OR_NULL()
to check it.Fixes: 0d67e0fa1664 (device property: fix for a case of use-after-free)
Reported-by: Dan Carpenter
Signed-off-by: Heikki Krogerus
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki
09 Apr, 2016
1 commit
-
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
Reviewed-by: Mika Westerberg
Acked-by: Thierry Reding
Acked-by: Lee Jones
Signed-off-by: Heikki Krogerus
Signed-off-by: Rafael J. Wysocki
18 Mar, 2016
1 commit
-
The new helper returns index of the mathing string in an array. We
would use it here.Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Mar, 2016
1 commit
-
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
Signed-off-by: Heikki Krogerus
Signed-off-by: Rafael J. Wysocki
09 Mar, 2016
1 commit
-
This fixes BUG triggered when fwnode->secondary is not NULL,
but has ERR_PTR(-ENODEV) instead.BUG: unable to handle kernel paging request at ffffffffffffffed
IP: [] __fwnode_property_read_string+0x26/0x160
PGD 200e067 PUD 2010067 PMD 0
Oops: 0000 [#1] SMP KASAN
Modules linked in: dwc3_pci(+) dwc3
CPU: 0 PID: 1138 Comm: modprobe Not tainted 4.5.0-rc5+ #61
task: ffff88015aaf5b00 ti: ffff88007b958000 task.ti: ffff88007b958000
RIP: 0010:[] [] __fwnode_property_read_string+0x26/0x160
RSP: 0018:ffff88007b95eff8 EFLAGS: 00010246
RAX: fffffbfffffffffd RBX: ffffffffffffffed RCX: ffff88015999cd37
RDX: dffffc0000000000 RSI: ffffffff81e11bc0 RDI: ffffffffffffffed
RBP: ffff88007b95f020 R08: 0000000000000000 R09: 0000000000000000
R10: ffff88007b90f7cf R11: 0000000000000000 R12: ffff88007b95f0a0
R13: 00000000fffffffa R14: ffffffff81e11bc0 R15: ffff880159ea37a0
FS: 00007ff35f46c700(0000) GS:ffff88015b800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffffffffffed CR3: 000000007b8be000 CR4: 00000000001006f0
Stack:
ffff88015999cd20 ffffffff81e11bc0 ffff88007b95f0a0 ffff88007b383dd8
ffff880159ea37a0 ffff88007b95f048 ffffffff81677d03 ffff88007b952460
ffffffff81e11bc0 ffff88007b95f0a0 ffff88007b95f070 ffffffff81677d40
Call Trace:
[] fwnode_property_read_string+0x43/0x50
[] device_property_read_string+0x30/0x40
...Fixes: 362c0b30249e (device property: Fallback to secondary fwnode if primary misses the property)
Signed-off-by: Heikki Krogerus
Signed-off-by: Rafael J. Wysocki
01 Jan, 2016
2 commits
-
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
Signed-off-by: Rafael J. Wysocki -
This fixes NULL pointer dereference when the primary fwnode handle
does not exist, for example with PCI devices that do not have ACPI
companion.Signed-off-by: Heikki Krogerus
Signed-off-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
07 Dec, 2015
4 commits
-
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
Signed-off-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki -
There is no functional change.
Signed-off-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Rafael J. Wysocki