| 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
| ||
|
Message-ID: <1f431375-f2cb-49a7-a0bd-6c00273a3c92@vaisala.com>
Date: Mon, 19 Jan 2026 15:49:45 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: Nuno Sá <noname.nuno@...il.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
Hi,
On 14/01/2026 14:20, Nuno Sá wrote:
> 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.
That might be easier said than done. A certain capability might map to
slightly different operations on different frontend/backend combinations.
Agree on general level but I would omit this check currently.
>
>> 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.
Agreed, I will update the text.
>
>> + */
>> +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.
AFAIU this was exactly what was suggested. Citing:
>> bool iio_backend_has_capabilities(struct iio_backend *back, u32 flags)
>> (caps is fine too if we want to keep it short)
Using the longer format is not very practial. Can we keep it as
iio_backend_has_caps ?
Thanks,
Tomas
>
> - Nuno Sá
Powered by blists - more mailing lists