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] [day] [month] [year] [list]

Message-ID:
 <AMBPR06MB1036581C0CC704B85E159B7EDFDABA@AMBPR06MB10365.eurprd06.prod.outlook.com>
Date: Wed, 17 Dec 2025 10:39:37 +0000
From: Tomas Melin <tomas.melin@...sala.com>
To: 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>, David Lechner
	<dlechner@...libre.com>, 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 17/12/2025 11:26, Nuno Sá wrote:
> On Tue, 2025-12-16 at 15:39 +0000, 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.
> 
> Hmm, ideally I would then like to see the backend driver upstreamed...

First of all, as I responded in another thread, there is certainly real
use case behind this, I would not be suggesting it otherwise.

Driver for custom backend would not be of any interest for mainline
kernel as the IP would not be publicly available. So nobody could really
use such a driver, nor would it be accepted. The default ADI backend is
 a different story, as it is available and documented.

> 
>> 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?
>>
> 
> I mean, I don't love this and I'm not really sure I'm ok with it. These are fairly
> high speed devices which often do require an FPGA IP to handle the data flow. Now
> we can ignore the backend device (which is an essential piece) being it
> expected or not.
> 
> Or maybe we can just do something like regulators and get a dummy backend or just add
> some fixed kind of backend. Bottom line is, it still seems the backend device is a core
> piece in your design and we're just hacking around the driver in way that conceptually
> doesn't make sense to me.

I considered the idea of dummy backend, but in the end it doesn't make much sense to me.
These ADCs can work perfectly fine with a minimalistic custom backend that does exactly
what the design needs, without the need for basically any configuration.
So the ADCs rely on some sort of backend, ofcourse, but they are in the end standalone
devices that can be integrated in many ways, the adi backend being only one such option.

Another problem with a dummy backend is that for example calibration cannot really
work. It expects certain features from the backend to be available, etc. Similarly would
a custom backend connected need to implemented exactly same test features as the
backend now assumes.

> Other question that comes to mind (I guess I was not that clear)... Do you have a real
> usecase with your own custom backend IP or is this just theoretical?

This dependency on the adi hdl has been causing me problems over the years for a
number of adi devices, and the iio-backend has been a step in the right direction.
I hope we can take this further in direction that allows use cases that
were not expected from the beginning but are still valid.

Thanks,
Tomas

> 
> - Nuno Sá