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

Jonathan Cameron
2026-01-16T18:32:21Z

On Thu, 15 Jan 2026 11:54:28 +0000
Nuno Sá <noname.nuno@gmail.com> wrote:

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

I'd prefer capabilities for each thing rather than a mixed scheme.
Nothing wrong with also returning -ENOTSUPP if someone doesn't check
the capability first as that's still helpful for debug.

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