linux-kernel - Re: [PATCH v3 0/4] iio: adc: ad9467: Support alternative backends

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: <41cac06c-8db2-4a52-854f-659606d89121@vaisala.com>
Date: Thu, 15 Jan 2026 15:30:55 +0200
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>,
 Olivier Moysan <olivier.moysan@...s.st.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/4] iio: adc: ad9467: Support alternative backends

Hi,

On 15/01/2026 14:04, Nuno Sá wrote:
> On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
>> Hi Nuno,
>>
>> On 14/01/2026 15:32, Nuno Sá wrote:

>>>
>>> But more importantly, how are your usecase supposed to work with this
>>> series? I'm not seeing any new backend being added as part of the series.
>>> Point is, if we are adding all of this, I would expect your usecase to
>>> have fully upstream support. If I'm not missing nothing, we would at least
>>> need a dummy backend providing stubs for enable()/disable()
>> My usecase adds simplistic backend support and registers to the
>> framework via an related driver. So that use case works with that
>> approach. I think it is better to assume there is always some entity
>> that can take on the role of being backend, rather than adding a dummy
>> backend. Adding the capabilities are defining role here, as having that
> 
> Well, I would argue your backend is exactly that. A dummy one :)

It's kindof ;)  But on general level it handles the stuff a backend
needs to do, just does not have most of the operations or capabilities
available. OTOH having the backend defined means that if some of the
capabilites would be added, there is a natural place to add it.

> 
>> allows for customer integrations with backends that differ but are of no
>> interest for the mainline.
>>
> 
> It would still be nice to have this usecase fully supported upstream 
> (having a black box backend). 
> 
> What I have in mind would be really to do the same as regulators do. If you call
> regulator_get() then the consumer really assumes a regulator must exist. But if it
> is something the kernel does not control we get a dummy one with very limited
> functionality/stubs. If you call regulator_get_optional(), then the regulator is
> really optional and might not physically exist. Seems very similar to what you have.

There could perhaps be use for a backend like this too. Is the idea such
that one would still need to define a "iio-backend-simple" node or such
to device tree which would then provide the backend link and compatible?

Thanks,
Tomas

> 
> - Nuno Sá