user/sven/linux.git/drivers/base/property.c, branch v4.9.74

device property: Track owner device of device property

2017-10-18T07:35:39Z

commit 5ab894aee0f171a682bcd90dd5d1930cb53c55dc upstream. 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) Signed-off-by: Jarkko Nikula Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

device property: Make dev_fwnode() public

2017-08-11T15:49:29Z

commit e44bb0cbdc88686c21e2175a990b40bf6db5d005 upstream. 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 Cc: Chris Metcalf Signed-off-by: Greg Kroah-Hartman

device property: Add function to search for named child of device

2016-06-26T11:39:03Z

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

Merge back new device properties material for v4.7.

2016-05-06T20:07:33Z

device property: Avoid potential dereferences of invalid pointers

2016-04-27T21:40:02Z

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

device property: don't bother the drivers with struct property_set

2016-04-09T01:10:50Z

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

device property: convert to use match_string() helper

2016-03-17T22:09:34Z

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

device property: fix for a case of use-after-free

2016-03-10T20:33:16Z

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

device property: fwnode->secondary may contain ERR_PTR(-ENODEV)

2016-03-09T00:07:43Z

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

device property: avoid allocations of 0 length

2016-01-01T01:09:51Z

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