Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC with
integrated fully differential amplifiers (FDA).

Architecture notes:

The AD4880 is modeled as a single IIO device rather than two independent
devices because the channels share power supplies, a voltage reference,
the CNV conversion clock, and a single interleaved data output stream.
Splitting them into separate IIO devices would make synchronized
dual-channel capture impossible from userspace.

An MFD approach does not apply here either - the channels are not
functionally distinct sub-devices but identical ADC paths sharing a
common data interface.

Each channel has fully independent configuration registers accessible
through separate SPI chip selects, so per-channel regmaps are used with
no locking between them. The data path has no software involvement at
runtime: the CNV clock triggers simultaneous conversions and the device
outputs an interleaved bitstream captured directly by the IIO backend
(FPGA). spi_new_ancillary_device() handles the configuration path;
the IIO backend handles the data path.

The debugfs_reg_access callback is not exposed for the dual-channel
variant since the IIO framework provides a single (reg, val) interface
with no channel parameter, and exposing only one channel would be
misleading.

The AD4880 is a fairly unique part - having separate SPI config
interfaces per channel with a shared interleaved data output is not
a common pattern.

Changes in v7:
  - Drop debugfs_reg_access for dual-channel AD4880 variant
  - Pass struct device * to ad4080_properties_parse() instead of
    using regmap_get_device(st->regmap[0])
  - Use 100-column limit consistently for function signatures
  - Add architecture summary to cover letter (per Andy's request)

Antoniu Miclaus (4):
  iio: backend: use __free(fwnode_handle) for automatic cleanup
  iio: backend: add devm_iio_backend_get_by_index()
  dt-bindings: iio: adc: ad4080: add AD4880 support
  iio: adc: ad4080: add support for AD4880 dual-channel ADC

 .../bindings/iio/adc/adi,ad4080.yaml          |  53 +++-
 drivers/iio/adc/ad4080.c                      | 231 ++++++++++++++----
 drivers/iio/industrialio-backend.c            |  59 +++--
 include/linux/iio/backend.h                   |   1 +
 4 files changed, 273 insertions(+), 71 deletions(-)

-- 
2.43.0

On Sat, 21 Mar 2026 12:01:50 +0200
Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:

> Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC with
> integrated fully differential amplifiers (FDA).

Given the lkml cc this got picked up by sashiko:
https://sashiko.dev/#/patchset/20260321100154.1258-1-antoniu.miclaus%40analog.com

Mixed bag on correct and (I think) incorrect stuff but take a look and fix
up anything you agree with for v8.

Thanks,

Jonathan

> 
> Architecture notes:
> 
> The AD4880 is modeled as a single IIO device rather than two independent
> devices because the channels share power supplies, a voltage reference,
> the CNV conversion clock, and a single interleaved data output stream.
> Splitting them into separate IIO devices would make synchronized
> dual-channel capture impossible from userspace.
> 
> An MFD approach does not apply here either - the channels are not
> functionally distinct sub-devices but identical ADC paths sharing a
> common data interface.
> 
> Each channel has fully independent configuration registers accessible
> through separate SPI chip selects, so per-channel regmaps are used with
> no locking between them. The data path has no software involvement at
> runtime: the CNV clock triggers simultaneous conversions and the device
> outputs an interleaved bitstream captured directly by the IIO backend
> (FPGA). spi_new_ancillary_device() handles the configuration path;
> the IIO backend handles the data path.
> 
> The debugfs_reg_access callback is not exposed for the dual-channel
> variant since the IIO framework provides a single (reg, val) interface
> with no channel parameter, and exposing only one channel would be
> misleading.
> 
> The AD4880 is a fairly unique part - having separate SPI config
> interfaces per channel with a shared interleaved data output is not
> a common pattern.
> 
> Changes in v7:
>   - Drop debugfs_reg_access for dual-channel AD4880 variant
>   - Pass struct device * to ad4080_properties_parse() instead of
>     using regmap_get_device(st->regmap[0])
>   - Use 100-column limit consistently for function signatures
>   - Add architecture summary to cover letter (per Andy's request)
> 
> Antoniu Miclaus (4):
>   iio: backend: use __free(fwnode_handle) for automatic cleanup
>   iio: backend: add devm_iio_backend_get_by_index()
>   dt-bindings: iio: adc: ad4080: add AD4880 support
>   iio: adc: ad4080: add support for AD4880 dual-channel ADC
> 
>  .../bindings/iio/adc/adi,ad4080.yaml          |  53 +++-
>  drivers/iio/adc/ad4080.c                      | 231 ++++++++++++++----
>  drivers/iio/industrialio-backend.c            |  59 +++--
>  include/linux/iio/backend.h                   |   1 +
>  4 files changed, 273 insertions(+), 71 deletions(-)
>

On Sat, 21 Mar 2026 12:01:50 +0200
Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:

> Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC with
> integrated fully differential amplifiers (FDA).
> 
> Architecture notes:
> 
> The AD4880 is modeled as a single IIO device rather than two independent
> devices because the channels share power supplies, a voltage reference,
> the CNV conversion clock, 

This might be worth confirming as the datasheet I found implies they
are separate - if there is a section that says they must be wired to the
same clock, please add a reference.  They aren't wired together internally
and in LVDS mode I'd imagine they are kept separate to make signal timing
simpler as each complete channels worth of LVDS are in blocks in the pin out.

> and a single interleaved data output stream.

Aas per my (very late!) reply to v6, is this true, or is this down to
the backend? My reading of the datasheet suggests they are separate
interfaces from the ADC itself.

> Splitting them into separate IIO devices would make synchronized
> dual-channel capture impossible from userspace.

Would be more complex and require some extra glue logic in the subsystem
I think, but not impossible. Just hard.

> 
> An MFD approach does not apply here either - the channels are not
> functionally distinct sub-devices but identical ADC paths sharing a
> common data interface.

As above. Not seeing that from the datasheet. I'd change these to say
that's the backend constraint.

> 
> Each channel has fully independent configuration registers accessible
> through separate SPI chip selects, so per-channel regmaps are used with
> no locking between them. The data path has no software involvement at
> runtime: the CNV clock triggers simultaneous conversions and the device
> outputs an interleaved bitstream captured directly by the IIO backend
> (FPGA).

Again, reference for that interleaved bitstream.

> spi_new_ancillary_device() handles the configuration path;
> the IIO backend handles the data path.
> 
> The debugfs_reg_access callback is not exposed for the dual-channel
> variant since the IIO framework provides a single (reg, val) interface
> with no channel parameter, and exposing only one channel would be
> misleading.

Leaving that for now is fine. Can revisit if we care later. Given
it's debugfs and mostly useless after driver development is done
I doubt we really care.

> 
> The AD4880 is a fairly unique part - having separate SPI config
> interfaces per channel with a shared interleaved data output is not
> a common pattern.
> 
> Changes in v7:
>   - Drop debugfs_reg_access for dual-channel AD4880 variant
>   - Pass struct device * to ad4080_properties_parse() instead of
>     using regmap_get_device(st->regmap[0])
>   - Use 100-column limit consistently for function signatures
>   - Add architecture summary to cover letter (per Andy's request)
> 
> Antoniu Miclaus (4):
>   iio: backend: use __free(fwnode_handle) for automatic cleanup
>   iio: backend: add devm_iio_backend_get_by_index()
>   dt-bindings: iio: adc: ad4080: add AD4880 support
>   iio: adc: ad4080: add support for AD4880 dual-channel ADC
> 
>  .../bindings/iio/adc/adi,ad4080.yaml          |  53 +++-
>  drivers/iio/adc/ad4080.c                      | 231 ++++++++++++++----
>  drivers/iio/industrialio-backend.c            |  59 +++--
>  include/linux/iio/backend.h                   |   1 +
>  4 files changed, 273 insertions(+), 71 deletions(-)
>