Message-ID: <186a9a1a9cf8bd6c4c91bac62344b7015e696005.camel@gmail.com>
Date: Tue, 13 Jan 2026 12:44:06 +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 13:49 +0200, Tomas Melin wrote:
> Hi,
> 
> On 13/01/2026 12:52, Nuno Sá wrote:
> > 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:
> 
> > > > > 
> > > > > 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)?
> 
> Yes, IP handles data reception and data transfer outside of iio context.
> 
> > 
> > > 
> > > 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 :).
> 
> I understand this concern, but would anticipate that there are only a
> limited number of capabilties that need to be handled, so it should stay
> fairly managable.
> 
> >  
> > 
> > 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.
> 
> I think the dummy backend is probably not gonna be needed as the current
> axi backend can advertise the available set of capabilities. The
> frontends are then free to make use of the capability bits as needed.
> In my use case, I need to implement a limited backend that does not
> claim any capabilities but only provides a minimum set of functionality.
> 

Ok, looking at the driver indeed it seems we would not need much advertised.
Let's see how something like the above would look like and discuss on top of that.

- Nuno Sá

Powered by blists - more mailing lists