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: <20260113100051.0000077a@huawei.com>
Date: Tue, 13 Jan 2026 10:00:51 +0000
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: Tomas Melin <tomas.melin@...sala.com>
CC: Nuno Sá <noname.nuno@...il.com>, Jonathan Cameron
	<jic23@...nel.org>, 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, 13 Jan 2026 09:47:46 +0200
Tomas Melin <tomas.melin@...sala.com> 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.
> 
> 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
> 
> If you think this seems reasonable, I can implement something like this
> and post a new version for comments.
> 
Sounds good to me, but I defer to Nuno for backend stuff!

Thanks,

Jonathan

> Thanks,
> Tomas
> 
> 
> 
> > 
> > - Nuno Sá  
> 
> 
>