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

["Nuno Sá" <noname.nuno@gmail.com>]

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@vaisala.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@vaisala.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.

> -  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.

- Nuno Sá

>