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: <20260116183212.08630389@jic23-huawei>
Date: Fri, 16 Jan 2026 18:32:12 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>
Cc: Tomas Melin <tomas.melin@...sala.com>, 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 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.


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