linux-kernel - Re: [PATCH v5 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: <db4978d8a8c46844c6c80580af626e7340b28e1c.camel@gmail.com>
Date: Tue, 03 Feb 2026 09:51:42 +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 v5 4/4] iio: adc: ad9467: check for backend capabilities

On Mon, 2026-02-02 at 14:03 +0200, Tomas Melin wrote:
> Hi,
> 
> On 02/02/2026 12:42, Nuno Sá wrote:
> > On Fri, 2026-01-30 at 09:17 +0000, Tomas Melin wrote:
> > > Add capability checks for operation with backends that do not necessarily
> > > support full set of features, but are otherwise compatible with the device.
> > > This ensures a fully functional device, but with limited capabilities.
> ...
> > >  
> > > @@ -1263,8 +1271,10 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
> > >  	if (!st->chan_test)
> > >  		return;
> > >  
> > > -	debugfs_create_file("calibration_table_dump", 0400, d, st,
> > > -			    &ad9467_calib_table_fops);
> > > +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> > > +		debugfs_create_file("calibration_table_dump", 0400, d, st,
> > > +				    &ad9467_calib_table_fops);
> > > +	}
> > >  
> > >  	for (chan = 0; chan < st->info->num_channels; chan++) {
> > >  		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
> > 
> > Change the permissions for in_voltage%u_test_mode so that is WO in case we can't
> > IIO_BACKEND_CAP_CALIBRATION. You can even reuse the above check to tweak the permissions
> > accordingly. Then no need to check for the capability in ad9467_chan_test_mode_read()
> 
> This RO would be then only for cases PN9, PN23. For the other attributes

> RW would still be applicable. But basically I think the test modes in
> the device are still available even if the backend status does not exist?

Yeah, they are. The backend is only validating the pattern to make sure it is what's
expected. TBH, I'm not sure what's the utility without the backend but I guess one might
want to connect the interface somewhere and check the patterns.

> IMHO the current approach is slightly cleaner, as all the test modes the
> device supports are available and no need to think about which ones have
> RW/RO inside this function. Please let me know, in case you insist on
> this kind of approach.
> 
> 
Ok, I reviewed the code and I see we still print some running status for all the patterns.
Feel free to leave as-is then

- Nuno Sá