[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260122204310.55446399@jic23-huawei>
Date: Thu, 22 Jan 2026 20:43:10 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Tomas Melin <tomas.melin@...sala.com>
Cc: Michael Hennerich <Michael.Hennerich@...log.com>, Nuno Sa
<nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, David Lechner
<dlechner@...libre.com>, Andy Shevchenko <andy@...nel.org>, Olivier Moysan
<olivier.moysan@...s.st.com>, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/4] iio: industrialio-backend: support backend
capabilities
On Wed, 21 Jan 2026 12:08:30 +0000
Tomas Melin <tomas.melin@...sala.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@...sala.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,
>
Powered by blists - more mailing lists