Re: [PATCH 02/10] iio: backend: add devm_iio_backend_get_optional()

["Nuno Sá" <nuno.sa@analog.com>]

On Fri, Oct 16, 2026 at 08:18:08AM -0300, Rodrigo Alencar wrote:
> On 16/10/26 09:45, Nuno Sá wrote:
> > On Thu, Oct 15, 2026 at 09:41:40PM +0300, Andy Shevchenko wrote:
> > > On Thu, Oct 15, 2026 at 01:49:42PM -0300, Rodrigo Alencar via B4 Relay wrote:
> > > 
> > > > Frontend devices might not need a backend driver to rely on. An IIO device
> > > > that supports backends can behave differently when they are not available
> > > > and that should be acceptable. Such parts may provide basic functionality
> > > > solely using the control interface (SPI for instance), being able to have
> > > > extended features when a backend is present.
> > > > 
> > > > Add devm_iio_backend_get_optional(), which returns NULL when the backend
> > > > is not described in firmware, i.e., when the io-backends property is not
> > > > present or, for a named lookup, when the name is not listed in the
> > > > io-backend-names property. Other errors, such as probe deferral, are
> > > > still returned.
> > > > 
> > > > To make that possible, a named lookup that does not match any entry of
> > > > io-backend-names now fails with -ENOENT, the same error returned when the
> > > > io-backends reference is missing. Also, the missing reference is no longer
> > > > logged as an error, leaving that to the caller.
> 
> ...
> 
> > > >  		ret = device_property_match_string(dev, "io-backend-names", name);
> > > > +		if (ret == -EINVAL || ret == -ENODATA)
> > > > +			return ERR_PTR(-ENOENT);
> > > 
> > > No. Please, use device_property_present() instead.
> > 
> > Oh right! Totally forgot about that internally :). And it fits into my
> > internal point where I don't agree much in treating -ENODATA the same
> > way as property does not exist.
> 
> Say a frontend consumes multiple backends, but some of them are optional.
> If we care only about the presence of the property we would fail when
> trying to acquire the optional ones when the required ones are defined.
> am I thinking correctly?

Hmm not sure that makes much sense (I mean having optional and non
optional backends for a frontend). At least I'm not aware of any
possible usecase we might have internally. That said, you're thinking
correctly and it's fairly simple to accommodate for that today. But
Andy might still prefer something like:

if (!device_property_present())
	return return ERR_PTR(-ENOENT);
/* A comment here would make sense given it's not that clear what are we
 * trying to get with the below check */
ret = device_property_match_string();
if (ret == -ENODATA)
	return ERR_PTR(-ENOENT);
...

Personally, I'm fine either way

- Nuno Sá
> 
> -- 
> Kind regards,
> 
> Rodrigo Alencar