kernel/git/next/linux-next.git/drivers/base/property.c, branch master

driver core: fix typos in comments

2026-09-08T09:39:23+00:00

Fix typos in comments, reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: LLM Signed-off-by: Hemanth Selam Reviewed-by: Andy Shevchenko Acked-by: Randy Dunlap Link: https://patch.msgid.link/20260904111816.31254-1-hemanth.selam@gmail.com Signed-off-by: Danilo Krummrich

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

device property: Refactor to use RAII approach

2026-07-17T13:44:44+00:00

In a couple of functions code can be made cleaner with help of __free() macro. Refactor these to use RAII approach. Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260611203537.1786399-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

device property: fix infinite loop in fwnode_for_each_child_node()

2026-07-17T13:44:44+00:00

When iterate over children of a fwnode that has a secondary fwnode, fwnode_get_next_child_node() can enter an infinite loop if the secondary fwnode has more than one child. Parent Child (Primary fwnode) FWa: {FWa1, FWa2, FWa3} (Secondary fwnode) FWb: {FWb1, FWb2} In this case: ┌─> fwnode_get_next_child_node(FWa, FWa1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa1) returns FWa2 │ │ ... │ │ fwnode_get_next_child_node(FWa, FWa3) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa3) returns NULL │ - fwnode_call_ptr_op(FWb, get_next_child_node, FWa3) returns FWb1 │ │ fwnode_get_next_child_node(FWa, FWb1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWb1) returns FWa1 └────┘ This cause fwnode_for_each_child_node() to loop indefinitely, reapeatedly output {FWa1, FWa2, FWa3, FWb1, FWa1, ...}. The root cause is that when the current child (FWb1) belongs to the secondary fwnode, calling get_next_child_node() on the parimary fwnode incorrectly returns the first child (FWa1) again instead of NULL. Fix this by dynamically checking the parent fwnode of the current child before calling get_next_child_node(). This approach follows the pattern established in commit b5b41ab6b0c1 ("device property: Check fwnode->secondary in fwnode_graph_get_next_endpoint()"). Fixes: 2692c614f8f0 ("device property: Allow secondary lookup in fwnode_get_next_child_node()") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Tested-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Tested-by: Xu Yang Link: https://patch.msgid.link/20260611203537.1786399-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

device property: fix fwnode reference leak in fwnode_graph_get_endpoint_by_id()

2026-05-22T11:33:09+00:00

When called with FWNODE_GRAPH_ENDPOINT_NEXT, the function walks every endpoint under the requested port and, for any endpoint whose ID is greater than or equal to the requested one, may store a fwnode reference in best_ep via fwnode_handle_get(). If a later iteration finds an exact-ID match, the function returns that endpoint directly without dropping the reference held by best_ep, leaking it. Drop the saved candidate before returning the exact-match endpoint. This affects callers that use FWNODE_GRAPH_ENDPOINT_NEXT to ask for the next endpoint with ID >= the requested one (used by a number of media drivers, e.g. imx7/8, sun6i CSI, omap3isp, xilinx-csi2, stm32-csi). Each leak retains a fwnode reference until reboot/unbind. Fixes: 0fcc2bdc8aff ("device property: Add fwnode_graph_get_endpoint_by_id()") Signed-off-by: Stepan Ionichev Link: https://patch.msgid.link/20260514171455.27271-1-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'driver-core-7.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core

2026-04-19T19:58:08+00:00

Pull driver core fixes from Danilo Krummrich: - Prevent a device from being probed before device_add() has finished initializing it; gate probe with a "ready_to_probe" device flag to avoid races with concurrent driver_register() calls - Fix a kernel-doc warning for DEV_FLAG_COUNT introduced by the above - Return -ENOTCONN from software_node_get_reference_args() when a referenced software node is known but not yet registered, allowing callers to defer probe - In sysfs_group_attrs_change_owner(), also check is_visible_const(); missed when the const variant was introduced * tag 'driver-core-7.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: driver core: Add kernel-doc for DEV_FLAG_COUNT enum value sysfs: attribute_group: Respect is_visible_const() when changing owner software node: return -ENOTCONN when referenced swnode is not registered yet driver core: Don't let a device probe until it's ready

software node: return -ENOTCONN when referenced swnode is not registered yet

2026-04-11T13:57:54+00:00

It's possible that at the time of resolving a reference to a remote software node, the node we know exists is not yet registered as a full firmware node. We currently return -ENOENT in this case but the same error code is also returned in some other cases, like the reference property with given name not existing in the property list of the local software node. It makes sense to let users know that we're dealing with an unregistered software node so that they can defer probe - the situation is somewhat similar to there existing a firmware node to which no device is bound yet - which is valid grounds for probe deferral. To that end: use -ENOTCONN to indicate the software node is "not connected". Acked-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260407-swnode-unreg-retcode-v4-1-1b2f0725eb9c@oss.qualcomm.com [ Drop software node backend specifics from fwnode_property_get_reference_args() documentation. - Danilo ] Signed-off-by: Danilo Krummrich

device property: Document how to check for the property presence

2026-04-02T15:09:36+00:00

Currently it's unclear if one may or may not rely on the error codes returned from the property getters to check for the property presence. Clarify this by updating kernel-doc for fwnode_property_*() and device_property_*() where it's applicable. Reported-by: Guenter Roeck Closes: https://lore.kernel.org/r/4b24f1f4-b395-467a-81b7-1334a2d48845@roeck-us.net Signed-off-by: Andy Shevchenko Reviewed-by: Sakari Ailus Link: https://patch.msgid.link/20260318142404.2526642-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

device property: Allow secondary lookup in fwnode_get_next_child_node()

2026-02-22T23:10:31+00:00

When device_get_child_node_count() got split to the fwnode and device respective APIs, the fwnode didn't inherit the ability to traverse over the secondary fwnode. Hence any user, that switches from device to fwnode API misses this feature. In particular, this was revealed by the commit 1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()") that effectively broke the GPIO enumeration on Intel Galileo boards. Fix this by moving the secondary lookup from device to fwnode API. Note, in general no device_*() API should go into the depth of the fwnode implementation. Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary") Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Sakari Ailus Link: https://patch.msgid.link/20260210135822.47335-1-andriy.shevchenko@linux.intel.com Signed-off-by: Danilo Krummrich

ACPI: Add support for nargs_prop in acpi_fwnode_get_reference_args()

2025-09-26T01:48:47+00:00

Currently, ACPI does not support the use of a nargs_prop (e.g., associated with a reference in fwnode_property_get_reference_args(). Instead, ACPI expects the number of arguments (nargs) to be explicitly passed or known. This behavior diverges from Open Firmware (OF), which allows the use of a #*-cells property in the referenced node to determine the number of arguments. Since fwnode_property_get_reference_args() is a common interface used across both OF and ACPI firmware paradigms, it is desirable to have a unified calling convention that works seamlessly for both. Add the support for ACPI to parse a nargs_prop from the referenced fwnode, aligning its behavior with the OF backend. This allows drivers and subsystems using fwnode_property_get_reference_args() to work in a firmware-agnostic way without having to hardcode or special-case argument counts for ACPI. Acked-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Signed-off-by: Sunil V L Signed-off-by: Anup Patel Acked-by: Jassi Brar Link: https://lore.kernel.org/r/20250818040920.272664-16-apatel@ventanamicro.com Signed-off-by: Paul Walmsley