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: <5896ab55e0d23d235908f9f592c8a7975428dc54.camel@gmail.com>
Date: Thu, 15 Jan 2026 12:04:37 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Tomas Melin <tomas.melin@...sala.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

On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
> 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

Well, I would argue your backend is exactly that. A dummy one :)

> 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.

- Nuno Sá