[PATCH v3 0/5] iio: adc: ad4080: add support for AD4880 dual-channel ADC

Antoniu Miclaus posted 5 patches 1 month, 2 weeks ago
There is a newer version of this series
.../bindings/iio/adc/adi,ad4080.yaml          |  54 +++-
drivers/iio/adc/ad4080.c                      | 248 ++++++++++++++----
drivers/iio/industrialio-backend.c            |  61 +++--
drivers/spi/spi.c                             |  69 ++++-
include/linux/iio/backend.h                   |   2 +
include/linux/spi/spi.h                       |   1 +
6 files changed, 357 insertions(+), 78 deletions(-)
[PATCH v3 0/5] iio: adc: ad4080: add support for AD4880 dual-channel ADC
Posted by Antoniu Miclaus 1 month, 2 weeks ago
Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC from
the same family as AD4080.

The AD4880 has two independent ADC channels, each with its own SPI
configuration interface and LVDS data output. The driver uses
spi_new_ancillary_device() for the second channel's SPI and requires
two io-backend instances for the data interfaces.

This series includes:
  - SPI core fix to allow ancillary devices to share parent's chip selects
  - New devm_spi_new_ancillary_device() managed helper
  - Refactored devm_iio_backend_get_by_index() for multi-channel backend lookup
  - DT bindings update for AD4880
  - Driver support for AD4880

Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4880.pdf

Changes in v3:
  - Drop redundant NULL check for info->parent in spi_dev_check()
  - Add new devm_spi_new_ancillary_device() managed helper (new patch)
  - Refactor iio backend: make __devm_iio_backend_fwnode_get() reuse
    __devm_iio_backend_fwnode_get_by_index() to avoid code duplication
  - Use __free(fwnode_handle) for automatic cleanup in backend code
  - Add items descriptions for io-backends in dt-bindings
  - Fix reg example format in dt-bindings
  - Use devm_spi_new_ancillary_device() instead of manual
    spi_new_ancillary_device() + devm_add_action_or_reset()
  - Generalize ancillary device setup with loop instead of
    hardcoding channel 1


Antoniu Miclaus (5):
  spi: allow ancillary devices to share parent's chip selects
  spi: add devm_spi_new_ancillary_device()
  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          |  54 +++-
 drivers/iio/adc/ad4080.c                      | 248 ++++++++++++++----
 drivers/iio/industrialio-backend.c            |  61 +++--
 drivers/spi/spi.c                             |  69 ++++-
 include/linux/iio/backend.h                   |   2 +
 include/linux/spi/spi.h                       |   1 +
 6 files changed, 357 insertions(+), 78 deletions(-)

-- 
2.43.0
Re: [PATCH v3 0/5] iio: adc: ad4080: add support for AD4880 dual-channel ADC
Posted by Jonathan Cameron 1 month, 2 weeks ago
On Fri, 13 Feb 2026 16:47:32 +0200
Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:

> Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC from
> the same family as AD4080.
> 
> The AD4880 has two independent ADC channels, each with its own SPI
> configuration interface and LVDS data output. The driver uses
> spi_new_ancillary_device() for the second channel's SPI and requires
> two io-backend instances for the data interfaces.
> 
> This series includes:
>   - SPI core fix to allow ancillary devices to share parent's chip selects
>   - New devm_spi_new_ancillary_device() managed helper
>   - Refactored devm_iio_backend_get_by_index() for multi-channel backend lookup
>   - DT bindings update for AD4880
>   - Driver support for AD4880
> 
> Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4880.pdf

Just to be clear on status, this set is held on resolving Andy's
observation (that probably raced with posting this update) that
the SPI core has support for multiple chip select devices and how
this code differs from what that provides.

I haven't looked into this in detail so it may well just be a case
of providing more details on what is going on here vs what the SPI
subsystem supports (which might just be switching all the chip selects
together?)

Jonathan