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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <68cee45e-4822-41af-a0da-d1b88166425d@vaisala.com>
Date: Wed, 14 Jan 2026 17:23:55 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: Nuno Sá <noname.nuno@...il.com>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Nuno Sa <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
 Jonathan Cameron <jic23@...nel.org>, David Lechner <dlechner@...libre.com>,
 Andy Shevchenko <andy@...nel.org>,
 Olivier Moysan <olivier.moysan@...s.st.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/4] iio: adc: ad9467: check for backend capabilities

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á