[PATCH] software node: allow referencing software nodes by name

[PATCH] software node: allow referencing software nodes by name

[Dmitry Torokhov]

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

Re: [PATCH] software node: allow referencing software nodes by name

[Greg Kroah-Hartman]

On Mon, Mar 23, 2026 at 09:46:50PM -0700, Dmitry Torokhov wrote:
> 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(-)

Do you have a follow-on patch that uses this new api anywhere?

thanks,

greg k-h

Re: [PATCH] software node: allow referencing software nodes by name

[Bartosz Golaszewski]

On Tue, 24 Mar 2026 05:46:50 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
> 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).
>

For context: this is a follow up to the discussion we had under my alternative
proposal[1]. This should ba an [RFC] too I think.

Probably unsurprisingly, but I'd like to express my opposition to this idea.
The final decision is not mine to make and we have yet to hear from the swnode
and driver core maintainers but I'll present a couple arguments in favor of the
tighter coupling.

> 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.
>

In my first proposal I did in fact create a header and put the software node
definitions in the pinctrl drivers. Andy pointed out, the software nodes should
live inside the android tablet drivers that rely on them and not in the pinctrl
drivers where they would be attached on all the platforms, not only the tiny
number of the ones that need them. I agree with this and plan on changing that
in my v2.

We also discussed the possibility of returning -EPROBE_DEFER if we resolve
a reference to a remote software node that has not yet been registered as
a firmware node[2] as it's a situation similar to a firmware node for which
no device exists yet.

With the above changes to my series, the problems of link order disappear and
we can create real links at build-time with no need to set names of software
nodes (which are typically not required and only used to display them in sysfs,
unless someone uses them for matching the swnodes to devices that is :) ).

IOW: for v2 of my[1] series I propose to put swnode back into the android
tablets drivers but still use the mechanism that will either wait for the
relevant platform device to appear or look up the matching ACPI node. If the
driver tries to resolve the reference before the software node is registered,
it will simply defer probe, though if we can use the ACPI node and not wait
for the platform device, the registration will have typically happened before
the driver even gets registered.

> 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.
>

And it also limits the ways we can match real firmware nodes to their
complementary and puts that limitation into the very driver core. For my v2,
I'd like to propose additional mechanisms for such matching like looking up
the correct ACPI and OF nodes and using unnamed software nodes.

> 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.
>

I don't think this should happen in core software node code. The -ENOENT
should be interpreted by whatever subsystem tries to resolve the reference.

> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---

I think that with a few changes to the initial idea, referencing software
nodes by their addresses is the way to go. Keep in mind that this is also
quite the corner-case. In other places we have been typically able to easily
assign the software node to their target fwnode as it would be either a legacy
board file or an MFD driver which already knows its cells' layout and
dependencies.

Thanks,
Bartosz

[1] https://lore.kernel.org/all/20260319-baytrail-real-swnode-v1-0-75f2264ae49f@oss.qualcomm.com/
[2] https://lore.kernel.org/all/CAMRc=MdmuOS-5mHGYtsr3jz654rA9moH4Po_rAFdaPBq-5KCZA@mail.gmail.com/

Re: [PATCH] software node: allow referencing software nodes by name

[Dmitry Torokhov]

On Tue, Mar 24, 2026 at 08:59:24AM +0100, Greg Kroah-Hartman wrote:
> 
> Do you have a follow-on patch that uses this new api anywhere?
> 

It will look like this (obviously split in 2 patches):

diff --git a/arch/x86/platform/geode/geode-common.c b/arch/x86/platform/geode/geode-common.c
index 05189c5f7d2a..ae43ca2ba4ec 100644
--- a/arch/x86/platform/geode/geode-common.c
+++ b/arch/x86/platform/geode/geode-common.c
@@ -14,10 +14,6 @@
 
 #include "geode-common.h"
 
-static const struct software_node geode_gpiochip_node = {
-	.name = "cs5535-gpio",
-};
-
 static const struct property_entry geode_gpio_keys_props[] = {
 	PROPERTY_ENTRY_U32("poll-interval", 20),
 	{ }
@@ -42,7 +38,6 @@ static const struct software_node geode_restart_key_node = {
 };
 
 static const struct software_node *geode_gpio_keys_swnodes[] __initconst = {
-	&geode_gpiochip_node,
 	&geode_gpio_keys_node,
 	&geode_restart_key_node,
 	NULL
@@ -50,10 +45,6 @@ static const struct software_node *geode_gpio_keys_swnodes[] __initconst = {
 
 /*
  * Creates gpio-keys-polled device for the restart key.
- *
- * Note that it needs to be called first, before geode_create_leds(),
- * because it registers gpiochip software node used by both gpio-keys and
- * leds-gpio devices.
  */
 int __init geode_create_restart_key(unsigned int pin)
 {
@@ -64,8 +55,7 @@ int __init geode_create_restart_key(unsigned int pin)
 	struct platform_device *pd;
 	int err;
 
-	geode_restart_key_props[0] = PROPERTY_ENTRY_GPIO("gpios",
-							 &geode_gpiochip_node,
+	geode_restart_key_props[0] = PROPERTY_ENTRY_GPIO("gpios", "cs5535-gpio",
 							 pin, GPIO_ACTIVE_LOW);
 
 	err = software_node_register_node_group(geode_gpio_keys_swnodes);
@@ -136,7 +126,7 @@ int __init geode_create_leds(const char *label, const struct geode_led *leds,
 		}
 
 		props[i * 3 + 0] =
-			PROPERTY_ENTRY_GPIO("gpios", &geode_gpiochip_node,
+			PROPERTY_ENTRY_GPIO("gpios", "cs5535-gpio",
 					    leds[i].pin, GPIO_ACTIVE_LOW);
 		props[i * 3 + 1] =
 			PROPERTY_ENTRY_STRING("linux,default-trigger",
diff --git a/drivers/mfd/cs5535-mfd.c b/drivers/mfd/cs5535-mfd.c
index d0fb2e52ee76..6941e124e87f 100644
--- a/drivers/mfd/cs5535-mfd.c
+++ b/drivers/mfd/cs5535-mfd.c
@@ -14,6 +14,7 @@
 #include <linux/mfd/core.h>
 #include <linux/module.h>
 #include <linux/pci.h>
+#include <linux/property.h>
 #include <asm/olpc.h>
 
 #define DRV_NAME "cs5535-mfd"
@@ -29,6 +30,10 @@ enum cs5535_mfd_bars {
 
 static struct resource cs5535_mfd_resources[NR_BARS];
 
+static const struct software_node cs5535_gpiochip_node = {
+	.name = "cs5535-gpio",
+};
+
 static struct mfd_cell cs5535_mfd_cells[] = {
 	{
 		.name = "cs5535-smb",
@@ -39,6 +44,7 @@ static struct mfd_cell cs5535_mfd_cells[] = {
 		.name = "cs5535-gpio",
 		.num_resources = 1,
 		.resources = &cs5535_mfd_resources[GPIO_BAR],
+		.swnode = &cs5535_gpiochip_node,
 	},
 	{
 		.name = "cs5535-mfgpt",

Thanks.

-- 
Dmitry

Re: [PATCH] software node: allow referencing software nodes by name

[Dmitry Torokhov]

On Tue, Mar 24, 2026 at 02:46:06AM -0700, Bartosz Golaszewski wrote:
> On Tue, 24 Mar 2026 05:46:50 +0100, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> said:
> > 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).
> >
> 
> For context: this is a follow up to the discussion we had under my alternative
> proposal[1]. This should ba an [RFC] too I think.
> 
> Probably unsurprisingly, but I'd like to express my opposition to this idea.
> The final decision is not mine to make and we have yet to hear from the swnode
> and driver core maintainers but I'll present a couple arguments in favor of the
> tighter coupling.
> 
> > 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.
> >
> 
> In my first proposal I did in fact create a header and put the software node
> definitions in the pinctrl drivers. Andy pointed out, the software nodes should
> live inside the android tablet drivers that rely on them and not in the pinctrl
> drivers where they would be attached on all the platforms, not only the tiny
> number of the ones that need them. I agree with this and plan on changing that
> in my v2.
> 
> We also discussed the possibility of returning -EPROBE_DEFER if we resolve
> a reference to a remote software node that has not yet been registered as
> a firmware node[2] as it's a situation similar to a firmware node for which
> no device exists yet.
> 
> With the above changes to my series, the problems of link order disappear and
> we can create real links at build-time with no need to set names of software
> nodes (which are typically not required and only used to display them in sysfs,
> unless someone uses them for matching the swnodes to devices that is :) ).

But having them is strongly encouraged anyways.

> 
> IOW: for v2 of my[1] series I propose to put swnode back into the android
> tablets drivers but still use the mechanism that will either wait for the
> relevant platform device to appear or look up the matching ACPI node. If the
> driver tries to resolve the reference before the software node is registered,
> it will simply defer probe, though if we can use the ACPI node and not wait
> for the platform device, the registration will have typically happened before
> the driver even gets registered.

Please post the reworked version so we can review all the details. My
concern was that it relies on notifier chains to notify when devices
get registered and unregistered, and instead of matching node names you
now need to somehow match device instances and software node instances,
which again likely is done based on some name. This just piles on
complexity where a simpler solution would be sufficient.

I think this approach also will give trouble when there are multiple
users of GPIOs provided by the same gpiochip, in cases where users are
split across multiple modules.

> 
> > 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.
> >
> 
> And it also limits the ways we can match real firmware nodes to their

It does not limit, it only provides additional opportunity when a simple
case is enough. We are not replacing seoftware node instance in the
reference with name, we allow using either, depending on user's wishes.
So it does not preclude also having the mechanism that you propose when
you need more complex management.

> complementary and puts that limitation into the very driver core. For my v2,
> I'd like to propose additional mechanisms for such matching like looking up
> the correct ACPI and OF nodes and using unnamed software nodes.
> 
> > 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.
> >
> 
> I don't think this should happen in core software node code. The -ENOENT
> should be interpreted by whatever subsystem tries to resolve the reference.

OK, I am fine with making it a subsystem's decision.

Thanks.

-- 
Dmitry

Re: [PATCH] software node: allow referencing software nodes by name

[Bartosz Golaszewski]

On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Please post the reworked version so we can review all the details. My
> concern was that it relies on notifier chains to notify when devices
> get registered and unregistered, and instead of matching node names you
> now need to somehow match device instances and software node instances,
> which again likely is done based on some name. This just piles on
> complexity where a simpler solution would be sufficient.
>

I will post it. Hopefully before the end of the week. I want to cover
both OF nodes with paz00 as well as ACPI with android tablets. The
latter case will have to wait for devices because there's no way to
look up an ACPI node by name that I could idenfity (correct me if I'm
wrong).

> I think this approach also will give trouble when there are multiple
> users of GPIOs provided by the same gpiochip, in cases where users are
> split across multiple modules.
>

Do we have any such use-case? I haven't found any. If we do end up
running into this corner-case, it can still be done by centralizing
the software nodes in question. But maybe let's cross that bridge when
(and if) we get to it.

Bart

Re: [PATCH] software node: allow referencing software nodes by name

[Dmitry Torokhov]

On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Please post the reworked version so we can review all the details. My
> > concern was that it relies on notifier chains to notify when devices
> > get registered and unregistered, and instead of matching node names you
> > now need to somehow match device instances and software node instances,
> > which again likely is done based on some name. This just piles on
> > complexity where a simpler solution would be sufficient.
> >
> 
> I will post it. Hopefully before the end of the week. I want to cover
> both OF nodes with paz00 as well as ACPI with android tablets. The

For paz00 I hope Tierry will pick up my patch converting rfkill-gpio
from board file to dts.

> latter case will have to wait for devices because there's no way to
> look up an ACPI node by name that I could idenfity (correct me if I'm
> wrong).
> 
> > I think this approach also will give trouble when there are multiple
> > users of GPIOs provided by the same gpiochip, in cases where users are
> > split across multiple modules.
> >
> 
> Do we have any such use-case? I haven't found any. If we do end up
> running into this corner-case, it can still be done by centralizing
> the software nodes in question. But maybe let's cross that bridge when
> (and if) we get to it.

Android-tablet could probably use it. The gpiochip software nodes are
already consolidated there but the code could be simplified if we could
simply use names/labels.

Thanks.

-- 
Dmitry

Re: [PATCH] software node: allow referencing software nodes by name

[Andy Shevchenko]

On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Please post the reworked version so we can review all the details. My
> > concern was that it relies on notifier chains to notify when devices
> > get registered and unregistered, and instead of matching node names you
> > now need to somehow match device instances and software node instances,
> > which again likely is done based on some name. This just piles on
> > complexity where a simpler solution would be sufficient.
> 
> I will post it. Hopefully before the end of the week. I want to cover
> both OF nodes with paz00 as well as ACPI with android tablets. The
> latter case will have to wait for devices because there's no way to
> look up an ACPI node by name that I could idenfity (correct me if I'm
> wrong).

What do you need from ACPI exactly? The ACPI namespace in the OS is represented
by set of ACPI handles, each of which is the object pointing out to some object
in it. Any object in ACPI has a unique path. At any time, after parsing the
ACPI table(s) into ACPI namespace we may get a handle based on the path.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] software node: allow referencing software nodes by name

[Andy Shevchenko]

On Thu, Mar 26, 2026 at 10:27:00AM +0200, Andy Shevchenko wrote:
> On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> > On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > Please post the reworked version so we can review all the details. My
> > > concern was that it relies on notifier chains to notify when devices
> > > get registered and unregistered, and instead of matching node names you
> > > now need to somehow match device instances and software node instances,
> > > which again likely is done based on some name. This just piles on
> > > complexity where a simpler solution would be sufficient.
> > 
> > I will post it. Hopefully before the end of the week. I want to cover
> > both OF nodes with paz00 as well as ACPI with android tablets. The
> > latter case will have to wait for devices because there's no way to
> > look up an ACPI node by name that I could idenfity (correct me if I'm
> > wrong).
> 
> What do you need from ACPI exactly? The ACPI namespace in the OS is represented
> by set of ACPI handles, each of which is the object pointing out to some object

"...which is the pointer..."
(sorry for the possible confusion)

> in it. Any object in ACPI has a unique path. At any time, after parsing the
> ACPI table(s) into ACPI namespace we may get a handle based on the path.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] software node: allow referencing software nodes by name

[Bartosz Golaszewski]

On Thu, Mar 26, 2026 at 9:27 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> > On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > Please post the reworked version so we can review all the details. My
> > > concern was that it relies on notifier chains to notify when devices
> > > get registered and unregistered, and instead of matching node names you
> > > now need to somehow match device instances and software node instances,
> > > which again likely is done based on some name. This just piles on
> > > complexity where a simpler solution would be sufficient.
> >
> > I will post it. Hopefully before the end of the week. I want to cover
> > both OF nodes with paz00 as well as ACPI with android tablets. The
> > latter case will have to wait for devices because there's no way to
> > look up an ACPI node by name that I could idenfity (correct me if I'm
> > wrong).
>
> What do you need from ACPI exactly? The ACPI namespace in the OS is represented
> by set of ACPI handles, each of which is the object pointing out to some object
> in it. Any object in ACPI has a unique path. At any time, after parsing the
> ACPI table(s) into ACPI namespace we may get a handle based on the path.
>

DT is unflattened very early into the boot sequence. Is this the case
for ACPI tables as well? Knowing the name of the device (HID + index,
eg.: "INT33FF:00"), can I check if there's a corresponding ACPI node
(of_find_by_path/name() in DT parlance)?

Bart

Re: [PATCH] software node: allow referencing software nodes by name

[Andy Shevchenko]

On Thu, Mar 26, 2026 at 09:34:01AM +0100, Bartosz Golaszewski wrote:
> On Thu, Mar 26, 2026 at 9:27 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> > > On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> > > <dmitry.torokhov@gmail.com> wrote:
> > > >
> > > > Please post the reworked version so we can review all the details. My
> > > > concern was that it relies on notifier chains to notify when devices
> > > > get registered and unregistered, and instead of matching node names you
> > > > now need to somehow match device instances and software node instances,
> > > > which again likely is done based on some name. This just piles on
> > > > complexity where a simpler solution would be sufficient.
> > >
> > > I will post it. Hopefully before the end of the week. I want to cover
> > > both OF nodes with paz00 as well as ACPI with android tablets. The
> > > latter case will have to wait for devices because there's no way to
> > > look up an ACPI node by name that I could idenfity (correct me if I'm
> > > wrong).
> >
> > What do you need from ACPI exactly? The ACPI namespace in the OS is represented
> > by set of ACPI handles, each of which is the object pointing out to some object
> > in it. Any object in ACPI has a unique path. At any time, after parsing the
> > ACPI table(s) into ACPI namespace we may get a handle based on the path.
> 
> DT is unflattened very early into the boot sequence. Is this the case
> for ACPI tables as well? Knowing the name of the device (HID + index,
> eg.: "INT33FF:00"), can I check if there's a corresponding ACPI node
> (of_find_by_path/name() in DT parlance)?

I believe so. See how we find a GPIO chip in the gpiolib-acpi-core.c.
In the similar way you can try finding any object in ACPI namespace.

But note, ":00" is part of device instance name, it's not available
in ACPI namespace. There we have HID, UID, et cetera, ":00" is pure
Linux kernel thingy.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] software node: allow referencing software nodes by name

[Bartosz Golaszewski]

On Thu, Mar 26, 2026 at 9:39 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Mar 26, 2026 at 09:34:01AM +0100, Bartosz Golaszewski wrote:
> > On Thu, Mar 26, 2026 at 9:27 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> > > > On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > > >
> > > > > Please post the reworked version so we can review all the details. My
> > > > > concern was that it relies on notifier chains to notify when devices
> > > > > get registered and unregistered, and instead of matching node names you
> > > > > now need to somehow match device instances and software node instances,
> > > > > which again likely is done based on some name. This just piles on
> > > > > complexity where a simpler solution would be sufficient.
> > > >
> > > > I will post it. Hopefully before the end of the week. I want to cover
> > > > both OF nodes with paz00 as well as ACPI with android tablets. The
> > > > latter case will have to wait for devices because there's no way to
> > > > look up an ACPI node by name that I could idenfity (correct me if I'm
> > > > wrong).
> > >
> > > What do you need from ACPI exactly? The ACPI namespace in the OS is represented
> > > by set of ACPI handles, each of which is the object pointing out to some object
> > > in it. Any object in ACPI has a unique path. At any time, after parsing the
> > > ACPI table(s) into ACPI namespace we may get a handle based on the path.
> >
> > DT is unflattened very early into the boot sequence. Is this the case
> > for ACPI tables as well? Knowing the name of the device (HID + index,
> > eg.: "INT33FF:00"), can I check if there's a corresponding ACPI node
> > (of_find_by_path/name() in DT parlance)?
>
> I believe so. See how we find a GPIO chip in the gpiolib-acpi-core.c.
> In the similar way you can try finding any object in ACPI namespace.
>
> But note, ":00" is part of device instance name, it's not available
> in ACPI namespace. There we have HID, UID, et cetera, ":00" is pure
> Linux kernel thingy.
>

And how would the four instances of the cherryview pin controller be
identified in ACPI? I've just created a dumy table with a single
device, I don't know ACPI very well. Could you post an example .dsl
here for testing?

Bartosz

Re: [PATCH] software node: allow referencing software nodes by name

[Andy Shevchenko]

On Thu, Mar 26, 2026 at 10:39:09AM +0200, Andy Shevchenko wrote:
> On Thu, Mar 26, 2026 at 09:34:01AM +0100, Bartosz Golaszewski wrote:
> > On Thu, Mar 26, 2026 at 9:27 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> > > > On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > > >
> > > > > Please post the reworked version so we can review all the details. My
> > > > > concern was that it relies on notifier chains to notify when devices
> > > > > get registered and unregistered, and instead of matching node names you
> > > > > now need to somehow match device instances and software node instances,
> > > > > which again likely is done based on some name. This just piles on
> > > > > complexity where a simpler solution would be sufficient.
> > > >
> > > > I will post it. Hopefully before the end of the week. I want to cover
> > > > both OF nodes with paz00 as well as ACPI with android tablets. The
> > > > latter case will have to wait for devices because there's no way to
> > > > look up an ACPI node by name that I could idenfity (correct me if I'm
> > > > wrong).
> > >
> > > What do you need from ACPI exactly? The ACPI namespace in the OS is represented
> > > by set of ACPI handles, each of which is the object pointing out to some object
> > > in it. Any object in ACPI has a unique path. At any time, after parsing the
> > > ACPI table(s) into ACPI namespace we may get a handle based on the path.
> > 
> > DT is unflattened very early into the boot sequence. Is this the case
> > for ACPI tables as well? Knowing the name of the device (HID + index,
> > eg.: "INT33FF:00"), can I check if there's a corresponding ACPI node
> > (of_find_by_path/name() in DT parlance)?
> 
> I believe so. See how we find a GPIO chip in the gpiolib-acpi-core.c.
> In the similar way you can try finding any object in ACPI namespace.
> 
> But note, ":00" is part of device instance name, it's not available
> in ACPI namespace. There we have HID, UID, et cetera, ":00" is pure
> Linux kernel thingy.

We have acpi_dev_present(), but if you read its kernel-doc, it suggests
to use acpi_get_devices() for the case of early checks (before device
are actually being instantiated).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] software node: allow referencing software nodes by name

[Andy Shevchenko]

On Thu, Mar 26, 2026 at 09:47:03AM +0100, Bartosz Golaszewski wrote:
> On Thu, Mar 26, 2026 at 9:39 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Mar 26, 2026 at 09:34:01AM +0100, Bartosz Golaszewski wrote:
> > > On Thu, Mar 26, 2026 at 9:27 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> > > > > On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> > > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > >
> > > > > > Please post the reworked version so we can review all the details. My
> > > > > > concern was that it relies on notifier chains to notify when devices
> > > > > > get registered and unregistered, and instead of matching node names you
> > > > > > now need to somehow match device instances and software node instances,
> > > > > > which again likely is done based on some name. This just piles on
> > > > > > complexity where a simpler solution would be sufficient.
> > > > >
> > > > > I will post it. Hopefully before the end of the week. I want to cover
> > > > > both OF nodes with paz00 as well as ACPI with android tablets. The
> > > > > latter case will have to wait for devices because there's no way to
> > > > > look up an ACPI node by name that I could idenfity (correct me if I'm
> > > > > wrong).
> > > >
> > > > What do you need from ACPI exactly? The ACPI namespace in the OS is represented
> > > > by set of ACPI handles, each of which is the object pointing out to some object
> > > > in it. Any object in ACPI has a unique path. At any time, after parsing the
> > > > ACPI table(s) into ACPI namespace we may get a handle based on the path.
> > >
> > > DT is unflattened very early into the boot sequence. Is this the case
> > > for ACPI tables as well? Knowing the name of the device (HID + index,
> > > eg.: "INT33FF:00"), can I check if there's a corresponding ACPI node
> > > (of_find_by_path/name() in DT parlance)?
> >
> > I believe so. See how we find a GPIO chip in the gpiolib-acpi-core.c.
> > In the similar way you can try finding any object in ACPI namespace.
> >
> > But note, ":00" is part of device instance name, it's not available
> > in ACPI namespace. There we have HID, UID, et cetera, ":00" is pure
> > Linux kernel thingy.
> 
> And how would the four instances of the cherryview pin controller be
> identified in ACPI? I've just created a dumy table with a single
> device, I don't know ACPI very well. Could you post an example .dsl
> here for testing?

They are identified in the driver by using HID + UID combination:

https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/pinctrl/intel/pinctrl-cherryview.c#L1757

https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/pinctrl/intel/pinctrl-cherryview.c#L273
https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/pinctrl/intel/pinctrl-cherryview.c#L367
https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/pinctrl/intel/pinctrl-cherryview.c#L412
https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/pinctrl/intel/pinctrl-cherryview.c#L412

In ASL it will be something like

	Device (GPO1) {
		Name (_HID, "INT33FF")
		Name (_UID, "1")
	}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] software node: allow referencing software nodes by name

[Bartosz Golaszewski]

On Thu, Mar 26, 2026 at 9:48 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Mar 26, 2026 at 10:39:09AM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 26, 2026 at 09:34:01AM +0100, Bartosz Golaszewski wrote:
> > > On Thu, Mar 26, 2026 at 9:27 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Wed, Mar 25, 2026 at 05:32:06PM +0100, Bartosz Golaszewski wrote:
> > > > > On Tue, Mar 24, 2026 at 8:30 PM Dmitry Torokhov
> > > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > >
> > > > > > Please post the reworked version so we can review all the details. My
> > > > > > concern was that it relies on notifier chains to notify when devices
> > > > > > get registered and unregistered, and instead of matching node names you
> > > > > > now need to somehow match device instances and software node instances,
> > > > > > which again likely is done based on some name. This just piles on
> > > > > > complexity where a simpler solution would be sufficient.
> > > > >
> > > > > I will post it. Hopefully before the end of the week. I want to cover
> > > > > both OF nodes with paz00 as well as ACPI with android tablets. The
> > > > > latter case will have to wait for devices because there's no way to
> > > > > look up an ACPI node by name that I could idenfity (correct me if I'm
> > > > > wrong).
> > > >
> > > > What do you need from ACPI exactly? The ACPI namespace in the OS is represented
> > > > by set of ACPI handles, each of which is the object pointing out to some object
> > > > in it. Any object in ACPI has a unique path. At any time, after parsing the
> > > > ACPI table(s) into ACPI namespace we may get a handle based on the path.
> > >
> > > DT is unflattened very early into the boot sequence. Is this the case
> > > for ACPI tables as well? Knowing the name of the device (HID + index,
> > > eg.: "INT33FF:00"), can I check if there's a corresponding ACPI node
> > > (of_find_by_path/name() in DT parlance)?
> >
> > I believe so. See how we find a GPIO chip in the gpiolib-acpi-core.c.
> > In the similar way you can try finding any object in ACPI namespace.
> >
> > But note, ":00" is part of device instance name, it's not available
> > in ACPI namespace. There we have HID, UID, et cetera, ":00" is pure
> > Linux kernel thingy.
>
> We have acpi_dev_present(), but if you read its kernel-doc, it suggests
> to use acpi_get_devices() for the case of early checks (before device
> are actually being instantiated).
>

Ah, but I'm seeing that the firmware node handle of the acpi device is
part of struct acpi_device and is only initialized during the scanning
phase which happens at subsys_initcall() time? When using
acpi_get_devices() you have an abstract handle and no fwnode for which
to assign the secondary node yet, right?

It's not like with DT where there already is an instance of struct
device_node to which you can assign the secondary fwnode even if its
device doesn't exist yet.

Bart

Re: [PATCH] software node: allow referencing software nodes by name

[Andy Shevchenko]

On Thu, Mar 26, 2026 at 04:47:00PM +0100, Bartosz Golaszewski wrote:
> On Thu, Mar 26, 2026 at 9:48 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Mar 26, 2026 at 10:39:09AM +0200, Andy Shevchenko wrote:
> > > On Thu, Mar 26, 2026 at 09:34:01AM +0100, Bartosz Golaszewski wrote:

...

> > > I believe so. See how we find a GPIO chip in the gpiolib-acpi-core.c.
> > > In the similar way you can try finding any object in ACPI namespace.
> > >
> > > But note, ":00" is part of device instance name, it's not available
> > > in ACPI namespace. There we have HID, UID, et cetera, ":00" is pure
> > > Linux kernel thingy.
> >
> > We have acpi_dev_present(), but if you read its kernel-doc, it suggests
> > to use acpi_get_devices() for the case of early checks (before device
> > are actually being instantiated).
> 
> Ah, but I'm seeing that the firmware node handle of the acpi device is
> part of struct acpi_device and is only initialized during the scanning
> phase which happens at subsys_initcall() time?

Sounds correct. With that you can just check the device presence in the table
and maybe evaluate the status (but I'm not sure about the latter).

> When using
> acpi_get_devices() you have an abstract handle and no fwnode for which
> to assign the secondary node yet, right?

You have no fwnode concept in ACPI namespace. It's Linux thingy.
So, yes, until you have a companion device (ACPI device as object of
struct acpi_device), you have fwnode, without that device, there is
no fwnode.

> It's not like with DT where there already is an instance of struct
> device_node to which you can assign the secondary fwnode even if its
> device doesn't exist yet.

Yeah DT in this sense is available earlier because they are just
static data. ACPI needs an interpreter and hence some preparations
to be done before full access to the namespace will be available.

-- 
With Best Regards,
Andy Shevchenko