fwnode_property_get_reference_args() now returns -ENXIO 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 -ENXIO.

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

diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
index 0d7f3f09a0b4bee0cf1bbdaa8b7b8ae4cd5de581..06d74e9e199de0b91a019e5e15d4b83d330291e7 100644
--- a/drivers/gpio/gpiolib-swnode.c
+++ b/drivers/gpio/gpiolib-swnode.c
@@ -95,6 +95,15 @@ struct gpio_desc *swnode_find_gpio(struct fwnode_handle *fwnode,
 			break;
 	}
 	if (ret) {
+		if (ret == -ENXIO)
+			/*
+			 * -ENXIO 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);
+
 		pr_debug("%s: can't parse '%s' property of node '%pfwP[%d]'\n",
 			__func__, propname, fwnode, idx);
 		return ERR_PTR(ret);

-- 
2.47.3

On Thu, Apr 02, 2026 at 02:54:27PM +0200, Bartosz Golaszewski wrote:
> fwnode_property_get_reference_args() now returns -ENXIO 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 -ENXIO.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>  drivers/gpio/gpiolib-swnode.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> index 0d7f3f09a0b4bee0cf1bbdaa8b7b8ae4cd5de581..06d74e9e199de0b91a019e5e15d4b83d330291e7 100644
> --- a/drivers/gpio/gpiolib-swnode.c
> +++ b/drivers/gpio/gpiolib-swnode.c
> @@ -95,6 +95,15 @@ struct gpio_desc *swnode_find_gpio(struct fwnode_handle *fwnode,
>  			break;
>  	}
>  	if (ret) {
> +		if (ret == -ENXIO)


I'll be just sitting here and quoting sashiko all day long ;)

"
If swnode_gpio_get_reference() returns -ENXIO during the first iteration
(for example, when checking the con_id-gpios suffix), won't the loop continue
since the return value is not 0?

Looking at the loop just above this block:

        for_each_gpio_property_name(propname, con_id) {
                ret = swnode_gpio_get_reference(fwnode, propname, idx, &args);
                if (ret == 0)
                        break;
        }

If the initial property check returns -ENXIO, but the subsequent fallback
check for the con_id-gpio suffix returns -ENOENT, the ret variable gets
overwritten. 

When the loop terminates, ret would be -ENOENT instead of -ENXIO. Could this
cause the probe deferral check to evaluate to false and fail the probe
entirely instead of deferring it as intended? 

Should the loop also break early if -ENXIO is encountered?

"

You need to change that to

	if (ret == 0 || ret == -ENXIO)
		break;

because if we get -ENXIO that means the GPIO must be there (the property
exists) but not ready yet and we do not want to fall back to another
suffix. 

Thanks.

-- 
Dmitry

On Thu, Apr 2, 2026 at 11:04 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> You need to change that to
>
>         if (ret == 0 || ret == -ENXIO)
>                 break;
>
> because if we get -ENXIO that means the GPIO must be there (the property
> exists) but not ready yet and we do not want to fall back to another
> suffix.
>

I'm wondering if we should make this check even stricter and only
continue on -ENOENT - which means: there is no such property - and
bail out on other errors.

But that would be a separate change.

Bart

On Thu, Apr 2, 2026 at 11:04 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Thu, Apr 02, 2026 at 02:54:27PM +0200, Bartosz Golaszewski wrote:
> > fwnode_property_get_reference_args() now returns -ENXIO 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 -ENXIO.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > ---
> >  drivers/gpio/gpiolib-swnode.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> > index 0d7f3f09a0b4bee0cf1bbdaa8b7b8ae4cd5de581..06d74e9e199de0b91a019e5e15d4b83d330291e7 100644
> > --- a/drivers/gpio/gpiolib-swnode.c
> > +++ b/drivers/gpio/gpiolib-swnode.c
> > @@ -95,6 +95,15 @@ struct gpio_desc *swnode_find_gpio(struct fwnode_handle *fwnode,
> >                       break;
> >       }
> >       if (ret) {
> > +             if (ret == -ENXIO)
>
>
> I'll be just sitting here and quoting sashiko all day long ;)
>

I would love it to produce briefer messages. I'm always put off by the
walls of text. I would literally rather deal with neanderthal mode
like: "loop continues on ret != 0, bad!".

> "
> If swnode_gpio_get_reference() returns -ENXIO during the first iteration
> (for example, when checking the con_id-gpios suffix), won't the loop continue
> since the return value is not 0?
>
> Looking at the loop just above this block:
>
>         for_each_gpio_property_name(propname, con_id) {
>                 ret = swnode_gpio_get_reference(fwnode, propname, idx, &args);
>                 if (ret == 0)
>                         break;
>         }
>
> If the initial property check returns -ENXIO, but the subsequent fallback
> check for the con_id-gpio suffix returns -ENOENT, the ret variable gets
> overwritten.
>
> When the loop terminates, ret would be -ENOENT instead of -ENXIO. Could this
> cause the probe deferral check to evaluate to false and fail the probe
> entirely instead of deferring it as intended?
>
> Should the loop also break early if -ENXIO is encountered?
>
> "
>
> You need to change that to
>
>         if (ret == 0 || ret == -ENXIO)
>                 break;
>
> because if we get -ENXIO that means the GPIO must be there (the property
> exists) but not ready yet and we do not want to fall back to another
> suffix.
>

Yes, thanks.

Bart