linux-kernel - Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

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: <f4cd3b85c47b2829cc54c514dffd254433f796e4.camel@gmail.com>
Date: Tue, 13 Jan 2026 10:52:36 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Tomas Melin <tomas.melin@...sala.com>, Jonathan Cameron
 <jic23@...nel.org>
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>, 
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

On Tue, 2026-01-13 at 09:47 +0200, Tomas Melin wrote:
> Hi,
> 
> On 12/01/2026 15:21, Nuno Sá wrote:
> > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote:
> > > On Mon, 05 Jan 2026 14:57:02 +0000
> > > Nuno Sá <noname.nuno@...il.com> wrote:
> > > 
> > > > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:
> > > > > Hi,
> > > > > 
> > > > > On 21/12/2025 22:00, Jonathan Cameron wrote:  
> > > > > > On Tue, 16 Dec 2025 11:40:06 +0000
> > > > > > Tomas Melin <tomas.melin@...sala.com> wrote:
> > > > > >   
> > > > > > > Not all users can or want to use the device with an iio-backend.
> > > > > > > For these users, let the driver work in standalone mode, not coupled
> > > > > > > to the backend or the services it provides.
> > > > > > > 
> > > > > > > Signed-off-by: Tomas Melin <tomas.melin@...sala.com>  
> > > > > > Hi Tomas,
> > > > > >   
> > > > > > >  static int ad9467_probe(struct spi_device *spi)
> > > > > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
> > > > > > >  	indio_dev->channels = st->info->channels;
> > > > > > >  	indio_dev->num_channels = st->info->num_channels;
> > > > > > >  
> > > > > > > +	/* Using a backend is optional */  
> > > > > > 
> > > > > > I'll largely defer to Nuno on the backend aspects but I would like a
> > > > > > lot more than a statement that it is optional in this comment.
> > > > > > At least something about where the data goes and what a real system
> > > > > > that didn't provide a backend would look like etc.  
> > > > > 
> > > > > Having the backend as optional is about flexibility to incorporate these
> > > > > devices as fits best with the system. The current backend approach is
> > > > > pretty much dictated with how the ADI default backend is implemented.
> > > > > These devices are fully configurable via SPI interface so the backend
> > > > > doesn't necessarily need to be anything fancy or even configurable.
> > > > > 
> > > > > So there is atleast two use cases that promote the optional iio-backend
> > > > > approach
> > > > >  - simple backend that is not configurable, no need for a dedicated
> > > > > driver. The backend (FPGA) sits and waits for data and handles it when
> > > > > it arrives  
> > > > 
> > > > Agree on the above. Ideally we could have some dummy backend for the above but
> > > > it is not really easy/maintainable to have it.
> > > 
> > > When we say the backend needs no driver, where does the data end up?
> > > Is the idea that it goes into some processing pipeline and sent to
> > > some external path that we have no visibility of? i.e. We configure the
> > > data capture in Linux but never see the data?
> > 
> > Yes, that's also my assumption about Tomas's usecase.
> 
> The data becomes available to user space but there is currently no
> immediate need or natural place to create a separate instance to
> function as a backend device.

So do you have some completely different data path bypassing IIO (just curious)?

> 
> But that being said, I'm leaning towards thinking that perhaps a
> minimalistic backend should always be registered after all. That would
> keep the idea of the backend always existing intact.
> But since the backend can be missing a lot of the features defined for
> the current ADI backend, capability handling would need to be added to
> the backend framework to make it functional.
> 
> Looking into how this could be achieved with reasonable impact, I have
> tried to identify capabilities that we could add for starters, and then
> have the frontend behave differently depending on what features are present.
> 
> Something like this (added to backend_info),
> .caps = IIO_BACKEND_CAP_TEST_PATTERNS |  --> backend patterns are avail.
> 	IIO_BACKEND_CAP_BUFFERING |  --> backend has buffering cap.
> 	IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration
> 

Looks reasonable but I'm still a bit afraid to open this can of worms. But as Jonathan
pointed out multiple times on the backend code, this is mostly inkernel interfaces so
it is easier to deal with bad choices :).
 

We would still need to "combine" these capabilities feature with a dummy backend that
would dummy implement the more common/expected like (chan)enable/disable and so on.

We can then decide on a usecase by usecase basis on what should be a capability or what
should be dummy implemented.

Bottom line, I'm leaning on "I'm ok with the above" since I expect usecases like this to
be fairly rare (famous last words :)). And It would be nice to have more feedback
on this one.

- Nuno Sá