Re: [PATCH v3 0/4] iio: adc: ad9467: Support alternative backends

["Nuno Sá" <noname.nuno@gmail.com>]

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@gmail.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á