Re: [PATCH v2 1/4] software node: return -ENXIO when referenced swnode is not registered yet

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Apr 07, 2026 at 12:57:29PM +0200, Bartosz Golaszewski wrote:
> On Fri, Apr 3, 2026 at 8:07 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > 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:

...

> > > 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?
> 
> I'd argue that gpiod_get() should really be limited to being called at
> probe() time but I see your point.

There is weird hardware that might need to switch GPIO from IRQ (input) to
output at runtime (at least some touchscreens functioning like that IIRC).
But I dunno if it requires gpiod_put()/gpiod_get() dances.

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

> Andy et al: what is your take on this?

I already commented on this while ago, and I think EPROBE_DEFER should be
limited as much as possible (and eventually killed for good). This is known
hack to the Linux device model instead of doing it via some graphs that are
constructed during initialisation. There were talks and approaches how to
solve this using graph theory IIRC (i.o.w. mathematically proven).

To the current case, I think the fwnode/swnode APIs should be clean of
deferred probe hack, so I like Bart's patch.

-- 
With Best Regards,
Andy Shevchenko