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: <84bb3751-178f-4577-9952-2b3ad5d11dad@vaisala.com>
Date: Wed, 17 Dec 2025 05:38:05 +0000
From: Tomas Melin <tomas.melin@...sala.com>
To: David Lechner <dlechner@...libre.com>, Nuno Sá
	<noname.nuno@...il.com>, Michael Hennerich <Michael.Hennerich@...log.com>,
	Nuno Sa <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, Jonathan
 Cameron <jic23@...nel.org>, Andy Shevchenko <andy@...nel.org>
CC: "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

Hi,

On 16/12/2025 23:27, David Lechner wrote:
> On 12/16/25 9:39 AM, Tomas Melin wrote:
>> Hi,
>>
>> On 16/12/2025 14:56, Nuno Sá wrote:
>>> On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin 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>
>>>> ---
>>>
>>> Which users? The only usecases (for all the supported devices) we have require
>>> the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
>>> prefer an explicit boolean in the chip_info struture for the device(s) we know this
>>> can happen (unless you have a usecase for all :)).
>>
>> This is generically for all the devices supported by the ad9467, not
>> only a specific device. So it's about how this is used as part of the
>> design.
>>
>> This is aimed at users that do not use the ADI HDL reference backend
>> with these devices, but instead have custom backends suited for their
>> own needs.
> 
> If you have your own backend, why would it not use the IIO backend
> framework?
> 
> I can understand if this custom backend sends the data somewhere else
> besides an IIO buffer and we don't want to create the buffer for the IIO
> device. But I would still think that there needs to be some sort of
> communication between the IIO device and the backend.

True, there needs to some kind of backend, but they don't all have iio
backends or other kernel drivers. Data will flow when the device starts
sending without much further need to configure. Adding a backend driver
in these cases could have some benefits, but often it would just be an
unneeded complication.

And even if there were a custom iio-backend available, it would not be
compatible with the current assumptions about ADI backend wrt
calibration, test mode enabling and iio buffering. So having a strict
dependency on an iio-backend does not really work in a generic use case.

> 
> Maybe you could explain more how this custom backend is intended to work?

I hope the explanation above helps. There is real use case behind, this
is not some imaginary nice to have feature. Before the introduction of
the iio backend, the driver was even more dependent on the backend. At
that point, needed to carry some out of tree patches to remove the
dependency and make it a standalone iio driver. Thankfully with the
introduction of the iio-backend, this is now more loosely coupled and I
see opportunity for making this standalone mode possible also in mainline.

Thanks,
Tomas

> 
>> In that case, we need to be able to skip the backend registration and
>> register device as a standalone iio device.
>>
>> Hopefully this made the use case clearer?
>>
>> Thanks,
>> Tomas
>>
>>
>>>
>>> - Nuno Sá
>>>
>>
>