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

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

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á