Re: [PATCH v8 0/6] iio: adc: ad4691: add driver for AD4691 multichannel SAR ADC family

Jonathan Cameron
2026-04-25T18:32:06Z

On Thu, 16 Apr 2026 12:18:45 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:

> This series adds support for the Analog Devices AD4691 family of
> high-speed, low-power multichannel successive approximation register
> (SAR) ADCs with an SPI-compatible serial interface.
>
> The family includes:
> - AD4691: 16-channel, 500 kSPS
> - AD4692: 16-channel, 1 MSPS
> - AD4693: 8-channel, 500 kSPS
> - AD4694: 8-channel, 1 MSPS
>
> The devices support two operating modes, auto-detected from the device
> tree:
> - CNV Burst Mode: external PWM drives CNV independently of SPI;
> DATA_READY on a GP pin signals end of conversion
> - Manual Mode: CNV tied to SPI CS; each SPI transfer reads
> the previous conversion result and starts the
> next (pipelined N+1 scheme)
>
> A new driver is warranted rather than extending ad4695: the AD4691
> data path uses an accumulator-register model — results are read from
> AVG_IN registers, with ACC_MASK, ADC_SETUP, DEVICE_SETUP, and
> GPIO_MODE registers controlling the sequencer — none of which exist
> in AD4695. CNV Burst Mode (PWM drives CNV independently of SPI) and
> Manual Mode (pipelined N+1 transfers) also have no equivalent in
> AD4695's command-embedded single-cycle protocol.
>
> The series is structured as follows:
> 1/6 - DT bindings (YAML schema) and MAINTAINERS entry
> 2/6 - Initial driver: register map via custom regmap callbacks,
> IIO read_raw/write_raw, both operating modes, single-channel
> reads via internal oscillator (Autonomous Mode)
> 3/6 - Triggered buffer support: IRQ-driven (DATA_READY on a GP pin
> selected via interrupt-names) for CNV Burst Mode; external IIO
> trigger for Manual Mode to handle the pipelined N+1 SPI protocol
> 4/6 - SPI Engine offload support: DMA-backed high-throughput
> capture path using the SPI offload subsystem
> 5/6 - Per-channel oversampling ratio support for CNV Burst Mode
> 6/6 - Driver documentation (Documentation/iio/ad4691.rst)
>
> Datasheets:
> https://www.analog.com/en/products/ad4691.html
> https://www.analog.com/en/products/ad4692.html
> https://www.analog.com/en/products/ad4693.html
> https://www.analog.com/en/products/ad4694.html
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
drivers/iio/adc/ad4691.c: note: in included file:
./include/linux/bitmap.h:845:55: warning: shift too big (64) for type unsigned long
./include/linux/bitmap.h:845:55: warning: shift too big (64) for type unsigned long
./include/linux/bitmap.h:845:55: warning: shift too big (64) for type unsigned long
./include/linux/bitmap.h:845:55: warning: shift too big (64) for type unsigned long

From sparse. I think it's a false positive.
It's the bitmap_read() calls - probably the the nbits parameter.
Using bitmap_read() to copy the whole bitmap is unusual so maybe this is a corner
case that isn't handled.

Any ideas? I'm going to assume it's a false positive due to the ACCESS_PRIVATE()
confusing sparse.

So with that in mind, series applied to the testing branch of iio.git.

thanks,

Jonathan