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

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),
> +};

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),
>> +};

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".

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á

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á

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á

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

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á

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

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);

	...
}

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);
> 
> 	...
> }
> 
> 

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.

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



> 
>