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

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

On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
> Hi Nuno,
> 
> On 14/01/2026 15:32, Nuno Sá wrote:
> > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> > > To facilitate backends with different set of features, add support
> > > for defining capabilites provided by the backend. These capabilites
> > > typically extend beyond a single operation and are therefore not
> > > directly linked to if a single function call is implemented or not.
> > > Furthermore, the capabilites determine if a certain set of operations
> > > should be attempted, or skipped by the frontend. This way
> > > the frontend driver can work with a minimalistic set of features and
> > > still have the device in fully functional state.
> > > 
> > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> > > ---
> > 
> > Hi Tomas,
> > 
> > > Changes in v3:
> > > - Reduce set of capabilities to only include calibration. The other
> > >   ones propsed in V2 can be seen as subset of calibration, or single
> > >   operation failing with opnotsupported
> > 
> > As stated in my patch comment. Using opnotsupported for buffers defeats
> > the CAPS idea.
> Please check my other reply, to me adding cap for a 1:1 mapping of a
> operation seems like duplicating the information. But of course, this
> can be viewed from different angles and it is also possible to look at
> it like that.
> 
> > 
> > 
> > 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 :)

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

- Nuno Sá