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: <51085acb-91c9-43ad-8f7e-94f1e9c995ed@vaisala.com>
Date: Tue, 13 Jan 2026 09:47:46 +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 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.

Thanks,
Tomas



> 
> - Nuno Sá