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: <9214d1ba49ee31e4f35d8d3fe5d894142e1d6fef.camel@gmail.com>
Date: Thu, 15 Jan 2026 11:54:28 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Tomas Melin <tomas.melin@...sala.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

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á