lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fda7d715e2cab2545c9ecdeead22d8a58ae5032d.camel@gmail.com>
Date: Wed, 14 Jan 2026 12:20:26 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Tomas Melin <tomas.melin@...sala.com>, Michael Hennerich	
 <Michael.Hennerich@...log.com>, Nuno Sa <nuno.sa@...log.com>, Lars-Peter
 Clausen <lars@...afoo.de>, Jonathan Cameron <jic23@...nel.org>, David
 Lechner	 <dlechner@...libre.com>, Andy Shevchenko <andy@...nel.org>,
 Olivier Moysan	 <olivier.moysan@...s.st.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/4] iio: industrialio-backend: support backend
 capabilities

On Wed, 2026-01-14 at 10:45 +0000, 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.
> 
> Signed-off-by: Tomas Melin <tomas.melin@...sala.com>
> ---
>  drivers/iio/industrialio-backend.c | 17 +++++++++++++++++
>  include/linux/iio/backend.h        | 17 +++++++++++++++++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..0a98fdd5df9db6cc233af819ac5243ba8cd5266f 100644
> --- a/drivers/iio/industrialio-backend.c
> +++ b/drivers/iio/industrialio-backend.c
> @@ -56,6 +56,7 @@ struct iio_backend {
>  	void *priv;
>  	const char *name;
>  	unsigned int cached_reg_addr;
> +	u32 caps;
>  	/*
>  	 * This index is relative to the frontend. Meaning that for
>  	 * frontends with multiple backends, this will be the index of this
> @@ -774,6 +775,21 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>  }
>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>  
> +/**
> + * iio_backend_has_caps - Check if backend has specific capabilities
> + * @back: Backend device
> + * @caps: Capabilities to check
> + *
> + * RETURNS:
> + * Non-zero value if backend has all the requested capabilities,
> + * 0 otherwise.
> + */
> +int iio_backend_has_caps(struct iio_backend *back, u32 caps)
> +{
> +	return back->caps & caps;
> +}
> +EXPORT_SYMBOL_NS_GPL(iio_backend_has_caps, "IIO_BACKEND");
> +
>  static void iio_backend_release(void *arg)
>  {
>  	struct iio_backend *back = arg;
> @@ -1114,6 +1130,7 @@ int devm_iio_backend_register(struct device *dev,
>  
>  	back->ops = info->ops;
>  	back->name = info->name;
> +	back->caps = info->caps;

It would be nice to sanity check the registered backend here. If it advertises some capability,
then better to support the corresponding op.

>  	back->owner = dev->driver->owner;
>  	back->dev = dev;
>  	back->priv = priv;
> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..8a0df8e980e910ac2d5398275963dc5adf077c8a 100644
> --- a/include/linux/iio/backend.h
> +++ b/include/linux/iio/backend.h
> @@ -84,6 +84,20 @@ 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. Capabilities are loosely
> + * coupled with operations, meaning that a capability requires certain
> + * operations to be implemented by the backend.
> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports calibration. Needs at least
> + * iodelay_set(), test_pattern_set() data_sample_trigger(), chan_status()
> + * and data_format_set() operations implemented.

I would not be so explicit as the above. It is very specific to the ad9467 process.
There are other devices with other ways of calibrating the interface and I don't want
people to keep adding things into the comment. So it needs to be a bit more generic
and we should also be more explicit about it being about calibrating the data interface.

> + */
> +enum iio_backend_capabilities {
> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
> +};
> +
>  /**
>   * struct iio_backend_ops - operations structure for an iio_backend
>   * @enable: Enable backend.
> @@ -179,10 +193,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 +251,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);
> +int iio_backend_has_caps(struct iio_backend *back, u32 caps);

Not what David suggested and I do agree with him FWIW.

- Nuno Sá

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ