[PATCH v5 0/4] iio: adc: ad9467: Support alternative backends

[PATCH v5 0/4] iio: adc: ad9467: Support alternative backends

[Tomas Melin]

To facilitate backends with different set of features, add support
for defining capabilities provided by the backend. These capabilities
typically extend beyond a single operation and are therefore not
directly linked to if a single function call is implemented or not.
Furthermore, the capabilities determine if a certain set of operations
should be attempted, or skipped by the frontend. This way
the frontend driver can work with a minimalistic set of features and
still have the device in fully functional state.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
Changes in v5:
- As per recommendation, use guard for whole block
- Typo fix in commit message and cover letter
- Link to v4: https://lore.kernel.org/r/20260121-b4-ad9467-optional-backend-v4-0-18d2c0d450cc@vaisala.com

Changes in v4:
- Readd CAP_BUFFERING and also add CAP_ALWAYS_ON to support backends
  that do not need explicit enable/disable
- Don't mix checks for eopnotsupp and caps. Prefer capability checking
  also for caps that map to single operation
- Move capability checking to top of call stack
- Revise iio_backend_has_caps to use bool signature and fixup semantics
- Amend documentation texts
- Add capability checks for axi-dac
- Drop two's complement patch from this series, already applied
- Link to v3: https://lore.kernel.org/r/20260114-b4-ad9467-optional-backend-v3-0-d2c84979d010@vaisala.com

Changes in v3:
- Reduce set of capabilities to only include calibration. The other
  ones propsed in V2 can be seen as subset of calibration, or single
  operation failing with opnotsupported
- Rename backends checking function
- Relocate caps field inside backend struct (pahole)
- Add kernel-docs
- Add capabilites for exisiting backend variants
- Link to v2: https://lore.kernel.org/r/20260113-b4-ad9467-optional-backend-v2-0-0a27e7e72f41@vaisala.com

Changes in v2:
- Added industrialio-backend capabilities feature
- Removed acceptance for fully optional backend, instead require atleast
  minimalistic backend to exist
- Switched to FIELD_MODIFY()
- Fixed kernel test robot reported failure for missing bitfield.h
- Link to v1: https://lore.kernel.org/r/20251216-b4-ad9467-optional-backend-v1-0-83e61531ef4d@vaisala.com

---
Tomas Melin (4):
      iio: industrialio-backend: support backend capabilities
      iio: adc: adi-axi-adc: define supported iio-backend capabilities
      iio: dac: adi-axi-dac: define supported iio-backend capabilities
      iio: adc: ad9467: check for backend capabilities

 drivers/iio/adc/ad9467.c           | 69 ++++++++++++++++++++++++--------------
 drivers/iio/adc/adi-axi-adc.c      |  3 ++
 drivers/iio/dac/adi-axi-dac.c      |  2 ++
 drivers/iio/industrialio-backend.c | 16 +++++++++
 include/linux/iio/backend.h        | 25 ++++++++++++++
 5 files changed, 89 insertions(+), 26 deletions(-)
---
base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7

Best regards,
--  
Tomas Melin <tomas.melin@vaisala.com>

[PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

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@vaisala.com>
---
 drivers/iio/industrialio-backend.c | 16 ++++++++++++++++
 include/linux/iio/backend.h        | 25 +++++++++++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
index 447b694d6d5f..1afd00763da9 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,20 @@ 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:
+ * True if backend has all the requested capabilities, false otherwise.
+ */
+bool iio_backend_has_caps(struct iio_backend *back, u32 caps)
+{
+	return (back->caps & 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 +1129,7 @@ int devm_iio_backend_register(struct device *dev,
 
 	back->ops = info->ops;
 	back->name = info->name;
+	back->caps = info->caps;
 	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 7f815f3fed6a..ac80abb71bbc 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.
+ */
+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,

-- 
2.47.3

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[David Lechner]

On 1/30/26 3:16 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.
> 

...

> +/**
> + * 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.

It would be helpful to list these operations explicitly for each
enum member.

> + *
> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
> + * calibration. Calibration procedure is device specific.
> + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.

I assume this means it supports devm_iio_backend_request_buffer()?

In IIO, we usually say "buffer" and rarely "buffering" so this name and
description is a bit confusing to me.

> + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
> + * enabled/disabled. It is always on.

Do we actually need this one? Alternative could be, for example:

int iio_backend_enable(struct iio_backend *back)
{
	int ret;

	ret = iio_backend_op_call(back, enable);
	
	return ret == -EOPNOTSUPP ? 0 : ret;
}

Or make a iio_backend_optional_op_call() macro.

Or if there is some other nuance where this capability makes a
difference, it should be explained in more detail.


> + */
> +enum iio_backend_capabilities {

Documenting members like this works too (saves a bit of cross-referencing).

	/** @IIO_BACKEND_CAP_CALIBRATION: ... */
> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
> +	IIO_BACKEND_CAP_ALWAYS_ON = BIT(2),
> +};

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Nuno Sá]

On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
> On 1/30/26 3:16 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.
> > 
> 
> ...
> 
> > +/**
> > + * 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.
> 
> It would be helpful to list these operations explicitly for each
> enum member.
> 
> > + *
> > + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
> > + * calibration. Calibration procedure is device specific.
> > + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
> 
> I assume this means it supports devm_iio_backend_request_buffer()?
> 
> In IIO, we usually say "buffer" and rarely "buffering" so this name and
> description is a bit confusing to me.
> 
> > + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
> > + * enabled/disabled. It is always on.
> 
> Do we actually need this one? Alternative could be, for example:
> 
> int iio_backend_enable(struct iio_backend *back)
> {
> 	int ret;
> 
> 	ret = iio_backend_op_call(back, enable);
> 	
> 	return ret == -EOPNOTSUPP ? 0 : ret;
> }

I would prefer not to assume we can ignore the backend not supporting
the call. It opens up the question for other operations.

My preferred way for this kind of fundamental operation (enabling/disabling)
would be to check with DT maintainers if we could have some kind of fixed-backend
(fixed in the sense the HW is present but not controlled by Linux) dummy device that
with implement a no-OP enable/disable().

- Nuno Sá

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 02/02/2026 12:28, Nuno Sá wrote:
> On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:

>>
>> Do we actually need this one? Alternative could be, for example:
>>
>> int iio_backend_enable(struct iio_backend *back)
>> {
>> 	int ret;
>>
>> 	ret = iio_backend_op_call(back, enable);
>> 	
>> 	return ret == -EOPNOTSUPP ? 0 : ret;
>> }
> 
> I would prefer not to assume we can ignore the backend not supporting
> the call. It opens up the question for other operations.
> 
> My preferred way for this kind of fundamental operation (enabling/disabling)
> would be to check with DT maintainers if we could have some kind of fixed-backend
> (fixed in the sense the HW is present but not controlled by Linux) dummy device that
> with implement a no-OP enable/disable().

There is also use cases for the always_on cap with a configurable
non-dummy backend. Some applications are such that the driver should
leave the enabling/disabling up to the user space consuming the data.
For this case it's great to have the frontend leave the backend enable
alone using this capability.

thanks,
Tomas


> 
> - Nuno Sá

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Nuno Sá]

On Mon, 2026-02-02 at 13:08 +0200, Tomas Melin wrote:
> Hi,
> 
> On 02/02/2026 12:28, Nuno Sá wrote:
> > On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
> 
> > > 
> > > Do we actually need this one? Alternative could be, for example:
> > > 
> > > int iio_backend_enable(struct iio_backend *back)
> > > {
> > > 	int ret;
> > > 
> > > 	ret = iio_backend_op_call(back, enable);
> > > 	
> > > 	return ret == -EOPNOTSUPP ? 0 : ret;
> > > }
> > 
> > I would prefer not to assume we can ignore the backend not supporting
> > the call. It opens up the question for other operations.
> > 
> > My preferred way for this kind of fundamental operation (enabling/disabling)
> > would be to check with DT maintainers if we could have some kind of fixed-backend
> > (fixed in the sense the HW is present but not controlled by Linux) dummy device that
> > with implement a no-OP enable/disable().
> 
> There is also use cases for the always_on cap with a configurable
> non-dummy backend. Some applications are such that the driver should
> leave the enabling/disabling up to the user space consuming the data.
> For this case it's great to have the frontend leave the backend enable
> alone using this capability.
> 

I would argue the above would be something to take care at the frontend level. The way
I see it, the always_on cap is pretty much saying that we can't really control the on/off state
of the backing device and we just assume it's on. 

If we can control it but we need it always on (for some specific usecase), I would say that should
be handled at the frontend and just enable the backend once. Also note that as of now, I think all
of the users (or most at least) we have just enable the backend during probe and leave it on until
we unbind the device.

- Nuno Sá

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 02/02/2026 14:40, Nuno Sá wrote:
> On Mon, 2026-02-02 at 13:08 +0200, Tomas Melin wrote:
>> Hi,
>>
>> On 02/02/2026 12:28, Nuno Sá wrote:
>>> On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
>>
>>>>
>>>> Do we actually need this one? Alternative could be, for example:
>>>>
>>>> int iio_backend_enable(struct iio_backend *back)
>>>> {
>>>> 	int ret;
>>>>
>>>> 	ret = iio_backend_op_call(back, enable);
>>>> 	
>>>> 	return ret == -EOPNOTSUPP ? 0 : ret;
>>>> }
>>>
>>> I would prefer not to assume we can ignore the backend not supporting
>>> the call. It opens up the question for other operations.
>>>
>>> My preferred way for this kind of fundamental operation (enabling/disabling)
>>> would be to check with DT maintainers if we could have some kind of fixed-backend
>>> (fixed in the sense the HW is present but not controlled by Linux) dummy device that
>>> with implement a no-OP enable/disable().
>>
>> There is also use cases for the always_on cap with a configurable
>> non-dummy backend. Some applications are such that the driver should
>> leave the enabling/disabling up to the user space consuming the data.
>> For this case it's great to have the frontend leave the backend enable
>> alone using this capability.
>>
> 
> I would argue the above would be something to take care at the frontend level. The way
> I see it, the always_on cap is pretty much saying that we can't really control the on/off state
> of the backing device and we just assume it's on. 
> 
> If we can control it but we need it always on (for some specific usecase), I would say that should
> be handled at the frontend and just enable the backend once. Also note that as of now, I think all
> of the users (or most at least) we have just enable the backend during probe and leave it on until
> we unbind the device.

Yes, this is debatable. It's not necessarily always on, but should not
be enabled/touched by the frontend during probe.
But anyways, having a capability that says if the enable/disable feature
is available, is in any case useful and what I was planning on
leveraging in my use case.
Fundamentally, with the capabilites as now proposed, it is possible to
select what features of the ad9467 are available, in addition to the
basic requirements.

The ALWAYS_ON capability could be inverted, like CAP_HAS_ENABLE_DISABLE,
but to me, the ALWAYS_ON naming still seems the better option.

Thanks,
Tomas


> 
> - Nuno Sá
> 
> 

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[David Lechner]

On 2/2/26 7:04 AM, Tomas Melin wrote:
> Hi,
> 
> On 02/02/2026 14:40, Nuno Sá wrote:
>> On Mon, 2026-02-02 at 13:08 +0200, Tomas Melin wrote:
>>> Hi,
>>>
>>> On 02/02/2026 12:28, Nuno Sá wrote:
>>>> On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
>>>
>>>>>
>>>>> Do we actually need this one? Alternative could be, for example:
>>>>>
>>>>> int iio_backend_enable(struct iio_backend *back)
>>>>> {
>>>>> 	int ret;
>>>>>
>>>>> 	ret = iio_backend_op_call(back, enable);
>>>>> 	
>>>>> 	return ret == -EOPNOTSUPP ? 0 : ret;
>>>>> }
>>>>
>>>> I would prefer not to assume we can ignore the backend not supporting
>>>> the call. It opens up the question for other operations.
>>>>
>>>> My preferred way for this kind of fundamental operation (enabling/disabling)
>>>> would be to check with DT maintainers if we could have some kind of fixed-backend
>>>> (fixed in the sense the HW is present but not controlled by Linux) dummy device that
>>>> with implement a no-OP enable/disable().
>>>
>>> There is also use cases for the always_on cap with a configurable
>>> non-dummy backend. Some applications are such that the driver should
>>> leave the enabling/disabling up to the user space consuming the data.
>>> For this case it's great to have the frontend leave the backend enable
>>> alone using this capability.
>>>
>>
>> I would argue the above would be something to take care at the frontend level. The way
>> I see it, the always_on cap is pretty much saying that we can't really control the on/off state
>> of the backing device and we just assume it's on. 
>>
>> If we can control it but we need it always on (for some specific usecase), I would say that should
>> be handled at the frontend and just enable the backend once. Also note that as of now, I think all
>> of the users (or most at least) we have just enable the backend during probe and leave it on until
>> we unbind the device.
> 
> Yes, this is debatable. It's not necessarily always on, but should not
> be enabled/touched by the frontend during probe.
> But anyways, having a capability that says if the enable/disable feature
> is available, is in any case useful and what I was planning on
> leveraging in my use case.
> Fundamentally, with the capabilites as now proposed, it is possible to
> select what features of the ad9467 are available, in addition to the
> basic requirements.
> 
> The ALWAYS_ON capability could be inverted, like CAP_HAS_ENABLE_DISABLE,
> but to me, the ALWAYS_ON naming still seems the better option.
> 

Ah, this is what Jonathan mentioned before about this really being a
restriction rather than a capability.

Perhaps we should have a separate restrictions/quirks flag? If the flag
means "do not enable during probe" then a better name would be
*_DO_NOT_ENABLE_AT_PROBE.

And I agree with Nuno that if the backend can be enabled/disabled later
(after probe), it should still be managed through the frontend driver.
There should be no usespace access directly to the backend without going
through the frontend.

In this case, I guess we could call it a capability still. But I would
call it something like *_DEFERABLE_ENABLE or something like that. The
logic would be something like:

int probe() {
	...

	if (_DEFERABLE_ENABLE) {
		/* Basically equivalent to buffer enable, but there is no buffer. */
		register_userspace_enable_attribute();
	else
		iio_backend_enable(backend);

	...
}

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 02/02/2026 17:50, David Lechner wrote:
> On 2/2/26 7:04 AM, Tomas Melin wrote:
>> Hi,
>>
>> On 02/02/2026 14:40, Nuno Sá wrote:
>>> On Mon, 2026-02-02 at 13:08 +0200, Tomas Melin wrote:
>>>> Hi,
>>>>
>>>> On 02/02/2026 12:28, Nuno Sá wrote:
>>>>> On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
>>>>
>>>>>>
>>>>>> Do we actually need this one? Alternative could be, for example:
>>>>>>
>>>>>> int iio_backend_enable(struct iio_backend *back)
>>>>>> {
>>>>>> 	int ret;
>>>>>>
>>>>>> 	ret = iio_backend_op_call(back, enable);
>>>>>> 	
>>>>>> 	return ret == -EOPNOTSUPP ? 0 : ret;
>>>>>> }
>>>>>
>>>>> I would prefer not to assume we can ignore the backend not supporting
>>>>> the call. It opens up the question for other operations.
>>>>>
>>>>> My preferred way for this kind of fundamental operation (enabling/disabling)
>>>>> would be to check with DT maintainers if we could have some kind of fixed-backend
>>>>> (fixed in the sense the HW is present but not controlled by Linux) dummy device that
>>>>> with implement a no-OP enable/disable().
>>>>
>>>> There is also use cases for the always_on cap with a configurable
>>>> non-dummy backend. Some applications are such that the driver should
>>>> leave the enabling/disabling up to the user space consuming the data.
>>>> For this case it's great to have the frontend leave the backend enable
>>>> alone using this capability.
>>>>
>>>
>>> I would argue the above would be something to take care at the frontend level. The way
>>> I see it, the always_on cap is pretty much saying that we can't really control the on/off state
>>> of the backing device and we just assume it's on. 
>>>
>>> If we can control it but we need it always on (for some specific usecase), I would say that should
>>> be handled at the frontend and just enable the backend once. Also note that as of now, I think all
>>> of the users (or most at least) we have just enable the backend during probe and leave it on until
>>> we unbind the device.
>>
>> Yes, this is debatable. It's not necessarily always on, but should not
>> be enabled/touched by the frontend during probe.
>> But anyways, having a capability that says if the enable/disable feature
>> is available, is in any case useful and what I was planning on
>> leveraging in my use case.
>> Fundamentally, with the capabilites as now proposed, it is possible to
>> select what features of the ad9467 are available, in addition to the
>> basic requirements.
>>
>> The ALWAYS_ON capability could be inverted, like CAP_HAS_ENABLE_DISABLE,
>> but to me, the ALWAYS_ON naming still seems the better option.
>>
> 
> Ah, this is what Jonathan mentioned before about this really being a
> restriction rather than a capability.
> 
> Perhaps we should have a separate restrictions/quirks flag? If the flag
> means "do not enable during probe" then a better name would be
> *_DO_NOT_ENABLE_AT_PROBE.
> 
> And I agree with Nuno that if the backend can be enabled/disabled later
> (after probe), it should still be managed through the frontend driver.
> There should be no usespace access directly to the backend without going
> through the frontend.

Thanks for the input, that use case is slightly different from normal
usage, let's keep it in mind if actually required. For now, the option
to just leave the enable/disable alone is what would help to solve
smooth integration with this device for me.

ALWAYS_ON does not seem to get much votes here, but how about calling it
something like IIO_BACKEND_CAP_AUTO_ENABLE or
IIO_BACKEND_CAP_HAS_ENABLE_DISABLE?

br,
Tomas



> 
> In this case, I guess we could call it a capability still. But I would
> call it something like *_DEFERABLE_ENABLE or something like that. The
> logic would be something like:
> 
> int probe() {
> 	...
> 
> 	if (_DEFERABLE_ENABLE) {
> 		/* Basically equivalent to buffer enable, but there is no buffer. */
> 		register_userspace_enable_attribute();
> 	else
> 		iio_backend_enable(backend);
> 
> 	...
> }
> 
> 

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[David Lechner]

On 2/3/26 3:50 AM, Tomas Melin wrote:
> Hi,
> 
> On 02/02/2026 17:50, David Lechner wrote:
>> On 2/2/26 7:04 AM, Tomas Melin wrote:
>>> Hi,
>>>
>>> On 02/02/2026 14:40, Nuno Sá wrote:
>>>> On Mon, 2026-02-02 at 13:08 +0200, Tomas Melin wrote:
>>>>> Hi,
>>>>>
>>>>> On 02/02/2026 12:28, Nuno Sá wrote:
>>>>>> On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
>>>>>
>>>>>>>
>>>>>>> Do we actually need this one? Alternative could be, for example:
>>>>>>>
>>>>>>> int iio_backend_enable(struct iio_backend *back)
>>>>>>> {
>>>>>>> 	int ret;
>>>>>>>
>>>>>>> 	ret = iio_backend_op_call(back, enable);
>>>>>>> 	
>>>>>>> 	return ret == -EOPNOTSUPP ? 0 : ret;
>>>>>>> }
>>>>>>
>>>>>> I would prefer not to assume we can ignore the backend not supporting
>>>>>> the call. It opens up the question for other operations.
>>>>>>
>>>>>> My preferred way for this kind of fundamental operation (enabling/disabling)
>>>>>> would be to check with DT maintainers if we could have some kind of fixed-backend
>>>>>> (fixed in the sense the HW is present but not controlled by Linux) dummy device that
>>>>>> with implement a no-OP enable/disable().
>>>>>
>>>>> There is also use cases for the always_on cap with a configurable
>>>>> non-dummy backend. Some applications are such that the driver should
>>>>> leave the enabling/disabling up to the user space consuming the data.
>>>>> For this case it's great to have the frontend leave the backend enable
>>>>> alone using this capability.
>>>>>
>>>>
>>>> I would argue the above would be something to take care at the frontend level. The way
>>>> I see it, the always_on cap is pretty much saying that we can't really control the on/off state
>>>> of the backing device and we just assume it's on. 
>>>>
>>>> If we can control it but we need it always on (for some specific usecase), I would say that should
>>>> be handled at the frontend and just enable the backend once. Also note that as of now, I think all
>>>> of the users (or most at least) we have just enable the backend during probe and leave it on until
>>>> we unbind the device.
>>>
>>> Yes, this is debatable. It's not necessarily always on, but should not
>>> be enabled/touched by the frontend during probe.
>>> But anyways, having a capability that says if the enable/disable feature
>>> is available, is in any case useful and what I was planning on
>>> leveraging in my use case.
>>> Fundamentally, with the capabilites as now proposed, it is possible to
>>> select what features of the ad9467 are available, in addition to the
>>> basic requirements.
>>>
>>> The ALWAYS_ON capability could be inverted, like CAP_HAS_ENABLE_DISABLE,
>>> but to me, the ALWAYS_ON naming still seems the better option.
>>>
>>
>> Ah, this is what Jonathan mentioned before about this really being a
>> restriction rather than a capability.
>>
>> Perhaps we should have a separate restrictions/quirks flag? If the flag
>> means "do not enable during probe" then a better name would be
>> *_DO_NOT_ENABLE_AT_PROBE.
>>
>> And I agree with Nuno that if the backend can be enabled/disabled later
>> (after probe), it should still be managed through the frontend driver.
>> There should be no usespace access directly to the backend without going
>> through the frontend.
> 
> Thanks for the input, that use case is slightly different from normal
> usage, let's keep it in mind if actually required. For now, the option
> to just leave the enable/disable alone is what would help to solve
> smooth integration with this device for me.
> 
> ALWAYS_ON does not seem to get much votes here, but how about calling it
> something like IIO_BACKEND_CAP_AUTO_ENABLE or
> IIO_BACKEND_CAP_HAS_ENABLE_DISABLE?
> 
IIO_BACKEND_CAP_HAS_ENABLE_DISABLE seems the most sensible given the
way it is used in the ad9467 patch. Although IIO_BACKEND_CAP_ENABLE_DISABLE
would be more consistent with the other flags being added since they
don't say _HAS_.

Probably IIO_BACKEND_CAP_ENABLE is enough to imply both if we want
to keep it shorter.

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

On 04/02/2026 03:07, David Lechner wrote:
> On 2/3/26 3:50 AM, Tomas Melin wrote:
>> Hi,
>>
>> On 02/02/2026 17:50, David Lechner wrote:
>>> On 2/2/26 7:04 AM, Tomas Melin wrote:
>>>> Hi,
>>>>
>>>> On 02/02/2026 14:40, Nuno Sá wrote:
>>>>> On Mon, 2026-02-02 at 13:08 +0200, Tomas Melin wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 02/02/2026 12:28, Nuno Sá wrote:
>>>>>>> On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
>>>>>>
>>>>>>>>
>>>>>>>> Do we actually need this one? Alternative could be, for example:
>>>>>>>>
>>>>>>>> int iio_backend_enable(struct iio_backend *back)
>>>>>>>> {
>>>>>>>> 	int ret;
>>>>>>>>
>>>>>>>> 	ret = iio_backend_op_call(back, enable);
>>>>>>>> 	
>>>>>>>> 	return ret == -EOPNOTSUPP ? 0 : ret;
>>>>>>>> }
>>>>>>>
>>>>>>> I would prefer not to assume we can ignore the backend not supporting
>>>>>>> the call. It opens up the question for other operations.
>>>>>>>
>>>>>>> My preferred way for this kind of fundamental operation (enabling/disabling)
>>>>>>> would be to check with DT maintainers if we could have some kind of fixed-backend
>>>>>>> (fixed in the sense the HW is present but not controlled by Linux) dummy device that
>>>>>>> with implement a no-OP enable/disable().
>>>>>>
>>>>>> There is also use cases for the always_on cap with a configurable
>>>>>> non-dummy backend. Some applications are such that the driver should
>>>>>> leave the enabling/disabling up to the user space consuming the data.
>>>>>> For this case it's great to have the frontend leave the backend enable
>>>>>> alone using this capability.
>>>>>>
>>>>>
>>>>> I would argue the above would be something to take care at the frontend level. The way
>>>>> I see it, the always_on cap is pretty much saying that we can't really control the on/off state
>>>>> of the backing device and we just assume it's on. 
>>>>>
>>>>> If we can control it but we need it always on (for some specific usecase), I would say that should
>>>>> be handled at the frontend and just enable the backend once. Also note that as of now, I think all
>>>>> of the users (or most at least) we have just enable the backend during probe and leave it on until
>>>>> we unbind the device.
>>>>
>>>> Yes, this is debatable. It's not necessarily always on, but should not
>>>> be enabled/touched by the frontend during probe.
>>>> But anyways, having a capability that says if the enable/disable feature
>>>> is available, is in any case useful and what I was planning on
>>>> leveraging in my use case.
>>>> Fundamentally, with the capabilites as now proposed, it is possible to
>>>> select what features of the ad9467 are available, in addition to the
>>>> basic requirements.
>>>>
>>>> The ALWAYS_ON capability could be inverted, like CAP_HAS_ENABLE_DISABLE,
>>>> but to me, the ALWAYS_ON naming still seems the better option.
>>>>
>>>
>>> Ah, this is what Jonathan mentioned before about this really being a
>>> restriction rather than a capability.
>>>
>>> Perhaps we should have a separate restrictions/quirks flag? If the flag
>>> means "do not enable during probe" then a better name would be
>>> *_DO_NOT_ENABLE_AT_PROBE.
>>>
>>> And I agree with Nuno that if the backend can be enabled/disabled later
>>> (after probe), it should still be managed through the frontend driver.
>>> There should be no usespace access directly to the backend without going
>>> through the frontend.
>>
>> Thanks for the input, that use case is slightly different from normal
>> usage, let's keep it in mind if actually required. For now, the option
>> to just leave the enable/disable alone is what would help to solve
>> smooth integration with this device for me.
>>
>> ALWAYS_ON does not seem to get much votes here, but how about calling it
>> something like IIO_BACKEND_CAP_AUTO_ENABLE or
>> IIO_BACKEND_CAP_HAS_ENABLE_DISABLE?
>>
> IIO_BACKEND_CAP_HAS_ENABLE_DISABLE seems the most sensible given the
> way it is used in the ad9467 patch. Although IIO_BACKEND_CAP_ENABLE_DISABLE
> would be more consistent with the other flags being added since they
> don't say _HAS_.
> 
> Probably IIO_BACKEND_CAP_ENABLE is enough to imply both if we want
> to keep it shorter.

I would agree that IIO_BACKEND_CAP_ENABLE should be clear enough. I'll
use this in the next version.

thanks,
Tomas



> 
> 

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Nuno Sá]

On Mon, 2026-02-02 at 15:04 +0200, Tomas Melin wrote:
> Hi,
> 
> On 02/02/2026 14:40, Nuno Sá wrote:
> > On Mon, 2026-02-02 at 13:08 +0200, Tomas Melin wrote:
> > > Hi,
> > > 
> > > On 02/02/2026 12:28, Nuno Sá wrote:
> > > > On Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote:
> > > 
> > > > > 
> > > > > Do we actually need this one? Alternative could be, for example:
> > > > > 
> > > > > int iio_backend_enable(struct iio_backend *back)
> > > > > {
> > > > > 	int ret;
> > > > > 
> > > > > 	ret = iio_backend_op_call(back, enable);
> > > > > 	
> > > > > 	return ret == -EOPNOTSUPP ? 0 : ret;
> > > > > }
> > > > 
> > > > I would prefer not to assume we can ignore the backend not supporting
> > > > the call. It opens up the question for other operations.
> > > > 
> > > > My preferred way for this kind of fundamental operation (enabling/disabling)
> > > > would be to check with DT maintainers if we could have some kind of fixed-backend
> > > > (fixed in the sense the HW is present but not controlled by Linux) dummy device that
> > > > with implement a no-OP enable/disable().
> > > 
> > > There is also use cases for the always_on cap with a configurable
> > > non-dummy backend. Some applications are such that the driver should
> > > leave the enabling/disabling up to the user space consuming the data.
> > > For this case it's great to have the frontend leave the backend enable
> > > alone using this capability.
> > > 
> > 
> > I would argue the above would be something to take care at the frontend level. The way
> > I see it, the always_on cap is pretty much saying that we can't really control the on/off state
> > of the backing device and we just assume it's on. 
> > 
> > If we can control it but we need it always on (for some specific usecase), I would say that
> > should
> > be handled at the frontend and just enable the backend once. Also note that as of now, I think
> > all
> > of the users (or most at least) we have just enable the backend during probe and leave it on
> > until
> > we unbind the device.
> 
> Yes, this is debatable. It's not necessarily always on, but should not
> be enabled/touched by the frontend during probe.
> But anyways, having a capability that says if the enable/disable feature
> is available, is in any case useful and what I was planning on
> leveraging in my use case.
> Fundamentally, with the capabilites as now proposed, it is possible to
> select what features of the ad9467 are available, in addition to the
> basic requirements.

Yeah but this is just tweaking for your special case. Like you said, if we ever have
something like "but should not be enabled/touched by the frontend during probe." then what David
suggests in his reply makes more sense to me and clearly fits the usecase. That's not what we have
here. Here we have a fixed, non (linux) managed hardware and we do have a pattern in other
subsystems for HW like this. That is why my preferred approach would be a fixed-backend kind of
thing (naturally to be discussed with DT maintainers likely).
> 
> The ALWAYS_ON capability could be inverted, like CAP_HAS_ENABLE_DISABLE,
> but to me, the ALWAYS_ON naming still seems the better option.
> > 

But ok, I don't feel strong enough to be pushing for the above even though (and for the record :))
it's not my preferred approach. If every one else is fine with it, I won't object either.

- Nuno Sá

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 03/02/2026 12:01, Nuno Sá wrote:
> On Mon, 2026-02-02 at 15:04 +0200, Tomas Melin wrote:

>>
>> Yes, this is debatable. It's not necessarily always on, but should not
>> be enabled/touched by the frontend during probe.
>> But anyways, having a capability that says if the enable/disable feature
>> is available, is in any case useful and what I was planning on
>> leveraging in my use case.
>> Fundamentally, with the capabilites as now proposed, it is possible to
>> select what features of the ad9467 are available, in addition to the
>> basic requirements.
> 
> Yeah but this is just tweaking for your special case.

Actually goal for me is just to have the optional features of the
backend really optional. In a sense, it's tweaking for my use case but
at the same time it's making things work more generally.

That said, this always_on is not a showstopper for me. Since it seems
there is no real consensus over that capability, I can drop the
ALWAYS_ON for next version of the series.

Thanks,
Tomas

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 31/01/2026 22:30, David Lechner wrote:
> On 1/30/26 3:16 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.
>>
> 
> ...
> 
>> +/**
>> + * 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.
> 
> It would be helpful to list these operations explicitly for each
> enum member.

This has been discussed, the mapping might depend on the use case, i.e.
the combination of backend-frontend. For example the calibration might
be implemented in several ways depending on the device. Writing out the
mapping here would create problems for that kind of situations.
> 
>> + *
>> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
>> + * calibration. Calibration procedure is device specific.
>> + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
> 
> I assume this means it supports devm_iio_backend_request_buffer()?
> 
> In IIO, we usually say "buffer" and rarely "buffering" so this name and
> description is a bit confusing to me.

Sure, would this mean that name and comment should be?
IIO_BACKEND_CAP_BUFFER: Backend has support for buffers

> 
>> + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
>> + * enabled/disabled. It is always on.
> 
> Do we actually need this one? Alternative could be, for example:
> 
> int iio_backend_enable(struct iio_backend *back)
> {
> 	int ret;
> 
> 	ret = iio_backend_op_call(back, enable);
> 	
> 	return ret == -EOPNOTSUPP ? 0 : ret;
> }
> 
> Or make a iio_backend_optional_op_call() macro.
> 
> Or if there is some other nuance where this capability makes a
> difference, it should be explained in more detail.
One version in this series had that kind of approach where a single
capability mapping instead was shorted to check for EOPNOTSUPP, but it
was deemed better to have capability for everything needed and not in a
mixed fashion.


Thanks,
Tomas

> 
> 
>> + */
>> +enum iio_backend_capabilities {
> 
> Documenting members like this works too (saves a bit of cross-referencing).
> 
> 	/** @IIO_BACKEND_CAP_CALIBRATION: ... */
>> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
>> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
>> +	IIO_BACKEND_CAP_ALWAYS_ON = BIT(2),
>> +};

Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities

[David Lechner]

On 2/2/26 4:58 AM, Tomas Melin wrote:
> Hi,
> 
> On 31/01/2026 22:30, David Lechner wrote:
>> On 1/30/26 3:16 AM, Tomas Melin wrote:

...

>>> + *
>>> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
>>> + * calibration. Calibration procedure is device specific.
>>> + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
>>
>> I assume this means it supports devm_iio_backend_request_buffer()?
>>
>> In IIO, we usually say "buffer" and rarely "buffering" so this name and
>> description is a bit confusing to me.
> 
> Sure, would this mean that name and comment should be?
> IIO_BACKEND_CAP_BUFFER: Backend has support for buffers
> 
Works for me. Or even more precise: "support for IIO buffers"
or "support for IIO buffer interface".

[PATCH v5 2/4] iio: adc: adi-axi-adc: define supported iio-backend capabilities

[Tomas Melin]

axi-adc and axi-ad485x backend variants provide calibration support,
whereas the axi-ad408x does not. Set accordingly.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
 drivers/iio/adc/adi-axi-adc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c
index 14fa4238c2b9..133aa6f43a38 100644
--- a/drivers/iio/adc/adi-axi-adc.c
+++ b/drivers/iio/adc/adi-axi-adc.c
@@ -626,6 +626,7 @@ static const struct iio_backend_ops adi_axi_adc_ops = {
 static const struct iio_backend_info adi_axi_adc_generic = {
 	.name = "axi-adc",
 	.ops = &adi_axi_adc_ops,
+	.caps = IIO_BACKEND_CAP_CALIBRATION | IIO_BACKEND_CAP_BUFFERING,
 };
 
 static const struct iio_backend_ops adi_ad485x_ops = {
@@ -650,6 +651,7 @@ static const struct iio_backend_ops adi_ad485x_ops = {
 static const struct iio_backend_info axi_ad485x = {
 	.name = "axi-ad485x",
 	.ops = &adi_ad485x_ops,
+	.caps = IIO_BACKEND_CAP_CALIBRATION | IIO_BACKEND_CAP_BUFFERING,
 };
 
 static const struct iio_backend_ops adi_ad408x_ops = {
@@ -670,6 +672,7 @@ static const struct iio_backend_ops adi_ad408x_ops = {
 static const struct iio_backend_info axi_ad408x = {
 	.name = "axi-ad408x",
 	.ops = &adi_ad408x_ops,
+	.caps = IIO_BACKEND_CAP_BUFFERING,
 };
 
 static int adi_axi_adc_probe(struct platform_device *pdev)

-- 
2.47.3

Re: [PATCH v5 2/4] iio: adc: adi-axi-adc: define supported iio-backend capabilities

[Nuno Sá]

On Fri, 2026-01-30 at 09:17 +0000, Tomas Melin wrote:
> axi-adc and axi-ad485x backend variants provide calibration support,
> whereas the axi-ad408x does not. Set accordingly.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---

Reviewed-by: Nuno Sá <nuno.sa@analog.com>

>  drivers/iio/adc/adi-axi-adc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c
> index 14fa4238c2b9..133aa6f43a38 100644
> --- a/drivers/iio/adc/adi-axi-adc.c
> +++ b/drivers/iio/adc/adi-axi-adc.c
> @@ -626,6 +626,7 @@ static const struct iio_backend_ops adi_axi_adc_ops = {
>  static const struct iio_backend_info adi_axi_adc_generic = {
>  	.name = "axi-adc",
>  	.ops = &adi_axi_adc_ops,
> +	.caps = IIO_BACKEND_CAP_CALIBRATION | IIO_BACKEND_CAP_BUFFERING,
>  };
>  
>  static const struct iio_backend_ops adi_ad485x_ops = {
> @@ -650,6 +651,7 @@ static const struct iio_backend_ops adi_ad485x_ops = {
>  static const struct iio_backend_info axi_ad485x = {
>  	.name = "axi-ad485x",
>  	.ops = &adi_ad485x_ops,
> +	.caps = IIO_BACKEND_CAP_CALIBRATION | IIO_BACKEND_CAP_BUFFERING,
>  };
>  
>  static const struct iio_backend_ops adi_ad408x_ops = {
> @@ -670,6 +672,7 @@ static const struct iio_backend_ops adi_ad408x_ops = {
>  static const struct iio_backend_info axi_ad408x = {
>  	.name = "axi-ad408x",
>  	.ops = &adi_ad408x_ops,
> +	.caps = IIO_BACKEND_CAP_BUFFERING,
>  };
>  
>  static int adi_axi_adc_probe(struct platform_device *pdev)

[PATCH v5 3/4] iio: dac: adi-axi-dac: define supported iio-backend capabilities

[Tomas Melin]

Backends support buffering capability so advertise it while registering
in case a frontend makes checks for it.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
 drivers/iio/dac/adi-axi-dac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/dac/adi-axi-dac.c b/drivers/iio/dac/adi-axi-dac.c
index 0d525272a8a8..cd06cd4587af 100644
--- a/drivers/iio/dac/adi-axi-dac.c
+++ b/drivers/iio/dac/adi-axi-dac.c
@@ -869,11 +869,13 @@ static const struct iio_backend_ops axi_ad3552r_ops = {
 static const struct iio_backend_info axi_dac_generic = {
 	.name = "axi-dac",
 	.ops = &axi_dac_generic_ops,
+	.caps = IIO_BACKEND_CAP_BUFFERING,
 };
 
 static const struct iio_backend_info axi_ad3552r = {
 	.name = "axi-ad3552r",
 	.ops = &axi_ad3552r_ops,
+	.caps = IIO_BACKEND_CAP_BUFFERING,
 };
 
 static const struct regmap_config axi_dac_regmap_config = {

-- 
2.47.3

Re: [PATCH v5 3/4] iio: dac: adi-axi-dac: define supported iio-backend capabilities

[Nuno Sá]

On Fri, 2026-01-30 at 09:17 +0000, Tomas Melin wrote:
> Backends support buffering capability so advertise it while registering
> in case a frontend makes checks for it.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---

Reviewed-by: Nuno Sá <nuno.sa@analog.com>

>  drivers/iio/dac/adi-axi-dac.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/dac/adi-axi-dac.c b/drivers/iio/dac/adi-axi-dac.c
> index 0d525272a8a8..cd06cd4587af 100644
> --- a/drivers/iio/dac/adi-axi-dac.c
> +++ b/drivers/iio/dac/adi-axi-dac.c
> @@ -869,11 +869,13 @@ static const struct iio_backend_ops axi_ad3552r_ops = {
>  static const struct iio_backend_info axi_dac_generic = {
>  	.name = "axi-dac",
>  	.ops = &axi_dac_generic_ops,
> +	.caps = IIO_BACKEND_CAP_BUFFERING,
>  };
>  
>  static const struct iio_backend_info axi_ad3552r = {
>  	.name = "axi-ad3552r",
>  	.ops = &axi_ad3552r_ops,
> +	.caps = IIO_BACKEND_CAP_BUFFERING,
>  };
>  
>  static const struct regmap_config axi_dac_regmap_config = {

[PATCH v5 4/4] iio: adc: ad9467: check for backend capabilities

[Tomas Melin]

Add capability checks for operation with backends that do not necessarily
support full set of features, but are otherwise compatible with the device.
This ensures a fully functional device, but with limited capabilities.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
 drivers/iio/adc/ad9467.c | 69 ++++++++++++++++++++++++++++++------------------
 1 file changed, 43 insertions(+), 26 deletions(-)

diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 59c3fa3bcc9b..d768f7bf2a1c 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -913,7 +913,9 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
 		return ret;
 
 	guard(mutex)(&st->lock);
-	return ad9467_calibrate(st);
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+		return ad9467_calibrate(st);
+	return 0;
 }
 
 static int ad9467_write_raw(struct iio_dev *indio_dev,
@@ -1119,12 +1121,15 @@ static ssize_t ad9467_chan_test_mode_read(struct file *file,
 		len = scnprintf(buf, sizeof(buf), "Running \"%s\" Test:\n\t",
 				ad9467_test_modes[chan->mode]);
 
-		ret = iio_backend_debugfs_print_chan_status(st->back, chan->idx,
-							    buf + len,
-							    sizeof(buf) - len);
-		if (ret < 0)
-			return ret;
-		len += ret;
+		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
+			ret = iio_backend_debugfs_print_chan_status(st->back,
+								    chan->idx,
+								    buf + len,
+								    sizeof(buf) - len);
+			if (ret < 0)
+				return ret;
+			len += ret;
+		}
 	} else if (chan->mode == AN877_ADC_TESTMODE_OFF) {
 		len = scnprintf(buf, sizeof(buf), "No test Running...\n");
 	} else {
@@ -1188,16 +1193,19 @@ static ssize_t ad9467_chan_test_mode_write(struct file *file,
 			return ret;
 
 		/*  some patterns have a backend matching monitoring block */
-		if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
-			ret = ad9467_backend_testmode_on(st, chan->idx,
+		if (iio_backend_has_caps(st->back,
+					 IIO_BACKEND_CAP_CALIBRATION)) {
+			if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
+				ret = ad9467_backend_testmode_on(st, chan->idx,
 							 IIO_BACKEND_ADI_PRBS_9A);
-			if (ret)
-				return ret;
-		} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
-			ret = ad9467_backend_testmode_on(st, chan->idx,
+				if (ret)
+					return ret;
+			} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
+				ret = ad9467_backend_testmode_on(st, chan->idx,
 							 IIO_BACKEND_ADI_PRBS_23A);
-			if (ret)
-				return ret;
+				if (ret)
+					return ret;
+			}
 		}
 	}
 
@@ -1263,8 +1271,10 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
 	if (!st->chan_test)
 		return;
 
-	debugfs_create_file("calibration_table_dump", 0400, d, st,
-			    &ad9467_calib_table_fops);
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
+		debugfs_create_file("calibration_table_dump", 0400, d, st,
+				    &ad9467_calib_table_fops);
+	}
 
 	for (chan = 0; chan < st->info->num_channels; chan++) {
 		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
@@ -1339,17 +1349,24 @@ static int ad9467_probe(struct spi_device *spi)
 	if (ret)
 		return ret;
 
-	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
-	if (ret)
-		return ret;
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_BUFFERING)) {
+		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
+						      indio_dev);
+		if (ret)
+			return ret;
+	}
 
-	ret = devm_iio_backend_enable(&spi->dev, st->back);
-	if (ret)
-		return ret;
+	if (!iio_backend_has_caps(st->back, IIO_BACKEND_CAP_ALWAYS_ON)) {
+		ret = devm_iio_backend_enable(&spi->dev, st->back);
+		if (ret)
+			return ret;
+	}
 
-	ret = ad9467_calibrate(st);
-	if (ret)
-		return ret;
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
+		ret = ad9467_calibrate(st);
+		if (ret)
+			return ret;
+	}
 
 	ret = devm_iio_device_register(&spi->dev, indio_dev);
 	if (ret)

-- 
2.47.3

Re: [PATCH v5 4/4] iio: adc: ad9467: check for backend capabilities

[David Lechner]

On 1/30/26 3:17 AM, Tomas Melin wrote:
> Add capability checks for operation with backends that do not necessarily
> support full set of features, but are otherwise compatible with the device.
> This ensures a fully functional device, but with limited capabilities.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/adc/ad9467.c | 69 ++++++++++++++++++++++++++++++------------------
>  1 file changed, 43 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 59c3fa3bcc9b..d768f7bf2a1c 100644
> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c
> @@ -913,7 +913,9 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
>  		return ret;
>  
>  	guard(mutex)(&st->lock);

I saw in the changelog that leaving the guard here was intentional, but I
don't see why.

> -	return ad9467_calibrate(st);
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return ad9467_calibrate(st);
> +	return 0;
>  }
>  

...

>  static int ad9467_write_raw(struct iio_dev *indio_dev,
> @@ -1119,12 +1121,15 @@ static ssize_t ad9467_chan_test_mode_read(struct file *file,
>  		len = scnprintf(buf, sizeof(buf), "Running \"%s\" Test:\n\t",
>  				ad9467_test_modes[chan->mode]);
>  
> -		ret = iio_backend_debugfs_print_chan_status(st->back, chan->idx,
> -							    buf + len,
> -							    sizeof(buf) - len);
> -		if (ret < 0)
> -			return ret;
> -		len += ret;
> +		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> +			ret = iio_backend_debugfs_print_chan_status(st->back,
> +								    chan->idx,
> +								    buf + len,
> +								    sizeof(buf) - len);
> +			if (ret < 0)
> +				return ret;
> +			len += ret;
> +		}
>  	} else if (chan->mode == AN877_ADC_TESTMODE_OFF) {
>  		len = scnprintf(buf, sizeof(buf), "No test Running...\n");
>  	} else {
> @@ -1188,16 +1193,19 @@ static ssize_t ad9467_chan_test_mode_write(struct file *file,
>  			return ret;
>  
>  		/*  some patterns have a backend matching monitoring block */
> -		if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
> -			ret = ad9467_backend_testmode_on(st, chan->idx,
> +		if (iio_backend_has_caps(st->back,
> +					 IIO_BACKEND_CAP_CALIBRATION)) {
> +			if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>  							 IIO_BACKEND_ADI_PRBS_9A);
> -			if (ret)
> -				return ret;
> -		} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
> -			ret = ad9467_backend_testmode_on(st, chan->idx,
> +				if (ret)
> +					return ret;
> +			} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>  							 IIO_BACKEND_ADI_PRBS_23A);
> -			if (ret)
> -				return ret;
> +				if (ret)
> +					return ret;
> +			}
>  		}
>  	}
>  
> @@ -1263,8 +1271,10 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
>  	if (!st->chan_test)
>  		return;
>  
> -	debugfs_create_file("calibration_table_dump", 0400, d, st,
> -			    &ad9467_calib_table_fops);
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> +		debugfs_create_file("calibration_table_dump", 0400, d, st,
> +				    &ad9467_calib_table_fops);
> +	}
>  
>  	for (chan = 0; chan < st->info->num_channels; chan++) {
>  		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",


Do we actually need to change these test mode/debugfs functions since
debugfs_create_file() is only callded if IIO_BACKEND_CAP_CALIBRATION
already?

Re: [PATCH v5 4/4] iio: adc: ad9467: check for backend capabilities

[Tomas Melin]

Hi,

On 31/01/2026 22:40, David Lechner wrote:
> On 1/30/26 3:17 AM, Tomas Melin wrote:
>> Add capability checks for operation with backends that do not necessarily
>> support full set of features, but are otherwise compatible with the device.
>> This ensures a fully functional device, but with limited capabilities.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>>  drivers/iio/adc/ad9467.c | 69 ++++++++++++++++++++++++++++++------------------
>>  1 file changed, 43 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
>> index 59c3fa3bcc9b..d768f7bf2a1c 100644
>> --- a/drivers/iio/adc/ad9467.c
>> +++ b/drivers/iio/adc/ad9467.c
>> @@ -913,7 +913,9 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
>>  		return ret;
>>  
>>  	guard(mutex)(&st->lock);
> 
> I saw in the changelog that leaving the guard here was intentional, but I
> don't see why.

This was discussed here:
https://marc.info/?l=linux-iio&m=176900394618857&w=4

> 
>> -	return ad9467_calibrate(st);
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
>> +		return ad9467_calibrate(st);
>> +	return 0;
>>  }
>>  
> 
> ...
> 
>>  static int ad9467_write_raw(struct iio_dev *indio_dev,
>> @@ -1119,12 +1121,15 @@ static ssize_t ad9467_chan_test_mode_read(struct file *file,
>>  		len = scnprintf(buf, sizeof(buf), "Running \"%s\" Test:\n\t",
>>  				ad9467_test_modes[chan->mode]);
>>  
>> -		ret = iio_backend_debugfs_print_chan_status(st->back, chan->idx,
>> -							    buf + len,
>> -							    sizeof(buf) - len);
>> -		if (ret < 0)
>> -			return ret;
>> -		len += ret;
>> +		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
>> +			ret = iio_backend_debugfs_print_chan_status(st->back,
>> +								    chan->idx,
>> +								    buf + len,
>> +								    sizeof(buf) - len);
>> +			if (ret < 0)
>> +				return ret;
>> +			len += ret;
>> +		}
>>  	} else if (chan->mode == AN877_ADC_TESTMODE_OFF) {
>>  		len = scnprintf(buf, sizeof(buf), "No test Running...\n");
>>  	} else {
>> @@ -1188,16 +1193,19 @@ static ssize_t ad9467_chan_test_mode_write(struct file *file,
>>  			return ret;
>>  
>>  		/*  some patterns have a backend matching monitoring block */
>> -		if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
>> -			ret = ad9467_backend_testmode_on(st, chan->idx,
>> +		if (iio_backend_has_caps(st->back,
>> +					 IIO_BACKEND_CAP_CALIBRATION)) {
>> +			if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
>> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>>  							 IIO_BACKEND_ADI_PRBS_9A);
>> -			if (ret)
>> -				return ret;
>> -		} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
>> -			ret = ad9467_backend_testmode_on(st, chan->idx,
>> +				if (ret)
>> +					return ret;
>> +			} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
>> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>>  							 IIO_BACKEND_ADI_PRBS_23A);
>> -			if (ret)
>> -				return ret;
>> +				if (ret)
>> +					return ret;
>> +			}
>>  		}
>>  	}
>>  
>> @@ -1263,8 +1271,10 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
>>  	if (!st->chan_test)
>>  		return;
>>  
>> -	debugfs_create_file("calibration_table_dump", 0400, d, st,
>> -			    &ad9467_calib_table_fops);
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
>> +		debugfs_create_file("calibration_table_dump", 0400, d, st,
>> +				    &ad9467_calib_table_fops);
>> +	}
>>  
>>  	for (chan = 0; chan < st->info->num_channels; chan++) {
>>  		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
> 
> 
> Do we actually need to change these test mode/debugfs functions since
> debugfs_create_file() is only callded if IIO_BACKEND_CAP_CALIBRATION
> already?

The set of available test modes as such are part of the device, not the
backend. Based on that I have concluded that they should remain intact.

Thanks,
Tomas


> 
> 

Re: [PATCH v5 4/4] iio: adc: ad9467: check for backend capabilities

[Nuno Sá]

On Fri, 2026-01-30 at 09:17 +0000, Tomas Melin wrote:
> Add capability checks for operation with backends that do not necessarily
> support full set of features, but are otherwise compatible with the device.
> This ensures a fully functional device, but with limited capabilities.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/adc/ad9467.c | 69 ++++++++++++++++++++++++++++++------------------
>  1 file changed, 43 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 59c3fa3bcc9b..d768f7bf2a1c 100644
> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c
> @@ -913,7 +913,9 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
>  		return ret;
>  
>  	guard(mutex)(&st->lock);
> -	return ad9467_calibrate(st);
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return ad9467_calibrate(st);
> +	return 0;
>  }
>  
>  static int ad9467_write_raw(struct iio_dev *indio_dev,
> @@ -1119,12 +1121,15 @@ static ssize_t ad9467_chan_test_mode_read(struct file *file,
>  		len = scnprintf(buf, sizeof(buf), "Running \"%s\" Test:\n\t",
>  				ad9467_test_modes[chan->mode]);
>  
> -		ret = iio_backend_debugfs_print_chan_status(st->back, chan->idx,
> -							    buf + len,
> -							    sizeof(buf) - len);
> -		if (ret < 0)
> -			return ret;
> -		len += ret;
> +		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> +			ret = iio_backend_debugfs_print_chan_status(st->back,
> +								    chan->idx,
> +								    buf + len,
> +								    sizeof(buf) - len);
> +			if (ret < 0)
> +				return ret;
> +			len += ret;

Given that we can't really check the status we could maybe do this in a better way. See
below...
> +		}
>  	} else if (chan->mode == AN877_ADC_TESTMODE_OFF) {
>  		len = scnprintf(buf, sizeof(buf), "No test Running...\n");
>  	} else {
> @@ -1188,16 +1193,19 @@ static ssize_t ad9467_chan_test_mode_write(struct file *file,
>  			return ret;
>  
>  		/*  some patterns have a backend matching monitoring block */
> -		if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
> -			ret = ad9467_backend_testmode_on(st, chan->idx,
> +		if (iio_backend_has_caps(st->back,
> +					 IIO_BACKEND_CAP_CALIBRATION)) {
> +			if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>  							 IIO_BACKEND_ADI_PRBS_9A);
> -			if (ret)
> -				return ret;
> -		} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
> -			ret = ad9467_backend_testmode_on(st, chan->idx,
> +				if (ret)
> +					return ret;
> +			} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>  							 IIO_BACKEND_ADI_PRBS_23A);
> -			if (ret)
> -				return ret;
> +				if (ret)
> +					return ret;
> +			}
>  		}
>  	}
>  
> @@ -1263,8 +1271,10 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
>  	if (!st->chan_test)
>  		return;
>  
> -	debugfs_create_file("calibration_table_dump", 0400, d, st,
> -			    &ad9467_calib_table_fops);
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> +		debugfs_create_file("calibration_table_dump", 0400, d, st,
> +				    &ad9467_calib_table_fops);
> +	}
>  
>  	for (chan = 0; chan < st->info->num_channels; chan++) {
>  		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",

Change the permissions for in_voltage%u_test_mode so that is WO in case we can't
IIO_BACKEND_CAP_CALIBRATION. You can even reuse the above check to tweak the permissions
accordingly. Then no need to check for the capability in ad9467_chan_test_mode_read()

- Nuno Sá

Re: [PATCH v5 4/4] iio: adc: ad9467: check for backend capabilities

[Tomas Melin]

Hi,

On 02/02/2026 12:42, Nuno Sá wrote:
> On Fri, 2026-01-30 at 09:17 +0000, Tomas Melin wrote:
>> Add capability checks for operation with backends that do not necessarily
>> support full set of features, but are otherwise compatible with the device.
>> This ensures a fully functional device, but with limited capabilities.
...
>>  
>> @@ -1263,8 +1271,10 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
>>  	if (!st->chan_test)
>>  		return;
>>  
>> -	debugfs_create_file("calibration_table_dump", 0400, d, st,
>> -			    &ad9467_calib_table_fops);
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
>> +		debugfs_create_file("calibration_table_dump", 0400, d, st,
>> +				    &ad9467_calib_table_fops);
>> +	}
>>  
>>  	for (chan = 0; chan < st->info->num_channels; chan++) {
>>  		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
> 
> Change the permissions for in_voltage%u_test_mode so that is WO in case we can't
> IIO_BACKEND_CAP_CALIBRATION. You can even reuse the above check to tweak the permissions
> accordingly. Then no need to check for the capability in ad9467_chan_test_mode_read()

This RO would be then only for cases PN9, PN23. For the other attributes
RW would still be applicable. But basically I think the test modes in
the device are still available even if the backend status does not exist?

IMHO the current approach is slightly cleaner, as all the test modes the
device supports are available and no need to think about which ones have
RW/RO inside this function. Please let me know, in case you insist on
this kind of approach.

Thanks,
Tomas

Re: [PATCH v5 4/4] iio: adc: ad9467: check for backend capabilities

[Nuno Sá]

On Mon, 2026-02-02 at 14:03 +0200, Tomas Melin wrote:
> Hi,
> 
> On 02/02/2026 12:42, Nuno Sá wrote:
> > On Fri, 2026-01-30 at 09:17 +0000, Tomas Melin wrote:
> > > Add capability checks for operation with backends that do not necessarily
> > > support full set of features, but are otherwise compatible with the device.
> > > This ensures a fully functional device, but with limited capabilities.
> ...
> > >  
> > > @@ -1263,8 +1271,10 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
> > >  	if (!st->chan_test)
> > >  		return;
> > >  
> > > -	debugfs_create_file("calibration_table_dump", 0400, d, st,
> > > -			    &ad9467_calib_table_fops);
> > > +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> > > +		debugfs_create_file("calibration_table_dump", 0400, d, st,
> > > +				    &ad9467_calib_table_fops);
> > > +	}
> > >  
> > >  	for (chan = 0; chan < st->info->num_channels; chan++) {
> > >  		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
> > 
> > Change the permissions for in_voltage%u_test_mode so that is WO in case we can't
> > IIO_BACKEND_CAP_CALIBRATION. You can even reuse the above check to tweak the permissions
> > accordingly. Then no need to check for the capability in ad9467_chan_test_mode_read()
> 
> This RO would be then only for cases PN9, PN23. For the other attributes

> RW would still be applicable. But basically I think the test modes in
> the device are still available even if the backend status does not exist?

Yeah, they are. The backend is only validating the pattern to make sure it is what's
expected. TBH, I'm not sure what's the utility without the backend but I guess one might
want to connect the interface somewhere and check the patterns.

> IMHO the current approach is slightly cleaner, as all the test modes the
> device supports are available and no need to think about which ones have
> RW/RO inside this function. Please let me know, in case you insist on
> this kind of approach.
> 
> 
Ok, I reviewed the code and I see we still print some running status for all the patterns.
Feel free to leave as-is then

- Nuno Sá