Re: [PATCH v3 4/4] iio: adc: ad9467: check for backend capabilities

["Nuno Sá" <noname.nuno@gmail.com>]

On Wed, 2026-01-14 at 17:23 +0200, Tomas Melin wrote:
> Hi,
> 
> On 14/01/2026 14:29, Nuno Sá wrote:
> > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> > > Add capability checks for operation with backends that do not support
> > > full set of features, but are otherwise compatible with the device.
> > > 
> 
> > > +		return 0;
> > > +
> > 
> > As David suggested, it might make more sense to do the check from the callers. Not as
> > important as within the backend functions though.
> > 
> > >  	/* all points invalid */
> > >  	bitmap_fill(st->calib_map, st->calib_map_size);
> > >  
> > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
> > >  		return ret;
> > >  
> > >  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
> > > -	if (ret)
> > > +	if (ret && ret != -EOPNOTSUPP)
> > >  		return ret;
> > 
> > Don't agree with the above. I would prefer to see a dedicated CAP for buffering
> > otherwise I would argue why not doing the same for everything? While it might
> > be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION
> > (given they are related to some extent), that does not apply to buffering.
> 
> Okay perhaps we first need to agree on how we define a capability;)
> 
> So my thinking here was that calibration capability expands across
> several or even many op calls, so it's a feature level thing and
> requires several coordinated functions. So does the test pattern, but
> it's a sub entity of the calibration so I merged the two together. So
> checking for a capability in these cases makes sense, since checking
> against a single operation call for determining if the capability is
> present is not easy and which function would it be, etc.

Makes sense.

> 
> The backend buffer on the other hand maps to a single op call (in theory
> two). So checking for that buffering capability can be done by checking
> if the op call is supported (eopnotsupp). I was kindof thinking that why
> need a capability if the mapping is 1:1 and the information is available
> through that error value directly?

Yeah, TBH the only reason I can think of is readability. To me, it is more
explicit:

if (has_buffering())
	request_buffer(); //not allowed to fail

And can be a bit confusing having a mix of has_capability() and checking for
error codes.

But yes, checking for specific error codes for determining behavior is a common
pattern so I won't be nitpicky about it.

> 
> On frontend level, like here it is known that the driver can function
> without that buffering, so if the backend does not supported it can be
> okay to proceed.
> If we add a capability for a single operation that has 1:1 mapping then
> basically we should map all and that is not really the point?

> I see the capability like a contract between the backend and frontend on
> feature level, that the feature is there but the implementation of a
> specific capability might actually differ depending on the use case
> (like we see with ad9467 and ad485x calibration and their backends)
> 
> What are your thoughts about this?
> 

Ok, I think it makes sense to me but maybe we should be more explicit/clear in
the docs:

"... meaning that a capability requires certain 
operations to be implemented by the backend"

Maybe s/certain/multiple and we could even mention that if a frontend is interested
in knowing that a operation is not supported, the error code can be checked
(though this could be obvious already).

Let's see what Jonathan and others thinks about it.

- Nuno Sá