[PATCH v6 0/5] iio: adc: ad9467: Support alternative backends

[PATCH v6 0/5] iio: adc: ad9467: Support alternative backends

[Tomas Melin]

To facilitate backends with different set of features, add support
for defining capabilities provided by the backend. These capabilities
typically extend beyond a single operation and are therefore not
directly linked to if a single function call is implemented or not.
Furthermore, the capabilities 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 v6:
- Renamed CAP_ALWAYS_ON to CAP_ENABLE with inverted interpretation
- Renamed CAP_BUFFERING to CAP_BUFFER
- Added sd_adc_modulator capability commit (CAP_ENABLE)
- minor fixups in code and docs
- Link to v5: https://patch.msgid.link/20260130-b4-ad9467-optional-backend-v5-0-7da803ba7326@vaisala.com

Changes in v5:
- As per recommendation, use guard for whole block
- Typo fix in commit message and cover letter
- Link to v4: https://lore.kernel.org/r/20260121-b4-ad9467-optional-backend-v4-0-18d2c0d450cc@vaisala.com

Changes in v4:
- Readd CAP_BUFFERING and also add CAP_ALWAYS_ON to support backends
  that do not need explicit enable/disable
- Don't mix checks for eopnotsupp and caps. Prefer capability checking
  also for caps that map to single operation
- Move capability checking to top of call stack
- Revise iio_backend_has_caps to use bool signature and fixup semantics
- Amend documentation texts
- Add capability checks for axi-dac
- Drop two's complement patch from this series, already applied
- Link to v3: https://lore.kernel.org/r/20260114-b4-ad9467-optional-backend-v3-0-d2c84979d010@vaisala.com

Changes in v3:
- Reduce set of capabilities to only include calibration. The other
  ones propsed in V2 can be seen as subset of calibration, or single
  operation failing with opnotsupported
- Rename backends checking function
- Relocate caps field inside backend struct (pahole)
- Add kernel-docs
- Add capabilites for exisiting backend variants
- Link to v2: https://lore.kernel.org/r/20260113-b4-ad9467-optional-backend-v2-0-0a27e7e72f41@vaisala.com

Changes in v2:
- Added industrialio-backend capabilities feature
- Removed acceptance for fully optional backend, instead require atleast
  minimalistic backend to exist
- Switched to FIELD_MODIFY()
- Fixed kernel test robot reported failure for missing bitfield.h
- Link to v1: https://lore.kernel.org/r/20251216-b4-ad9467-optional-backend-v1-0-83e61531ef4d@vaisala.com

---
Tomas Melin (5):
      iio: industrialio-backend: support backend capabilities
      iio: adc: adi-axi-adc: define supported iio-backend capabilities
      iio: dac: adi-axi-dac: define supported iio-backend capabilities
      iio: adc: sd_adc_modulator: define supported iio-backend capabilities
      iio: adc: ad9467: check for backend capabilities

 drivers/iio/adc/ad9467.c           | 67 +++++++++++++++++++++++---------------
 drivers/iio/adc/adi-axi-adc.c      |  5 +++
 drivers/iio/adc/sd_adc_modulator.c |  1 +
 drivers/iio/dac/adi-axi-dac.c      |  2 ++
 drivers/iio/industrialio-backend.c | 16 +++++++++
 include/linux/iio/backend.h        | 24 ++++++++++++++
 6 files changed, 89 insertions(+), 26 deletions(-)
---
base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7

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

[PATCH v6 1/5] iio: industrialio-backend: support backend capabilities

[Tomas Melin]

Not all backends support the full set of capabilities provided by the
industrialio-backend framework. Capability bits can be used in frontends
and backends for checking for a certain feature set, or if using
related functions can be expected to fail.

Capability bits should be set by a compatible backend and provided when
registering the backend.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
 drivers/iio/industrialio-backend.c | 16 ++++++++++++++++
 include/linux/iio/backend.h        | 24 ++++++++++++++++++++++++
 2 files changed, 40 insertions(+)

diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
index 447b694d6d5f..1afd00763da9 100644
--- a/drivers/iio/industrialio-backend.c
+++ b/drivers/iio/industrialio-backend.c
@@ -56,6 +56,7 @@ struct iio_backend {
 	void *priv;
 	const char *name;
 	unsigned int cached_reg_addr;
+	u32 caps;
 	/*
 	 * This index is relative to the frontend. Meaning that for
 	 * frontends with multiple backends, this will be the index of this
@@ -774,6 +775,20 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
 }
 EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, "IIO_BACKEND");
 
+/**
+ * iio_backend_has_caps - Check if backend has specific capabilities
+ * @back: Backend device
+ * @caps: Capabilities to check
+ *
+ * RETURNS:
+ * True if backend has all the requested capabilities, false otherwise.
+ */
+bool iio_backend_has_caps(struct iio_backend *back, u32 caps)
+{
+	return (back->caps & caps) == caps;
+}
+EXPORT_SYMBOL_NS_GPL(iio_backend_has_caps, "IIO_BACKEND");
+
 static void iio_backend_release(void *arg)
 {
 	struct iio_backend *back = arg;
@@ -1114,6 +1129,7 @@ int devm_iio_backend_register(struct device *dev,
 
 	back->ops = info->ops;
 	back->name = info->name;
+	back->caps = info->caps;
 	back->owner = dev->driver->owner;
 	back->dev = dev;
 	back->priv = priv;
diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
index 7f815f3fed6a..4d15c2a9802c 100644
--- a/include/linux/iio/backend.h
+++ b/include/linux/iio/backend.h
@@ -84,6 +84,27 @@ enum iio_backend_filter_type {
 	IIO_BACKEND_FILTER_TYPE_MAX
 };
 
+/**
+ * enum iio_backend_capabilities - Backend capabilities
+ * Backend capabilities can be used by frontends to check if a given
+ * functionality is supported by the backend. This is useful for frontend
+ * devices which are expected to work with alternative backend
+ * implementations. Capabilities are loosely coupled with operations,
+ * meaning that a capability requires certain operations to be implemented
+ * by the backend. A capability might be mapped to a single operation or
+ * multiple operations.
+ *
+ * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface
+ * calibration. Calibration procedure is device specific.
+ * @IIO_BACKEND_CAP_BUFFER: Support for IIO buffer interface.
+ * @IIO_BACKEND_CAP_ENABLE: Backend can be explicitly enabled/disabled.
+ */
+enum iio_backend_capabilities {
+	IIO_BACKEND_CAP_CALIBRATION = BIT(0),
+	IIO_BACKEND_CAP_BUFFER = BIT(1),
+	IIO_BACKEND_CAP_ENABLE = BIT(2),
+};
+
 /**
  * struct iio_backend_ops - operations structure for an iio_backend
  * @enable: Enable backend.
@@ -179,10 +200,12 @@ struct iio_backend_ops {
  * struct iio_backend_info - info structure for an iio_backend
  * @name: Backend name.
  * @ops: Backend operations.
+ * @caps: Backend capabilities. (bitmask of enum 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 +258,7 @@ int iio_backend_read_raw(struct iio_backend *back,
 			 long mask);
 int iio_backend_extend_chan_spec(struct iio_backend *back,
 				 struct iio_chan_spec *chan);
+bool iio_backend_has_caps(struct iio_backend *back, u32 caps);
 void *iio_backend_get_priv(const struct iio_backend *conv);
 struct iio_backend *devm_iio_backend_get(struct device *dev, const char *name);
 struct iio_backend *devm_iio_backend_fwnode_get(struct device *dev,

-- 
2.47.3

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

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

diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c
index 14fa4238c2b9..a27745695b7f 100644
--- a/drivers/iio/adc/adi-axi-adc.c
+++ b/drivers/iio/adc/adi-axi-adc.c
@@ -626,6 +626,8 @@ static const struct iio_backend_ops adi_axi_adc_ops = {
 static const struct iio_backend_info adi_axi_adc_generic = {
 	.name = "axi-adc",
 	.ops = &adi_axi_adc_ops,
+	.caps = IIO_BACKEND_CAP_CALIBRATION | IIO_BACKEND_CAP_BUFFER |
+		IIO_BACKEND_CAP_ENABLE,
 };
 
 static const struct iio_backend_ops adi_ad485x_ops = {
@@ -650,6 +652,8 @@ static const struct iio_backend_ops adi_ad485x_ops = {
 static const struct iio_backend_info axi_ad485x = {
 	.name = "axi-ad485x",
 	.ops = &adi_ad485x_ops,
+	.caps = IIO_BACKEND_CAP_CALIBRATION | IIO_BACKEND_CAP_BUFFER |
+		IIO_BACKEND_CAP_ENABLE,
 };
 
 static const struct iio_backend_ops adi_ad408x_ops = {
@@ -670,6 +674,7 @@ static const struct iio_backend_ops adi_ad408x_ops = {
 static const struct iio_backend_info axi_ad408x = {
 	.name = "axi-ad408x",
 	.ops = &adi_ad408x_ops,
+	.caps = IIO_BACKEND_CAP_BUFFER | IIO_BACKEND_CAP_ENABLE,
 };
 
 static int adi_axi_adc_probe(struct platform_device *pdev)

-- 
2.47.3

[PATCH v6 3/5] iio: dac: adi-axi-dac: define supported iio-backend capabilities

[Tomas Melin]

Backends support the buffer/enable capabilities so advertise it
while registering in case a frontend makes checks for it.

Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
 drivers/iio/dac/adi-axi-dac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/dac/adi-axi-dac.c b/drivers/iio/dac/adi-axi-dac.c
index 0d525272a8a8..b02498aed43e 100644
--- a/drivers/iio/dac/adi-axi-dac.c
+++ b/drivers/iio/dac/adi-axi-dac.c
@@ -869,11 +869,13 @@ static const struct iio_backend_ops axi_ad3552r_ops = {
 static const struct iio_backend_info axi_dac_generic = {
 	.name = "axi-dac",
 	.ops = &axi_dac_generic_ops,
+	.caps = IIO_BACKEND_CAP_BUFFER | IIO_BACKEND_CAP_ENABLE,
 };
 
 static const struct iio_backend_info axi_ad3552r = {
 	.name = "axi-ad3552r",
 	.ops = &axi_ad3552r_ops,
+	.caps = IIO_BACKEND_CAP_BUFFER | IIO_BACKEND_CAP_ENABLE,
 };
 
 static const struct regmap_config axi_dac_regmap_config = {

-- 
2.47.3

[PATCH v6 4/5] iio: adc: sd_adc_modulator: define supported iio-backend capabilities

[Tomas Melin]

This backend supports the added CAP_ENABLE capability.

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

diff --git a/drivers/iio/adc/sd_adc_modulator.c b/drivers/iio/adc/sd_adc_modulator.c
index 9f7a75168aac..218117c45ec8 100644
--- a/drivers/iio/adc/sd_adc_modulator.c
+++ b/drivers/iio/adc/sd_adc_modulator.c
@@ -77,6 +77,7 @@ static const struct iio_backend_ops sd_backend_ops = {
 static const struct iio_backend_info sd_backend_info = {
 	.name = "sd-modulator",
 	.ops = &sd_backend_ops,
+	.caps = IIO_BACKEND_CAP_ENABLE,
 };
 
 static int iio_sd_mod_register(struct platform_device *pdev)

-- 
2.47.3

[PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Tomas Melin]

Add capability checks for operation with backends that do not necessarily
support full set of features, but are otherwise compatible with the device.
This ensures a fully functional device, but with limited capabilities.

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

diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 59c3fa3bcc9b..7a3db36121b0 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -913,7 +913,9 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
 		return ret;
 
 	guard(mutex)(&st->lock);
-	return ad9467_calibrate(st);
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+		return ad9467_calibrate(st);
+	return 0;
 }
 
 static int ad9467_write_raw(struct iio_dev *indio_dev,
@@ -1119,12 +1121,15 @@ static ssize_t ad9467_chan_test_mode_read(struct file *file,
 		len = scnprintf(buf, sizeof(buf), "Running \"%s\" Test:\n\t",
 				ad9467_test_modes[chan->mode]);
 
-		ret = iio_backend_debugfs_print_chan_status(st->back, chan->idx,
-							    buf + len,
-							    sizeof(buf) - len);
-		if (ret < 0)
-			return ret;
-		len += ret;
+		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
+			ret = iio_backend_debugfs_print_chan_status(st->back,
+								    chan->idx,
+								    buf + len,
+								    sizeof(buf) - len);
+			if (ret < 0)
+				return ret;
+			len += ret;
+		}
 	} else if (chan->mode == AN877_ADC_TESTMODE_OFF) {
 		len = scnprintf(buf, sizeof(buf), "No test Running...\n");
 	} else {
@@ -1188,16 +1193,18 @@ static ssize_t ad9467_chan_test_mode_write(struct file *file,
 			return ret;
 
 		/*  some patterns have a backend matching monitoring block */
-		if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
-			ret = ad9467_backend_testmode_on(st, chan->idx,
+		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
+			if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
+				ret = ad9467_backend_testmode_on(st, chan->idx,
 							 IIO_BACKEND_ADI_PRBS_9A);
-			if (ret)
-				return ret;
-		} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
-			ret = ad9467_backend_testmode_on(st, chan->idx,
+				if (ret)
+					return ret;
+			} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
+				ret = ad9467_backend_testmode_on(st, chan->idx,
 							 IIO_BACKEND_ADI_PRBS_23A);
-			if (ret)
-				return ret;
+				if (ret)
+					return ret;
+			}
 		}
 	}
 
@@ -1263,8 +1270,9 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
 	if (!st->chan_test)
 		return;
 
-	debugfs_create_file("calibration_table_dump", 0400, d, st,
-			    &ad9467_calib_table_fops);
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
+		debugfs_create_file("calibration_table_dump", 0400, d, st,
+				    &ad9467_calib_table_fops);
 
 	for (chan = 0; chan < st->info->num_channels; chan++) {
 		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
@@ -1339,17 +1347,24 @@ static int ad9467_probe(struct spi_device *spi)
 	if (ret)
 		return ret;
 
-	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
-	if (ret)
-		return ret;
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_BUFFER)) {
+		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
+						      indio_dev);
+		if (ret)
+			return ret;
+	}
 
-	ret = devm_iio_backend_enable(&spi->dev, st->back);
-	if (ret)
-		return ret;
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_ENABLE)) {
+		ret = devm_iio_backend_enable(&spi->dev, st->back);
+		if (ret)
+			return ret;
+	}
 
-	ret = ad9467_calibrate(st);
-	if (ret)
-		return ret;
+	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
+		ret = ad9467_calibrate(st);
+		if (ret)
+			return ret;
+	}
 
 	ret = devm_iio_device_register(&spi->dev, indio_dev);
 	if (ret)

-- 
2.47.3

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Andy Shevchenko]

On Thu, Feb 05, 2026 at 12:24:11PM +0000, Tomas Melin wrote:
> Add capability checks for operation with backends that do not necessarily
> support full set of features, but are otherwise compatible with the device.
> This ensures a fully functional device, but with limited capabilities.

...

> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_BUFFER)) {
> +		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
> +						      indio_dev);

With

	struct device *dev = &spi->dev;

at the top, this one becomes exactly a 80 character line.
And in general it will help cleaning up the rest afterwards.

> +		if (ret)
> +			return ret;
> +	}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[David Lechner]

On 2/5/26 6:24 AM, Tomas Melin wrote:
> Add capability checks for operation with backends that do not necessarily
> support full set of features, but are otherwise compatible with the device.
> This ensures a fully functional device, but with limited capabilities.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/iio/adc/ad9467.c | 67 +++++++++++++++++++++++++++++-------------------
>  1 file changed, 41 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 59c3fa3bcc9b..7a3db36121b0 100644
> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c
> @@ -913,7 +913,9 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
>  		return ret;
>  
>  	guard(mutex)(&st->lock);
> -	return ad9467_calibrate(st);
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return ad9467_calibrate(st);
> +	return 0;
>  }
>  
I would appreciate a blank line before and after the if statement
if we end up needing a v7.

Re: [PATCH v6 0/5] iio: adc: ad9467: Support alternative backends

[David Lechner]

On 2/5/26 6:24 AM, Tomas Melin wrote:
> To facilitate backends with different set of features, add support
> for defining capabilities provided by the backend. These capabilities
> typically extend beyond a single operation and are therefore not
> directly linked to if a single function call is implemented or not.
> Furthermore, the capabilities 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.
> 
Looks good to me now.

Reviewed-by: David Lechner <dlechner@baylibre.com>

Re: [PATCH v6 0/5] iio: adc: ad9467: Support alternative backends

[Nuno Sá]

On Thu, 2026-02-05 at 12:24 +0000, Tomas Melin wrote:
> To facilitate backends with different set of features, add support
> for defining capabilities provided by the backend. These capabilities
> typically extend beyond a single operation and are therefore not
> directly linked to if a single function call is implemented or not.
> Furthermore, the capabilities 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>
> ---

Well, as you all know, not my preferred way to handle the enable/disable stuff,
but, anyways:

Reviewed-by: Nuno Sá <nuno.sa@analog.com>

> Changes in v6:
> - Renamed CAP_ALWAYS_ON to CAP_ENABLE with inverted interpretation
> - Renamed CAP_BUFFERING to CAP_BUFFER
> - Added sd_adc_modulator capability commit (CAP_ENABLE)
> - minor fixups in code and docs
> - Link to v5:
> https://patch.msgid.link/20260130-b4-ad9467-optional-backend-v5-0-7da803ba7326@vaisala.com
> 
> Changes in v5:
> - As per recommendation, use guard for whole block
> - Typo fix in commit message and cover letter
> - Link to v4:
> https://lore.kernel.org/r/20260121-b4-ad9467-optional-backend-v4-0-18d2c0d450cc@vaisala.com
> 
> Changes in v4:
> - Readd CAP_BUFFERING and also add CAP_ALWAYS_ON to support backends
>   that do not need explicit enable/disable
> - Don't mix checks for eopnotsupp and caps. Prefer capability checking
>   also for caps that map to single operation
> - Move capability checking to top of call stack
> - Revise iio_backend_has_caps to use bool signature and fixup semantics
> - Amend documentation texts
> - Add capability checks for axi-dac
> - Drop two's complement patch from this series, already applied
> - Link to v3:
> https://lore.kernel.org/r/20260114-b4-ad9467-optional-backend-v3-0-d2c84979d010@vaisala.com
> 
> Changes in v3:
> - Reduce set of capabilities to only include calibration. The other
>   ones propsed in V2 can be seen as subset of calibration, or single
>   operation failing with opnotsupported
> - Rename backends checking function
> - Relocate caps field inside backend struct (pahole)
> - Add kernel-docs
> - Add capabilites for exisiting backend variants
> - Link to v2:
> https://lore.kernel.org/r/20260113-b4-ad9467-optional-backend-v2-0-0a27e7e72f41@vaisala.com
> 
> Changes in v2:
> - Added industrialio-backend capabilities feature
> - Removed acceptance for fully optional backend, instead require atleast
>   minimalistic backend to exist
> - Switched to FIELD_MODIFY()
> - Fixed kernel test robot reported failure for missing bitfield.h
> - Link to v1:
> https://lore.kernel.org/r/20251216-b4-ad9467-optional-backend-v1-0-83e61531ef4d@vaisala.com
> 
> ---
> Tomas Melin (5):
>       iio: industrialio-backend: support backend capabilities
>       iio: adc: adi-axi-adc: define supported iio-backend capabilities
>       iio: dac: adi-axi-dac: define supported iio-backend capabilities
>       iio: adc: sd_adc_modulator: define supported iio-backend capabilities
>       iio: adc: ad9467: check for backend capabilities
> 
>  drivers/iio/adc/ad9467.c           | 67 +++++++++++++++++++++++---------------
>  drivers/iio/adc/adi-axi-adc.c      |  5 +++
>  drivers/iio/adc/sd_adc_modulator.c |  1 +
>  drivers/iio/dac/adi-axi-dac.c      |  2 ++
>  drivers/iio/industrialio-backend.c | 16 +++++++++
>  include/linux/iio/backend.h        | 24 ++++++++++++++
>  6 files changed, 89 insertions(+), 26 deletions(-)
> ---
> base-commit: a7b10f0963c651a6406d958a5f64b9c5594f84da
> change-id: 20251215-b4-ad9467-optional-backend-23f1099ee4d7
> 
> Best regards,
> --  
> Tomas Melin <tomas.melin@vaisala.com>

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Jonathan Cameron]

On Thu, 05 Feb 2026 12:24:11 +0000
Tomas Melin <tomas.melin@vaisala.com> wrote:

> Add capability checks for operation with backends that do not necessarily
> support full set of features, but are otherwise compatible with the device.
> This ensures a fully functional device, but with limited capabilities.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
I've mentioned before that I've started messing around with Chris Mason's
set of Claude Code prompts and today I was trying out the new stuff mentioned in:
https://lore.kernel.org/all/b187e0c1-1df8-4529-bfe4-0a1d65221adc@meta.com/


Given this patch set is pretty much ready to merge I asked it to take a look
and it came up with something that certainly merited me taking a look.

 Issue: In ad9467_chan_test_mode_write(), the testmode_on path is guarded
  by IIO_BACKEND_CAP_CALIBRATION but the matching testmode_off path is not.
  On backends without that capability, entering PN test mode succeeds but
  exiting fails with -EOPNOTSUPP, leaving the ADC stuck in test mode.

I may be missing some protection path, but I think it is right and if you
were to set up the test modes with a backend that doesn't support the
relevant functionality you would indeed be able to turn them on but never
off again.

So this might be the first bug in IIO that the LLM found and human's, including
me, missed!  

Thanks Chris! I won't +CC you every time but wanted to acknowledge that your
hard work taming these tools is very useful to me.

Jonathan




> ---
>  drivers/iio/adc/ad9467.c | 67 +++++++++++++++++++++++++++++-------------------
>  1 file changed, 41 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
> index 59c3fa3bcc9b..7a3db36121b0 100644
> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c
> @@ -913,7 +913,9 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
>  		return ret;
>  
>  	guard(mutex)(&st->lock);
> -	return ad9467_calibrate(st);
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		return ad9467_calibrate(st);
> +	return 0;
>  }
>  
>  static int ad9467_write_raw(struct iio_dev *indio_dev,
> @@ -1119,12 +1121,15 @@ static ssize_t ad9467_chan_test_mode_read(struct file *file,
>  		len = scnprintf(buf, sizeof(buf), "Running \"%s\" Test:\n\t",
>  				ad9467_test_modes[chan->mode]);
>  
> -		ret = iio_backend_debugfs_print_chan_status(st->back, chan->idx,
> -							    buf + len,
> -							    sizeof(buf) - len);
> -		if (ret < 0)
> -			return ret;
> -		len += ret;
> +		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> +			ret = iio_backend_debugfs_print_chan_status(st->back,
> +								    chan->idx,
> +								    buf + len,
> +								    sizeof(buf) - len);
> +			if (ret < 0)
> +				return ret;
> +			len += ret;
> +		}
>  	} else if (chan->mode == AN877_ADC_TESTMODE_OFF) {
>  		len = scnprintf(buf, sizeof(buf), "No test Running...\n");
>  	} else {
> @@ -1188,16 +1193,18 @@ static ssize_t ad9467_chan_test_mode_write(struct file *file,
>  			return ret;
>  
>  		/*  some patterns have a backend matching monitoring block */
> -		if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
> -			ret = ad9467_backend_testmode_on(st, chan->idx,
> +		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> +			if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>  							 IIO_BACKEND_ADI_PRBS_9A);
> -			if (ret)
> -				return ret;
> -		} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
> -			ret = ad9467_backend_testmode_on(st, chan->idx,
> +				if (ret)
> +					return ret;
> +			} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>  							 IIO_BACKEND_ADI_PRBS_23A);
> -			if (ret)
> -				return ret;
> +				if (ret)
> +					return ret;
> +			}
>  		}
>  	}
>  
> @@ -1263,8 +1270,9 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
>  	if (!st->chan_test)
>  		return;
>  
> -	debugfs_create_file("calibration_table_dump", 0400, d, st,
> -			    &ad9467_calib_table_fops);
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
> +		debugfs_create_file("calibration_table_dump", 0400, d, st,
> +				    &ad9467_calib_table_fops);
>  
>  	for (chan = 0; chan < st->info->num_channels; chan++) {
>  		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
> @@ -1339,17 +1347,24 @@ static int ad9467_probe(struct spi_device *spi)
>  	if (ret)
>  		return ret;
>  
> -	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
> -	if (ret)
> -		return ret;
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_BUFFER)) {
> +		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
> +						      indio_dev);
> +		if (ret)
> +			return ret;
> +	}
>  
> -	ret = devm_iio_backend_enable(&spi->dev, st->back);
> -	if (ret)
> -		return ret;
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_ENABLE)) {
> +		ret = devm_iio_backend_enable(&spi->dev, st->back);
> +		if (ret)
> +			return ret;
> +	}
>  
> -	ret = ad9467_calibrate(st);
> -	if (ret)
> -		return ret;
> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
> +		ret = ad9467_calibrate(st);
> +		if (ret)
> +			return ret;
> +	}
>  
>  	ret = devm_iio_device_register(&spi->dev, indio_dev);
>  	if (ret)
> 

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Tomas Melin]

Hi,

On 08/02/2026 21:30, Jonathan Cameron wrote:
> On Thu, 05 Feb 2026 12:24:11 +0000
> Tomas Melin <tomas.melin@vaisala.com> wrote:
> 
>> Add capability checks for operation with backends that do not necessarily
>> support full set of features, but are otherwise compatible with the device.
>> This ensures a fully functional device, but with limited capabilities.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> I've mentioned before that I've started messing around with Chris Mason's
> set of Claude Code prompts and today I was trying out the new stuff mentioned in:
> https://lore.kernel.org/all/b187e0c1-1df8-4529-bfe4-0a1d65221adc@meta.com/
> 
> 
> Given this patch set is pretty much ready to merge I asked it to take a look
> and it came up with something that certainly merited me taking a look.
> 
>  Issue: In ad9467_chan_test_mode_write(), the testmode_on path is guarded
>   by IIO_BACKEND_CAP_CALIBRATION but the matching testmode_off path is not.
>   On backends without that capability, entering PN test mode succeeds but
>   exiting fails with -EOPNOTSUPP, leaving the ADC stuck in test mode.
> 
> I may be missing some protection path, but I think it is right and if you
> were to set up the test modes with a backend that doesn't support the
> relevant functionality you would indeed be able to turn them on but never
> off again.

The analysis does look correct. I think this has probably bubbled up in
the whirl of changes to call locations etc. Thanks, I will verify and
fix this.

br,
Tomas



> 
> So this might be the first bug in IIO that the LLM found and human's, including
> me, missed!  
> 
> Thanks Chris! I won't +CC you every time but wanted to acknowledge that your
> hard work taming these tools is very useful to me.
> 
> Jonathan
> 
> 
> 
> 
>> ---
>>  drivers/iio/adc/ad9467.c | 67 +++++++++++++++++++++++++++++-------------------
>>  1 file changed, 41 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
>> index 59c3fa3bcc9b..7a3db36121b0 100644
>> --- a/drivers/iio/adc/ad9467.c
>> +++ b/drivers/iio/adc/ad9467.c
>> @@ -913,7 +913,9 @@ static int __ad9467_update_clock(struct ad9467_state *st, long r_clk)
>>  		return ret;
>>  
>>  	guard(mutex)(&st->lock);
>> -	return ad9467_calibrate(st);
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
>> +		return ad9467_calibrate(st);
>> +	return 0;
>>  }
>>  
>>  static int ad9467_write_raw(struct iio_dev *indio_dev,
>> @@ -1119,12 +1121,15 @@ static ssize_t ad9467_chan_test_mode_read(struct file *file,
>>  		len = scnprintf(buf, sizeof(buf), "Running \"%s\" Test:\n\t",
>>  				ad9467_test_modes[chan->mode]);
>>  
>> -		ret = iio_backend_debugfs_print_chan_status(st->back, chan->idx,
>> -							    buf + len,
>> -							    sizeof(buf) - len);
>> -		if (ret < 0)
>> -			return ret;
>> -		len += ret;
>> +		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
>> +			ret = iio_backend_debugfs_print_chan_status(st->back,
>> +								    chan->idx,
>> +								    buf + len,
>> +								    sizeof(buf) - len);
>> +			if (ret < 0)
>> +				return ret;
>> +			len += ret;
>> +		}
>>  	} else if (chan->mode == AN877_ADC_TESTMODE_OFF) {
>>  		len = scnprintf(buf, sizeof(buf), "No test Running...\n");
>>  	} else {
>> @@ -1188,16 +1193,18 @@ static ssize_t ad9467_chan_test_mode_write(struct file *file,
>>  			return ret;
>>  
>>  		/*  some patterns have a backend matching monitoring block */
>> -		if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
>> -			ret = ad9467_backend_testmode_on(st, chan->idx,
>> +		if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
>> +			if (mode == AN877_ADC_TESTMODE_PN9_SEQ) {
>> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>>  							 IIO_BACKEND_ADI_PRBS_9A);
>> -			if (ret)
>> -				return ret;
>> -		} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
>> -			ret = ad9467_backend_testmode_on(st, chan->idx,
>> +				if (ret)
>> +					return ret;
>> +			} else if (mode == AN877_ADC_TESTMODE_PN23_SEQ) {
>> +				ret = ad9467_backend_testmode_on(st, chan->idx,
>>  							 IIO_BACKEND_ADI_PRBS_23A);
>> -			if (ret)
>> -				return ret;
>> +				if (ret)
>> +					return ret;
>> +			}
>>  		}
>>  	}
>>  
>> @@ -1263,8 +1270,9 @@ static void ad9467_debugfs_init(struct iio_dev *indio_dev)
>>  	if (!st->chan_test)
>>  		return;
>>  
>> -	debugfs_create_file("calibration_table_dump", 0400, d, st,
>> -			    &ad9467_calib_table_fops);
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION))
>> +		debugfs_create_file("calibration_table_dump", 0400, d, st,
>> +				    &ad9467_calib_table_fops);
>>  
>>  	for (chan = 0; chan < st->info->num_channels; chan++) {
>>  		snprintf(attr_name, sizeof(attr_name), "in_voltage%u_test_mode",
>> @@ -1339,17 +1347,24 @@ static int ad9467_probe(struct spi_device *spi)
>>  	if (ret)
>>  		return ret;
>>  
>> -	ret = devm_iio_backend_request_buffer(&spi->dev, st->back, indio_dev);
>> -	if (ret)
>> -		return ret;
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_BUFFER)) {
>> +		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
>> +						      indio_dev);
>> +		if (ret)
>> +			return ret;
>> +	}
>>  
>> -	ret = devm_iio_backend_enable(&spi->dev, st->back);
>> -	if (ret)
>> -		return ret;
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_ENABLE)) {
>> +		ret = devm_iio_backend_enable(&spi->dev, st->back);
>> +		if (ret)
>> +			return ret;
>> +	}
>>  
>> -	ret = ad9467_calibrate(st);
>> -	if (ret)
>> -		return ret;
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_CALIBRATION)) {
>> +		ret = ad9467_calibrate(st);
>> +		if (ret)
>> +			return ret;
>> +	}
>>  
>>  	ret = devm_iio_device_register(&spi->dev, indio_dev);
>>  	if (ret)
>>
> 

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Tomas Melin]

Hi,

On 05/02/2026 18:34, Andy Shevchenko wrote:
> On Thu, Feb 05, 2026 at 12:24:11PM +0000, Tomas Melin wrote:
>> Add capability checks for operation with backends that do not necessarily
>> support full set of features, but are otherwise compatible with the device.
>> This ensures a fully functional device, but with limited capabilities.
> 
> ...
> 
>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_BUFFER)) {
>> +		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
>> +						      indio_dev);
> 
> With
> 
> 	struct device *dev = &spi->dev;
> 
> at the top, this one becomes exactly a 80 character line.
> And in general it will help cleaning up the rest afterwards.

Given it seems it would still be 81 characters long I would like to
leave this change as it also creates a bit of noise.

Thanks,
Tomas


> 
>> +		if (ret)
>> +			return ret;
>> +	}
> 

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 09:24:09AM +0200, Tomas Melin wrote:
> On 05/02/2026 18:34, Andy Shevchenko wrote:
> > On Thu, Feb 05, 2026 at 12:24:11PM +0000, Tomas Melin wrote:

...

> >> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_BUFFER)) {
> >> +		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
> >> +						      indio_dev);
> > 
> > With
> > 
> > 	struct device *dev = &spi->dev;
> > 
> > at the top, this one becomes exactly a 80 character line.
> > And in general it will help cleaning up the rest afterwards.
> 
> Given it seems it would still be 81 characters long I would like to
> leave this change as it also creates a bit of noise.

		ret = devm_iio_backend_request_buffer(dev, st->back, indio_dev);

We have different arithmetics for sure, I have it 80.

"There are *two* problems in programming: naming, cache invalidation,
 and off-by-one error."

> >> +		if (ret)
> >> +			return ret;
> >> +	}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Tomas Melin]

On 09/02/2026 10:41, Andy Shevchenko wrote:
> On Mon, Feb 09, 2026 at 09:24:09AM +0200, Tomas Melin wrote:
>> On 05/02/2026 18:34, Andy Shevchenko wrote:
>>> On Thu, Feb 05, 2026 at 12:24:11PM +0000, Tomas Melin wrote:
> 
> ...
> 
>>>> +	if (iio_backend_has_caps(st->back, IIO_BACKEND_CAP_BUFFER)) {
>>>> +		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
>>>> +						      indio_dev);
>>>
>>> With
>>>
>>> 	struct device *dev = &spi->dev;
>>>
>>> at the top, this one becomes exactly a 80 character line.
>>> And in general it will help cleaning up the rest afterwards.
>>
>> Given it seems it would still be 81 characters long I would like to
>> leave this change as it also creates a bit of noise.
> 
> 		ret = devm_iio_backend_request_buffer(dev, st->back, indio_dev);
> 
> We have different arithmetics for sure, I have it 80.

Indeed this seems to be the case, different editors count this
differently :D

-T



> 
> "There are *two* problems in programming: naming, cache invalidation,
>  and off-by-one error."
> 
>>>> +		if (ret)
>>>> +			return ret;
>>>> +	}
> 

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 12:01:07PM +0200, Tomas Melin wrote:
> On 09/02/2026 10:41, Andy Shevchenko wrote:
> > On Mon, Feb 09, 2026 at 09:24:09AM +0200, Tomas Melin wrote:
> >> On 05/02/2026 18:34, Andy Shevchenko wrote:
> >>> On Thu, Feb 05, 2026 at 12:24:11PM +0000, Tomas Melin wrote:

...

> >>>> +		ret = devm_iio_backend_request_buffer(&spi->dev, st->back,
> >>>> +						      indio_dev);
> >>>
> >>> With
> >>>
> >>> 	struct device *dev = &spi->dev;
> >>>
> >>> at the top, this one becomes exactly a 80 character line.
> >>> And in general it will help cleaning up the rest afterwards.
> >>
> >> Given it seems it would still be 81 characters long I would like to
> >> leave this change as it also creates a bit of noise.
> > 
> > 		ret = devm_iio_backend_request_buffer(dev, st->back, indio_dev);
> > 
> > We have different arithmetics for sure, I have it 80.
> 
> Indeed this seems to be the case, different editors count this
> differently :D

It depends if your cursor is under the last character or after, and depending
on the meaning of the value: position of the cursor versus the line length
it may be off-by-one.

In VIM in the default mode it shows the position under the cursor and with
starting column number equal to 1 the line length is calculated as

	position of the cursor - 1 + 1

I believe I have in the bar the length of the line in bytes and columns
(these numbers are different due to tabs versus spaces)

> > "There are *two* problems in programming: naming, cache invalidation,
> >  and off-by-one error."

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Nuno Sá]

On Sun, 2026-02-08 at 19:30 +0000, Jonathan Cameron wrote:
> On Thu, 05 Feb 2026 12:24:11 +0000
> Tomas Melin <tomas.melin@vaisala.com> wrote:
> 
> > Add capability checks for operation with backends that do not necessarily
> > support full set of features, but are otherwise compatible with the device.
> > This ensures a fully functional device, but with limited capabilities.
> > 
> > Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> I've mentioned before that I've started messing around with Chris Mason's
> set of Claude Code prompts and today I was trying out the new stuff mentioned in:
> https://lore.kernel.org/all/b187e0c1-1df8-4529-bfe4-0a1d65221adc@meta.com/
> 

Yeps, we're doing the same and adding the above to our CI. I guess an IIO skill will
be helpful long term.

> 
> Given this patch set is pretty much ready to merge I asked it to take a look
> and it came up with something that certainly merited me taking a look.
> 
>  Issue: In ad9467_chan_test_mode_write(), the testmode_on path is guarded
>   by IIO_BACKEND_CAP_CALIBRATION but the matching testmode_off path is not.
>   On backends without that capability, entering PN test mode succeeds but
>   exiting fails with -EOPNOTSUPP, leaving the ADC stuck in test mode.
> 
> I may be missing some protection path, but I think it is right and if you
> were to set up the test modes with a backend that doesn't support the
> relevant functionality you would indeed be able to turn them on but never
> off again.
> 
> So this might be the first bug in IIO that the LLM found and human's, including
> me, missed!  

Yes, that seems to be the case.

- Nuno Sá

Re: [PATCH v6 5/5] iio: adc: ad9467: check for backend capabilities

[Chris Mason]

On 2/8/26 2:30 PM, Jonathan Cameron wrote:
> On Thu, 05 Feb 2026 12:24:11 +0000
> Tomas Melin <tomas.melin@vaisala.com> wrote:
> 
>> Add capability checks for operation with backends that do not necessarily
>> support full set of features, but are otherwise compatible with the device.
>> This ensures a fully functional device, but with limited capabilities.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> I've mentioned before that I've started messing around with Chris Mason's
> set of Claude Code prompts and today I was trying out the new stuff mentioned in:
> https://lore.kernel.org/all/b187e0c1-1df8-4529-bfe4-0a1d65221adc@meta.com/ 
> 
> 
> Given this patch set is pretty much ready to merge I asked it to take a look
> and it came up with something that certainly merited me taking a look.
> 
>  Issue: In ad9467_chan_test_mode_write(), the testmode_on path is guarded
>   by IIO_BACKEND_CAP_CALIBRATION but the matching testmode_off path is not.
>   On backends without that capability, entering PN test mode succeeds but
>   exiting fails with -EOPNOTSUPP, leaving the ADC stuck in test mode.
> 
> I may be missing some protection path, but I think it is right and if you
> were to set up the test modes with a backend that doesn't support the
> relevant functionality you would indeed be able to turn them on but never
> off again.
> 
> So this might be the first bug in IIO that the LLM found and human's, including
> me, missed!  
> 
> Thanks Chris! I won't +CC you every time but wanted to acknowledge that your
> hard work taming these tools is very useful to me.

I'm really glad the AI reviews are helpful, please don't hesitate to
reach out with feature requests or buggy reviews.

Also, if you're using the prompts in CI, I try to keep the breaking
changes to a minimum, but I'll be refactoring things over the next few
weeks.  The entry points (kernel/review-core.md and kernel/agent/orc.md)
shouldn't change, but some of the other files might move around.

Please don't be shy if we're adding regressions for you, my goal is to
make these easy to consume.

-chris