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

[PATCH v3 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 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: adc: ad9467: include two's complement in default mode
      iio: industrialio-backend: support backend capabilities
      iio: adc: adi-axi-adc: define supported iio-backend capabilities
      iio: adc: ad9467: check for backend capabilities

 drivers/iio/adc/ad9467.c           | 44 ++++++++++++++++++++++++++++++--------
 drivers/iio/adc/adi-axi-adc.c      |  2 ++
 drivers/iio/industrialio-backend.c | 17 +++++++++++++++
 include/linux/iio/backend.h        | 17 +++++++++++++++
 4 files changed, 71 insertions(+), 9 deletions(-)
---
base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7

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

[PATCH v3 1/4] 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 v3 1/4] iio: adc: ad9467: include two's complement in default mode

[Jonathan Cameron]

On Wed, 14 Jan 2026 10:45:50 +0000
Tomas Melin <tomas.melin@vaisala.com> 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.
> 
> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Given this is not really related to the rest of the series, I'll pick it
up now.  Applied to the togreg branch of iio.git which I'll initially push
out as testing.

No need to send this one in v4!
Thanks,

Jonathan

[PATCH v3 2/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 | 17 +++++++++++++++++
 include/linux/iio/backend.h        | 17 +++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..0a98fdd5df9db6cc233af819ac5243ba8cd5266f 100644
--- a/drivers/iio/industrialio-backend.c
+++ b/drivers/iio/industrialio-backend.c
@@ -56,6 +56,7 @@ struct iio_backend {
 	void *priv;
 	const char *name;
 	unsigned int cached_reg_addr;
+	u32 caps;
 	/*
 	 * This index is relative to the frontend. Meaning that for
 	 * frontends with multiple backends, this will be the index of this
@@ -774,6 +775,21 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
 }
 EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
 
+/**
+ * iio_backend_has_caps - Check if backend has specific capabilities
+ * @back: Backend device
+ * @caps: Capabilities to check
+ *
+ * RETURNS:
+ * Non-zero value if backend has all the requested capabilities,
+ * 0 otherwise.
+ */
+int iio_backend_has_caps(struct iio_backend *back, u32 caps)
+{
+	return back->caps & caps;
+}
+EXPORT_SYMBOL_NS_GPL(iio_backend_has_caps, "IIO_BACKEND");
+
 static void iio_backend_release(void *arg)
 {
 	struct iio_backend *back = arg;
@@ -1114,6 +1130,7 @@ int devm_iio_backend_register(struct device *dev,
 
 	back->ops = info->ops;
 	back->name = info->name;
+	back->caps = info->caps;
 	back->owner = dev->driver->owner;
 	back->dev = dev;
 	back->priv = priv;
diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..8a0df8e980e910ac2d5398275963dc5adf077c8a 100644
--- a/include/linux/iio/backend.h
+++ b/include/linux/iio/backend.h
@@ -84,6 +84,20 @@ enum iio_backend_filter_type {
 	IIO_BACKEND_FILTER_TYPE_MAX
 };
 
+/**
+ * enum iio_backend_capabilities - Backend capabilities
+ * Backend capabilities can be used by frontends to check if a given
+ * functionality is supported by the backend. Capabilities are loosely
+ * coupled with operations, meaning that a capability requires certain
+ * operations to be implemented by the backend.
+ * @IIO_BACKEND_CAP_CALIBRATION: Backend supports calibration. Needs at least
+ * iodelay_set(), test_pattern_set() data_sample_trigger(), chan_status()
+ * and data_format_set() operations implemented.
+ */
+enum iio_backend_capabilities {
+	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
+};
+
 /**
  * struct iio_backend_ops - operations structure for an iio_backend
  * @enable: Enable backend.
@@ -179,10 +193,12 @@ struct iio_backend_ops {
  * struct iio_backend_info - info structure for an iio_backend
  * @name: Backend name.
  * @ops: Backend operations.
+ * @caps: Backend capabilities. @see iio_backend_capabilities
  */
 struct iio_backend_info {
 	const char *name;
 	const struct iio_backend_ops *ops;
+	u32 caps;
 };
 
 int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
@@ -235,6 +251,7 @@ int iio_backend_read_raw(struct iio_backend *back,
 			 long mask);
 int iio_backend_extend_chan_spec(struct iio_backend *back,
 				 struct iio_chan_spec *chan);
+int iio_backend_has_caps(struct iio_backend *back, u32 caps);
 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 v3 2/4] iio: industrialio-backend: support backend capabilities

[Nuno Sá]

On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> Not all backends support the full set of capabilities provided by the
> industrialio-backend framework. Capability bits can be used in frontends
> and backends for checking for a certain feature set, or if using
> related functions can be expected to fail.
> 
> Capability bits should be set by a compatible backend and provided when
> registering the backend.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/industrialio-backend.c | 17 +++++++++++++++++
>  include/linux/iio/backend.h        | 17 +++++++++++++++++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..0a98fdd5df9db6cc233af819ac5243ba8cd5266f 100644
> --- a/drivers/iio/industrialio-backend.c
> +++ b/drivers/iio/industrialio-backend.c
> @@ -56,6 +56,7 @@ struct iio_backend {
>  	void *priv;
>  	const char *name;
>  	unsigned int cached_reg_addr;
> +	u32 caps;
>  	/*
>  	 * This index is relative to the frontend. Meaning that for
>  	 * frontends with multiple backends, this will be the index of this
> @@ -774,6 +775,21 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>  }
>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>  
> +/**
> + * iio_backend_has_caps - Check if backend has specific capabilities
> + * @back: Backend device
> + * @caps: Capabilities to check
> + *
> + * RETURNS:
> + * Non-zero value if backend has all the requested capabilities,
> + * 0 otherwise.
> + */
> +int iio_backend_has_caps(struct iio_backend *back, u32 caps)
> +{
> +	return back->caps & caps;
> +}
> +EXPORT_SYMBOL_NS_GPL(iio_backend_has_caps, "IIO_BACKEND");
> +
>  static void iio_backend_release(void *arg)
>  {
>  	struct iio_backend *back = arg;
> @@ -1114,6 +1130,7 @@ int devm_iio_backend_register(struct device *dev,
>  
>  	back->ops = info->ops;
>  	back->name = info->name;
> +	back->caps = info->caps;

It would be nice to sanity check the registered backend here. If it advertises some capability,
then better to support the corresponding op.

>  	back->owner = dev->driver->owner;
>  	back->dev = dev;
>  	back->priv = priv;
> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..8a0df8e980e910ac2d5398275963dc5adf077c8a 100644
> --- a/include/linux/iio/backend.h
> +++ b/include/linux/iio/backend.h
> @@ -84,6 +84,20 @@ enum iio_backend_filter_type {
>  	IIO_BACKEND_FILTER_TYPE_MAX
>  };
>  
> +/**
> + * enum iio_backend_capabilities - Backend capabilities
> + * Backend capabilities can be used by frontends to check if a given
> + * functionality is supported by the backend. Capabilities are loosely
> + * coupled with operations, meaning that a capability requires certain
> + * operations to be implemented by the backend.
> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports calibration. Needs at least
> + * iodelay_set(), test_pattern_set() data_sample_trigger(), chan_status()
> + * and data_format_set() operations implemented.

I would not be so explicit as the above. It is very specific to the ad9467 process.
There are other devices with other ways of calibrating the interface and I don't want
people to keep adding things into the comment. So it needs to be a bit more generic
and we should also be more explicit about it being about calibrating the data interface.

> + */
> +enum iio_backend_capabilities {
> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
> +};
> +
>  /**
>   * struct iio_backend_ops - operations structure for an iio_backend
>   * @enable: Enable backend.
> @@ -179,10 +193,12 @@ struct iio_backend_ops {
>   * struct iio_backend_info - info structure for an iio_backend
>   * @name: Backend name.
>   * @ops: Backend operations.
> + * @caps: Backend capabilities. @see iio_backend_capabilities
>   */
>  struct iio_backend_info {
>  	const char *name;
>  	const struct iio_backend_ops *ops;
> +	u32 caps;
>  };
>  
>  int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
> @@ -235,6 +251,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>  			 long mask);
>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>  				 struct iio_chan_spec *chan);
> +int iio_backend_has_caps(struct iio_backend *back, u32 caps);

Not what David suggested and I do agree with him FWIW.

- Nuno Sá

Re: [PATCH v3 2/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 14/01/2026 14:20, Nuno Sá wrote:
> On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
>> Not all backends support the full set of capabilities provided by the
>> industrialio-backend framework. Capability bits can be used in frontends
>> and backends for checking for a certain feature set, or if using
>> related functions can be expected to fail.
>>
>> Capability bits should be set by a compatible backend and provided when
>> registering the backend.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>>  drivers/iio/industrialio-backend.c | 17 +++++++++++++++++
>>  include/linux/iio/backend.h        | 17 +++++++++++++++++
>>  2 files changed, 34 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
>> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..0a98fdd5df9db6cc233af819ac5243ba8cd5266f 100644
>> --- a/drivers/iio/industrialio-backend.c
>> +++ b/drivers/iio/industrialio-backend.c
>> @@ -56,6 +56,7 @@ struct iio_backend {
>>  	void *priv;
>>  	const char *name;
>>  	unsigned int cached_reg_addr;
>> +	u32 caps;
>>  	/*
>>  	 * This index is relative to the frontend. Meaning that for
>>  	 * frontends with multiple backends, this will be the index of this
>> @@ -774,6 +775,21 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>>  }
>>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>>  
>> +/**
>> + * iio_backend_has_caps - Check if backend has specific capabilities
>> + * @back: Backend device
>> + * @caps: Capabilities to check
>> + *
>> + * RETURNS:
>> + * Non-zero value if backend has all the requested capabilities,
>> + * 0 otherwise.
>> + */
>> +int iio_backend_has_caps(struct iio_backend *back, u32 caps)
>> +{
>> +	return back->caps & caps;
>> +}
>> +EXPORT_SYMBOL_NS_GPL(iio_backend_has_caps, "IIO_BACKEND");
>> +
>>  static void iio_backend_release(void *arg)
>>  {
>>  	struct iio_backend *back = arg;
>> @@ -1114,6 +1130,7 @@ int devm_iio_backend_register(struct device *dev,
>>  
>>  	back->ops = info->ops;
>>  	back->name = info->name;
>> +	back->caps = info->caps;
> 
> It would be nice to sanity check the registered backend here. If it advertises some capability,
> then better to support the corresponding op.
That might be easier said than done. A certain capability might map to
slightly different operations on different frontend/backend combinations.
Agree on general level but I would omit this check currently.

> 
>>  	back->owner = dev->driver->owner;
>>  	back->dev = dev;
>>  	back->priv = priv;
>> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
>> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..8a0df8e980e910ac2d5398275963dc5adf077c8a 100644
>> --- a/include/linux/iio/backend.h
>> +++ b/include/linux/iio/backend.h
>> @@ -84,6 +84,20 @@ enum iio_backend_filter_type {
>>  	IIO_BACKEND_FILTER_TYPE_MAX
>>  };
>>  
>> +/**
>> + * enum iio_backend_capabilities - Backend capabilities
>> + * Backend capabilities can be used by frontends to check if a given
>> + * functionality is supported by the backend. Capabilities are loosely
>> + * coupled with operations, meaning that a capability requires certain
>> + * operations to be implemented by the backend.
>> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports calibration. Needs at least
>> + * iodelay_set(), test_pattern_set() data_sample_trigger(), chan_status()
>> + * and data_format_set() operations implemented.
> 
> I would not be so explicit as the above. It is very specific to the ad9467 process.
> There are other devices with other ways of calibrating the interface and I don't want
> people to keep adding things into the comment. So it needs to be a bit more generic
> and we should also be more explicit about it being about calibrating the data interface.
Agreed, I will update the text.

> 
>> + */
>> +enum iio_backend_capabilities {
>> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
>> +};
>> +
>>  /**
>>   * struct iio_backend_ops - operations structure for an iio_backend
>>   * @enable: Enable backend.
>> @@ -179,10 +193,12 @@ struct iio_backend_ops {
>>   * struct iio_backend_info - info structure for an iio_backend
>>   * @name: Backend name.
>>   * @ops: Backend operations.
>> + * @caps: Backend capabilities. @see iio_backend_capabilities
>>   */
>>  struct iio_backend_info {
>>  	const char *name;
>>  	const struct iio_backend_ops *ops;
>> +	u32 caps;
>>  };
>>  
>>  int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
>> @@ -235,6 +251,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>>  			 long mask);
>>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>>  				 struct iio_chan_spec *chan);
>> +int iio_backend_has_caps(struct iio_backend *back, u32 caps);
> 
> Not what David suggested and I do agree with him FWIW.
AFAIU this was exactly what was suggested. Citing:

>> bool iio_backend_has_capabilities(struct iio_backend *back, u32 flags)
>> (caps is fine too if we want to keep it short)

Using the longer format is not very practial. Can we keep it as

iio_backend_has_caps ?


Thanks,
Tomas


> 
> - Nuno Sá

Re: [PATCH v3 2/4] iio: industrialio-backend: support backend capabilities

[David Lechner]

On 1/19/26 7:49 AM, Tomas Melin wrote:

...

>>>  int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
>>> @@ -235,6 +251,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>>>  			 long mask);
>>>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>>>  				 struct iio_chan_spec *chan);
>>> +int iio_backend_has_caps(struct iio_backend *back, u32 caps);
>>
>> Not what David suggested and I do agree with him FWIW.
> AFAIU this was exactly what was suggested. Citing:

Slight difference. Should return bool instead of int.

> 
>>> bool iio_backend_has_capabilities(struct iio_backend *back, u32 flags)
>>> (caps is fine too if we want to keep it short)
> 
> Using the longer format is not very practical. Can we keep it as
> iio_backend_has_caps ?

Yes, I said as much already. But I guess you are asking Nuno. ;-)

Re: [PATCH v3 2/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 19/01/2026 17:00, David Lechner wrote:
> On 1/19/26 7:49 AM, Tomas Melin wrote:
> 
> ...
> 
>>>>  int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
>>>> @@ -235,6 +251,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>>>>  			 long mask);
>>>>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>>>>  				 struct iio_chan_spec *chan);
>>>> +int iio_backend_has_caps(struct iio_backend *back, u32 caps);
>>>
>>> Not what David suggested and I do agree with him FWIW.
>> AFAIU this was exactly what was suggested. Citing:
> 
> Slight difference. Should return bool instead of int.
Yes absolutely, perhaps it was about the signature. That is on the
change list for next version.

Thanks,
Tomas

> 
>>
>>>> bool iio_backend_has_capabilities(struct iio_backend *back, u32 flags)
>>>> (caps is fine too if we want to keep it short)
>>
>> Using the longer format is not very practical. Can we keep it as
>> iio_backend_has_caps ?
> 
> Yes, I said as much already. But I guess you are asking Nuno. ;-)

Re: [PATCH v3 2/4] iio: industrialio-backend: support backend capabilities

[Jonathan Cameron]

On Wed, 14 Jan 2026 10:45:51 +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>
Hi Tomas,

One thing inline.

Thanks

Jonathan


> ---
>  drivers/iio/industrialio-backend.c | 17 +++++++++++++++++
>  include/linux/iio/backend.h        | 17 +++++++++++++++++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..0a98fdd5df9db6cc233af819ac5243ba8cd5266f 100644
> --- a/drivers/iio/industrialio-backend.c
> +++ b/drivers/iio/industrialio-backend.c
> @@ -56,6 +56,7 @@ struct iio_backend {
>  	void *priv;
>  	const char *name;
>  	unsigned int cached_reg_addr;
> +	u32 caps;
>  	/*
>  	 * This index is relative to the frontend. Meaning that for
>  	 * frontends with multiple backends, this will be the index of this
> @@ -774,6 +775,21 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>  }
>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>  
> +/**
> + * iio_backend_has_caps - Check if backend has specific capabilities
> + * @back: Backend device
> + * @caps: Capabilities to check
> + *
> + * RETURNS:
> + * Non-zero value if backend has all the requested capabilities,

It doesn't...   back->caps = 0x1, caps = 0x3 returns 0x1 which
is non-zero.   I'd do
return (back->caps & caps) == caps;

Though that also rather strongly indicates this would be better returning
a bool.


> + * 0 otherwise.
> + */
> +int iio_backend_has_caps(struct iio_backend *back, u32 caps)
> +{
> +	return back->caps & caps;
> +}
> +EXPORT_SYMBOL_NS_GPL(iio_backend_has_caps, "IIO_BACKEND");

Re: [PATCH v3 2/4] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Hi,

On 14/01/2026 14:28, Jonathan Cameron wrote:
> On Wed, 14 Jan 2026 10:45:51 +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>
> Hi Tomas,
> 
> One thing inline.
> 
> Thanks
> 
> Jonathan
> 
> 
>> ---
>>  drivers/iio/industrialio-backend.c | 17 +++++++++++++++++
>>  include/linux/iio/backend.h        | 17 +++++++++++++++++
>>  2 files changed, 34 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
>> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..0a98fdd5df9db6cc233af819ac5243ba8cd5266f 100644
>> --- a/drivers/iio/industrialio-backend.c
>> +++ b/drivers/iio/industrialio-backend.c
>> @@ -56,6 +56,7 @@ struct iio_backend {
>>  	void *priv;
>>  	const char *name;
>>  	unsigned int cached_reg_addr;
>> +	u32 caps;
>>  	/*
>>  	 * This index is relative to the frontend. Meaning that for
>>  	 * frontends with multiple backends, this will be the index of this
>> @@ -774,6 +775,21 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>>  }
>>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>>  
>> +/**
>> + * iio_backend_has_caps - Check if backend has specific capabilities
>> + * @back: Backend device
>> + * @caps: Capabilities to check
>> + *
>> + * RETURNS:
>> + * Non-zero value if backend has all the requested capabilities,
> 
> It doesn't...   back->caps = 0x1, caps = 0x3 returns 0x1 which
> is non-zero.   I'd do
> return (back->caps & caps) == caps;
> 
> Though that also rather strongly indicates this would be better returning
> a bool.

Thanks for pointing this out, will fix and change to boolean return value.

Thanks,
Tomas


> 
> 
>> + * 0 otherwise.
>> + */
>> +int iio_backend_has_caps(struct iio_backend *back, u32 caps)
>> +{
>> +	return back->caps & caps;
>> +}
>> +EXPORT_SYMBOL_NS_GPL(iio_backend_has_caps, "IIO_BACKEND");
> 
> 
> 

Re: [PATCH v3 2/4] iio: industrialio-backend: support backend capabilities

[Nuno Sá]

On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> Not all backends support the full set of capabilities provided by the
> industrialio-backend framework. Capability bits can be used in frontends
> and backends for checking for a certain feature set, or if using
> related functions can be expected to fail.
> 
> Capability bits should be set by a compatible backend and provided when
> registering the backend.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/industrialio-backend.c | 17 +++++++++++++++++
>  include/linux/iio/backend.h        | 17 +++++++++++++++++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
> index 447b694d6d5f72dc6f018b1697fdb88e555bd61e..0a98fdd5df9db6cc233af819ac5243ba8cd5266f 100644
> --- a/drivers/iio/industrialio-backend.c
> +++ b/drivers/iio/industrialio-backend.c
> @@ -56,6 +56,7 @@ struct iio_backend {
>  	void *priv;
>  	const char *name;
>  	unsigned int cached_reg_addr;
> +	u32 caps;
>  	/*
>  	 * This index is relative to the frontend. Meaning that for
>  	 * frontends with multiple backends, this will be the index of this
> @@ -774,6 +775,21 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
>  }
>  EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
>  
> +/**
> + * iio_backend_has_caps - Check if backend has specific capabilities
> + * @back: Backend device
> + * @caps: Capabilities to check
> + *
> + * RETURNS:
> + * Non-zero value if backend has all the requested capabilities,
> + * 0 otherwise.
> + */
> +int iio_backend_has_caps(struct iio_backend *back, u32 caps)
> +{
> +	return back->caps & caps;
> +}
> +EXPORT_SYMBOL_NS_GPL(iio_backend_has_caps, "IIO_BACKEND");
> +
>  static void iio_backend_release(void *arg)
>  {
>  	struct iio_backend *back = arg;
> @@ -1114,6 +1130,7 @@ int devm_iio_backend_register(struct device *dev,
>  
>  	back->ops = info->ops;
>  	back->name = info->name;
> +	back->caps = info->caps;
>  	back->owner = dev->driver->owner;
>  	back->dev = dev;
>  	back->priv = priv;
> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
> index 7f815f3fed6ae34c65ffc579d5101020fc9bd336..8a0df8e980e910ac2d5398275963dc5adf077c8a 100644
> --- a/include/linux/iio/backend.h
> +++ b/include/linux/iio/backend.h
> @@ -84,6 +84,20 @@ enum iio_backend_filter_type {
>  	IIO_BACKEND_FILTER_TYPE_MAX
>  };
>  
> +/**
> + * enum iio_backend_capabilities - Backend capabilities
> + * Backend capabilities can be used by frontends to check if a given
> + * functionality is supported by the backend. Capabilities are loosely
> + * coupled with operations, meaning that a capability requires certain
> + * operations to be implemented by the backend.

We could also mention this is useful for frontends that are expected to
work with different backends which can offer different functionality.

- Nuno Sá

> + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports calibration. Needs at least
> + * iodelay_set(), test_pattern_set() data_sample_trigger(), chan_status()
> + * and data_format_set() operations implemented.
> + */
> +enum iio_backend_capabilities {
> +	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
> +};
> +
>  /**
>   * struct iio_backend_ops - operations structure for an iio_backend
>   * @enable: Enable backend.
> @@ -179,10 +193,12 @@ struct iio_backend_ops {
>   * struct iio_backend_info - info structure for an iio_backend
>   * @name: Backend name.
>   * @ops: Backend operations.
> + * @caps: Backend capabilities. @see iio_backend_capabilities
>   */
>  struct iio_backend_info {
>  	const char *name;
>  	const struct iio_backend_ops *ops;
> +	u32 caps;
>  };
>  
>  int iio_backend_chan_enable(struct iio_backend *back, unsigned int chan);
> @@ -235,6 +251,7 @@ int iio_backend_read_raw(struct iio_backend *back,
>  			 long mask);
>  int iio_backend_extend_chan_spec(struct iio_backend *back,
>  				 struct iio_chan_spec *chan);
> +int iio_backend_has_caps(struct iio_backend *back, u32 caps);
>  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 v3 3/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 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c
index 14fa4238c2b96b1ac722d537bc49ed4ca8e36925..968e35b0a29e0da3b4cfb8a33944b9c23e3cdb4e 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,
 };
 
 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,
 };
 
 static const struct iio_backend_ops adi_ad408x_ops = {

-- 
2.47.3

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

[Tomas Melin]

Add capability checks for operation with backends that do not support
full set of features, but are otherwise compatible with the device.

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

diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+		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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+		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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+		return 0;
+
 	/* all points invalid */
 	bitmap_fill(st->calib_map, st->calib_map_size);
 
@@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
 		return ret;
 
 	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
-	if (ret)
+	if (ret && ret != -EOPNOTSUPP)
 		return ret;
 
 	ret = devm_iio_backend_enable(&spi->dev, st->back);

-- 
2.47.3

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

[Nuno Sá]

On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> Add capability checks for operation with backends that do not support
> full set of features, but are otherwise compatible with the device.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/adc/ad9467.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return 0;
> +

As David suggested, it might make more sense to do the check from the callers. Not as
important as within the backend functions though.

>  	/* all points invalid */
>  	bitmap_fill(st->calib_map, st->calib_map_size);
>  
> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
>  		return ret;
>  
>  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
> -	if (ret)
> +	if (ret && ret != -EOPNOTSUPP)
>  		return ret;

Don't agree with the above. I would prefer to see a dedicated CAP for buffering
otherwise I would argue why not doing the same for everything? While it might
be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION
(given they are related to some extent), that does not apply to buffering.

- Nuno Sá

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

[Tomas Melin]

Hi,

On 14/01/2026 14:29, Nuno Sá wrote:
> On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
>> Add capability checks for operation with backends that do not support
>> full set of features, but are otherwise compatible with the device.
>>

>> +		return 0;
>> +
> 
> As David suggested, it might make more sense to do the check from the callers. Not as
> important as within the backend functions though.
> 
>>  	/* all points invalid */
>>  	bitmap_fill(st->calib_map, st->calib_map_size);
>>  
>> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
>>  		return ret;
>>  
>>  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
>> -	if (ret)
>> +	if (ret && ret != -EOPNOTSUPP)
>>  		return ret;
> 
> Don't agree with the above. I would prefer to see a dedicated CAP for buffering
> otherwise I would argue why not doing the same for everything? While it might
> be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION
> (given they are related to some extent), that does not apply to buffering.

Okay perhaps we first need to agree on how we define a capability;)

So my thinking here was that calibration capability expands across
several or even many op calls, so it's a feature level thing and
requires several coordinated functions. So does the test pattern, but
it's a sub entity of the calibration so I merged the two together. So
checking for a capability in these cases makes sense, since checking
against a single operation call for determining if the capability is
present is not easy and which function would it be, etc.

The backend buffer on the other hand maps to a single op call (in theory
two). So checking for that buffering capability can be done by checking
if the op call is supported (eopnotsupp). I was kindof thinking that why
need a capability if the mapping is 1:1 and the information is available
through that error value directly?

On frontend level, like here it is known that the driver can function
without that buffering, so if the backend does not supported it can be
okay to proceed.
If we add a capability for a single operation that has 1:1 mapping then
basically we should map all and that is not really the point?

I see the capability like a contract between the backend and frontend on
feature level, that the feature is there but the implementation of a
specific capability might actually differ depending on the use case
(like we see with ad9467 and ad485x calibration and their backends)

What are your thoughts about this?

Thanks,
Tomas


> 
> - Nuno Sá

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

[Nuno Sá]

On Wed, 2026-01-14 at 17:23 +0200, Tomas Melin wrote:
> Hi,
> 
> On 14/01/2026 14:29, Nuno Sá wrote:
> > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> > > Add capability checks for operation with backends that do not support
> > > full set of features, but are otherwise compatible with the device.
> > > 
> 
> > > +		return 0;
> > > +
> > 
> > As David suggested, it might make more sense to do the check from the callers. Not as
> > important as within the backend functions though.
> > 
> > >  	/* all points invalid */
> > >  	bitmap_fill(st->calib_map, st->calib_map_size);
> > >  
> > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
> > >  		return ret;
> > >  
> > >  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
> > > -	if (ret)
> > > +	if (ret && ret != -EOPNOTSUPP)
> > >  		return ret;
> > 
> > Don't agree with the above. I would prefer to see a dedicated CAP for buffering
> > otherwise I would argue why not doing the same for everything? While it might
> > be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION
> > (given they are related to some extent), that does not apply to buffering.
> 
> Okay perhaps we first need to agree on how we define a capability;)
> 
> So my thinking here was that calibration capability expands across
> several or even many op calls, so it's a feature level thing and
> requires several coordinated functions. So does the test pattern, but
> it's a sub entity of the calibration so I merged the two together. So
> checking for a capability in these cases makes sense, since checking
> against a single operation call for determining if the capability is
> present is not easy and which function would it be, etc.

Makes sense.

> 
> The backend buffer on the other hand maps to a single op call (in theory
> two). So checking for that buffering capability can be done by checking
> if the op call is supported (eopnotsupp). I was kindof thinking that why
> need a capability if the mapping is 1:1 and the information is available
> through that error value directly?

Yeah, TBH the only reason I can think of is readability. To me, it is more
explicit:

if (has_buffering())
	request_buffer(); //not allowed to fail

And can be a bit confusing having a mix of has_capability() and checking for
error codes.

But yes, checking for specific error codes for determining behavior is a common
pattern so I won't be nitpicky about it.

> 
> On frontend level, like here it is known that the driver can function
> without that buffering, so if the backend does not supported it can be
> okay to proceed.
> If we add a capability for a single operation that has 1:1 mapping then
> basically we should map all and that is not really the point?

> I see the capability like a contract between the backend and frontend on
> feature level, that the feature is there but the implementation of a
> specific capability might actually differ depending on the use case
> (like we see with ad9467 and ad485x calibration and their backends)
> 
> What are your thoughts about this?
> 

Ok, I think it makes sense to me but maybe we should be more explicit/clear in
the docs:

"... meaning that a capability requires certain 
operations to be implemented by the backend"

Maybe s/certain/multiple and we could even mention that if a frontend is interested
in knowing that a operation is not supported, the error code can be checked
(though this could be obvious already).

Let's see what Jonathan and others thinks about it.

- Nuno Sá

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

[Jonathan Cameron]

On Thu, 15 Jan 2026 11:54:28 +0000
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Wed, 2026-01-14 at 17:23 +0200, Tomas Melin wrote:
> > Hi,
> > 
> > On 14/01/2026 14:29, Nuno Sá wrote:  
> > > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:  
> > > > Add capability checks for operation with backends that do not support
> > > > full set of features, but are otherwise compatible with the device.
> > > >   
> >   
> > > > +		return 0;
> > > > +  
> > > 
> > > As David suggested, it might make more sense to do the check from the callers. Not as
> > > important as within the backend functions though.
> > >   
> > > >  	/* all points invalid */
> > > >  	bitmap_fill(st->calib_map, st->calib_map_size);
> > > >  
> > > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
> > > >  		return ret;
> > > >  
> > > >  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
> > > > -	if (ret)
> > > > +	if (ret && ret != -EOPNOTSUPP)
> > > >  		return ret;  
> > > 
> > > Don't agree with the above. I would prefer to see a dedicated CAP for buffering
> > > otherwise I would argue why not doing the same for everything? While it might
> > > be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION
> > > (given they are related to some extent), that does not apply to buffering.  
> > 
> > Okay perhaps we first need to agree on how we define a capability;)
> > 
> > So my thinking here was that calibration capability expands across
> > several or even many op calls, so it's a feature level thing and
> > requires several coordinated functions. So does the test pattern, but
> > it's a sub entity of the calibration so I merged the two together. So
> > checking for a capability in these cases makes sense, since checking
> > against a single operation call for determining if the capability is
> > present is not easy and which function would it be, etc.  
> 
> Makes sense.
> 
> > 
> > The backend buffer on the other hand maps to a single op call (in theory
> > two). So checking for that buffering capability can be done by checking
> > if the op call is supported (eopnotsupp). I was kindof thinking that why
> > need a capability if the mapping is 1:1 and the information is available
> > through that error value directly?  
> 
> Yeah, TBH the only reason I can think of is readability. To me, it is more
> explicit:
> 
> if (has_buffering())
> 	request_buffer(); //not allowed to fail
> 
> And can be a bit confusing having a mix of has_capability() and checking for
> error codes.
> 
> But yes, checking for specific error codes for determining behavior is a common
> pattern so I won't be nitpicky about it.

I'd prefer capabilities for each thing rather than a mixed scheme.
Nothing wrong with also returning -ENOTSUPP if someone doesn't check
the capability first as that's still helpful for debug.


> 
> > 
> > On frontend level, like here it is known that the driver can function
> > without that buffering, so if the backend does not supported it can be
> > okay to proceed.
> > If we add a capability for a single operation that has 1:1 mapping then
> > basically we should map all and that is not really the point?  
> 
> > I see the capability like a contract between the backend and frontend on
> > feature level, that the feature is there but the implementation of a
> > specific capability might actually differ depending on the use case
> > (like we see with ad9467 and ad485x calibration and their backends)
> > 
> > What are your thoughts about this?
> >   
> 
> Ok, I think it makes sense to me but maybe we should be more explicit/clear in
> the docs:
> 
> "... meaning that a capability requires certain 
> operations to be implemented by the backend"
> 
> Maybe s/certain/multiple and we could even mention that if a frontend is interested
> in knowing that a operation is not supported, the error code can be checked
> (though this could be obvious already).
> 
> Let's see what Jonathan and others thinks about it.
> 
> - Nuno Sá
> 
> 
> 
> 
> 
> 

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

[Tomas Melin]

On 16/01/2026 20:32, Jonathan Cameron wrote:
> On Thu, 15 Jan 2026 11:54:28 +0000
> Nuno Sá <noname.nuno@gmail.com> wrote:
> 
>> On Wed, 2026-01-14 at 17:23 +0200, Tomas Melin wrote:
>>> Hi,
>>>
>>> On 14/01/2026 14:29, Nuno Sá wrote:  
>>>> On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:  
>>>>> Add capability checks for operation with backends that do not support
>>>>> full set of features, but are otherwise compatible with the device.
>>>>>   
>>>   
>>>>> +		return 0;
>>>>> +  
>>>>
>>>> As David suggested, it might make more sense to do the check from the callers. Not as
>>>> important as within the backend functions though.
>>>>   
>>>>>  	/* all points invalid */
>>>>>  	bitmap_fill(st->calib_map, st->calib_map_size);
>>>>>  
>>>>> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
>>>>>  		return ret;
>>>>>  
>>>>>  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
>>>>> -	if (ret)
>>>>> +	if (ret && ret != -EOPNOTSUPP)
>>>>>  		return ret;  
>>>>
>>>> Don't agree with the above. I would prefer to see a dedicated CAP for buffering
>>>> otherwise I would argue why not doing the same for everything? While it might
>>>> be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP_CALIBRATION
>>>> (given they are related to some extent), that does not apply to buffering.  
>>>
>>> Okay perhaps we first need to agree on how we define a capability;)
>>>
>>> So my thinking here was that calibration capability expands across
>>> several or even many op calls, so it's a feature level thing and
>>> requires several coordinated functions. So does the test pattern, but
>>> it's a sub entity of the calibration so I merged the two together. So
>>> checking for a capability in these cases makes sense, since checking
>>> against a single operation call for determining if the capability is
>>> present is not easy and which function would it be, etc.  
>>
>> Makes sense.
>>
>>>
>>> The backend buffer on the other hand maps to a single op call (in theory
>>> two). So checking for that buffering capability can be done by checking
>>> if the op call is supported (eopnotsupp). I was kindof thinking that why
>>> need a capability if the mapping is 1:1 and the information is available
>>> through that error value directly?  
>>
>> Yeah, TBH the only reason I can think of is readability. To me, it is more
>> explicit:
>>
>> if (has_buffering())
>> 	request_buffer(); //not allowed to fail
>>
>> And can be a bit confusing having a mix of has_capability() and checking for
>> error codes.
>>
>> But yes, checking for specific error codes for determining behavior is a common
>> pattern so I won't be nitpicky about it.
> 
> I'd prefer capabilities for each thing rather than a mixed scheme.
> Nothing wrong with also returning -ENOTSUPP if someone doesn't check
> the capability first as that's still helpful for debug.

Okay I'll update accordingly. So capabilities are defined as being
something that

* is defined/added on a need basis to help frontends decide if a feature
is supported
* can map into multiple operations
* can map to a single operation

Thanks,
Tomas



> 
> 
>>
>>>
>>> On frontend level, like here it is known that the driver can function
>>> without that buffering, so if the backend does not supported it can be
>>> okay to proceed.
>>> If we add a capability for a single operation that has 1:1 mapping then
>>> basically we should map all and that is not really the point?  
>>
>>> I see the capability like a contract between the backend and frontend on
>>> feature level, that the feature is there but the implementation of a
>>> specific capability might actually differ depending on the use case
>>> (like we see with ad9467 and ad485x calibration and their backends)
>>>
>>> What are your thoughts about this?
>>>   
>>
>> Ok, I think it makes sense to me but maybe we should be more explicit/clear in
>> the docs:
>>
>> "... meaning that a capability requires certain 
>> operations to be implemented by the backend"
>>
>> Maybe s/certain/multiple and we could even mention that if a frontend is interested
>> in knowing that a operation is not supported, the error code can be checked
>> (though this could be obvious already).
>>
>> Let's see what Jonathan and others thinks about it.
>>
>> - Nuno Sá
>>
>>
>>
>>
>>
>>
> 
> 

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

[Jonathan Cameron]

On Wed, 14 Jan 2026 10:45:53 +0000
Tomas Melin <tomas.melin@vaisala.com> wrote:

> Add capability checks for operation with backends that do not support
> full set of features, but are otherwise compatible with the device.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Hi Tomas,

A few comments inline around when we should or should not return errors.

> ---
>  drivers/iio/adc/ad9467.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return 0;

If it isn't supported then isn't any attempt to turn test_mode on an error?
I would return errors from all these calls and only decide it doesn't
matter right at the top of the call stack.

In this particular case that's either calibration mode stuff (covered by check
below) or ad9467_chan_test_mod_write()  I'd just add a top level check there
on ability to do calibration. Alternative would be to not register the debugfs
at all.  Challenge is that is a small ABI break.  Do we care?  If we had
been doing this from the start we would have just hidden the pointless
interface.
(Key is we can change userspace interfaces, as long no one notices!)

> +
>  	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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return 0;

So this the idea of a stub calibration bothers me a little, but I think
it's more acceptable to do it for this top level call. So keep this one, but
all the others look to me like they should be returning errors.

> +
>  	/* all points invalid */
>  	bitmap_fill(st->calib_map, st->calib_map_size);
>  
> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
>  		return ret;
>  
>  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
> -	if (ret)
> +	if (ret && ret != -EOPNOTSUPP)

I don't see any modification of devm_iio_backend_request_buffer() in this
set so why why is it now acceptable to return not supported?
Given the capabilities stuff added, should this not be another capability
we check before trying to request the buffer?

>  		return ret;
>  
>  	ret = devm_iio_backend_enable(&spi->dev, st->back);
> 

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

[Tomas Melin]

Hi,

On 14/01/2026 14:45, Jonathan Cameron wrote:
> On Wed, 14 Jan 2026 10:45:53 +0000
> Tomas Melin <tomas.melin@vaisala.com> wrote:
> 
>> Add capability checks for operation with backends that do not support
>> full set of features, but are otherwise compatible with the device.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> Hi Tomas,
> 
> A few comments inline around when we should or should not return errors.
> 
>> ---
>>  drivers/iio/adc/ad9467.c | 11 ++++++++++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
>> index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
>> +		return 0;
> 
> If it isn't supported then isn't any attempt to turn test_mode on an error?
> I would return errors from all these calls and only decide it doesn't
> matter right at the top of the call stack.
I was considering this option too, I will change accordingly.

> 
> In this particular case that's either calibration mode stuff (covered by check
> below) or ad9467_chan_test_mod_write()  I'd just add a top level check there
> on ability to do calibration. Alternative would be to not register the debugfs
> at all.  Challenge is that is a small ABI break.  Do we care?  If we had
> been doing this from the start we would have just hidden the pointless
> interface.
> (Key is we can change userspace interfaces, as long no one notices!)

The testmodes from device side should still at least be there, only a
few of the modes currently have a backend mode, too.

> 
>> +
>>  	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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
>> +		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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
>> +		return 0;
> 
> So this the idea of a stub calibration bothers me a little, but I think
> it's more acceptable to do it for this top level call. So keep this one, but
> all the others look to me like they should be returning errors.
OK
> 
>> +
>>  	/* all points invalid */
>>  	bitmap_fill(st->calib_map, st->calib_map_size);
>>  
>> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
>>  		return ret;
>>  
>>  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
>> -	if (ret)
>> +	if (ret && ret != -EOPNOTSUPP)
> 
> I don't see any modification of devm_iio_backend_request_buffer() in this
> set so why why is it now acceptable to return not supported?
> Given the capabilities stuff added, should this not be another capability
> we check before trying to request the buffer?
Basically because I reasoned that capabilities are more like features
rather than single operation. The single operation tells if the
capability is there. I reasoned a bit more about this in a related
answer replying to Nuno, hopefully you find time to read that
explanation and provide your thoughts.

And reason it would now be acceptable is that the original code does not
account for any optional features within the backends, but now it does.
It knows it can work without the buffering, and the return value can
tell if it is supported or not.

Thanks,
Tomas



> 
>>  		return ret;
>>  
>>  	ret = devm_iio_backend_enable(&spi->dev, st->back);
>>
> 

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

[Nuno Sá]

On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> Add capability checks for operation with backends that do not support
> full set of features, but are otherwise compatible with the device.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---

Another thing is that we also need to care about ad9467_debugfs_init(). No point in
adding that interface if we cannot do (or get) anything with it.

I guess we can still have the device specific test modes (without going to the backend)
but "calibration_table_dump" does not make sense to add if IIO_BACKEND_CAP_CALIBRATION is off.

With a dummy backend, iio_backend_debugfs_add() should already be a no-op.

- Nuno Sá

>  drivers/iio/adc/ad9467.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 9cfe66425d4e91e215cccc40e24a92c5e99e9b87..349779a049ad68b4c9f72abfc40154b4a3f2e095 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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		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_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return 0;
> +
>  	/* all points invalid */
>  	bitmap_fill(st->calib_map, st->calib_map_size);
>  
> @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi)
>  		return ret;
>  
>  	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
> -	if (ret)
> +	if (ret && ret != -EOPNOTSUPP)
>  		return ret;
>  
>  	ret = devm_iio_backend_enable(&spi->dev, st->back);

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

[Nuno Sá]

On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> 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>
> ---

Hi Tomas,

> 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

As stated in my patch comment. Using opnotsupported for buffers defeats
the CAPS idea.


But more importantly, how are your usecase supposed to work with this
series? I'm not seeing any new backend being added as part of the series.
Point is, if we are adding all of this, I would expect your usecase to
have fully upstream support. If I'm not missing nothing, we would at least
need a dummy backend providing stubs for enable()/disable()

- Nuno Sá

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

[Tomas Melin]

Hi Nuno,

On 14/01/2026 15:32, Nuno Sá wrote:
> On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
>> 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>
>> ---
> 
> Hi Tomas,
> 
>> 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
> 
> As stated in my patch comment. Using opnotsupported for buffers defeats
> the CAPS idea.
Please check my other reply, to me adding cap for a 1:1 mapping of a
operation seems like duplicating the information. But of course, this
can be viewed from different angles and it is also possible to look at
it like that.

> 
> 
> But more importantly, how are your usecase supposed to work with this
> series? I'm not seeing any new backend being added as part of the series.
> Point is, if we are adding all of this, I would expect your usecase to
> have fully upstream support. If I'm not missing nothing, we would at least
> need a dummy backend providing stubs for enable()/disable()
My usecase adds simplistic backend support and registers to the
framework via an related driver. So that use case works with that
approach. I think it is better to assume there is always some entity
that can take on the role of being backend, rather than adding a dummy
backend. Adding the capabilities are defining role here, as having that
allows for customer integrations with backends that differ but are of no
interest for the mainline.

Thanks,
Tomas






> 
> - Nuno Sá

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

[Nuno Sá]

On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
> Hi Nuno,
> 
> On 14/01/2026 15:32, Nuno Sá wrote:
> > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote:
> > > 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>
> > > ---
> > 
> > Hi Tomas,
> > 
> > > 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
> > 
> > As stated in my patch comment. Using opnotsupported for buffers defeats
> > the CAPS idea.
> Please check my other reply, to me adding cap for a 1:1 mapping of a
> operation seems like duplicating the information. But of course, this
> can be viewed from different angles and it is also possible to look at
> it like that.
> 
> > 
> > 
> > But more importantly, how are your usecase supposed to work with this
> > series? I'm not seeing any new backend being added as part of the series.
> > Point is, if we are adding all of this, I would expect your usecase to
> > have fully upstream support. If I'm not missing nothing, we would at least
> > need a dummy backend providing stubs for enable()/disable()
> My usecase adds simplistic backend support and registers to the
> framework via an related driver. So that use case works with that
> approach. I think it is better to assume there is always some entity
> that can take on the role of being backend, rather than adding a dummy
> backend. Adding the capabilities are defining role here, as having that

Well, I would argue your backend is exactly that. A dummy one :)

> allows for customer integrations with backends that differ but are of no
> interest for the mainline.
> 

It would still be nice to have this usecase fully supported upstream 
(having a black box backend). 

What I have in mind would be really to do the same as regulators do. If you call
regulator_get() then the consumer really assumes a regulator must exist. But if it
is something the kernel does not control we get a dummy one with very limited
functionality/stubs. If you call regulator_get_optional(), then the regulator is
really optional and might not physically exist. Seems very similar to what you have.

- Nuno Sá

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

[Tomas Melin]

Hi,

On 15/01/2026 14:04, Nuno Sá wrote:
> On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
>> Hi Nuno,
>>
>> On 14/01/2026 15:32, Nuno Sá wrote:

>>>
>>> But more importantly, how are your usecase supposed to work with this
>>> series? I'm not seeing any new backend being added as part of the series.
>>> Point is, if we are adding all of this, I would expect your usecase to
>>> have fully upstream support. If I'm not missing nothing, we would at least
>>> need a dummy backend providing stubs for enable()/disable()
>> My usecase adds simplistic backend support and registers to the
>> framework via an related driver. So that use case works with that
>> approach. I think it is better to assume there is always some entity
>> that can take on the role of being backend, rather than adding a dummy
>> backend. Adding the capabilities are defining role here, as having that
> 
> Well, I would argue your backend is exactly that. A dummy one :)

It's kindof ;)  But on general level it handles the stuff a backend
needs to do, just does not have most of the operations or capabilities
available. OTOH having the backend defined means that if some of the
capabilites would be added, there is a natural place to add it.

> 
>> allows for customer integrations with backends that differ but are of no
>> interest for the mainline.
>>
> 
> It would still be nice to have this usecase fully supported upstream 
> (having a black box backend). 
> 
> What I have in mind would be really to do the same as regulators do. If you call
> regulator_get() then the consumer really assumes a regulator must exist. But if it
> is something the kernel does not control we get a dummy one with very limited
> functionality/stubs. If you call regulator_get_optional(), then the regulator is
> really optional and might not physically exist. Seems very similar to what you have.

There could perhaps be use for a backend like this too. Is the idea such
that one would still need to define a "iio-backend-simple" node or such
to device tree which would then provide the backend link and compatible?

Thanks,
Tomas

> 
> - Nuno Sá

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

[Nuno Sá]

On Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:
> Hi,
> 
> On 15/01/2026 14:04, Nuno Sá wrote:
> > On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:
> > > Hi Nuno,
> > > 
> > > On 14/01/2026 15:32, Nuno Sá wrote:
> 
> > > > 
> > > > But more importantly, how are your usecase supposed to work with this
> > > > series? I'm not seeing any new backend being added as part of the series.
> > > > Point is, if we are adding all of this, I would expect your usecase to
> > > > have fully upstream support. If I'm not missing nothing, we would at least
> > > > need a dummy backend providing stubs for enable()/disable()
> > > My usecase adds simplistic backend support and registers to the
> > > framework via an related driver. So that use case works with that
> > > approach. I think it is better to assume there is always some entity
> > > that can take on the role of being backend, rather than adding a dummy
> > > backend. Adding the capabilities are defining role here, as having that
> > 
> > Well, I would argue your backend is exactly that. A dummy one :)
> 
> It's kindof ;)  But on general level it handles the stuff a backend
> needs to do, just does not have most of the operations or capabilities
> available. OTOH having the backend defined means that if some of the
> capabilites would be added, there is a natural place to add it.
> 

But there's nothing you can control from Linux right?

> > 
> > > allows for customer integrations with backends that differ but are of no
> > > interest for the mainline.
> > > 
> > 
> > It would still be nice to have this usecase fully supported upstream 
> > (having a black box backend). 
> > 
> > What I have in mind would be really to do the same as regulators do. If you call
> > regulator_get() then the consumer really assumes a regulator must exist. But if it
> > is something the kernel does not control we get a dummy one with very limited
> > functionality/stubs. If you call regulator_get_optional(), then the regulator is
> > really optional and might not physically exist. Seems very similar to what you have.
> 
> There could perhaps be use for a backend like this too. Is the idea such
> that one would still need to define a "iio-backend-simple" node or such
> to device tree which would then provide the backend link and compatible?
> 

My idea would be to automatically define one if we fail to find it. Naturally if we
ever add an optional() get the dummy could not be added. See how regulator_get()
handles it. That's basically what I have in mind.

- Nuno Sá

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

[Jonathan Cameron]

On Fri, 16 Jan 2026 13:31:39 +0000
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:
> > Hi,
> > 
> > On 15/01/2026 14:04, Nuno Sá wrote:  
> > > On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:  
> > > > Hi Nuno,
> > > > 
> > > > On 14/01/2026 15:32, Nuno Sá wrote:  
> >   
> > > > > 
> > > > > But more importantly, how are your usecase supposed to work with this
> > > > > series? I'm not seeing any new backend being added as part of the series.
> > > > > Point is, if we are adding all of this, I would expect your usecase to
> > > > > have fully upstream support. If I'm not missing nothing, we would at least
> > > > > need a dummy backend providing stubs for enable()/disable()  
> > > > My usecase adds simplistic backend support and registers to the
> > > > framework via an related driver. So that use case works with that
> > > > approach. I think it is better to assume there is always some entity
> > > > that can take on the role of being backend, rather than adding a dummy
> > > > backend. Adding the capabilities are defining role here, as having that  
> > > 
> > > Well, I would argue your backend is exactly that. A dummy one :)  
> > 
> > It's kindof ;)  But on general level it handles the stuff a backend
> > needs to do, just does not have most of the operations or capabilities
> > available. OTOH having the backend defined means that if some of the
> > capabilites would be added, there is a natural place to add it.
> >   
> 
> But there's nothing you can control from Linux right?
> 
> > >   
> > > > allows for customer integrations with backends that differ but are of no
> > > > interest for the mainline.
> > > >   
> > > 
> > > It would still be nice to have this usecase fully supported upstream 
> > > (having a black box backend). 
> > > 
> > > What I have in mind would be really to do the same as regulators do. If you call
> > > regulator_get() then the consumer really assumes a regulator must exist. But if it
> > > is something the kernel does not control we get a dummy one with very limited
> > > functionality/stubs. If you call regulator_get_optional(), then the regulator is
> > > really optional and might not physically exist. Seems very similar to what you have.  
> > 
> > There could perhaps be use for a backend like this too. Is the idea such
> > that one would still need to define a "iio-backend-simple" node or such
> > to device tree which would then provide the backend link and compatible?
> >   
> 
> My idea would be to automatically define one if we fail to find it. Naturally if we
> ever add an optional() get the dummy could not be added. See how regulator_get()
> handles it. That's basically what I have in mind.
> 
It's an interesting idea, but I'd like some input from DT folk on this.
The fake regulators thing is kind of legacy from lots of drivers gaining the
power handling later and it being boring / too late to add all the fixed regs
to DT.  This is a much less common case and I find it a little unlikely there
is nothing useful to know about where the data is going - so how useful
is an autocreated backend?

Jonathan

> - Nuno Sá

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

[Nuno Sá]

On Fri, 2026-01-16 at 18:37 +0000, Jonathan Cameron wrote:
> On Fri, 16 Jan 2026 13:31:39 +0000
> Nuno Sá <noname.nuno@gmail.com> wrote:
> 
> > On Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:
> > > Hi,
> > > 
> > > On 15/01/2026 14:04, Nuno Sá wrote:  
> > > > On Wed, 2026-01-14 at 17:32 +0200, Tomas Melin wrote:  
> > > > > Hi Nuno,
> > > > > 
> > > > > On 14/01/2026 15:32, Nuno Sá wrote:  
> > >   
> > > > > > 
> > > > > > But more importantly, how are your usecase supposed to work with this
> > > > > > series? I'm not seeing any new backend being added as part of the series.
> > > > > > Point is, if we are adding all of this, I would expect your usecase to
> > > > > > have fully upstream support. If I'm not missing nothing, we would at
> > > > > > least
> > > > > > need a dummy backend providing stubs for enable()/disable()  
> > > > > My usecase adds simplistic backend support and registers to the
> > > > > framework via an related driver. So that use case works with that
> > > > > approach. I think it is better to assume there is always some entity
> > > > > that can take on the role of being backend, rather than adding a dummy
> > > > > backend. Adding the capabilities are defining role here, as having that  
> > > > 
> > > > Well, I would argue your backend is exactly that. A dummy one :)  
> > > 
> > > It's kindof ;)  But on general level it handles the stuff a backend
> > > needs to do, just does not have most of the operations or capabilities
> > > available. OTOH having the backend defined means that if some of the
> > > capabilites would be added, there is a natural place to add it.
> > >   
> > 
> > But there's nothing you can control from Linux right?
> > 
> > > >   
> > > > > allows for customer integrations with backends that differ but are of no
> > > > > interest for the mainline.
> > > > >   
> > > > 
> > > > It would still be nice to have this usecase fully supported upstream 
> > > > (having a black box backend). 
> > > > 
> > > > What I have in mind would be really to do the same as regulators do. If you
> > > > call
> > > > regulator_get() then the consumer really assumes a regulator must exist. But
> > > > if it
> > > > is something the kernel does not control we get a dummy one with very limited
> > > > functionality/stubs. If you call regulator_get_optional(), then the regulator
> > > > is
> > > > really optional and might not physically exist. Seems very similar to what
> > > > you have.  
> > > 
> > > There could perhaps be use for a backend like this too. Is the idea such
> > > that one would still need to define a "iio-backend-simple" node or such
> > > to device tree which would then provide the backend link and compatible?
> > >   
> > 
> > My idea would be to automatically define one if we fail to find it. Naturally if
> > we
> > ever add an optional() get the dummy could not be added. See how regulator_get()
> > handles it. That's basically what I have in mind.
> > 
> It's an interesting idea, but I'd like some input from DT folk on this.
> The fake regulators thing is kind of legacy from lots of drivers gaining the
> power handling later and it being boring / too late to add all the fixed regs
> to DT.  This is a much less common case and I find it a little unlikely there
> is nothing useful to know about where the data is going - so how useful
> is an autocreated backend?
> 

Not really that useful. This was just something I thought of to have the full usecase
supported in Linux. But, if we can add an explicit fixed/dummy (whatever name fits
best) backend with a proper compatible that would be preferable, yes.

- Nuno Sá

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

[Tomas Melin]

Hi,

On 18/01/2026 11:21, Nuno Sá wrote:
> On Fri, 2026-01-16 at 18:37 +0000, Jonathan Cameron wrote:
>> On Fri, 16 Jan 2026 13:31:39 +0000
>> Nuno Sá <noname.nuno@gmail.com> wrote:
>>
>>> On Thu, 2026-01-15 at 15:30 +0200, Tomas Melin wrote:

>>>>> What I have in mind would be really to do the same as regulators do. If you
>>>>> call
>>>>> regulator_get() then the consumer really assumes a regulator must exist. But
>>>>> if it
>>>>> is something the kernel does not control we get a dummy one with very limited
>>>>> functionality/stubs. If you call regulator_get_optional(), then the regulator
>>>>> is
>>>>> really optional and might not physically exist. Seems very similar to what
>>>>> you have.  
>>>>
>>>> There could perhaps be use for a backend like this too. Is the idea such
>>>> that one would still need to define a "iio-backend-simple" node or such
>>>> to device tree which would then provide the backend link and compatible?
>>>>   
>>>
>>> My idea would be to automatically define one if we fail to find it. Naturally if
>>> we
>>> ever add an optional() get the dummy could not be added. See how regulator_get()
>>> handles it. That's basically what I have in mind.
>>>
>> It's an interesting idea, but I'd like some input from DT folk on this.
>> The fake regulators thing is kind of legacy from lots of drivers gaining the
>> power handling later and it being boring / too late to add all the fixed regs
>> to DT.  This is a much less common case and I find it a little unlikely there
>> is nothing useful to know about where the data is going - so how useful
>> is an autocreated backend?
>>
> 
> Not really that useful. This was just something I thought of to have the full usecase
> supported in Linux. But, if we can add an explicit fixed/dummy (whatever name fits
> best) backend with a proper compatible that would be preferable, yes.

For now I think we should be okay without a dummy backend. Once the
capability feature is accepted this will be enough for current needs.
The capabilites will bring in a lot of flexibility as to what needs to
be implemented and not in the backend. In my case I can register a
backend from a driver that is not exactly that, but provides related
functionality.

BR,
Tomas


> 
> - Nuno Sá
>