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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <acc10955a646b13da7ff191149b8f62181fbac5c.camel@gmail.com>
Date: Sun, 18 Jan 2026 09:21:05 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Tomas Melin <tomas.melin@...sala.com>, Michael Hennerich	
 <Michael.Hennerich@...log.com>, Nuno Sa <nuno.sa@...log.com>, Lars-Peter
 Clausen <lars@...afoo.de>, David Lechner <dlechner@...libre.com>, Andy
 Shevchenko <andy@...nel.org>,  Olivier Moysan <olivier.moysan@...s.st.com>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/4] iio: adc: ad9467: Support alternative backends

On Fri, 2026-01-16 at 18:37 +0000, Jonathan Cameron wrote:
> On Fri, 16 Jan 2026 13:31:39 +0000
> Nuno Sá <noname.nuno@...il.com> wrote:
> 
> > 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.
> > 
> It's an interesting idea, but I'd like some input from DT folk on this.
> The fake regulators thing is kind of legacy from lots of drivers gaining the
> power handling later and it being boring / too late to add all the fixed regs
> to DT.  This is a much less common case and I find it a little unlikely there
> is nothing useful to know about where the data is going - so how useful
> is an autocreated backend?
> 

Not really that useful. This was just something I thought of to have the full usecase
supported in Linux. But, if we can add an explicit fixed/dummy (whatever name fits
best) backend with a proper compatible that would be preferable, yes.

- Nuno Sá