Message-ID: <20260111114109.28b01266@jic23-huawei>
Date: Sun, 11 Jan 2026 11:41:09 +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>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

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?


> 
> > -  custom backend not compatible with the adi backend features. For
> > example different approach to calibration, or other model for data
> > channels etc.  
> 
> I would argue the above would require a new driver with, perhaps, a new compatible
> on the frontend side for the needed modifications. Or we could introduce some kind
> of "detect backend vendor thing" so that the frontend driver can adapt at runtime
> (though this looks like a "fancier" way of having a new compatible).
> 
> Ideally we could somehow "detect" backend capabilities but these kind of systems are
> so different and usecase specific that, at least for now, I don't see how that could be
> sanely done.

Agreed. If we need to extend things to deal with other styles of FPGA IP or different
feature sets, that is the way to go.  That would require some public implementation
that uses the interface

Jonathan

> 
> - Nuno Sá
> 
> >   

Powered by blists - more mailing lists