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

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 21 Jan 2026 12:08:30 +0000
Tomas Melin <tomas.melin@vaisala.com> 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.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>

One question on the 'sense' of the cap that controls whether it's
always on. It's the sort of question that I'm not sure has a perfect answer.


> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..ac80abb71bbca88c3f6313d8d67b9c7ace076ceb 100644
> --- a/include/linux/iio/backend.h
> +++ b/include/linux/iio/backend.h
> @@ -84,6 +84,28 @@ enum iio_backend_filter_type {
>  	IIO_BACKEND_FILTER_TYPE_MAX
>  };
>  
> +/**
> + * 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.
> + *
> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
> + * calibration. Calibration procedure is device specific.
> + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
> + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
> + * enabled/disabled. It is always on.
I'd like opinions on this one. To me it sound backwards though I can
see why you'd go this way.
Either the backend is capable of being enabled / disabled
in which case we have to further assume at boot it is disabled
(which is the dodgy bit!)

Or the backend is always on. To me that's not a capability,
it's a limitation.

My slight preference is for a capability meaning we 'can'
do something so the 1st option.

> + */
> +enum iio_backend_capabilities {
> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
> +	IIO_BACKEND_CAP_ALWAYS_ON = BIT(2),
> +};
> +
>  /**
>   * struct iio_backend_ops - operations structure for an iio_backend
>   * @enable: Enable backend.
> @@ -179,10 +201,12 @@ struct iio_backend_ops {
>   * struct iio_backend_info - info structure for an iio_backend
>   * @name: Backend name.
>   * @ops: Backend operations.
> + * @caps: Backend capabilities. @see iio_backend_capabilities
>   */
>  struct iio_backend_info {
>  	const char *name;
>  	const struct iio_backend_ops *ops;
> +	u32 caps;
>  };
>  
>  int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
> @@ -235,6 +259,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>  			 long mask);
>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>  				 struct iio_chan_spec *chan);
> +bool iio_backend_has_caps(struct iio_backend *back, u32 caps);
>  void *iio_backend_get_priv(const struct iio_backend *conv);
>  struct iio_backend *devm_iio_backend_get(struct device *dev, const char *name);
>  struct iio_backend *devm_iio_backend_fwnode_get(struct device *dev,
>