From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Bartosz Golaszewski <brgl@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Danilo Krummrich <dakr@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH] software node: allow referencing software nodes by name
Date: Mon, 23 Mar 2026 21:46:50 -0700 [thread overview]
Message-ID: <acIV6xF8mY-8wd5e@google.com> (raw)
Currently static device properties references require either an
instance of software node or an instance of fwnode_handle to be
available when defining a reference property. This may not be very
convenient when device node is instantiated from a different module
(which is usually the case).
The original implementation for describing GPIOs using software nodes
worked around this by creating a detached from gpiochip instances
software nodes, and performing matching using gpiochip label and node
name. The gpiolib maintainers rightfully questioned this approach, and
currently recommend to attach secondary software node to gpiochip
instance, export the symbol, and use it in board file when instantiating
static properties. This unfortunately results in tight coupling between
gpiochip drivers and board code, necessitates creation of header files,
requires adding Kconfig dependencies, limits options for choosing module
vs built-in compilation, and alters device initialization/probing order.
Solve the issue by providing an option to use software node name in
place of the node instance when describing reference properties. When
evaluating reference driver core will attempt to resolve the name to
concrete node instance and, in case of GPIO references, will use
identity match on firmware node to locate corresponding gpiochip device.
This approach has a drawback of needing to know name of the node that
gpiochip device will be using, however benefits (minimal coupling, no
need for adding dependencies) outweigh this drawback.
To deal cases with software nodes not being created or registered at
time of look up, assume that the node with matching name will get
registered eventually and return -EPROBE_DEFER in the meantime.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/base/swnode.c | 25 +++++++++++++++++++------
include/linux/property.h | 4 ++++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 51320837f3a9..9903f252d1d6 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -510,7 +510,6 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
const struct software_node_ref_args *ref_array;
const struct software_node_ref_args *ref;
const struct property_entry *prop;
- struct fwnode_handle *refnode;
u32 nargs_prop_val;
int error;
int i;
@@ -546,12 +545,26 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
* relevant properties and bump the reference count.
*/
- if (ref->swnode)
- refnode = software_node_fwnode(ref->swnode);
- else if (ref->fwnode)
- refnode = ref->fwnode;
- else
+ struct fwnode_handle *refnode __free(fwnode_handle) = NULL;
+ if (ref->swnode) {
+ refnode = fwnode_handle_get(software_node_fwnode(ref->swnode));
+ } else if (ref->fwnode) {
+ refnode = fwnode_handle_get(ref->fwnode);
+ } else if (ref->swnode_name) {
+ const struct software_node *ref_swnode =
+ software_node_find_by_name(NULL, ref->swnode_name);
+ /*
+ * When using a name instead of a software node structure
+ * assume the node will appear at some point.
+ */
+ if (!ref_swnode)
+ return -EPROBE_DEFER;
+
+ /* Reference is already taken by software_node_find_by_name() */
+ refnode = software_node_fwnode(ref_swnode);
+ } else {
return -EINVAL;
+ }
if (!refnode)
return -ENOENT;
diff --git a/include/linux/property.h b/include/linux/property.h
index e30ef23a9af3..44e96ee47272 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -363,6 +363,7 @@ struct software_node;
struct software_node_ref_args {
const struct software_node *swnode;
struct fwnode_handle *fwnode;
+ const char *swnode_name;
unsigned int nargs;
u64 args[NR_FWNODE_REFERENCE_ARGS];
};
@@ -373,6 +374,9 @@ struct software_node_ref_args {
const struct software_node *: _ref_, \
struct software_node *: _ref_, \
default: NULL), \
+ .swnode_name = _Generic(_ref_, \
+ const char *: _ref_, \
+ default: NULL), \
.fwnode = _Generic(_ref_, \
struct fwnode_handle *: _ref_, \
default: NULL), \
--
2.53.0.1018.g2bb0e51243-goog
--
Dmitry
next reply other threads:[~2026-03-24 4:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 4:46 Dmitry Torokhov [this message]
2026-03-24 7:59 ` [PATCH] software node: allow referencing software nodes by name Greg Kroah-Hartman
2026-03-24 16:25 ` Dmitry Torokhov
2026-03-24 9:46 ` Bartosz Golaszewski
2026-03-24 19:30 ` Dmitry Torokhov
2026-03-25 16:32 ` Bartosz Golaszewski
2026-03-25 18:11 ` Dmitry Torokhov
2026-03-26 8:26 ` Andy Shevchenko
2026-03-26 8:28 ` Andy Shevchenko
2026-03-26 8:34 ` Bartosz Golaszewski
2026-03-26 8:39 ` Andy Shevchenko
2026-03-26 8:47 ` Bartosz Golaszewski
2026-03-26 9:03 ` Andy Shevchenko
2026-03-26 8:48 ` Andy Shevchenko
2026-03-26 15:47 ` Bartosz Golaszewski
2026-03-26 19:01 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acIV6xF8mY-8wd5e@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@kernel.org \
--cc=dakr@kernel.org \
--cc=djrscally@gmail.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox