[PATCH 0/2] iio: adc: ad9467: Enable operation without iio-backend

[PATCH 0/2] iio: adc: ad9467: Enable operation without iio-backend

[Tomas Melin]

Not all users can or want to use the device with an iio-backend.
For these users, let the driver work in standalone mode, not coupled
to the backend or the services it provides.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
Tomas Melin (2):
      iio: adc: ad9467: include two's complement in default mode
      iio: adc: ad9467: make iio backend optional

 drivers/iio/adc/ad9467.c | 70 ++++++++++++++++++++++++++++++++++--------------
 1 file changed, 50 insertions(+), 20 deletions(-)
---
base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7

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

[PATCH 1/2] 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.

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..60fc3361b2689a4c38287c613ef93fe00338e5fa 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -72,6 +72,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 +86,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 +94,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 +102,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 +110,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 +118,7 @@
  */
 
 #define CHIPID_AD9643			0x82
+#define AD9643_DEF_OUTPUT_MODE		0x01
 #define AD9643_REG_VREF_MASK		0x1F
 
 /*
@@ -124,6 +126,7 @@
  */
 
 #define CHIPID_AD9652                   0xC1
+#define AD9652_DEF_OUTPUT_MODE		0x01
 #define AD9652_REG_VREF_MASK            0xC0
 
 /*
@@ -131,6 +134,7 @@
  */
 
 #define CHIPID_AD9649			0x6F
+#define AD9649_DEF_OUTPUT_MODE		0x01
 #define AD9649_TEST_POINTS		8
 
 #define AD9647_MAX_TEST_POINTS		32
@@ -461,6 +465,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 +484,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 +502,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 +678,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 & ~AN877_ADC_OUTPUT_MODE_MASK) |
+		FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
+			   AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
+	ret = ad9467_outputmode_set(st, cmode);
 	if (ret)
 		return ret;
 
@@ -778,7 +789,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 +1185,18 @@ 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 &
+			~AN877_ADC_OUTPUT_MODE_MASK) |
+			FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
+				   AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
+		ret = ad9467_outputmode_set(st, cmode);
 		if (ret)
 			return ret;
 

-- 
2.47.3

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

[Nuno Sá]

On Tue, 2025-12-16 at 11:40 +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.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---

Reviewed-by: Nuno Sá <nuno.sa@analog.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..60fc3361b2689a4c38287c613ef93fe00338e5fa 100644
> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c
> @@ -72,6 +72,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 +86,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 +94,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 +102,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 +110,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 +118,7 @@
>   */
>  
>  #define CHIPID_AD9643			0x82
> +#define AD9643_DEF_OUTPUT_MODE		0x01
>  #define AD9643_REG_VREF_MASK		0x1F
>  
>  /*
> @@ -124,6 +126,7 @@
>   */
>  
>  #define CHIPID_AD9652                   0xC1
> +#define AD9652_DEF_OUTPUT_MODE		0x01
>  #define AD9652_REG_VREF_MASK            0xC0
>  
>  /*
> @@ -131,6 +134,7 @@
>   */
>  
>  #define CHIPID_AD9649			0x6F
> +#define AD9649_DEF_OUTPUT_MODE		0x01
>  #define AD9649_TEST_POINTS		8
>  
>  #define AD9647_MAX_TEST_POINTS		32
> @@ -461,6 +465,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 +484,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 +502,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 +678,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 & ~AN877_ADC_OUTPUT_MODE_MASK) |
> +		FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
> +			   AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
> +	ret = ad9467_outputmode_set(st, cmode);
>  	if (ret)
>  		return ret;
>  
> @@ -778,7 +789,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 +1185,18 @@ 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 &
> +			~AN877_ADC_OUTPUT_MODE_MASK) |
> +			FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
> +				   AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
> +		ret = ad9467_outputmode_set(st, cmode);
>  		if (ret)
>  			return ret;
>  

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

[kernel test robot]

Hi Tomas,

kernel test robot noticed the following build errors:

[auto build test ERROR on a7b10f0963c651a6406d958a5f64b9c5594f84da]

url:    https://github.com/intel-lab-lkp/linux/commits/Tomas-Melin/iio-adc-ad9467-include-two-s-complement-in-default-mode/20251216-233841
base:   a7b10f0963c651a6406d958a5f64b9c5594f84da
patch link:    https://lore.kernel.org/r/20251216-b4-ad9467-optional-backend-v1-1-83e61531ef4d%40vaisala.com
patch subject: [PATCH 1/2] iio: adc: ad9467: include two's complement in default mode
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20251220/202512201109.STBoyjad-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251220/202512201109.STBoyjad-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512201109.STBoyjad-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/iio/adc/ad9467.c: In function 'ad9647_calibrate_prepare':
>> drivers/iio/adc/ad9467.c:686:17: error: implicit declaration of function 'FIELD_PREP' [-Wimplicit-function-declaration]
     686 |                 FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
         |                 ^~~~~~~~~~


vim +/FIELD_PREP +686 drivers/iio/adc/ad9467.c

   678	
   679	static int ad9647_calibrate_prepare(struct ad9467_state *st)
   680	{
   681		unsigned int cmode;
   682		unsigned int c;
   683		int ret;
   684	
   685		cmode = (st->info->default_output_mode & ~AN877_ADC_OUTPUT_MODE_MASK) |
 > 686			FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
   687				   AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
   688		ret = ad9467_outputmode_set(st, cmode);
   689		if (ret)
   690			return ret;
   691	
   692		for (c = 0; c < st->info->num_channels; c++) {
   693			ret = ad9467_testmode_set(st, c, AN877_ADC_TESTMODE_PN9_SEQ);
   694			if (ret)
   695				return ret;
   696	
   697			ret = ad9467_backend_testmode_on(st, c,
   698							 IIO_BACKEND_ADI_PRBS_9A);
   699			if (ret)
   700				return ret;
   701		}
   702	
   703		return 0;
   704	}
   705	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[kernel test robot]

Hi Tomas,

kernel test robot noticed the following build errors:

[auto build test ERROR on a7b10f0963c651a6406d958a5f64b9c5594f84da]

url:    https://github.com/intel-lab-lkp/linux/commits/Tomas-Melin/iio-adc-ad9467-include-two-s-complement-in-default-mode/20251216-233841
base:   a7b10f0963c651a6406d958a5f64b9c5594f84da
patch link:    https://lore.kernel.org/r/20251216-b4-ad9467-optional-backend-v1-1-83e61531ef4d%40vaisala.com
patch subject: [PATCH 1/2] iio: adc: ad9467: include two's complement in default mode
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20251220/202512201254.2FFxkibV-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251220/202512201254.2FFxkibV-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512201254.2FFxkibV-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/iio/adc/ad9467.c:686:3: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     686 |                 FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
         |                 ^
   drivers/iio/adc/ad9467.c:1197:4: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    1197 |                         FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
         |                         ^
   2 errors generated.


vim +/FIELD_PREP +686 drivers/iio/adc/ad9467.c

   678	
   679	static int ad9647_calibrate_prepare(struct ad9467_state *st)
   680	{
   681		unsigned int cmode;
   682		unsigned int c;
   683		int ret;
   684	
   685		cmode = (st->info->default_output_mode & ~AN877_ADC_OUTPUT_MODE_MASK) |
 > 686			FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
   687				   AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
   688		ret = ad9467_outputmode_set(st, cmode);
   689		if (ret)
   690			return ret;
   691	
   692		for (c = 0; c < st->info->num_channels; c++) {
   693			ret = ad9467_testmode_set(st, c, AN877_ADC_TESTMODE_PN9_SEQ);
   694			if (ret)
   695				return ret;
   696	
   697			ret = ad9467_backend_testmode_on(st, c,
   698							 IIO_BACKEND_ADI_PRBS_9A);
   699			if (ret)
   700				return ret;
   701		}
   702	
   703		return 0;
   704	}
   705	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Jonathan Cameron]

On Tue, 16 Dec 2025 11:40:05 +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.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
A few comments inline, along with the obvious build error fix
from the bot report of including linux/bitfield.h

> ---
>  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..60fc3361b2689a4c38287c613ef93fe00338e5fa 100644
> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c

> @@ -671,10 +678,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 & ~AN877_ADC_OUTPUT_MODE_MASK) |
> +		FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
> +			   AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
As below. Maybe copy then FIELD_MODIFY() the result.

> +	ret = ad9467_outputmode_set(st, cmode);
>  	if (ret)
>  		return ret;
>  
> @@ -778,7 +789,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 +1185,18 @@ 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 &
> +			~AN877_ADC_OUTPUT_MODE_MASK) |
> +			FIELD_PREP(AN877_ADC_OUTPUT_MODE_MASK,
> +				   AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);
Might be cleaner as
		unsigned int cmode = st->info->default_output_mode;

		FIELD_MODIFY(AN877_ADC_OUTPUT_MODE_MASK, &cmode, 
			     AN877_ADC_OUTPUT_MODE_OFFSET_BINARY);

I don't mind that much though if you prefer the original.

> +		ret = ad9467_outputmode_set(st, cmode);
>  		if (ret)
>  			return ret;
>  
> 

[PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

Not all users can or want to use the device with an iio-backend.
For these users, let the driver work in standalone mode, not coupled
to the backend or the services it provides.

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

diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 60fc3361b2689a4c38287c613ef93fe00338e5fa..37b8f88da6681d44f3fbbb6c8c171ae7117b9090 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -1000,6 +1000,9 @@ static int ad9467_update_scan_mode(struct iio_dev *indio_dev,
 	unsigned int c;
 	int ret;
 
+	if (!st->back)
+		return -EOPNOTSUPP;
+
 	for (c = 0; c < st->info->num_channels; c++) {
 		if (test_bit(c, scan_mask))
 			ret = iio_backend_chan_enable(st->back, c);
@@ -1066,6 +1069,7 @@ static int ad9467_iio_backend_get(struct ad9467_state *st)
 {
 	struct device *dev = &st->spi->dev;
 	struct device_node *__back;
+	unsigned int nr_nodes = 0;
 
 	st->back = devm_iio_backend_get(dev, NULL);
 	if (!IS_ERR(st->back))
@@ -1084,6 +1088,7 @@ static int ad9467_iio_backend_get(struct ad9467_state *st)
 	for_each_node_with_property(__back, "adi,adc-dev") {
 		struct device_node *__me;
 
+		nr_nodes++;
 		__me = of_parse_phandle(__back, "adi,adc-dev", 0);
 		if (!__me)
 			continue;
@@ -1100,6 +1105,10 @@ static int ad9467_iio_backend_get(struct ad9467_state *st)
 		return PTR_ERR_OR_ZERO(st->back);
 	}
 
+	st->back = NULL;
+	if (!nr_nodes)
+		return -ENOENT;
+
 	return -ENODEV;
 }
 
@@ -1294,8 +1303,8 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
 
 	debugfs_create_file("in_voltage_test_mode_available", 0400, d, st,
 			    &ad9467_test_mode_available_fops);
-
-	iio_backend_debugfs_add(st->back, indio_dev);
+	if (st->back)
+		iio_backend_debugfs_add(st->back, indio_dev);
 }
 
 static int ad9467_probe(struct spi_device *spi)
@@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
 	indio_dev->channels = st->info->channels;
 	indio_dev->num_channels = st->info->num_channels;
 
+	/* Using a backend is optional */
 	ret = ad9467_iio_backend_get(st);
-	if (ret)
+	if (ret && ret != -ENOENT)
 		return ret;
 
-	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
-	if (ret)
-		return ret;
+	if (!ret) {
+		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
+						      indio_dev);
+		if (ret)
+			return ret;
 
-	ret = devm_iio_backend_enable(&spi->dev, st->back);
-	if (ret)
-		return ret;
+		ret = devm_iio_backend_enable(&spi->dev, st->back);
+		if (ret)
+			return ret;
 
-	ret = ad9467_calibrate(st);
-	if (ret)
-		return ret;
+		ret = ad9467_calibrate(st);
+		if (ret)
+			return ret;
+	}
 
 	ret = devm_iio_device_register(&spi->dev, indio_dev);
 	if (ret)

-- 
2.47.3

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
> Not all users can or want to use the device with an iio-backend.
> For these users, let the driver work in standalone mode, not coupled
> to the backend or the services it provides.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---

Which users? The only usecases (for all the supported devices) we have require
the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
prefer an explicit boolean in the chip_info struture for the device(s) we know this
can happen (unless you have a usecase for all :)).

- Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

Hi,

On 16/12/2025 14:56, Nuno Sá wrote:
> On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
>> Not all users can or want to use the device with an iio-backend.
>> For these users, let the driver work in standalone mode, not coupled
>> to the backend or the services it provides.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>
> Which users? The only usecases (for all the supported devices) we have require
> the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
> prefer an explicit boolean in the chip_info struture for the device(s) we know this
> can happen (unless you have a usecase for all :)).

This is generically for all the devices supported by the ad9467, not
only a specific device. So it's about how this is used as part of the
design.

This is aimed at users that do not use the ADI HDL reference backend
with these devices, but instead have custom backends suited for their
own needs.
In that case, we need to be able to skip the backend registration and
register device as a standalone iio device.

Hopefully this made the use case clearer?

Thanks,
Tomas


>
> - Nuno Sá
>

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[David Lechner]

On 12/16/25 9:39 AM, Tomas Melin wrote:
> Hi,
> 
> On 16/12/2025 14:56, Nuno Sá wrote:
>> On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
>>> Not all users can or want to use the device with an iio-backend.
>>> For these users, let the driver work in standalone mode, not coupled
>>> to the backend or the services it provides.
>>>
>>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>>> ---
>>
>> Which users? The only usecases (for all the supported devices) we have require
>> the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
>> prefer an explicit boolean in the chip_info struture for the device(s) we know this
>> can happen (unless you have a usecase for all :)).
> 
> This is generically for all the devices supported by the ad9467, not
> only a specific device. So it's about how this is used as part of the
> design.
> 
> This is aimed at users that do not use the ADI HDL reference backend
> with these devices, but instead have custom backends suited for their
> own needs.

If you have your own backend, why would it not use the IIO backend
framework?

I can understand if this custom backend sends the data somewhere else
besides an IIO buffer and we don't want to create the buffer for the IIO
device. But I would still think that there needs to be some sort of
communication between the IIO device and the backend.

Maybe you could explain more how this custom backend is intended to work?

> In that case, we need to be able to skip the backend registration and
> register device as a standalone iio device.
> 
> Hopefully this made the use case clearer?
> 
> Thanks,
> Tomas
> 
> 
>>
>> - Nuno Sá
>>
> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

Hi,

On 16/12/2025 23:27, David Lechner wrote:
> On 12/16/25 9:39 AM, Tomas Melin wrote:
>> Hi,
>>
>> On 16/12/2025 14:56, Nuno Sá wrote:
>>> On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
>>>> Not all users can or want to use the device with an iio-backend.
>>>> For these users, let the driver work in standalone mode, not coupled
>>>> to the backend or the services it provides.
>>>>
>>>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>>>> ---
>>>
>>> Which users? The only usecases (for all the supported devices) we have require
>>> the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
>>> prefer an explicit boolean in the chip_info struture for the device(s) we know this
>>> can happen (unless you have a usecase for all :)).
>>
>> This is generically for all the devices supported by the ad9467, not
>> only a specific device. So it's about how this is used as part of the
>> design.
>>
>> This is aimed at users that do not use the ADI HDL reference backend
>> with these devices, but instead have custom backends suited for their
>> own needs.
> 
> If you have your own backend, why would it not use the IIO backend
> framework?
> 
> I can understand if this custom backend sends the data somewhere else
> besides an IIO buffer and we don't want to create the buffer for the IIO
> device. But I would still think that there needs to be some sort of
> communication between the IIO device and the backend.

True, there needs to some kind of backend, but they don't all have iio
backends or other kernel drivers. Data will flow when the device starts
sending without much further need to configure. Adding a backend driver
in these cases could have some benefits, but often it would just be an
unneeded complication.

And even if there were a custom iio-backend available, it would not be
compatible with the current assumptions about ADI backend wrt
calibration, test mode enabling and iio buffering. So having a strict
dependency on an iio-backend does not really work in a generic use case.

> 
> Maybe you could explain more how this custom backend is intended to work?

I hope the explanation above helps. There is real use case behind, this
is not some imaginary nice to have feature. Before the introduction of
the iio backend, the driver was even more dependent on the backend. At
that point, needed to carry some out of tree patches to remove the
dependency and make it a standalone iio driver. Thankfully with the
introduction of the iio-backend, this is now more loosely coupled and I
see opportunity for making this standalone mode possible also in mainline.

Thanks,
Tomas

> 
>> In that case, we need to be able to skip the backend registration and
>> register device as a standalone iio device.
>>
>> Hopefully this made the use case clearer?
>>
>> Thanks,
>> Tomas
>>
>>
>>>
>>> - Nuno Sá
>>>
>>
> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Tue, 2025-12-16 at 15:39 +0000, Tomas Melin wrote:
> Hi,
> 
> On 16/12/2025 14:56, Nuno Sá wrote:
> > On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
> > > Not all users can or want to use the device with an iio-backend.
> > > For these users, let the driver work in standalone mode, not coupled
> > > to the backend or the services it provides.
> > > 
> > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> > > ---
> > 
> > Which users? The only usecases (for all the supported devices) we have require
> > the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
> > prefer an explicit boolean in the chip_info struture for the device(s) we know this
> > can happen (unless you have a usecase for all :)).
> 
> This is generically for all the devices supported by the ad9467, not
> only a specific device. So it's about how this is used as part of the
> design.
> 
> This is aimed at users that do not use the ADI HDL reference backend
> with these devices, but instead have custom backends suited for their
> own needs.

Hmm, ideally I would then like to see the backend driver upstreamed...

> In that case, we need to be able to skip the backend registration and
> register device as a standalone iio device.
> 
> Hopefully this made the use case clearer?
> 

I mean, I don't love this and I'm not really sure I'm ok with it. These are fairly
high speed devices which often do require an FPGA IP to handle the data flow. Now
we can ignore the backend device (which is an essential piece) being it
expected or not.

Or maybe we can just do something like regulators and get a dummy backend or just add
some fixed kind of backend. Bottom line is, it still seems the backend device is a core
piece in your design and we're just hacking around the driver in way that conceptually
doesn't make sense to me.

Other question that comes to mind (I guess I was not that clear)... Do you have a real
usecase with your own custom backend IP or is this just theoretical?

- Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

Hi,

On 17/12/2025 11:26, Nuno Sá wrote:
> On Tue, 2025-12-16 at 15:39 +0000, Tomas Melin wrote:
>> Hi,
>>
>> On 16/12/2025 14:56, Nuno Sá wrote:
>>> On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
>>>> Not all users can or want to use the device with an iio-backend.
>>>> For these users, let the driver work in standalone mode, not coupled
>>>> to the backend or the services it provides.
>>>>
>>>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>>>> ---
>>>
>>> Which users? The only usecases (for all the supported devices) we have require
>>> the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
>>> prefer an explicit boolean in the chip_info struture for the device(s) we know this
>>> can happen (unless you have a usecase for all :)).
>>
>> This is generically for all the devices supported by the ad9467, not
>> only a specific device. So it's about how this is used as part of the
>> design.
>>
>> This is aimed at users that do not use the ADI HDL reference backend
>> with these devices, but instead have custom backends suited for their
>> own needs.
> 
> Hmm, ideally I would then like to see the backend driver upstreamed...

First of all, as I responded in another thread, there is certainly real
use case behind this, I would not be suggesting it otherwise.

Driver for custom backend would not be of any interest for mainline
kernel as the IP would not be publicly available. So nobody could really
use such a driver, nor would it be accepted. The default ADI backend is
 a different story, as it is available and documented.


> 
>> In that case, we need to be able to skip the backend registration and
>> register device as a standalone iio device.
>>
>> Hopefully this made the use case clearer?
>>
> 
> I mean, I don't love this and I'm not really sure I'm ok with it. These are fairly
> high speed devices which often do require an FPGA IP to handle the data flow. Now
> we can ignore the backend device (which is an essential piece) being it
> expected or not.
> 
> Or maybe we can just do something like regulators and get a dummy backend or just add
> some fixed kind of backend. Bottom line is, it still seems the backend device is a core
> piece in your design and we're just hacking around the driver in way that conceptually
> doesn't make sense to me.

I considered the idea of dummy backend, but in the end it doesn't make much sense to me.
These ADCs can work perfectly fine with a minimalistic custom backend that does exactly
what the design needs, without the need for basically any configuration.
So the ADCs rely on some sort of backend, ofcourse, but they are in the end standalone
devices that can be integrated in many ways, the adi backend being only one such option.

Another problem with a dummy backend is that for example calibration cannot really
work. It expects certain features from the backend to be available, etc. Similarly would
a custom backend connected need to implemented exactly same test features as the
backend now assumes.

> Other question that comes to mind (I guess I was not that clear)... Do you have a real
> usecase with your own custom backend IP or is this just theoretical?

This dependency on the adi hdl has been causing me problems over the years for a
number of adi devices, and the iio-backend has been a step in the right direction.
I hope we can take this further in direction that allows use cases that
were not expected from the beginning but are still valid.

Thanks,
Tomas

> 
> - Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

[resend, I think there was some problem with my first reply]

Hi,

On 17/12/2025 11:26, Nuno Sá wrote:
> On Tue, 2025-12-16 at 15:39 +0000, Tomas Melin wrote:
>> Hi,
>>
>> On 16/12/2025 14:56, Nuno Sá wrote:
>>> On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
>>>> Not all users can or want to use the device with an iio-backend.
>>>> For these users, let the driver work in standalone mode, not coupled
>>>> to the backend or the services it provides.
>>>>
>>>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>>>> ---
>>>
>>> Which users? The only usecases (for all the supported devices) we have require
>>> the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
>>> prefer an explicit boolean in the chip_info struture for the device(s) we know this
>>> can happen (unless you have a usecase for all :)).
>>
>> This is generically for all the devices supported by the ad9467, not
>> only a specific device. So it's about how this is used as part of the
>> design.
>>
>> This is aimed at users that do not use the ADI HDL reference backend
>> with these devices, but instead have custom backends suited for their
>> own needs.
> 
> Hmm, ideally I would then like to see the backend driver upstreamed...

First of all, as I responded in another thread, there is certainly real
use case behind this, I would not be suggesting it otherwise.

Driver for custom backend would not be of any interest for mainline
kernel as the IP would not be publicly available. So nobody could really
use such a driver, nor would it be accepted. The default ADI backend is
 a different story, as it is available and documented.

> 
>> In that case, we need to be able to skip the backend registration and
>> register device as a standalone iio device.
>>
>> Hopefully this made the use case clearer?
>>
> 
> I mean, I don't love this and I'm not really sure I'm ok with it. These are fairly
> high speed devices which often do require an FPGA IP to handle the data flow. Now
> we can ignore the backend device (which is an essential piece) being it
> expected or not.
> 
> Or maybe we can just do something like regulators and get a dummy backend or just add
> some fixed kind of backend. Bottom line is, it still seems the backend device is a core
> piece in your design and we're just hacking around the driver in way that conceptually
> doesn't make sense to me.

I considered the idea of dummy backend, but in the end it doesn't make
much sense to me.
These ADCs can work perfectly fine with a minimalistic custom backend
that does exactly what the design needs, without the need for basically
any configuration. So the ADCs rely on some sort of backend, ofcourse,
but they are in the end standalone devices that can be integrated in
many ways, the adi backend being only one such option.

Another problem with a dummy backend is that for example calibration
cannot really work. It expects certain features from the backend to be
available, etc. Similarly would a custom backend connected need to
implemented exactly same test features as the backend now assumes.

> 
> Other question that comes to mind (I guess I was not that clear)... Do you have a real
> usecase with your own custom backend IP or is this just theoretical?

This dependency on the adi hdl has been causing me problems over the
years for a number of adi devices, and the iio-backend has been a step
in the right direction.
I hope we can take this further in direction that allows use cases that
were not expected from the beginning but are still valid.

Thanks,
Tomas

> 
> - Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Wed, 2025-12-17 at 13:44 +0200, Tomas Melin wrote:
> [resend, I think there was some problem with my first reply]
> 
> Hi,
> 
> On 17/12/2025 11:26, Nuno Sá wrote:
> > On Tue, 2025-12-16 at 15:39 +0000, Tomas Melin wrote:
> > > Hi,
> > > 
> > > On 16/12/2025 14:56, Nuno Sá wrote:
> > > > On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
> > > > > Not all users can or want to use the device with an iio-backend.
> > > > > For these users, let the driver work in standalone mode, not coupled
> > > > > to the backend or the services it provides.
> > > > > 
> > > > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> > > > > ---
> > > > 
> > > > Which users? The only usecases (for all the supported devices) we have require
> > > > the FPGA backend. So do you have a specific usecase for a specific device? If so, I would
> > > > prefer an explicit boolean in the chip_info struture for the device(s) we know this
> > > > can happen (unless you have a usecase for all :)).
> > > 
> > > This is generically for all the devices supported by the ad9467, not
> > > only a specific device. So it's about how this is used as part of the
> > > design.
> > > 
> > > This is aimed at users that do not use the ADI HDL reference backend
> > > with these devices, but instead have custom backends suited for their
> > > own needs.
> > 
> > Hmm, ideally I would then like to see the backend driver upstreamed...
> 
> First of all, as I responded in another thread, there is certainly real
> use case behind this, I would not be suggesting it otherwise.
> 
> Driver for custom backend would not be of any interest for mainline
> kernel as the IP would not be publicly available. So nobody could really
> use such a driver, nor would it be accepted. The default ADI backend is
>  a different story, as it is available and documented.

I see.

> 
> > 
> > > In that case, we need to be able to skip the backend registration and
> > > register device as a standalone iio device.
> > > 
> > > Hopefully this made the use case clearer?
> > > 
> > 
> > I mean, I don't love this and I'm not really sure I'm ok with it. These are fairly
> > high speed devices which often do require an FPGA IP to handle the data flow. Now
> > we can ignore the backend device (which is an essential piece) being it
> > expected or not.
> > 
> > Or maybe we can just do something like regulators and get a dummy backend or just add
> > some fixed kind of backend. Bottom line is, it still seems the backend device is a core
> > piece in your design and we're just hacking around the driver in way that conceptually
> > doesn't make sense to me.
> 
> I considered the idea of dummy backend, but in the end it doesn't make
> much sense to me.
> These ADCs can work perfectly fine with a minimalistic custom backend
> that does exactly what the design needs, without the need for basically
> any configuration. So the ADCs rely on some sort of backend, ofcourse,
> but they are in the end standalone devices that can be integrated in
> many ways, the adi backend being only one such option.

There we have it. It relies on some external HW so conceptually the dummy would
make sense me. In the same way a device cannot work without power supply and hence
we get the dummy regulator. But...

> 
> Another problem with a dummy backend is that for example calibration
> cannot really work. It expects certain features from the backend to be
> available, etc. Similarly would a custom backend connected need to
> implemented exactly same test features as the backend now assumes.
> 

The above is indeed cumbersome. I guess dummy is not what we would need but something
like a fixed-backend that would implement all the ops in a dummy way. But that does not
make much sense and doesn't really scale.

I think my main complain is also that then we should add a devm_backend_get_optional() to make
the intent clear but unfortunately this driver is not the best candidate for that.

Anyways, I still don't love the idea of just ignoring it (given that some HW is indeed present)
but yeah. Not going to nack it either.

- Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

Hi,

On 18/12/2025 15:41, Nuno Sá wrote:
> On Wed, 2025-12-17 at 13:44 +0200, Tomas Melin wrote:
>> [resend, I think there was some problem with my first reply]
>>
>> Hi,
>>
>> On 17/12/2025 11:26, Nuno Sá wrote:
>>> On Tue, 2025-12-16 at 15:39 +0000, Tomas Melin wrote:
> 
> The above is indeed cumbersome. I guess dummy is not what we would need but something
> like a fixed-backend that would implement all the ops in a dummy way. But that does not
> make much sense and doesn't really scale.
> 
> I think my main complain is also that then we should add a devm_backend_get_optional() to make
> the intent clear but unfortunately this driver is not the best candidate for that.
> 
> Anyways, I still don't love the idea of just ignoring it (given that some HW is indeed present)
> but yeah. Not going to nack it either.

Good that you still see the optional backend as feasible. I will tune
the implementation in next version according to discussion in our other
thread and other possible feeback that comes up. I'm confident we can
find a solution that will work out nicely.

Thanks,
Tomas


> 
> - Nuno Sá
> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
> Not all users can or want to use the device with an iio-backend.
> For these users, let the driver work in standalone mode, not coupled
> to the backend or the services it provides.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/adc/ad9467.c | 37 +++++++++++++++++++++++++------------
>  1 file changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 60fc3361b2689a4c38287c613ef93fe00338e5fa..37b8f88da6681d44f3fbbb6c8c171ae7117b9090 100644
> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c
> @@ -1000,6 +1000,9 @@ static int ad9467_update_scan_mode(struct iio_dev *indio_dev,
>  	unsigned int c;
>  	int ret;
>  
> +	if (!st->back)
> +		return -EOPNOTSUPP;
> +

Let's not add the buffering interface if we can't control it.
Having it just to return error does not make sense to me. This means yet another info:

https://elixir.bootlin.com/linux/v6.18.1/source/drivers/iio/adc/ad9467.c#L916

Also the channel definition should not have the scan index. But, given that the IIO device
won't have any buffer I think there's no way to reach ad9467_update_scan_mode() (unless I'm
missing something).

Still, while I understand that updating the channels to not include the scan_index is very
cumbersome, having a new iio_info with no .update_scan_mode() is trivial and make things
more clear and explicit.

- Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

On 18/12/2025 15:49, Nuno Sá wrote:
> On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
>> Not all users can or want to use the device with an iio-backend.
>> For these users, let the driver work in standalone mode, not coupled
>> to the backend or the services it provides.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>>  drivers/iio/adc/ad9467.c | 37 +++++++++++++++++++++++++------------
>>  1 file changed, 25 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
>> index 60fc3361b2689a4c38287c613ef93fe00338e5fa..37b8f88da6681d44f3fbbb6c8c171ae7117b9090 100644
>> --- a/drivers/iio/adc/ad9467.c
>> +++ b/drivers/iio/adc/ad9467.c
>> @@ -1000,6 +1000,9 @@ static int ad9467_update_scan_mode(struct iio_dev *indio_dev,
>>  	unsigned int c;
>>  	int ret;
>>  
>> +	if (!st->back)
>> +		return -EOPNOTSUPP;
>> +
> 
> Let's not add the buffering interface if we can't control it.
> Having it just to return error does not make sense to me. This means yet another info:
> 
> https://elixir.bootlin.com/linux/v6.18.1/source/drivers/iio/adc/ad9467.c#L916
> 

I agree, not having the scan_mode at all would be more clean.
But adding those different iio_info structs comes across as a bit messy.
Would it make sense to create that iio_info dynamically in the probe and
fill out the callbacks that are supported for the configuration we
encounter? I could try out something like that and see how it would look
like in practice.

Thanks,
Tomas

> Also the channel definition should not have the scan index. But, given that the IIO device
> won't have any buffer I think there's no way to reach ad9467_update_scan_mode() (unless I'm
> missing something).
> 
> Still, while I understand that updating the channels to not include the scan_index is very
> cumbersome, having a new iio_info with no .update_scan_mode() is trivial and make things
> more clear and explicit.
> 
> - Nuno Sá
> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Fri, 2025-12-19 at 13:16 +0200, Tomas Melin wrote:
> 
> On 18/12/2025 15:49, Nuno Sá wrote:
> > On Tue, 2025-12-16 at 11:40 +0000, Tomas Melin wrote:
> > > Not all users can or want to use the device with an iio-backend.
> > > For these users, let the driver work in standalone mode, not coupled
> > > to the backend or the services it provides.
> > > 
> > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> > > ---
> > >  drivers/iio/adc/ad9467.c | 37 +++++++++++++++++++++++++------------
> > >  1 file changed, 25 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> > > index 60fc3361b2689a4c38287c613ef93fe00338e5fa..37b8f88da6681d44f3fbbb6c8c171ae7117b9090
> > > 100644
> > > --- a/drivers/iio/adc/ad9467.c
> > > +++ b/drivers/iio/adc/ad9467.c
> > > @@ -1000,6 +1000,9 @@ static int ad9467_update_scan_mode(struct iio_dev *indio_dev,
> > >  	unsigned int c;
> > >  	int ret;
> > >  
> > > +	if (!st->back)
> > > +		return -EOPNOTSUPP;
> > > +
> > 
> > Let's not add the buffering interface if we can't control it.
> > Having it just to return error does not make sense to me. This means yet another info:
> > 
> > https://elixir.bootlin.com/linux/v6.18.1/source/drivers/iio/adc/ad9467.c#L916
> > 
> 
> I agree, not having the scan_mode at all would be more clean.
> But adding those different iio_info structs comes across as a bit messy.
> Would it make sense to create that iio_info dynamically in the probe and
> fill out the callbacks that are supported for the configuration we
> encounter? I could try out something like that and see how it would look
> like in practice.
> 

Hmm yeah, it's not just one more iio_info we need but 2. But maybe let's keep it simple
and remove the check in ad9467_update_scan_mode(). I mean, if I'm not missing nothing, 
if there's no buffer, there's no real way for userspace to reach that code path.

- Nuno Sá

> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Jonathan Cameron]

On Tue, 16 Dec 2025 11:40:06 +0000
Tomas Melin <tomas.melin@vaisala.com> wrote:

> Not all users can or want to use the device with an iio-backend.
> For these users, let the driver work in standalone mode, not coupled
> to the backend or the services it provides.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Hi Tomas,

>  static int ad9467_probe(struct spi_device *spi)
> @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
>  	indio_dev->channels = st->info->channels;
>  	indio_dev->num_channels = st->info->num_channels;
>  
> +	/* Using a backend is optional */

I'll largely defer to Nuno on the backend aspects but I would like a
lot more than a statement that it is optional in this comment.
At least something about where the data goes and what a real system
that didn't provide a backend would look like etc.

I can think of some setups where I'd be fine with this change and others
where I'd push back harder.

Jonathan

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

Hi,

On 21/12/2025 22:00, Jonathan Cameron wrote:
> On Tue, 16 Dec 2025 11:40:06 +0000
> Tomas Melin <tomas.melin@vaisala.com> wrote:
> 
>> Not all users can or want to use the device with an iio-backend.
>> For these users, let the driver work in standalone mode, not coupled
>> to the backend or the services it provides.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> Hi Tomas,
> 
>>  static int ad9467_probe(struct spi_device *spi)
>> @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
>>  	indio_dev->channels = st->info->channels;
>>  	indio_dev->num_channels = st->info->num_channels;
>>  
>> +	/* Using a backend is optional */
> 
> I'll largely defer to Nuno on the backend aspects but I would like a
> lot more than a statement that it is optional in this comment.
> At least something about where the data goes and what a real system
> that didn't provide a backend would look like etc.

Having the backend as optional is about flexibility to incorporate these
devices as fits best with the system. The current backend approach is
pretty much dictated with how the ADI default backend is implemented.
These devices are fully configurable via SPI interface so the backend
doesn't necessarily need to be anything fancy or even configurable.

So there is atleast two use cases that promote the optional iio-backend
approach
 - simple backend that is not configurable, no need for a dedicated
driver. The backend (FPGA) sits and waits for data and handles it when
it arrives
-  custom backend not compatible with the adi backend features. For
example different approach to calibration, or other model for data
channels etc.

Not having it optional would mean more or less vendor lock with analog
devices backend which probably was not the idea when adding the
iio-backend feature in the first place.

Regarding the comment, perhaps something like

/**
 * Backend provided features are optional. If a compatible backend is
 * not present all features might not be available. If the system
 * otherwise provides a path for the data, the device will still be
 * fully functional.
 **/

> 
> I can think of some setups where I'd be fine with this change and others
> where I'd push back harder.

Given the explanations above, I'd be happy to have some more feedback on
this.

Thanks,
Tomas


> 
> Jonathan
> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:
> Hi,
> 
> On 21/12/2025 22:00, Jonathan Cameron wrote:
> > On Tue, 16 Dec 2025 11:40:06 +0000
> > Tomas Melin <tomas.melin@vaisala.com> wrote:
> > 
> > > Not all users can or want to use the device with an iio-backend.
> > > For these users, let the driver work in standalone mode, not coupled
> > > to the backend or the services it provides.
> > > 
> > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> > Hi Tomas,
> > 
> > >  static int ad9467_probe(struct spi_device *spi)
> > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
> > >  	indio_dev->channels = st->info->channels;
> > >  	indio_dev->num_channels = st->info->num_channels;
> > >  
> > > +	/* Using a backend is optional */
> > 
> > I'll largely defer to Nuno on the backend aspects but I would like a
> > lot more than a statement that it is optional in this comment.
> > At least something about where the data goes and what a real system
> > that didn't provide a backend would look like etc.
> 
> Having the backend as optional is about flexibility to incorporate these
> devices as fits best with the system. The current backend approach is
> pretty much dictated with how the ADI default backend is implemented.
> These devices are fully configurable via SPI interface so the backend
> doesn't necessarily need to be anything fancy or even configurable.
> 
> So there is atleast two use cases that promote the optional iio-backend
> approach
>  - simple backend that is not configurable, no need for a dedicated
> driver. The backend (FPGA) sits and waits for data and handles it when
> it arrives

Agree on the above. Ideally we could have some dummy backend for the above but
it is not really easy/maintainable to have it.

> -  custom backend not compatible with the adi backend features. For
> example different approach to calibration, or other model for data
> channels etc.

I would argue the above would require a new driver with, perhaps, a new compatible
on the frontend side for the needed modifications. Or we could introduce some kind
of "detect backend vendor thing" so that the frontend driver can adapt at runtime
(though this looks like a "fancier" way of having a new compatible).

Ideally we could somehow "detect" backend capabilities but these kind of systems are
so different and usecase specific that, at least for now, I don't see how that could be
sanely done.

- Nuno Sá

> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Jonathan Cameron]

On Mon, 05 Jan 2026 14:57:02 +0000
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:
> > Hi,
> > 
> > On 21/12/2025 22:00, Jonathan Cameron wrote:  
> > > On Tue, 16 Dec 2025 11:40:06 +0000
> > > Tomas Melin <tomas.melin@vaisala.com> wrote:
> > >   
> > > > Not all users can or want to use the device with an iio-backend.
> > > > For these users, let the driver work in standalone mode, not coupled
> > > > to the backend or the services it provides.
> > > > 
> > > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>  
> > > Hi Tomas,
> > >   
> > > >  static int ad9467_probe(struct spi_device *spi)
> > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
> > > >  	indio_dev->channels = st->info->channels;
> > > >  	indio_dev->num_channels = st->info->num_channels;
> > > >  
> > > > +	/* Using a backend is optional */  
> > > 
> > > I'll largely defer to Nuno on the backend aspects but I would like a
> > > lot more than a statement that it is optional in this comment.
> > > At least something about where the data goes and what a real system
> > > that didn't provide a backend would look like etc.  
> > 
> > Having the backend as optional is about flexibility to incorporate these
> > devices as fits best with the system. The current backend approach is
> > pretty much dictated with how the ADI default backend is implemented.
> > These devices are fully configurable via SPI interface so the backend
> > doesn't necessarily need to be anything fancy or even configurable.
> > 
> > So there is atleast two use cases that promote the optional iio-backend
> > approach
> >  - simple backend that is not configurable, no need for a dedicated
> > driver. The backend (FPGA) sits and waits for data and handles it when
> > it arrives  
> 
> Agree on the above. Ideally we could have some dummy backend for the above but
> it is not really easy/maintainable to have it.

When we say the backend needs no driver, where does the data end up?
Is the idea that it goes into some processing pipeline and sent to
some external path that we have no visibility of? i.e. We configure the
data capture in Linux but never see the data?


> 
> > -  custom backend not compatible with the adi backend features. For
> > example different approach to calibration, or other model for data
> > channels etc.  
> 
> I would argue the above would require a new driver with, perhaps, a new compatible
> on the frontend side for the needed modifications. Or we could introduce some kind
> of "detect backend vendor thing" so that the frontend driver can adapt at runtime
> (though this looks like a "fancier" way of having a new compatible).
> 
> Ideally we could somehow "detect" backend capabilities but these kind of systems are
> so different and usecase specific that, at least for now, I don't see how that could be
> sanely done.

Agreed. If we need to extend things to deal with other styles of FPGA IP or different
feature sets, that is the way to go.  That would require some public implementation
that uses the interface

Jonathan

> 
> - Nuno Sá
> 
> >   

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote:
> On Mon, 05 Jan 2026 14:57:02 +0000
> Nuno Sá <noname.nuno@gmail.com> wrote:
> 
> > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:
> > > Hi,
> > > 
> > > On 21/12/2025 22:00, Jonathan Cameron wrote:  
> > > > On Tue, 16 Dec 2025 11:40:06 +0000
> > > > Tomas Melin <tomas.melin@vaisala.com> wrote:
> > > >   
> > > > > Not all users can or want to use the device with an iio-backend.
> > > > > For these users, let the driver work in standalone mode, not coupled
> > > > > to the backend or the services it provides.
> > > > > 
> > > > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>  
> > > > Hi Tomas,
> > > >   
> > > > >  static int ad9467_probe(struct spi_device *spi)
> > > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
> > > > >  	indio_dev->channels = st->info->channels;
> > > > >  	indio_dev->num_channels = st->info->num_channels;
> > > > >  
> > > > > +	/* Using a backend is optional */  
> > > > 
> > > > I'll largely defer to Nuno on the backend aspects but I would like a
> > > > lot more than a statement that it is optional in this comment.
> > > > At least something about where the data goes and what a real system
> > > > that didn't provide a backend would look like etc.  
> > > 
> > > Having the backend as optional is about flexibility to incorporate these
> > > devices as fits best with the system. The current backend approach is
> > > pretty much dictated with how the ADI default backend is implemented.
> > > These devices are fully configurable via SPI interface so the backend
> > > doesn't necessarily need to be anything fancy or even configurable.
> > > 
> > > So there is atleast two use cases that promote the optional iio-backend
> > > approach
> > >  - simple backend that is not configurable, no need for a dedicated
> > > driver. The backend (FPGA) sits and waits for data and handles it when
> > > it arrives  
> > 
> > Agree on the above. Ideally we could have some dummy backend for the above but
> > it is not really easy/maintainable to have it.
> 
> When we say the backend needs no driver, where does the data end up?
> Is the idea that it goes into some processing pipeline and sent to
> some external path that we have no visibility of? i.e. We configure the
> data capture in Linux but never see the data?

Yes, that's also my assumption about Tomas's usecase.

- Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

Hi,

On 12/01/2026 15:21, Nuno Sá wrote:
> On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote:
>> On Mon, 05 Jan 2026 14:57:02 +0000
>> Nuno Sá <noname.nuno@gmail.com> wrote:
>>
>>> On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:
>>>> Hi,
>>>>
>>>> On 21/12/2025 22:00, Jonathan Cameron wrote:  
>>>>> On Tue, 16 Dec 2025 11:40:06 +0000
>>>>> Tomas Melin <tomas.melin@vaisala.com> wrote:
>>>>>   
>>>>>> Not all users can or want to use the device with an iio-backend.
>>>>>> For these users, let the driver work in standalone mode, not coupled
>>>>>> to the backend or the services it provides.
>>>>>>
>>>>>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>  
>>>>> Hi Tomas,
>>>>>   
>>>>>>  static int ad9467_probe(struct spi_device *spi)
>>>>>> @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
>>>>>>  	indio_dev->channels = st->info->channels;
>>>>>>  	indio_dev->num_channels = st->info->num_channels;
>>>>>>  
>>>>>> +	/* Using a backend is optional */  
>>>>>
>>>>> I'll largely defer to Nuno on the backend aspects but I would like a
>>>>> lot more than a statement that it is optional in this comment.
>>>>> At least something about where the data goes and what a real system
>>>>> that didn't provide a backend would look like etc.  
>>>>
>>>> Having the backend as optional is about flexibility to incorporate these
>>>> devices as fits best with the system. The current backend approach is
>>>> pretty much dictated with how the ADI default backend is implemented.
>>>> These devices are fully configurable via SPI interface so the backend
>>>> doesn't necessarily need to be anything fancy or even configurable.
>>>>
>>>> So there is atleast two use cases that promote the optional iio-backend
>>>> approach
>>>>  - simple backend that is not configurable, no need for a dedicated
>>>> driver. The backend (FPGA) sits and waits for data and handles it when
>>>> it arrives  
>>>
>>> Agree on the above. Ideally we could have some dummy backend for the above but
>>> it is not really easy/maintainable to have it.
>>
>> When we say the backend needs no driver, where does the data end up?
>> Is the idea that it goes into some processing pipeline and sent to
>> some external path that we have no visibility of? i.e. We configure the
>> data capture in Linux but never see the data?
> 
> Yes, that's also my assumption about Tomas's usecase.

The data becomes available to user space but there is currently no
immediate need or natural place to create a separate instance to
function as a backend device.

But that being said, I'm leaning towards thinking that perhaps a
minimalistic backend should always be registered after all. That would
keep the idea of the backend always existing intact.
But since the backend can be missing a lot of the features defined for
the current ADI backend, capability handling would need to be added to
the backend framework to make it functional.

Looking into how this could be achieved with reasonable impact, I have
tried to identify capabilities that we could add for starters, and then
have the frontend behave differently depending on what features are present.

Something like this (added to backend_info),
.caps = IIO_BACKEND_CAP_TEST_PATTERNS |  --> backend patterns are avail.
	IIO_BACKEND_CAP_BUFFERING |  --> backend has buffering cap.
	IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration

If you think this seems reasonable, I can implement something like this
and post a new version for comments.

Thanks,
Tomas



> 
> - Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Jonathan Cameron]

On Tue, 13 Jan 2026 09:47:46 +0200
Tomas Melin <tomas.melin@vaisala.com> wrote:

> Hi,
> 
> On 12/01/2026 15:21, Nuno Sá wrote:
> > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote:  
> >> On Mon, 05 Jan 2026 14:57:02 +0000
> >> Nuno Sá <noname.nuno@gmail.com> wrote:
> >>  
> >>> On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:  
> >>>> Hi,
> >>>>
> >>>> On 21/12/2025 22:00, Jonathan Cameron wrote:    
> >>>>> On Tue, 16 Dec 2025 11:40:06 +0000
> >>>>> Tomas Melin <tomas.melin@vaisala.com> wrote:
> >>>>>     
> >>>>>> Not all users can or want to use the device with an iio-backend.
> >>>>>> For these users, let the driver work in standalone mode, not coupled
> >>>>>> to the backend or the services it provides.
> >>>>>>
> >>>>>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>    
> >>>>> Hi Tomas,
> >>>>>     
> >>>>>>  static int ad9467_probe(struct spi_device *spi)
> >>>>>> @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
> >>>>>>  	indio_dev->channels = st->info->channels;
> >>>>>>  	indio_dev->num_channels = st->info->num_channels;
> >>>>>>  
> >>>>>> +	/* Using a backend is optional */    
> >>>>>
> >>>>> I'll largely defer to Nuno on the backend aspects but I would like a
> >>>>> lot more than a statement that it is optional in this comment.
> >>>>> At least something about where the data goes and what a real system
> >>>>> that didn't provide a backend would look like etc.    
> >>>>
> >>>> Having the backend as optional is about flexibility to incorporate these
> >>>> devices as fits best with the system. The current backend approach is
> >>>> pretty much dictated with how the ADI default backend is implemented.
> >>>> These devices are fully configurable via SPI interface so the backend
> >>>> doesn't necessarily need to be anything fancy or even configurable.
> >>>>
> >>>> So there is atleast two use cases that promote the optional iio-backend
> >>>> approach
> >>>>  - simple backend that is not configurable, no need for a dedicated
> >>>> driver. The backend (FPGA) sits and waits for data and handles it when
> >>>> it arrives    
> >>>
> >>> Agree on the above. Ideally we could have some dummy backend for the above but
> >>> it is not really easy/maintainable to have it.  
> >>
> >> When we say the backend needs no driver, where does the data end up?
> >> Is the idea that it goes into some processing pipeline and sent to
> >> some external path that we have no visibility of? i.e. We configure the
> >> data capture in Linux but never see the data?  
> > 
> > Yes, that's also my assumption about Tomas's usecase.  
> 
> The data becomes available to user space but there is currently no
> immediate need or natural place to create a separate instance to
> function as a backend device.
> 
> But that being said, I'm leaning towards thinking that perhaps a
> minimalistic backend should always be registered after all. That would
> keep the idea of the backend always existing intact.
> But since the backend can be missing a lot of the features defined for
> the current ADI backend, capability handling would need to be added to
> the backend framework to make it functional.
> 
> Looking into how this could be achieved with reasonable impact, I have
> tried to identify capabilities that we could add for starters, and then
> have the frontend behave differently depending on what features are present.
> 
> Something like this (added to backend_info),
> .caps = IIO_BACKEND_CAP_TEST_PATTERNS |  --> backend patterns are avail.
> 	IIO_BACKEND_CAP_BUFFERING |  --> backend has buffering cap.
> 	IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration
> 
> If you think this seems reasonable, I can implement something like this
> and post a new version for comments.
> 
Sounds good to me, but I defer to Nuno for backend stuff!

Thanks,

Jonathan

> Thanks,
> Tomas
> 
> 
> 
> > 
> > - Nuno Sá  
> 
> 
> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Tue, 2026-01-13 at 09:47 +0200, Tomas Melin wrote:
> Hi,
> 
> On 12/01/2026 15:21, Nuno Sá wrote:
> > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote:
> > > On Mon, 05 Jan 2026 14:57:02 +0000
> > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > 
> > > > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:
> > > > > Hi,
> > > > > 
> > > > > On 21/12/2025 22:00, Jonathan Cameron wrote:  
> > > > > > On Tue, 16 Dec 2025 11:40:06 +0000
> > > > > > Tomas Melin <tomas.melin@vaisala.com> wrote:
> > > > > >   
> > > > > > > Not all users can or want to use the device with an iio-backend.
> > > > > > > For these users, let the driver work in standalone mode, not coupled
> > > > > > > to the backend or the services it provides.
> > > > > > > 
> > > > > > > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>  
> > > > > > Hi Tomas,
> > > > > >   
> > > > > > >  static int ad9467_probe(struct spi_device *spi)
> > > > > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_device *spi)
> > > > > > >  	indio_dev->channels = st->info->channels;
> > > > > > >  	indio_dev->num_channels = st->info->num_channels;
> > > > > > >  
> > > > > > > +	/* Using a backend is optional */  
> > > > > > 
> > > > > > I'll largely defer to Nuno on the backend aspects but I would like a
> > > > > > lot more than a statement that it is optional in this comment.
> > > > > > At least something about where the data goes and what a real system
> > > > > > that didn't provide a backend would look like etc.  
> > > > > 
> > > > > Having the backend as optional is about flexibility to incorporate these
> > > > > devices as fits best with the system. The current backend approach is
> > > > > pretty much dictated with how the ADI default backend is implemented.
> > > > > These devices are fully configurable via SPI interface so the backend
> > > > > doesn't necessarily need to be anything fancy or even configurable.
> > > > > 
> > > > > So there is atleast two use cases that promote the optional iio-backend
> > > > > approach
> > > > >  - simple backend that is not configurable, no need for a dedicated
> > > > > driver. The backend (FPGA) sits and waits for data and handles it when
> > > > > it arrives  
> > > > 
> > > > Agree on the above. Ideally we could have some dummy backend for the above but
> > > > it is not really easy/maintainable to have it.
> > > 
> > > When we say the backend needs no driver, where does the data end up?
> > > Is the idea that it goes into some processing pipeline and sent to
> > > some external path that we have no visibility of? i.e. We configure the
> > > data capture in Linux but never see the data?
> > 
> > Yes, that's also my assumption about Tomas's usecase.
> 
> The data becomes available to user space but there is currently no
> immediate need or natural place to create a separate instance to
> function as a backend device.

So do you have some completely different data path bypassing IIO (just curious)?

> 
> But that being said, I'm leaning towards thinking that perhaps a
> minimalistic backend should always be registered after all. That would
> keep the idea of the backend always existing intact.
> But since the backend can be missing a lot of the features defined for
> the current ADI backend, capability handling would need to be added to
> the backend framework to make it functional.
> 
> Looking into how this could be achieved with reasonable impact, I have
> tried to identify capabilities that we could add for starters, and then
> have the frontend behave differently depending on what features are present.
> 
> Something like this (added to backend_info),
> .caps = IIO_BACKEND_CAP_TEST_PATTERNS |  --> backend patterns are avail.
> 	IIO_BACKEND_CAP_BUFFERING |  --> backend has buffering cap.
> 	IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration
> 

Looks reasonable but I'm still a bit afraid to open this can of worms. But as Jonathan
pointed out multiple times on the backend code, this is mostly inkernel interfaces so
it is easier to deal with bad choices :).
 

We would still need to "combine" these capabilities feature with a dummy backend that
would dummy implement the more common/expected like (chan)enable/disable and so on.

We can then decide on a usecase by usecase basis on what should be a capability or what
should be dummy implemented.

Bottom line, I'm leaning on "I'm ok with the above" since I expect usecases like this to
be fairly rare (famous last words :)). And It would be nice to have more feedback
on this one.

- Nuno Sá

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Tomas Melin]

Hi,

On 13/01/2026 12:52, Nuno Sá wrote:
> On Tue, 2026-01-13 at 09:47 +0200, Tomas Melin wrote:
>> Hi,
>>
>> On 12/01/2026 15:21, Nuno Sá wrote:
>>> On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote:
>>>> On Mon, 05 Jan 2026 14:57:02 +0000
>>>> Nuno Sá <noname.nuno@gmail.com> wrote:
>>>>
>>>>> On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:

>>>>
>>>> When we say the backend needs no driver, where does the data end up?
>>>> Is the idea that it goes into some processing pipeline and sent to
>>>> some external path that we have no visibility of? i.e. We configure the
>>>> data capture in Linux but never see the data?
>>>
>>> Yes, that's also my assumption about Tomas's usecase.
>>
>> The data becomes available to user space but there is currently no
>> immediate need or natural place to create a separate instance to
>> function as a backend device.
> 
> So do you have some completely different data path bypassing IIO (just curious)?

Yes, IP handles data reception and data transfer outside of iio context.

> 
>>
>> But that being said, I'm leaning towards thinking that perhaps a
>> minimalistic backend should always be registered after all. That would
>> keep the idea of the backend always existing intact.
>> But since the backend can be missing a lot of the features defined for
>> the current ADI backend, capability handling would need to be added to
>> the backend framework to make it functional.
>>
>> Looking into how this could be achieved with reasonable impact, I have
>> tried to identify capabilities that we could add for starters, and then
>> have the frontend behave differently depending on what features are present.
>>
>> Something like this (added to backend_info),
>> .caps = IIO_BACKEND_CAP_TEST_PATTERNS |  --> backend patterns are avail.
>> 	IIO_BACKEND_CAP_BUFFERING |  --> backend has buffering cap.
>> 	IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration
>>
> 
> Looks reasonable but I'm still a bit afraid to open this can of worms. But as Jonathan
> pointed out multiple times on the backend code, this is mostly inkernel interfaces so
> it is easier to deal with bad choices :).

I understand this concern, but would anticipate that there are only a
limited number of capabilties that need to be handled, so it should stay
fairly managable.

>  
> 
> We would still need to "combine" these capabilities feature with a dummy backend that
> would dummy implement the more common/expected like (chan)enable/disable and so on.

I think the dummy backend is probably not gonna be needed as the current
axi backend can advertise the available set of capabilities. The
frontends are then free to make use of the capability bits as needed.
In my use case, I need to implement a limited backend that does not
claim any capabilities but only provides a minimum set of functionality.

Thanks,
Tomas



> 
> We can then decide on a usecase by usecase basis on what should be a capability or what
> should be dummy implemented.
> 
> Bottom line, I'm leaning on "I'm ok with the above" since I expect usecases like this to
> be fairly rare (famous last words :)). And It would be nice to have more feedback
> on this one.
> 
> - Nuno Sá
> 

Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional

[Nuno Sá]

On Tue, 2026-01-13 at 13:49 +0200, Tomas Melin wrote:
> Hi,
> 
> On 13/01/2026 12:52, Nuno Sá wrote:
> > On Tue, 2026-01-13 at 09:47 +0200, Tomas Melin wrote:
> > > Hi,
> > > 
> > > On 12/01/2026 15:21, Nuno Sá wrote:
> > > > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote:
> > > > > On Mon, 05 Jan 2026 14:57:02 +0000
> > > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > > > 
> > > > > > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote:
> 
> > > > > 
> > > > > When we say the backend needs no driver, where does the data end up?
> > > > > Is the idea that it goes into some processing pipeline and sent to
> > > > > some external path that we have no visibility of? i.e. We configure the
> > > > > data capture in Linux but never see the data?
> > > > 
> > > > Yes, that's also my assumption about Tomas's usecase.
> > > 
> > > The data becomes available to user space but there is currently no
> > > immediate need or natural place to create a separate instance to
> > > function as a backend device.
> > 
> > So do you have some completely different data path bypassing IIO (just curious)?
> 
> Yes, IP handles data reception and data transfer outside of iio context.
> 
> > 
> > > 
> > > But that being said, I'm leaning towards thinking that perhaps a
> > > minimalistic backend should always be registered after all. That would
> > > keep the idea of the backend always existing intact.
> > > But since the backend can be missing a lot of the features defined for
> > > the current ADI backend, capability handling would need to be added to
> > > the backend framework to make it functional.
> > > 
> > > Looking into how this could be achieved with reasonable impact, I have
> > > tried to identify capabilities that we could add for starters, and then
> > > have the frontend behave differently depending on what features are present.
> > > 
> > > Something like this (added to backend_info),
> > > .caps = IIO_BACKEND_CAP_TEST_PATTERNS |  --> backend patterns are avail.
> > > 	IIO_BACKEND_CAP_BUFFERING |  --> backend has buffering cap.
> > > 	IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration
> > > 
> > 
> > Looks reasonable but I'm still a bit afraid to open this can of worms. But as Jonathan
> > pointed out multiple times on the backend code, this is mostly inkernel interfaces so
> > it is easier to deal with bad choices :).
> 
> I understand this concern, but would anticipate that there are only a
> limited number of capabilties that need to be handled, so it should stay
> fairly managable.
> 
> >  
> > 
> > We would still need to "combine" these capabilities feature with a dummy backend that
> > would dummy implement the more common/expected like (chan)enable/disable and so on.
> 
> I think the dummy backend is probably not gonna be needed as the current
> axi backend can advertise the available set of capabilities. The
> frontends are then free to make use of the capability bits as needed.
> In my use case, I need to implement a limited backend that does not
> claim any capabilities but only provides a minimum set of functionality.
> 

Ok, looking at the driver indeed it seems we would not need much advertised.
Let's see how something like the above would look like and discuss on top of that.

- Nuno Sá