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

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

[Tomas Melin]

To facilitate backends with different set of features, add support
for defining capabilites provided by the backend. These capabilites
typically extend beyond a single operation and are therefore not
directly linked to if a single function call is implemented or not.
Furthermore, the capabilites 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 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: adc: adi-axi-dac: define supported iio-backend capabilities
      iio: adc: ad9467: check for backend capabilities

 drivers/iio/adc/ad9467.c           | 72 ++++++++++++++++++++++++--------------
 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, 91 insertions(+), 27 deletions(-)
---
base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7

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

[PATCH v4 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 447b694d6d5f72dc6f018b1697fdb88e555bd61e..1afd00763da9e1f07160990fe3f729cbb7295d7f 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 7f815f3fed6ae34c65ffc579d5101020fc9bd336..ac80abb71bbca88c3f6313d8d67b9c7ace076ceb 100644
--- a/include/linux/iio/backend.h
+++ b/include/linux/iio/backend.h
@@ -84,6 +84,28 @@ enum iio_backend_filter_type {
 	IIO_BACKEND_FILTER_TYPE_MAX
 };
 
+/**
+ * enum iio_backend_capabilities - Backend capabilities
+ * Backend capabilities can be used by frontends to check if a given
+ * functionality is supported by the backend. This is useful for frontend
+ * devices which are expected to work with alternative backend
+ * implementations. Capabilities are loosely coupled with operations,
+ * meaning that a capability requires certain operations to be implemented
+ * by the backend. A capability might be mapped to a single operation or
+ * multiple operations.
+ *
+ * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
+ * calibration. Calibration procedure is device specific.
+ * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
+ * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
+ * enabled/disabled. It is always on.
+ */
+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 v4 1/4] iio: industrialio-backend: support backend capabilities

[Jonathan Cameron]

On Wed, 21 Jan 2026 12:08:30 +0000
Tomas Melin <tomas.melin@vaisala.com> wrote:

> Not all backends support the full set of capabilities provided by the
> industrialio-backend framework. Capability bits can be used in frontends
> and backends for checking for a certain feature set, or if using
> related functions can be expected to fail.
> 
> Capability bits should be set by a compatible backend and provided when
> registering the backend.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>

One question on the 'sense' of the cap that controls whether it's
always on. It's the sort of question that I'm not sure has a perfect answer.


> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..ac80abb71bbca88c3f6313d8d67b9c7ace076ceb 100644
> --- a/include/linux/iio/backend.h
> +++ b/include/linux/iio/backend.h
> @@ -84,6 +84,28 @@ enum iio_backend_filter_type {
>  	IIO_BACKEND_FILTER_TYPE_MAX
>  };
>  
> +/**
> + * enum iio_backend_capabilities - Backend capabilities
> + * Backend capabilities can be used by frontends to check if a given
> + * functionality is supported by the backend. This is useful for frontend
> + * devices which are expected to work with alternative backend
> + * implementations. Capabilities are loosely coupled with operations,
> + * meaning that a capability requires certain operations to be implemented
> + * by the backend. A capability might be mapped to a single operation or
> + * multiple operations.
> + *
> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
> + * calibration. Calibration procedure is device specific.
> + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
> + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
> + * enabled/disabled. It is always on.
I'd like opinions on this one. To me it sound backwards though I can
see why you'd go this way.
Either the backend is capable of being enabled / disabled
in which case we have to further assume at boot it is disabled
(which is the dodgy bit!)

Or the backend is always on. To me that's not a capability,
it's a limitation.

My slight preference is for a capability meaning we 'can'
do something so the 1st option.

> + */
> +enum iio_backend_capabilities {
> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
> +	IIO_BACKEND_CAP_ALWAYS_ON = BIT(2),
> +};
> +
>  /**
>   * struct iio_backend_ops - operations structure for an iio_backend
>   * @enable: Enable backend.
> @@ -179,10 +201,12 @@ struct iio_backend_ops {
>   * struct iio_backend_info - info structure for an iio_backend
>   * @name: Backend name.
>   * @ops: Backend operations.
> + * @caps: Backend capabilities. @see iio_backend_capabilities
>   */
>  struct iio_backend_info {
>  	const char *name;
>  	const struct iio_backend_ops *ops;
> +	u32 caps;
>  };
>  
>  int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
> @@ -235,6 +259,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>  			 long mask);
>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>  				 struct iio_chan_spec *chan);
> +bool iio_backend_has_caps(struct iio_backend *back, u32 caps);
>  void *iio_backend_get_priv(const struct iio_backend *conv);
>  struct iio_backend *devm_iio_backend_get(struct device *dev, const char *name);
>  struct iio_backend *devm_iio_backend_fwnode_get(struct device *dev,
> 

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

[Tomas Melin]

Hi,

On 22/01/2026 22:43, Jonathan Cameron wrote:
> On Wed, 21 Jan 2026 12:08:30 +0000
> Tomas Melin <tomas.melin@vaisala.com> wrote:
> 
>> Not all backends support the full set of capabilities provided by the
>> industrialio-backend framework. Capability bits can be used in frontends
>> and backends for checking for a certain feature set, or if using
>> related functions can be expected to fail.
>>
>> Capability bits should be set by a compatible backend and provided when
>> registering the backend.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> 
> One question on the 'sense' of the cap that controls whether it's
> always on. It's the sort of question that I'm not sure has a perfect answer.
Agreed, it is not as clear as the other bits. I'll give my reasoning below.

> 
> 
>> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
>> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..ac80abb71bbca88c3f6313d8d67b9c7ace076ceb 100644
>> --- a/include/linux/iio/backend.h
>> +++ b/include/linux/iio/backend.h
>> @@ -84,6 +84,28 @@ enum iio_backend_filter_type {
>>  	IIO_BACKEND_FILTER_TYPE_MAX
>>  };
>>  
>> +/**
>> + * enum iio_backend_capabilities - Backend capabilities
>> + * Backend capabilities can be used by frontends to check if a given
>> + * functionality is supported by the backend. This is useful for frontend
>> + * devices which are expected to work with alternative backend
>> + * implementations. Capabilities are loosely coupled with operations,
>> + * meaning that a capability requires certain operations to be implemented
>> + * by the backend. A capability might be mapped to a single operation or
>> + * multiple operations.
>> + *
>> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
>> + * calibration. Calibration procedure is device specific.
>> + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering.
>> + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly
>> + * enabled/disabled. It is always on.
> I'd like opinions on this one. To me it sound backwards though I can
> see why you'd go this way.
> Either the backend is capable of being enabled / disabled
> in which case we have to further assume at boot it is disabled
> (which is the dodgy bit!)
> 
> Or the backend is always on. To me that's not a capability,
> it's a limitation.
I pondered about this too, but ended up having the bit this way around.
The logic being that backend is capable of working even if not
explicitly enabled/disabled. So looking at it from that perspective it
would be a capability. And assumption being that typically the
enabling/disabling is required, checking if the capability to omit
enabling seemed logical to me.

Thanks,
Tomas

> 
> My slight preference is for a capability meaning we 'can'
> do something so the 1st option.
> 
>> + */
>> +enum iio_backend_capabilities {
>> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
>> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
>> +	IIO_BACKEND_CAP_ALWAYS_ON = BIT(2),
>> +};
>> +
>>  /**
>>   * struct iio_backend_ops - operations structure for an iio_backend
>>   * @enable: Enable backend.
>> @@ -179,10 +201,12 @@ struct iio_backend_ops {
>>   * struct iio_backend_info - info structure for an iio_backend
>>   * @name: Backend name.
>>   * @ops: Backend operations.
>> + * @caps: Backend capabilities. @see iio_backend_capabilities
>>   */
>>  struct iio_backend_info {
>>  	const char *name;
>>  	const struct iio_backend_ops *ops;
>> +	u32 caps;
>>  };
>>  
>>  int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
>> @@ -235,6 +259,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>>  			 long mask);
>>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>>  				 struct iio_chan_spec *chan);
>> +bool iio_backend_has_caps(struct iio_backend *back, u32 caps);
>>  void *iio_backend_get_priv(const struct iio_backend *conv);
>>  struct iio_backend *devm_iio_backend_get(struct device *dev, const char *name);
>>  struct iio_backend *devm_iio_backend_fwnode_get(struct device *dev,
>>
> 

[PATCH v4 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 14fa4238c2b96b1ac722d537bc49ed4ca8e36925..133aa6f43a3854e8365ac1ad26331ccf9caa7873 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

[PATCH v4 3/4] iio: adc: 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 0d525272a8a8378e616fae4d0af606979d7b7716..cd06cd4587af56cd2521efcaa37c407f172e7014 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 v4 3/4] iio: adc: adi-axi-dac: define supported iio-backend capabilities

[Jonathan Cameron]

On Wed, 21 Jan 2026 12:08:32 +0000
Tomas Melin <tomas.melin@vaisala.com> wrote:

iio: dac: adi-axi-dac: ...


> 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 0d525272a8a8378e616fae4d0af606979d7b7716..cd06cd4587af56cd2521efcaa37c407f172e7014 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 v4 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 | 72 ++++++++++++++++++++++++++++++------------------
 1 file changed, 45 insertions(+), 27 deletions(-)

diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 59c3fa3bcc9b0b8b36b78c3b54fd7977cae23496..eb57f72211430fc2c41baa9ed1a1e0ecf798ad57 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -912,8 +912,11 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
 	if (ret)
 		return ret;
 
-	guard(mutex)(&st->lock);
-	return ad9467_calibrate(st);
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
+		guard(mutex)(&st->lock);
+		return ad9467_calibrate(st);
+	}
+	return 0;
 }
 
 static int ad9467_write_raw(struct iio_dev *indio_dev,
@@ -1119,12 +1122,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 +1194,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 +1272,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 +1350,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 v4 4/4] iio: adc: ad9467: check for backend capabilities

[Andy Shevchenko]

On Wed, Jan 21, 2026 at 12:08:33PM +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.

...

> static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)

>  	if (ret)
>  		return ret;
>  
> -	guard(mutex)(&st->lock);

I would leave this as is. Yes, practically we don't need to cover
iio_backend_has_caps() with mutex to access the data, but it just makes code
slightly more maintainable in my opinion. If anything appears here, it would
probably mean some kind of if (...) do_blablabla(...); pattern that will need
a mutex.

> -	return ad9467_calibrate(st);
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> +		guard(mutex)(&st->lock);
> +		return ad9467_calibrate(st);
> +	}
> +	return 0;
>  }

-- 
With Best Regards,
Andy Shevchenko

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

[Tomas Melin]

Hi,

On 21/01/2026 14:58, Andy Shevchenko wrote:
> On Wed, Jan 21, 2026 at 12:08:33PM +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.
> 
> ...
> 
>> static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
> 
>>  	if (ret)
>>  		return ret;
>>  
>> -	guard(mutex)(&st->lock);
> 
> I would leave this as is. Yes, practically we don't need to cover
> iio_backend_has_caps() with mutex to access the data, but it just makes code
> slightly more maintainable in my opinion. If anything appears here, it would
> probably mean some kind of if (...) do_blablabla(...); pattern that will need
> a mutex.

I have no strong opinion on this. Current option was chosen as it seemed
cleaner in the sense that it a) takes the mutex only when needed and b)
check for caps does not require the mutex to be held. Based on this I
still suggest keeping as is but will change if you insist.

Thanks,
Tomas


> 
>> -	return ad9467_calibrate(st);
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
>> +		guard(mutex)(&st->lock);
>> +		return ad9467_calibrate(st);
>> +	}
>> +	return 0;
>>  }
> 

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

[Andy Shevchenko]

On Fri, Jan 23, 2026 at 09:10:20AM +0200, Tomas Melin wrote:
> On 21/01/2026 14:58, Andy Shevchenko wrote:
> > On Wed, Jan 21, 2026 at 12:08:33PM +0000, Tomas Melin wrote:

...

> >> static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
> > 
> >>  	if (ret)
> >>  		return ret;
> >>  
> >> -	guard(mutex)(&st->lock);
> > 
> > I would leave this as is. Yes, practically we don't need to cover
> > iio_backend_has_caps() with mutex to access the data, but it just makes code
> > slightly more maintainable in my opinion. If anything appears here, it would
> > probably mean some kind of if (...) do_blablabla(...); pattern that will need
> > a mutex.
> 
> I have no strong opinion on this. Current option was chosen as it seemed
> cleaner in the sense that it a) takes the mutex only when needed and b)
> check for caps does not require the mutex to be held. Based on this I
> still suggest keeping as is but will change if you insist.

If you want your way, do not use guard()(). guard()() inside branches is
unintuitive and not the common way of doing it. Most likely you wanted
scoped_guard(). So, to me, guard() indented to more than 1 tab is suspicious
(I don't say it's forbidden or wrong).

> >> -	return ad9467_calibrate(st);
> >> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> >> +		guard(mutex)(&st->lock);
> >> +		return ad9467_calibrate(st);
> >> +	}
> >> +	return 0;
> >>  }

-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Cameron]

On Wed, 21 Jan 2026 12:08:29 +0000
Tomas Melin <tomas.melin@vaisala.com> wrote:

> To facilitate backends with different set of features, add support
> for defining capabilites provided by the backend. These capabilites

Spell check. 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 capabilites 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 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: adc: adi-axi-dac: define supported iio-backend capabilities
>       iio: adc: ad9467: check for backend capabilities
> 
>  drivers/iio/adc/ad9467.c           | 72 ++++++++++++++++++++++++--------------
>  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, 91 insertions(+), 27 deletions(-)
> ---
> base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
> change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7
> 
> Best regards,