Message-ID: <39f4b68b-0bbc-4c41-a8ee-206209900a66@vaisala.com>
Date: Tue, 13 Jan 2026 13:49:18 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: Nuno Sá <noname.nuno@...il.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

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.

Thanks,
Tomas



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

Powered by blists - more mailing lists