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

Message-ID: <7ac7033a-2273-4556-a605-1ea0200665a9@vaisala.com>
Date: Wed, 14 Jan 2026 17:32:03 +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 Nuno,

On 14/01/2026 15:32, Nuno Sá wrote:
> On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
>> To facilitate backends with different set of features, add support
>> for defining capabilites provided by the backend. These capabilites
>> typically extend beyond a single operation and are therefore not
>> directly linked to if a single function call is implemented or not.
>> Furthermore, the capabilites determine if a certain set of operations
>> should be attempted, or skipped by the frontend. This way
>> the frontend driver can work with a minimalistic set of features and
>> still have the device in fully functional state.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@...sala.com>
>> ---
> 
> Hi Tomas,
> 
>> Changes in v3:
>> - Reduce set of capabilities to only include calibration. The other
>>   ones propsed in V2 can be seen as subset of calibration, or single
>>   operation failing with opnotsupported
> 
> As stated in my patch comment. Using opnotsupported for buffers defeats
> the CAPS idea.
Please check my other reply, to me adding cap for a 1:1 mapping of a
operation seems like duplicating the information. But of course, this
can be viewed from different angles and it is also possible to look at
it like that.

> 
> 
> 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
allows for customer integrations with backends that differ but are of no
interest for the mainline.

Thanks,
Tomas






> 
> - Nuno Sá