[PATCH v4 0/2] driver core: make references to unregistered software nodes a special case

[PATCH v4 0/2] driver core: make references to unregistered software nodes a special case

[Bartosz Golaszewski]

I spun this out of the bigger series (see: link to v2) in hopes that we
can get it in for v7.1 and make follow-up development easier next cycle.

This series proposes to make unregistered software nodes (ones that have
an address but which have not been passed to software_node_register()
yet) a special case with its dedicated error number. This will allow
subsystems to defer probe as if it was a firmware node not backed by
a device yet.

This is done in order to allow easier attaching of software nodes to
GPIO controllers and the removal of current label name matching against
the software node's name.

The patches can be picked up independently into driver core and GPIO
trees.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v4:
- Document the new error code in fwnode_get_reference_args()
- Simplify the logic in checking the new return value in GPIO code
- Link to v3: https://patch.msgid.link/20260403-swnode-unreg-retcode-v3-0-7886092b28b4@oss.qualcomm.com

Changes in v3:
- Drop x86 changes from the series (will be resubmitted later)
- Use -ENOTCONN instead of -ENXIO to indicate unregistered software
  nodes
- Fix retval check logic in gpiolib-swnode
- Link to v2: https://patch.msgid.link/20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com

Changes in v2:
- Completely new approach
- Keep the cherryview and baytrail secondary fwnode handling as a
  driver-specific quirk for x86 tablets and don't introduce any new API
- Change the return value when resolving a reference to an unregistered
  software node and defer probe in GPIOLIB in that situation
- Export acpi_bus_type for use in x86-android-tablets
- Link to v1: https://patch.msgid.link/20260319-baytrail-real-swnode-v1-0-75f2264ae49f@oss.qualcomm.com

---
Bartosz Golaszewski (2):
      software node: return -ENOTCONN when referenced swnode is not registered yet
      gpio: swnode: defer probe on references to unregistered software nodes

 drivers/base/property.c       | 2 ++
 drivers/base/swnode.c         | 2 +-
 drivers/gpio/gpiolib-swnode.c | 8 ++++++++
 3 files changed, 11 insertions(+), 1 deletion(-)
---
base-commit: cc13002a9f984d37906e9476f3e532a8cdd126f5
change-id: 20260403-swnode-unreg-retcode-38b5b92eab28

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

[PATCH v4 1/2] software node: return -ENOTCONN when referenced swnode is not registered yet

[Bartosz Golaszewski]

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 <andy@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/base/property.c | 2 ++
 drivers/base/swnode.c   | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 8d9a34be57fbf185e639c70cc4baae4510ba70ee..51394b7d44e31d0453e9c0084bb7ddb25b14a429 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -594,6 +594,8 @@ EXPORT_SYMBOL_GPL(fwnode_property_match_property_string);
  *	    %-ENOENT when the index is out of bounds, the index has an empty
  *		     reference or the property was not found
  *	    %-EINVAL on parse error
+ *	    %-ENOTCONN when the remote firmware node is a software node that
+ *		       has not been registered as a firmware node yet
  */
 int fwnode_property_get_reference_args(const struct fwnode_handle *fwnode,
 				       const char *prop, const char *nargs_prop,
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 51320837f3a9f1bf4f65aa161d9b941affc74936..61e73417aee89feb855b0f429e112ca0af78a003 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -554,7 +554,7 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
 		return -EINVAL;
 
 	if (!refnode)
-		return -ENOENT;
+		return -ENOTCONN;
 
 	if (nargs_prop) {
 		error = fwnode_property_read_u32(refnode, nargs_prop, &nargs_prop_val);

-- 
2.47.3

[PATCH v4 2/2] gpio: swnode: defer probe on references to unregistered software nodes

[Bartosz Golaszewski]

fwnode_property_get_reference_args() now returns -ENOTCONN when called
on a software node referencing another software node which has not yet
been registered as a firmware node. It makes sense to defer probe in this
situation as the node will most likely be registered later on and we'll
be able to resolve the reference eventually. Change the behavior of
swnode_find_gpio() to return -EPROBE_DEFER if the software node reference
resolution returns -ENOTCONN.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/gpio/gpiolib-swnode.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
index 0d7f3f09a0b4bee0cf1bbdaa8b7b8ae4cd5de581..4374067f621ed782a7e1549f7b0b7e44eac04930 100644
--- a/drivers/gpio/gpiolib-swnode.c
+++ b/drivers/gpio/gpiolib-swnode.c
@@ -93,6 +93,14 @@ struct gpio_desc *swnode_find_gpio(struct fwnode_handle *fwnode,
 		ret = swnode_gpio_get_reference(fwnode, propname, idx, &args);
 		if (ret == 0)
 			break;
+		if (ret == -ENOTCONN)
+			/*
+			 * -ENOTCONN for a software node reference lookup means
+			 *  that a remote struct software_node exists but has
+			 *  not yet been registered as a firmware node. Defer
+			 *  until this happens.
+			 */
+			return ERR_PTR(-EPROBE_DEFER);
 	}
 	if (ret) {
 		pr_debug("%s: can't parse '%s' property of node '%pfwP[%d]'\n",

-- 
2.47.3

Re: [PATCH v4 2/2] gpio: swnode: defer probe on references to unregistered software nodes

[Andy Shevchenko]

On Tue, Apr 07, 2026 at 03:27:58PM +0200, Bartosz Golaszewski wrote:
> fwnode_property_get_reference_args() now returns -ENOTCONN when called
> on a software node referencing another software node which has not yet
> been registered as a firmware node. It makes sense to defer probe in this
> situation as the node will most likely be registered later on and we'll
> be able to resolve the reference eventually. Change the behavior of
> swnode_find_gpio() to return -EPROBE_DEFER if the software node reference
> resolution returns -ENOTCONN.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

...

>  		ret = swnode_gpio_get_reference(fwnode, propname, idx, &args);

>  		if (ret == 0)
>  			break;

Maybe check for an error first? Dunno. Up to you.

		if (ret == -ENOTCONN)
			...
		if (ret)
			continue;

		/* The reference is found, bail out */
		break;

(Also may be done in a separate change no need to mix these things
 in the proposed change.)

> +		if (ret == -ENOTCONN)
> +			/*
> +			 * -ENOTCONN for a software node reference lookup means
> +			 *  that a remote struct software_node exists but has
> +			 *  not yet been registered as a firmware node. Defer
> +			 *  until this happens.
> +			 */
> +			return ERR_PTR(-EPROBE_DEFER);

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 2/2] gpio: swnode: defer probe on references to unregistered software nodes

[Bartosz Golaszewski]

On Tue, Apr 7, 2026 at 4:33 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 07, 2026 at 03:27:58PM +0200, Bartosz Golaszewski wrote:
> > fwnode_property_get_reference_args() now returns -ENOTCONN when called
> > on a software node referencing another software node which has not yet
> > been registered as a firmware node. It makes sense to defer probe in this
> > situation as the node will most likely be registered later on and we'll
> > be able to resolve the reference eventually. Change the behavior of
> > swnode_find_gpio() to return -EPROBE_DEFER if the software node reference
> > resolution returns -ENOTCONN.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> ...
>
> >               ret = swnode_gpio_get_reference(fwnode, propname, idx, &args);
>
> >               if (ret == 0)
> >                       break;
>
> Maybe check for an error first? Dunno. Up to you.
>
>                 if (ret == -ENOTCONN)
>                         ...
>                 if (ret)
>                         continue;
>
>                 /* The reference is found, bail out */
>                 break;
>
> (Also may be done in a separate change no need to mix these things
>  in the proposed change.)
>
> > +             if (ret == -ENOTCONN)
> > +                     /*
> > +                      * -ENOTCONN for a software node reference lookup means
> > +                      *  that a remote struct software_node exists but has
> > +                      *  not yet been registered as a firmware node. Defer
> > +                      *  until this happens.
> > +                      */
> > +                     return ERR_PTR(-EPROBE_DEFER);
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Yes, I mentioned it in one of the earlier revisions. I'll do it
separately and only continue the loop on -ENOENT.

Bart

Re: [PATCH v4 1/2] software node: return -ENOTCONN when referenced swnode is not registered yet

[Bartosz Golaszewski]

On Tue, Apr 7, 2026 at 3:28 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> 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 <andy@kernel.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---

Hi Danilo!

With Andy's Ack, do you think you could still queue this for v7.1? I'd
then take the GPIO patch (2/2) independently and it would make further
work next cycle much easier.

Thanks,
Bartosz

Re: [PATCH v4 1/2] software node: return -ENOTCONN when referenced swnode is not registered yet

[Danilo Krummrich]

On Wed Apr 8, 2026 at 9:19 AM CEST, Bartosz Golaszewski wrote:
> On Tue, Apr 7, 2026 at 3:28 PM Bartosz Golaszewski
> <bartosz.golaszewski@oss.qualcomm.com> wrote:
>>
>> 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 <andy@kernel.org>
>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> ---
>
> Hi Danilo!
>
> With Andy's Ack, do you think you could still queue this for v7.1?

Yeah, that should work, but I have a question about the patch.

The comment added to fwnode_property_get_reference_args() says:

	+ *            %-ENOTCONN when the remote firmware node is a software node that
	+ *                       has not been registered as a firmware node yet

This seems like a bit of a layering violation to me, as it makes it explicit
that this error code indicates a software node, while
fwnode_property_get_reference_args() itself should be agnostic.

The caller can easily derive more specific semantics with an is_software_node()
check as you already do in the GPIO code.

Can we describe the same condition, but without explicitly naming the backend?

Re: [PATCH v4 1/2] software node: return -ENOTCONN when referenced swnode is not registered yet

[Bartosz Golaszewski]

On Wed, 8 Apr 2026 17:28:46 +0200, Danilo Krummrich <dakr@kernel.org> said:
> On Wed Apr 8, 2026 at 9:19 AM CEST, Bartosz Golaszewski wrote:
>> On Tue, Apr 7, 2026 at 3:28 PM Bartosz Golaszewski
>> <bartosz.golaszewski@oss.qualcomm.com> wrote:
>>>
>>> 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 <andy@kernel.org>
>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>> ---
>>
>> Hi Danilo!
>>
>> With Andy's Ack, do you think you could still queue this for v7.1?
>
> Yeah, that should work, but I have a question about the patch.
>
> The comment added to fwnode_property_get_reference_args() says:
>
> 	+ *            %-ENOTCONN when the remote firmware node is a software node that
> 	+ *                       has not been registered as a firmware node yet
>
> This seems like a bit of a layering violation to me, as it makes it explicit
> that this error code indicates a software node, while
> fwnode_property_get_reference_args() itself should be agnostic.
>
> The caller can easily derive more specific semantics with an is_software_node()
> check as you already do in the GPIO code.
>
> Can we describe the same condition, but without explicitly naming the backend?
>

Yes, sure. It can be something like:

	%-ENOTCONN when the remote firmware node exists but has not been
		   registered yet.

Does this sound good and doo you want me to resend or can you change it
when applying?

Bart

Re: [PATCH v4 1/2] software node: return -ENOTCONN when referenced swnode is not registered yet

[Danilo Krummrich]

On Wed Apr 8, 2026 at 5:52 PM CEST, Bartosz Golaszewski wrote:
> On Wed, 8 Apr 2026 17:28:46 +0200, Danilo Krummrich <dakr@kernel.org> said:
>> On Wed Apr 8, 2026 at 9:19 AM CEST, Bartosz Golaszewski wrote:
>>> On Tue, Apr 7, 2026 at 3:28 PM Bartosz Golaszewski
>>> <bartosz.golaszewski@oss.qualcomm.com> wrote:
>>>>
>>>> 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 <andy@kernel.org>
>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>>> ---
>>>
>>> Hi Danilo!
>>>
>>> With Andy's Ack, do you think you could still queue this for v7.1?
>>
>> Yeah, that should work, but I have a question about the patch.
>>
>> The comment added to fwnode_property_get_reference_args() says:
>>
>> 	+ *            %-ENOTCONN when the remote firmware node is a software node that
>> 	+ *                       has not been registered as a firmware node yet
>>
>> This seems like a bit of a layering violation to me, as it makes it explicit
>> that this error code indicates a software node, while
>> fwnode_property_get_reference_args() itself should be agnostic.
>>
>> The caller can easily derive more specific semantics with an is_software_node()
>> check as you already do in the GPIO code.
>>
>> Can we describe the same condition, but without explicitly naming the backend?
>>
>
> Yes, sure. It can be something like:
>
> 	%-ENOTCONN when the remote firmware node exists but has not been
> 		   registered yet.
>
> Does this sound good and doo you want me to resend or can you change it
> when applying?

I can change it when applying.

One additional question though. I think it should be fine, but are we sure the
change can't regress other subsystems? It seems some of them (e.g. sfp-bus,
v4l2, iio) special case -ENOENT.

Re: [PATCH v4 1/2] software node: return -ENOTCONN when referenced swnode is not registered yet

[Andy Shevchenko]

On Wed, Apr 8, 2026 at 9:53 PM Danilo Krummrich <dakr@kernel.org> wrote:
> On Wed Apr 8, 2026 at 5:52 PM CEST, Bartosz Golaszewski wrote:
> > On Wed, 8 Apr 2026 17:28:46 +0200, Danilo Krummrich <dakr@kernel.org> said:
> >> On Wed Apr 8, 2026 at 9:19 AM CEST, Bartosz Golaszewski wrote:
> >>> On Tue, Apr 7, 2026 at 3:28 PM Bartosz Golaszewski
> >>> <bartosz.golaszewski@oss.qualcomm.com> wrote:
> >>>>
> >>>> 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".

> >>> With Andy's Ack, do you think you could still queue this for v7.1?
> >>
> >> Yeah, that should work, but I have a question about the patch.
> >>
> >> The comment added to fwnode_property_get_reference_args() says:
> >>
> >>      + *            %-ENOTCONN when the remote firmware node is a software node that
> >>      + *                       has not been registered as a firmware node yet
> >>
> >> This seems like a bit of a layering violation to me, as it makes it explicit
> >> that this error code indicates a software node, while
> >> fwnode_property_get_reference_args() itself should be agnostic.
> >>
> >> The caller can easily derive more specific semantics with an is_software_node()
> >> check as you already do in the GPIO code.
> >>
> >> Can we describe the same condition, but without explicitly naming the backend?

> > Yes, sure. It can be something like:
> >
> >       %-ENOTCONN when the remote firmware node exists but has not been
> >                  registered yet.

FWIW, good to me.

> > Does this sound good and doo you want me to resend or can you change it
> > when applying?
>
> I can change it when applying.
>
> One additional question though. I think it should be fine, but are we sure the
> change can't regress other subsystems? It seems some of them (e.g. sfp-bus,
> v4l2, iio) special case -ENOENT.

v4l2 uses the ENOTCONN in the cases similar to this

https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/media/v4l2-core/v4l2-async.c#L744

There are two more, but they seem more about connectors.

-- 
With Best Regards,
Andy Shevchenko