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

Tomas Melin
2026-01-14T15:24:02Z

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.

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?

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?

Thanks,
Tomas

>
> - Nuno Sá