Message-ID: <fdc20647-671b-4ba8-a30a-50e46ac71c6e@vaisala.com>
Date: Mon, 19 Jan 2026 13:55:08 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: Jonathan Cameron <jic23@...nel.org>, Nuno Sá
 <noname.nuno@...il.com>
Cc: Michael Hennerich <Michael.Hennerich@...log.com>,
 Nuno Sa <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
 David Lechner <dlechner@...libre.com>, Andy Shevchenko <andy@...nel.org>,
 Olivier Moysan <olivier.moysan@...s.st.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/4] iio: adc: ad9467: check for backend capabilities



On 16/01/2026 20:32, Jonathan Cameron wrote:
> On Thu, 15 Jan 2026 11:54:28 +0000
> Nuno Sá <noname.nuno@...il.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.

Okay I'll update accordingly. So capabilities are defined as being
something that

* is defined/added on a need basis to help frontends decide if a feature
is supported
* can map into multiple operations
* can map to a single operation

Thanks,
Tomas



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

Powered by blists - more mailing lists