linux-kernel - Re: [PATCH v2 2/3] iio: industrialio-backend: support backend capabilities

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: <b1982479-7563-4c12-8b9e-95182e1243c6@vaisala.com>
Date: Wed, 14 Jan 2026 09:29:54 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: David Lechner <dlechner@...libre.com>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Nuno Sa <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
 Jonathan Cameron <jic23@...nel.org>, 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 v2 2/3] iio: industrialio-backend: support backend
 capabilities

Hi,

On 13/01/2026 17:18, David Lechner wrote:
> On 1/13/26 6:12 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.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@...sala.com>
>> ---
>>  drivers/iio/industrialio-backend.c | 10 ++++++++++
>>  include/linux/iio/backend.h        |  9 +++++++++
>>  2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
>> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..997ec743dc67e7cf420ff667af33b4f6a71a5377 100644
>> --- a/drivers/iio/industrialio-backend.c
>> +++ b/drivers/iio/industrialio-backend.c
>> @@ -62,6 +62,7 @@ struct iio_backend {
>>  	 * backend. Used for the debugfs directory name.
>>  	 */
>>  	u8 idx;
>> +	u32 caps;
>>  };
>>  
>>  /*
>> @@ -542,6 +543,9 @@ int devm_iio_backend_request_buffer(struct device *dev,
>>  	struct iio_backend_buffer_pair *pair;
>>  	struct iio_buffer *buffer;
>>  
>> +	if (!iio_backend_caps(back, IIO_BACKEND_CAP_BUFFERING))
>> +		return 0;
> 
> I would be inclined to return an error here and leave it up to the
> caller to decide it if is OK to ignore the error or not. Otherwise,
> the return value of 0 has two possible meanings and the caller would
> have to separately check the flags to see which one it is.

Good point. Thinking now perhaps this check should go into the frontend
side and the decision be made there whether to call this or not.

> 
> We also need to add this flag to existing backends in the same patch,
> otherwise it is going to break existing callers. (Or we could split
> it into multiple patches - 1) add new enum and fields, 2) set flags
> on existing backends - 3) introduce new checks).
If the check is moved to frontend side, this might change slightly. But
I agree, this needs to be kept in mind.

> 
>> +
>>  	pair = devm_kzalloc(dev, sizeof(*pair), GFP_KERNEL);
>>  	if (!pair)
>>  		return -ENOMEM;
>> @@ -774,6 +778,12 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>>  }
>>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>>  
>> +int iio_backend_caps(struct iio_backend *back, u32 cap)
> 
> This would be more understandable to me as:
> 
> bool iio_backend_has_capabilities(struct iio_backend *back, u32 flags)
> 
> (caps is fine too if we want to keep it short)
Ok, sounds good to me.

> 
> Also could use kerneldoc comments.
> 
>> +{
>> +	return back->caps & cap;
>> +}
>> +EXPORT_SYMBOL_NS_GPL(iio_backend_caps, "IIO_BACKEND");
>> +
>>  static void iio_backend_release(void *arg)
>>  {
>>  	struct iio_backend *back = arg;
>> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
>> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..c020bc48cc05d6fcea00d23e471b12a29b5c0551 100644
>> --- a/include/linux/iio/backend.h
>> +++ b/include/linux/iio/backend.h
>> @@ -84,6 +84,12 @@ enum iio_backend_filter_type {
>>  	IIO_BACKEND_FILTER_TYPE_MAX
>>  };
>>  
>> +enum iio_backend_capabilities {
>> +	IIO_BACKEND_CAP_TEST_PATTERNS = BIT(0),
>> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
>> +	IIO_BACKEND_CAP_CALIBRATION = BIT(2)
>> +};
> 
> These could use kernel doc comments the specifically call out the
> functions that these correspond to. And also an explanation on why
> we don't have them for everything (I assume we are just adding them
> on an as-needed basis).
Sure, will add doc and comment about the usage.

Thanks for the review,
Tomas


> 
>> +
>>  /**
>>   * struct iio_backend_ops - operations structure for an iio_backend
>>   * @enable: Enable backend.
>> @@ -179,10 +185,12 @@ struct iio_backend_ops {
>>   * struct iio_backend_info - info structure for an iio_backend
>>   * @name: Backend name.
>>   * @ops: Backend operations.
>> + * @caps: 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 +243,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_caps(struct iio_backend *back, u32 cap);
>>  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,
>>
>