[PATCH v2 0/3] iio: adc: ad9467: Support alternative backends

[PATCH v2 0/3] 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 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 (3):
      iio: adc: ad9467: include two's complement in default mode
      iio: industrialio-backend: support backend capabilities
      iio: adc: ad9467: check for backend capabilities

 drivers/iio/adc/ad9467.c           | 42 ++++++++++++++++++++++++++++++--------
 drivers/iio/industrialio-backend.c | 10 +++++++++
 include/linux/iio/backend.h        |  9 ++++++++
 3 files changed, 53 insertions(+), 8 deletions(-)
---
base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7

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

[PATCH v2 1/3] iio: adc: ad9467: include two's complement in default mode

[Tomas Melin]

All supported drivers currently implicitly use two's complement mode.
Make this clear by declaring two's complement in the default
output mode. Calibration mode uses offset binary, so change the output
mode only when running the calibration or other test mode.

Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
 drivers/iio/adc/ad9467.c | 33 +++++++++++++++++++++++++--------
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 59c3fa3bcc9b0b8b36b78c3b54fd7977cae23496..9cfe66425d4e91e215cccc40e24a92c5e99e9b87 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -5,6 +5,7 @@
  * Copyright 2012-2020 Analog Devices Inc.
  */
 
+#include <linux/bitfield.h>
 #include <linux/bitmap.h>
 #include <linux/bitops.h>
 #include <linux/cleanup.h>
@@ -72,6 +73,7 @@
 #define AN877_ADC_OUTPUT_MODE_OFFSET_BINARY	0x0
 #define AN877_ADC_OUTPUT_MODE_TWOS_COMPLEMENT	0x1
 #define AN877_ADC_OUTPUT_MODE_GRAY_CODE		0x2
+#define AN877_ADC_OUTPUT_MODE_MASK		GENMASK(1, 0)
 
 /* AN877_ADC_REG_OUTPUT_PHASE */
 #define AN877_ADC_OUTPUT_EVEN_ODD_MODE_EN	0x20
@@ -85,7 +87,7 @@
  */
 
 #define CHIPID_AD9211			0x06
-#define AD9211_DEF_OUTPUT_MODE		0x00
+#define AD9211_DEF_OUTPUT_MODE		0x01
 #define AD9211_REG_VREF_MASK		GENMASK(4, 0)
 
 /*
@@ -93,7 +95,7 @@
  */
 
 #define CHIPID_AD9265			0x64
-#define AD9265_DEF_OUTPUT_MODE		0x40
+#define AD9265_DEF_OUTPUT_MODE		0x41
 #define AD9265_REG_VREF_MASK		0xC0
 
 /*
@@ -101,7 +103,7 @@
  */
 
 #define CHIPID_AD9434			0x6A
-#define AD9434_DEF_OUTPUT_MODE		0x00
+#define AD9434_DEF_OUTPUT_MODE		0x01
 #define AD9434_REG_VREF_MASK		0xC0
 
 /*
@@ -109,7 +111,7 @@
  */
 
 #define CHIPID_AD9467			0x50
-#define AD9467_DEF_OUTPUT_MODE		0x08
+#define AD9467_DEF_OUTPUT_MODE		0x09
 #define AD9467_REG_VREF_MASK		0x0F
 
 /*
@@ -117,6 +119,7 @@
  */
 
 #define CHIPID_AD9643			0x82
+#define AD9643_DEF_OUTPUT_MODE		0x01
 #define AD9643_REG_VREF_MASK		0x1F
 
 /*
@@ -124,6 +127,7 @@
  */
 
 #define CHIPID_AD9652                   0xC1
+#define AD9652_DEF_OUTPUT_MODE		0x01
 #define AD9652_REG_VREF_MASK            0xC0
 
 /*
@@ -131,6 +135,7 @@
  */
 
 #define CHIPID_AD9649			0x6F
+#define AD9649_DEF_OUTPUT_MODE		0x01
 #define AD9649_TEST_POINTS		8
 
 #define AD9647_MAX_TEST_POINTS		32
@@ -461,6 +466,7 @@ static const struct ad9467_chip_info ad9643_chip_tbl = {
 	.test_mask = BIT(AN877_ADC_TESTMODE_RAMP) |
 		GENMASK(AN877_ADC_TESTMODE_MIXED_BIT_FREQUENCY, AN877_ADC_TESTMODE_OFF),
 	.test_mask_len = AN877_ADC_TESTMODE_RAMP + 1,
+	.default_output_mode = AD9643_DEF_OUTPUT_MODE,
 	.vref_mask = AD9643_REG_VREF_MASK,
 	.has_dco = true,
 	.has_dco_invert = true,
@@ -479,6 +485,7 @@ static const struct ad9467_chip_info ad9649_chip_tbl = {
 	.test_mask = GENMASK(AN877_ADC_TESTMODE_MIXED_BIT_FREQUENCY,
 			     AN877_ADC_TESTMODE_OFF),
 	.test_mask_len = AN877_ADC_TESTMODE_MIXED_BIT_FREQUENCY + 1,
+	.default_output_mode = AD9649_DEF_OUTPUT_MODE,
 	.has_dco = true,
 	.has_dco_invert = true,
 	.dco_en = AN877_ADC_DCO_DELAY_ENABLE,
@@ -496,6 +503,7 @@ static const struct ad9467_chip_info ad9652_chip_tbl = {
 	.test_mask = GENMASK(AN877_ADC_TESTMODE_ONE_ZERO_TOGGLE,
 			     AN877_ADC_TESTMODE_OFF),
 	.test_mask_len = AN877_ADC_TESTMODE_ONE_ZERO_TOGGLE + 1,
+	.default_output_mode = AD9652_DEF_OUTPUT_MODE,
 	.vref_mask = AD9652_REG_VREF_MASK,
 	.has_dco = true,
 };
@@ -671,10 +679,14 @@ static int ad9467_backend_testmode_off(struct ad9467_state *st,
 
 static int ad9647_calibrate_prepare(struct ad9467_state *st)
 {
+	unsigned int cmode;
 	unsigned int c;
 	int ret;
 
-	ret = ad9467_outputmode_set(st, st->info->default_output_mode);
+	cmode = st->info->default_output_mode;
+	FIELD_MODIFY(AN877_ADC_OUTPUT_MODE_MASK, &cmode,
+		     AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
+	ret = ad9467_outputmode_set(st, cmode);
 	if (ret)
 		return ret;
 
@@ -778,7 +790,7 @@ static int ad9647_calibrate_stop(struct ad9467_state *st)
 			return ret;
 	}
 
-	mode = st->info->default_output_mode | AN877_ADC_OUTPUT_MODE_TWOS_COMPLEMENT;
+	mode = st->info->default_output_mode;
 	return ad9467_outputmode_set(st, mode);
 }
 
@@ -1174,12 +1186,17 @@ static ssize_t ad9467_chan_test_mode_write(struct file *file,
 		if (ret)
 			return ret;
 
-		out_mode = st->info->default_output_mode | AN877_ADC_OUTPUT_MODE_TWOS_COMPLEMENT;
+		out_mode = st->info->default_output_mode;
 		ret = ad9467_outputmode_set(st, out_mode);
 		if (ret)
 			return ret;
 	} else {
-		ret = ad9467_outputmode_set(st, st->info->default_output_mode);
+		unsigned int cmode;
+
+		cmode = st->info->default_output_mode;
+		FIELD_MODIFY(AN877_ADC_OUTPUT_MODE_MASK, &cmode,
+			     AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
+		ret = ad9467_outputmode_set(st, cmode);
 		if (ret)
 			return ret;
 

-- 
2.47.3

Re: [PATCH v2 1/3] iio: adc: ad9467: include two's complement in default mode

[Andy Shevchenko]

On Tue, Jan 13, 2026 at 12:12:47PM +0000, Tomas Melin wrote:
> All supported drivers currently implicitly use two's complement mode.
> Make this clear by declaring two's complement in the default
> output mode. Calibration mode uses offset binary, so change the output
> mode only when running the calibration or other test mode.

...

>  #include <linux/bitmap.h>
>  #include <linux/bitops.h>

Side note: bitmap.h implies and guarantees all bit ops to be provided. No need
to include bitops.h when bitmap.h is present.

...

>  #define CHIPID_AD9652                   0xC1
> +#define AD9652_DEF_OUTPUT_MODE		0x01
>  #define AD9652_REG_VREF_MASK            0xC0

Another side note: The other definitions around (mistakenly) have been indented
with spaces. You can see the problem in the diff.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/3] iio: adc: ad9467: include two's complement in default mode

[Tomas Melin]

On 13/01/2026 23:04, Andy Shevchenko wrote:
> On Tue, Jan 13, 2026 at 12:12:47PM +0000, Tomas Melin wrote:
>> All supported drivers currently implicitly use two's complement mode.
>> Make this clear by declaring two's complement in the default
>> output mode. Calibration mode uses offset binary, so change the output
>> mode only when running the calibration or other test mode.
> 
> ...
> 
>>  #include <linux/bitmap.h>
>>  #include <linux/bitops.h>
> 
> Side note: bitmap.h implies and guarantees all bit ops to be provided. No need
> to include bitops.h when bitmap.h is present.
> 
> ...
> 
>>  #define CHIPID_AD9652                   0xC1
>> +#define AD9652_DEF_OUTPUT_MODE		0x01
>>  #define AD9652_REG_VREF_MASK            0xC0
> 
> Another side note: The other definitions around (mistakenly) have been indented
> with spaces. You can see the problem in the diff.
I noticed this too but kept it out of this diff as not directly related.
Thanks for these remarks, keeping in mind for further updates.

BR,
Tomas



> 

[PATCH v2 2/3] 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 | 10 ++++++++++
 include/linux/iio/backend.h        |  9 +++++++++
 2 files changed, 19 insertions(+)

diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..997ec743dc67e7cf420ff667af33b4f6a71a5377 100644
--- a/drivers/iio/industrialio-backend.c
+++ b/drivers/iio/industrialio-backend.c
@@ -62,6 +62,7 @@ struct iio_backend {
 	 * backend. Used for the debugfs directory name.
 	 */
 	u8 idx;
+	u32 caps;
 };
 
 /*
@@ -542,6 +543,9 @@ int devm_iio_backend_request_buffer(struct device *dev,
 	struct iio_backend_buffer_pair *pair;
 	struct iio_buffer *buffer;
 
+	if (!iio_backend_caps(back, IIO_BACKEND_CAP_BUFFERING))
+		return 0;
+
 	pair = devm_kzalloc(dev, sizeof(*pair), GFP_KERNEL);
 	if (!pair)
 		return -ENOMEM;
@@ -774,6 +778,12 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
 }
 EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
 
+int iio_backend_caps(struct iio_backend *back, u32 cap)
+{
+	return back->caps & cap;
+}
+EXPORT_SYMBOL_NS_GPL(iio_backend_caps, "IIO_BACKEND");
+
 static void iio_backend_release(void *arg)
 {
 	struct iio_backend *back = arg;
diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..c020bc48cc05d6fcea00d23e471b12a29b5c0551 100644
--- a/include/linux/iio/backend.h
+++ b/include/linux/iio/backend.h
@@ -84,6 +84,12 @@ enum iio_backend_filter_type {
 	IIO_BACKEND_FILTER_TYPE_MAX
 };
 
+enum iio_backend_capabilities {
+	IIO_BACKEND_CAP_TEST_PATTERNS = BIT(0),
+	IIO_BACKEND_CAP_BUFFERING = BIT(1),
+	IIO_BACKEND_CAP_CALIBRATION = BIT(2)
+};
+
 /**
  * struct iio_backend_ops - operations structure for an iio_backend
  * @enable: Enable backend.
@@ -179,10 +185,12 @@ struct iio_backend_ops {
  * struct iio_backend_info - info structure for an iio_backend
  * @name: Backend name.
  * @ops: Backend operations.
+ * @caps: 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 +243,7 @@ int iio_backend_read_raw(struct iio_backend *back,
 			 long mask);
 int iio_backend_extend_chan_spec(struct iio_backend *back,
 				 struct iio_chan_spec *chan);
+int iio_backend_caps(struct iio_backend *back, u32 cap);
 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 v2 2/3] iio: industrialio-backend: support backend capabilities

[David Lechner]

On 1/13/26 6:12 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.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/industrialio-backend.c | 10 ++++++++++
>  include/linux/iio/backend.h        |  9 +++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..997ec743dc67e7cf420ff667af33b4f6a71a5377 100644
> --- a/drivers/iio/industrialio-backend.c
> +++ b/drivers/iio/industrialio-backend.c
> @@ -62,6 +62,7 @@ struct iio_backend {
>  	 * backend. Used for the debugfs directory name.
>  	 */
>  	u8 idx;
> +	u32 caps;
>  };
>  
>  /*
> @@ -542,6 +543,9 @@ int devm_iio_backend_request_buffer(struct device *dev,
>  	struct iio_backend_buffer_pair *pair;
>  	struct iio_buffer *buffer;
>  
> +	if (!iio_backend_caps(back, IIO_BACKEND_CAP_BUFFERING))
> +		return 0;

I would be inclined to return an error here and leave it up to the
caller to decide it if is OK to ignore the error or not. Otherwise,
the return value of 0 has two possible meanings and the caller would
have to separately check the flags to see which one it is.

We also need to add this flag to existing backends in the same patch,
otherwise it is going to break existing callers. (Or we could split
it into multiple patches - 1) add new enum and fields, 2) set flags
on existing backends - 3) introduce new checks).

> +
>  	pair = devm_kzalloc(dev, sizeof(*pair), GFP_KERNEL);
>  	if (!pair)
>  		return -ENOMEM;
> @@ -774,6 +778,12 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>  }
>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>  
> +int iio_backend_caps(struct iio_backend *back, u32 cap)

This would be more understandable to me as:

bool iio_backend_has_capabilities(struct iio_backend *back, u32 flags)

(caps is fine too if we want to keep it short)

Also could use kerneldoc comments.

> +{
> +	return back->caps & cap;
> +}
> +EXPORT_SYMBOL_NS_GPL(iio_backend_caps, "IIO_BACKEND");
> +
>  static void iio_backend_release(void *arg)
>  {
>  	struct iio_backend *back = arg;
> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..c020bc48cc05d6fcea00d23e471b12a29b5c0551 100644
> --- a/include/linux/iio/backend.h
> +++ b/include/linux/iio/backend.h
> @@ -84,6 +84,12 @@ enum iio_backend_filter_type {
>  	IIO_BACKEND_FILTER_TYPE_MAX
>  };
>  
> +enum iio_backend_capabilities {
> +	IIO_BACKEND_CAP_TEST_PATTERNS = BIT(0),
> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
> +	IIO_BACKEND_CAP_CALIBRATION = BIT(2)
> +};

These could use kernel doc comments the specifically call out the
functions that these correspond to. And also an explanation on why
we don't have them for everything (I assume we are just adding them
on an as-needed basis).

> +
>  /**
>   * struct iio_backend_ops - operations structure for an iio_backend
>   * @enable: Enable backend.
> @@ -179,10 +185,12 @@ struct iio_backend_ops {
>   * struct iio_backend_info - info structure for an iio_backend
>   * @name: Backend name.
>   * @ops: Backend operations.
> + * @caps: 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 +243,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>  			 long mask);
>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>  				 struct iio_chan_spec *chan);
> +int iio_backend_caps(struct iio_backend *back, u32 cap);
>  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 v2 2/3] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 13/01/2026 17:18, David Lechner wrote:
> On 1/13/26 6:12 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.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>>  drivers/iio/industrialio-backend.c | 10 ++++++++++
>>  include/linux/iio/backend.h        |  9 +++++++++
>>  2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
>> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..997ec743dc67e7cf420ff667af33b4f6a71a5377 100644
>> --- a/drivers/iio/industrialio-backend.c
>> +++ b/drivers/iio/industrialio-backend.c
>> @@ -62,6 +62,7 @@ struct iio_backend {
>>  	 * backend. Used for the debugfs directory name.
>>  	 */
>>  	u8 idx;
>> +	u32 caps;
>>  };
>>  
>>  /*
>> @@ -542,6 +543,9 @@ int devm_iio_backend_request_buffer(struct device *dev,
>>  	struct iio_backend_buffer_pair *pair;
>>  	struct iio_buffer *buffer;
>>  
>> +	if (!iio_backend_caps(back, IIO_BACKEND_CAP_BUFFERING))
>> +		return 0;
> 
> I would be inclined to return an error here and leave it up to the
> caller to decide it if is OK to ignore the error or not. Otherwise,
> the return value of 0 has two possible meanings and the caller would
> have to separately check the flags to see which one it is.

Good point. Thinking now perhaps this check should go into the frontend
side and the decision be made there whether to call this or not.

> 
> We also need to add this flag to existing backends in the same patch,
> otherwise it is going to break existing callers. (Or we could split
> it into multiple patches - 1) add new enum and fields, 2) set flags
> on existing backends - 3) introduce new checks).
If the check is moved to frontend side, this might change slightly. But
I agree, this needs to be kept in mind.

> 
>> +
>>  	pair = devm_kzalloc(dev, sizeof(*pair), GFP_KERNEL);
>>  	if (!pair)
>>  		return -ENOMEM;
>> @@ -774,6 +778,12 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>>  }
>>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>>  
>> +int iio_backend_caps(struct iio_backend *back, u32 cap)
> 
> This would be more understandable to me as:
> 
> bool iio_backend_has_capabilities(struct iio_backend *back, u32 flags)
> 
> (caps is fine too if we want to keep it short)
Ok, sounds good to me.

> 
> Also could use kerneldoc comments.
> 
>> +{
>> +	return back->caps & cap;
>> +}
>> +EXPORT_SYMBOL_NS_GPL(iio_backend_caps, "IIO_BACKEND");
>> +
>>  static void iio_backend_release(void *arg)
>>  {
>>  	struct iio_backend *back = arg;
>> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
>> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..c020bc48cc05d6fcea00d23e471b12a29b5c0551 100644
>> --- a/include/linux/iio/backend.h
>> +++ b/include/linux/iio/backend.h
>> @@ -84,6 +84,12 @@ enum iio_backend_filter_type {
>>  	IIO_BACKEND_FILTER_TYPE_MAX
>>  };
>>  
>> +enum iio_backend_capabilities {
>> +	IIO_BACKEND_CAP_TEST_PATTERNS = BIT(0),
>> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
>> +	IIO_BACKEND_CAP_CALIBRATION = BIT(2)
>> +};
> 
> These could use kernel doc comments the specifically call out the
> functions that these correspond to. And also an explanation on why
> we don't have them for everything (I assume we are just adding them
> on an as-needed basis).
Sure, will add doc and comment about the usage.

Thanks for the review,
Tomas


> 
>> +
>>  /**
>>   * struct iio_backend_ops - operations structure for an iio_backend
>>   * @enable: Enable backend.
>> @@ -179,10 +185,12 @@ struct iio_backend_ops {
>>   * struct iio_backend_info - info structure for an iio_backend
>>   * @name: Backend name.
>>   * @ops: Backend operations.
>> + * @caps: 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 +243,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>>  			 long mask);
>>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>>  				 struct iio_chan_spec *chan);
>> +int iio_backend_caps(struct iio_backend *back, u32 cap);
>>  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 v2 2/3] iio: industrialio-backend: support backend capabilities

[Andy Shevchenko]

On Tue, Jan 13, 2026 at 12:12:48PM +0000, Tomas Melin wrote:
> Not all backends support the full set of capabilities provided by the
> industrialio-backend framework. Capability bits can be used in frontends
> and backends for checking for a certain feature set, or if using
> related functions can be expected to fail.
> 
> Capability bits should be set by a compatible backend and provided when
> registering the backend.

...

> struct iio_backend {

>  	u8 idx;
> +	u32 caps;

Please, run `pahole` to see if there is a better place for a new member.
(I bet there is.)

>  };

...

> +enum iio_backend_capabilities {
> +	IIO_BACKEND_CAP_TEST_PATTERNS = BIT(0),
> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
> +	IIO_BACKEND_CAP_CALIBRATION = BIT(2)

Add trailing comma, it will allow to avoid unneeded churn in the future.

> +};


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/3] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 13/01/2026 23:06, Andy Shevchenko wrote:
> On Tue, Jan 13, 2026 at 12:12:48PM +0000, Tomas Melin wrote:
>> Not all backends support the full set of capabilities provided by the
>> industrialio-backend framework. Capability bits can be used in frontends
>> and backends for checking for a certain feature set, or if using
>> related functions can be expected to fail.
>>
>> Capability bits should be set by a compatible backend and provided when
>> registering the backend.
> 
> ...
> 
>> struct iio_backend {
> 
>>  	u8 idx;
>> +	u32 caps;
> 
> Please, run `pahole` to see if there is a better place for a new member.
> (I bet there is.)
Indeed, there seems to be. Thanks for the suggestion, will update.

> 
>>  };
> 
> ...
> 
>> +enum iio_backend_capabilities {
>> +	IIO_BACKEND_CAP_TEST_PATTERNS = BIT(0),
>> +	IIO_BACKEND_CAP_BUFFERING = BIT(1),
>> +	IIO_BACKEND_CAP_CALIBRATION = BIT(2)
> 
> Add trailing comma, it will allow to avoid unneeded churn in the future.
Sounds good, was just following existing style.

Thanks,
Tomas


> 
>> +};
> 
> 

Re: [PATCH v2 2/3] iio: industrialio-backend: support backend capabilities

[Andy Shevchenko]

On Wed, Jan 14, 2026 at 9:39 AM Tomas Melin <tomas.melin@vaisala.com> wrote:
> On 13/01/2026 23:06, Andy Shevchenko wrote:
> > On Tue, Jan 13, 2026 at 12:12:48PM +0000, Tomas Melin wrote:

...

> >> struct iio_backend {
> >
> >>      u8 idx;
> >> +    u32 caps;
> >
> > Please, run `pahole` to see if there is a better place for a new member.
> > (I bet there is.)
> Indeed, there seems to be. Thanks for the suggestion, will update.

Basically it should be your, as a developer, tool at hand to check the
data type layouts whenever the new member is added or rearrangement is
made.

> >>  };

...

> >> +enum iio_backend_capabilities {
> >> +    IIO_BACKEND_CAP_TEST_PATTERNS = BIT(0),
> >> +    IIO_BACKEND_CAP_BUFFERING = BIT(1),
> >> +    IIO_BACKEND_CAP_CALIBRATION = BIT(2)
> >
> > Add trailing comma, it will allow to avoid unneeded churn in the future.
> Sounds good, was just following existing style.

I haven't checked the rest, but the rule of thumb is that:
1) potential of the adding new entries after the last one — (almost)
always add a trailing comma;
2) termination entry — never add a trailing comma;
3) exceptions are some arrays which are located on one line, like
  static int foo[] = { 1, 2, 3 };
means no trailing comma.

> >> +};

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 3/3] iio: adc: ad9467: check for backend capabilities

[Tomas Melin]

For cases when the backend does not support test patterns or calibration,
do not attempt to use those features.

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

diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..ce7dde8b79540bb0eabfba9470b3984e8723d4b7 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -645,6 +645,9 @@ static int ad9467_backend_testmode_on(struct ad9467_state *st,
 	};
 	int ret;
 
+	if (!iio_backend_caps(st->back, IIO_BACKEND_CAP_TEST_PATTERNS))
+		return 0;
+
 	ret = iio_backend_data_format_set(st->back, chan, &data);
 	if (ret)
 		return ret;
@@ -665,6 +668,9 @@ static int ad9467_backend_testmode_off(struct ad9467_state *st,
 	};
 	int ret;
 
+	if (!iio_backend_caps(st->back, IIO_BACKEND_CAP_TEST_PATTERNS))
+		return 0;
+
 	ret = iio_backend_chan_disable(st->back, chan);
 	if (ret)
 		return ret;
@@ -807,6 +813,9 @@ static int ad9467_calibrate(struct ad9467_state *st)
 	bool invert = false, stat;
 	int ret;
 
+	if (!iio_backend_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+		return 0;
+
 	/* all points invalid */
 	bitmap_fill(st->calib_map, st->calib_map_size);
 

-- 
2.47.3

Re: [PATCH v2 3/3] iio: adc: ad9467: check for backend capabilities

[David Lechner]

On 1/13/26 6:12 AM, Tomas Melin wrote:
> For cases when the backend does not support test patterns or calibration,
> do not attempt to use those features.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/adc/ad9467.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..ce7dde8b79540bb0eabfba9470b3984e8723d4b7 100644
> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c
> @@ -645,6 +645,9 @@ static int ad9467_backend_testmode_on(struct ad9467_state *st,
>  	};
>  	int ret;
>  
> +	if (!iio_backend_caps(st->back, IIO_BACKEND_CAP_TEST_PATTERNS))
> +		return 0;
> +
>  	ret = iio_backend_data_format_set(st->back, chan, &data);
>  	if (ret)
>  		return ret;
> @@ -665,6 +668,9 @@ static int ad9467_backend_testmode_off(struct ad9467_state *st,
>  	};
>  	int ret;
>  
> +	if (!iio_backend_caps(st->back, IIO_BACKEND_CAP_TEST_PATTERNS))
> +		return 0;
> +
>  	ret = iio_backend_chan_disable(st->back, chan);
>  	if (ret)
>  		return ret;
> @@ -807,6 +813,9 @@ static int ad9467_calibrate(struct ad9467_state *st)
>  	bool invert = false, stat;
>  	int ret;
>  
> +	if (!iio_backend_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return 0;
> +
>  	/* all points invalid */
>  	bitmap_fill(st->calib_map, st->calib_map_size);
>  
> 

Same comments from my review of patch 2 apply here.