Message-ID: <20260116183724.18063cec@jic23-huawei>
Date: Fri, 16 Jan 2026 18:37:24 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>
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, 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?

Jonathan

> - Nuno Sá

Powered by blists - more mailing lists