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: <931160a27cfcfbf55d75bf9662442988c266343f.camel@gmail.com>
Date: Fri, 16 Jan 2026 13:31:39 +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 Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:
> 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.
> 

But there's nothing you can control from Linux right?

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

My idea would be to automatically define one if we fail to find it. Naturally if we
ever add an optional() get the dummy could not be added. See how regulator_get()
handles it. That's basically what I have in mind.

- Nuno Sá