linux-kernel - Re: [PATCH v4 1/4] 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: <86840afc-b21d-4637-815b-65615610363c@vaisala.com>
Date: Fri, 23 Jan 2026 07:38:55 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: Jonathan Cameron <jic23@...nel.org>
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

Hi,

On 22/01/2026 22:43, Jonathan Cameron wrote:
> 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.
Agreed, it is not as clear as the other bits. I'll give my reasoning below.

> 
> 
>> 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.
I pondered about this too, but ended up having the bit this way around.
The logic being that backend is capable of working even if not
explicitly enabled/disabled. So looking at it from that perspective it
would be a capability. And assumption being that typically the
enabling/disabling is required, checking if the capability to omit
enabling seemed logical to me.

Thanks,
Tomas

> 
> 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,
>>
>