Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

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

On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
> On 1/30/26 3:16 AM, Tomas Melin wrote:
> > Not all backends support the full set of capabilities provided by the
> > industrialio-backend framework. Capability bits can be used in frontends
> > and backends for checking for a certain feature set, or if using
> > related functions can be expected to fail.
> > 
> > Capability bits should be set by a compatible backend and provided when
> > registering the backend.
> > 
> 
> ...
> 
> > +/**
> > + * enum iio_backend_capabilities - Backend capabilities
> > + * Backend capabilities can be used by frontends to check if a given
> > + * functionality is supported by the backend. This is useful for frontend
> > + * devices which are expected to work with alternative backend
> > + * implementations. Capabilities are loosely coupled with operations,
> > + * meaning that a capability requires certain operations to be implemented
> > + * by the backend. A capability might be mapped to a single operation or
> > + * multiple operations.
> 
> It would be helpful to list these operations explicitly for each
> enum member.
> 
> > + *
> > + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
> > + * calibration. Calibration procedure is device specific.
> > + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
> 
> I assume this means it supports devm_iio_backend_request_buffer()?
> 
> In IIO, we usually say "buffer" and rarely "buffering" so this name and
> description is a bit confusing to me.
> 
> > + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
> > + * enabled/disabled. It is always on.
> 
> Do we actually need this one? Alternative could be, for example:
> 
> int iio_backend_enable(struct iio_backend *back)
> {
> 	int ret;
> 
> 	ret = iio_backend_op_call(back, enable);
> 	
> 	return ret == -EOPNOTSUPP ? 0 : ret;
> }

I would prefer not to assume we can ignore the backend not supporting
the call. It opens up the question for other operations.

My preferred way for this kind of fundamental operation (enabling/disabling)
would be to check with DT maintainers if we could have some kind of fixed-backend
(fixed in the sense the HW is present but not controlled by Linux) dummy device that
with implement a no-OP enable/disable().

- Nuno Sá