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 -ENXIO
which stands for "No such device or address".

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/base/swnode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 51320837f3a9f1bf4f65aa161d9b941affc74936..29eec7ba500e8c8a02482dfac68f2c313cfadee7 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 -ENXIO;
 
 	if (nargs_prop) {
 		error = fwnode_property_read_u32(refnode, nargs_prop, &nargs_prop_val);

-- 
2.47.3

On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski 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 -ENXIO
> which stands for "No such device or address".

This error code is also too generic to my taste. What about alternative(s)?
EADDRNOTAVAIL
ENOTCONN

(The brief grep shows that the second one might suit slightly better than the
 first one by existing use cases.)

Do we need to update the (chain of) kernel-doc?

-- 
With Best Regards,
Andy Shevchenko

On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski 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 -ENXIO
> > which stands for "No such device or address".
> 
> This error code is also too generic to my taste. What about alternative(s)?
> EADDRNOTAVAIL
> ENOTCONN
> 
> (The brief grep shows that the second one might suit slightly better than the
>  first one by existing use cases.)

We are in the core of the driver core. Why not simply use -EPROBE_DEFER
to which all users will resolve this error to and call it a day?

Thanks.

-- 
Dmitry

On Thu, Apr 2, 2026 at 10:43 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:
> > On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski 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 -ENXIO
> > > which stands for "No such device or address".
> >
> > This error code is also too generic to my taste. What about alternative(s)?
> > EADDRNOTAVAIL
> > ENOTCONN
> >
> > (The brief grep shows that the second one might suit slightly better than the
> >  first one by existing use cases.)
>
> We are in the core of the driver core. Why not simply use -EPROBE_DEFER
> to which all users will resolve this error to and call it a day?
>

Because -EPROBE_DEFER only makes sense in probe() context, while
fwnode_get_reference_args() may be called in many other situations. I
think ENOTCONN as "not connected" makes sense, though the string
representation says: "Transport endpoint is not connected" which
doesn't spell out quite the same thing.

Bart

On Fri, Apr 03, 2026 at 09:29:38AM +0200, Bartosz Golaszewski wrote:
> On Thu, Apr 2, 2026 at 10:43 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:
> > > On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski 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 -ENXIO
> > > > which stands for "No such device or address".
> > >
> > > This error code is also too generic to my taste. What about alternative(s)?
> > > EADDRNOTAVAIL
> > > ENOTCONN
> > >
> > > (The brief grep shows that the second one might suit slightly better than the
> > >  first one by existing use cases.)
> >
> > We are in the core of the driver core. Why not simply use -EPROBE_DEFER
> > to which all users will resolve this error to and call it a day?
> >
> 
> Because -EPROBE_DEFER only makes sense in probe() context, while
> fwnode_get_reference_args() may be called in many other situations.

Exactly same argument applies to your follow-up change: gpiod_get()
returning -EPROBE_DEFER only makes sense in probe context but it may be
called in many other situations. Are you planning to change all places
where gpiolib returns -EPROBE_DEFER to something else just in case it
might be called outside of probe context? 

-EPROBE_DEFER should have been called -ENOTREADY from the beginning and
then we would not have this argument. Or, even better, we should have
used -EAGAIN. But it is just a name, semantics does not really change.
We want to signal that something is not ready and the operation needs be
repeated. Currently we contorting ourselves by using yet another error
code that everyone will either convert to -EPORBE_DEFER or will handle
like -EAGAIN.

> I think ENOTCONN as "not connected" makes sense, though the string

Why is it better? Most of users of -ENOTCONN are in networking code so
it is somewhat unexpected to have other APIs return it. 

> representation says: "Transport endpoint is not connected" which
> doesn't spell out quite the same thing.

Yes, because it is really for networking/sockets handling.

Thanks.

-- 
Dmitryp