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

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 16 Oct 2026 15:07:02 +0100
Nuno Sá <nuno.sa@analog.com> wrote:

> On Fri, Oct 16, 2026 at 04:19:33PM +0300, Andy Shevchenko wrote:
> > 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.  
> > 
> > +1
> >   
> > > 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?  
> > 
> > If there is an empty property for names, shouldn't we simply fail? I rather
> > would consider the firmware table to be broken in such a case.  
> 
> What Rodrigo is saying is that an IIO frontend driver can have multiple
> backends. So in practice:
> 
> io-backend-names = "foo", "bar";
> 
> But we might want to have foo as optional while bar is mandatory so that
> 
> io-backend-names = "bar"

Not sure mandatory or not is relevant.  Two optional backends where the
driver can run with either or both of them would hit the same problem of
present property but particular backend not being there.

> 
> So if we treat all errors (after checking for presence) the same we will fail
> in the optional one. Note -ENODATA also means match_string() failed.
> 
> As of now there's no such usecase in tree or oeven out of tree (that I'm
> aware of) but to support it is also fairly simple that I don't mind to
> have it now.

I'm in two minds over this. It's unused complexity, but it also makes the
function behave how a user might expect.  Definitely needs some
good justifying comments in the code though as it will look weird!

Jonathan


> 
> - Nuno Sá
> 
> > 
> > -- 
> > With Best Regards,
> > Andy Shevchenko
> > 
> >