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: <356a75b0-dc3e-4d10-a827-1af3b4ab638f@vaisala.com>
Date: Mon, 5 Jan 2026 13:06:13 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: 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 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
-  custom backend not compatible with the adi backend features. For
example different approach to calibration, or other model for data
channels etc.

Not having it optional would mean more or less vendor lock with analog
devices backend which probably was not the idea when adding the
iio-backend feature in the first place.

Regarding the comment, perhaps something like

/**
 * Backend provided features are optional. If a compatible backend is
 * not present all features might not be available. If the system
 * otherwise provides a path for the data, the device will still be
 * fully functional.
 **/

> 
> I can think of some setups where I'd be fine with this change and others
> where I'd push back harder.

Given the explanations above, I'd be happy to have some more feedback on
this.

Thanks,
Tomas


> 
> Jonathan
>