iio: adc: Add support for LTC2378 and similar ADCs

Document how to describe LTC2378-20 and similar ADCs in device tree.

Signed-off-by Marcelo Schmitt <[email protected]>

---
Change log v1 -> v2:
- Use unevaluatedProperties:false with spi-peripheral-props.yaml reference/include.

- Use unique compatibles (no fallbacks).

Support for LTC2378-20 and similar analog-to-digital converters.

Signed-off-by Marcelo Schmitt <[email protected]>

drivers/iio/adc/Kconfig +7 -0

+	help
+	  Say yes here to build support for Analog Devices LTC2378-20 and
+	  similar analog to digital converters.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called ltc2378.
+
 

drivers/iio/adc/ltc2378.c new file +3 -0

new file mode 100644
index 000000000000..bdff98157979
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Analog Devices LTC2378 ADC series driver

drivers/iio/adc/ltc2378.c new file +9 -0

+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regulator/consumer.h>
+#include <linux/spi/spi.h>
+#include <linux/types.h>
+
+#include <linux/iio/iio.h>

drivers/iio/adc/ltc2378.c new file +10 -0

+	fsleep(4);
+	ret = spi_sync_transfer(st->spi, &st->xfer, 1);
+	gpiod_set_value_cansleep(st->cnv_gpio, 0);
+
+	return ret;
+}
+
+static int ltc2378_channel_single_read(const struct iio_chan_spec *chan,
+				       struct ltc2378_state *st, int *val)
+{

drivers/iio/adc/ltc2378.c new file +10 -0

+	else
+		sample = st->scan.data.sample_buf16;
+
+	if (scan_type->format == IIO_SCAN_FORMAT_SIGNED_INT)
+		*val = sign_extend32(sample, scan_type->realbits - 1);
+	else
+		*val = sample;
+
+	return 0;
+}

drivers/iio/adc/ltc2378.c new file +14 -0

+	case IIO_CHAN_INFO_SCALE:
+		*val = st->ref_uV / MILLI;
+		/*
+		 * For all LTC2378-like devices, the amount of bits that express
+		 * voltage magnitude depend on the output code format:
+		 * - straight binary: All precision/resolution bits are used.
+		 * - 2's complement: One of the precision bits is used for sign.
+		 */
+		if (st->info->twos_comp)
+			*val2 = st->info->resolution - 1;
+		else
+			*val2 = st->info->resolution;
+
+		return IIO_VAL_FRACTIONAL_LOG2;

drivers/iio/adc/ltc2378.c new file +3 -0

+MODULE_AUTHOR("Marcelo Schmitt <[email protected]>");
+MODULE_DESCRIPTION("Analog Devices LTC2378 ADC series driver");
+MODULE_LICENSE("GPL");

drivers/iio/adc/ltc2378.h new file +13 -0

new file mode 100644
index 000000000000..399e8f67cd0e
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Analog Devices LTC2378 and similar ADCs common definitions and properties
+ * Copyright (C) 2026 Analog Devices, Inc.
+ * Author: Marcelo Schmitt <[email protected]>
+ */
+
+#ifndef __DRIVERS_IIO_ADC_LTC2378_H__
+#define __DRIVERS_IIO_ADC_LTC2378_H__
+
+#include <linux/iio/iio.h>
+#include <linux/spi/spi.h>
+#include <linux/types.h>

drivers/iio/adc/ltc2378.h new file +24 -0

+};
+
+struct ltc2378_state {
+	const struct ltc2378_chip_info *info;
+	struct gpio_desc *cnv_gpio;
+	struct spi_device *spi;
+	struct spi_transfer xfer;
+	struct iio_chan_spec chans[2]; /* 1 physical chan + 1 timestamp chan */
+	int ref_uV;
+
+	/*
+	 * DMA (thus cache coherency maintenance) requires the
+	 * transfer buffers to live in their own cache lines.
+	 */
+	struct {
+		union {
+			u16 sample_buf16;
+			u32 sample_buf32;
+		} data;
+		aligned_s64 timestamp;
+	} scan __aligned(IIO_DMA_MINALIGN);
+};
+
+#endif /* __DRIVERS_IIO_ADC_LTC2378_H__ */

Quoted 3 lines · On Thu, 28 May 2026 12:03:52 -0300 Marcelo Schmitt…

Support for LTC2378-20 and similar analog-to-digital converters.

Signed-off-by Marcelo Schmitt <[email protected]>

drivers/iio/adc/Kconfig config LTC2309 · line 945

Quoted 5 lines

drivers/iio/adc/Kconfig +4 -0

+config LTC2378
+	tristate "Analog Devices LTC2378 ADC driver"
+	depends on SPI
+	depends on GPIOLIB || PWM

Triggered sashiko:
https://sashiko.dev/#/patchset/cover.1779976379.git.marcelo.schmitt%40analog.com
This dependency is odd enough that I think I'd add a comment on why. Also bring in the dependency on PWM in the patch that needs it not this one.

Will it build without gpiolib? If so I'd prefer that to be a || COMPILE_TEST just to get a little more coverage.

drivers/iio/adc/ltc2378.c line 153

Quoted 6 lines

drivers/iio/adc/ltc2378.c new file +6 -0

+static int ltc2378_convert_and_acquire(struct ltc2378_state *st)
+{
+	int ret;
+
+	/* Cause a rising edge of CNV to initiate a new ADC conversion */
+	gpiod_set_value_cansleep(st->cnv_gpio, 1);

Should we check for errors on setting the gpio?

Quoted 19 lines

drivers/iio/adc/ltc2378.c new file +19 -0

+	fsleep(4);
+	ret = spi_sync_transfer(st->spi, &st->xfer, 1);
+	gpiod_set_value_cansleep(st->cnv_gpio, 0);
+
+	return ret;
+}
+
+static int ltc2378_channel_single_read(const struct iio_chan_spec *chan,
+				       struct ltc2378_state *st, int *val)
+{
+	const struct iio_scan_type *scan_type = &chan->scan_type;
+	u32 sample;
+	int ret;
+
+	ret = ltc2378_convert_and_acquire(st);
+	if (ret)
+		return ret;
+
+	if (scan_type->realbits > 16)

drivers/iio/adc/ltc2378.c line 173

Quoted 1 line

drivers/iio/adc/ltc2378.c new file +1 -0

+		sample = st->scan.data.sample_buf32;

Sashikio has an interesting theory here that you need a shift. I can't immediately spot why it is wrong. Given we are clocking in 32bits I assume the first res_bits are valid then we get a bunch of garbage after that. Given it's MSB first the SPI controller should put those in the top bits of the resulting u32 with the garbage at the bottom. So shouldn't we shift them down by 32 - resolution or something like that? + in buffered case provide the relevant shift value (in later patches)

Quoted 11 lines

drivers/iio/adc/ltc2378.c new file +11 -0

+	else
+		sample = st->scan.data.sample_buf16;
+
+	if (scan_type->format == IIO_SCAN_FORMAT_SIGNED_INT)
+		*val = sign_extend32(sample, scan_type->realbits - 1);
+	else
+		*val = sample;
+
+	return 0;
+}
+

case IIO_CHAN_INFO_RAW: {

drivers/iio/adc/ltc2378.c line 203

Quoted 10 lines

drivers/iio/adc/ltc2378.c new file +10 -0

+		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
+		if (IIO_DEV_ACQUIRE_FAILED(claim))
+			return -EBUSY;
+
+		ret = ltc2378_channel_single_read(chan, st, val);
+		if (ret)
+			return ret;
+
+		return IIO_VAL_INT;
+

}

As that IIO_DEV_ACQUIRE_DIRECT_MODE() is declaring a local variable so there is something go out of scope and result in cleanup. LLVM moans about this, GCC just does the wrong thing which can in theory at least result in an underflow.
You'll get build bot warnings on this - bug sashiko caught it.

Quoted 7 lines · Jonathan Cameron

Quoted 3 lines · On Thu, 28 May 2026 12:03:52 -0300 Marcelo Schmitt…

Support for LTC2378-20 and similar analog-to-digital converters.

Signed-off-by Marcelo Schmitt <[email protected]>

...

Quoted 11 lines

drivers/iio/adc/Kconfig config LTC2309 · line 945

Quoted 5 lines

drivers/iio/adc/Kconfig +4 -0

+config LTC2378
+	tristate "Analog Devices LTC2378 ADC driver"
+	depends on SPI
+	depends on GPIOLIB || PWM  

Triggered sashiko:
https://sashiko.dev/#/patchset/cover.1779976379.git.marcelo.schmitt%40analog.com
This dependency is odd enough that I think I'd add a comment on why. Also bring in the dependency on PWM in the patch that needs it not this one.

Quoted 3 lines

Will it build without gpiolib? If so I'd prefer that to be a || COMPILE_TEST just to get a little more coverage.

The intent was to allow using the ADC with offload PWM triggered setup even if the GPIO is not provided/enabled. We would be able to do the buffered reads, but the single-shot read would be debatable since we would very likely trigger many conversions in between a pwm_enable()/pwm_disable(). In the doubt, I left the single-read procedure untouched specially because there's also the case where the GPIO is there and so the single-read would work normally.

     +-------------+         +-------------+
     |         CNV |<-----+--| GPIO        |
     |             |      +--| PWM0        |
     |             |         |             |
     |             |      +--| PWM1        |
     |             |      |  +-------------+
     |             |      +->| TRIGGER     |
     |             |         |             |
     |     ADC     |         |    SPI      |
     |             |         | controller  |
     |             |         |             |
     |         SDI |<--------| SDO         |
     |         SDO |-------->| SDI         |
     |        SCLK |<--------| SCLK        |
     +-------------+         +-------------+

Maybe I'm going too much flexible trying to allow all those combinations? Simplest way to avoid what sashiko points as garbage read is to go straight 'depends on GPIOLIB' and check the GPIO must always be there.

Quoted 2 lines

...

Quoted 28 lines

drivers/iio/adc/ltc2378.c line 153

Quoted 6 lines

drivers/iio/adc/ltc2378.c new file +6 -0

+static int ltc2378_convert_and_acquire(struct ltc2378_state *st)
+{
+	int ret;
+
+	/* Cause a rising edge of CNV to initiate a new ADC conversion */
+	gpiod_set_value_cansleep(st->cnv_gpio, 1);  

Should we check for errors on setting the gpio?

Quoted 19 lines

drivers/iio/adc/ltc2378.c new file +19 -0

+	fsleep(4);
+	ret = spi_sync_transfer(st->spi, &st->xfer, 1);
+	gpiod_set_value_cansleep(st->cnv_gpio, 0);
+
+	return ret;
+}
+
+static int ltc2378_channel_single_read(const struct iio_chan_spec *chan,
+				       struct ltc2378_state *st, int *val)
+{
+	const struct iio_scan_type *scan_type = &chan->scan_type;
+	u32 sample;
+	int ret;
+
+	ret = ltc2378_convert_and_acquire(st);
+	if (ret)
+		return ret;
+
+	if (scan_type->realbits > 16)

Quoted 9 lines

drivers/iio/adc/ltc2378.c line 173

Quoted 1 line

drivers/iio/adc/ltc2378.c new file +1 -0

+		sample = st->scan.data.sample_buf32;  

Sashikio has an interesting theory here that you need a shift. I can't immediately spot why it is wrong. Given we are clocking in 32bits I assume the first res_bits are valid then we get a bunch of garbage after that. Given it's MSB first the SPI controller should put those in the top bits of the resulting u32 with the garbage at the bottom. So shouldn't we shift them down by 32 - resolution or something like that? + in buffered case provide the relevant shift value (in later patches)

The only way I'm seing to get sample_buf32 with ADC data in the MSB is if the CPU endianness is BE. Otherwise (LE), the data bits would be put into the lower addresses when SPI puts the word in CPU endianness.

But, if we do unconditional
shift, won't that break sign_extend32() for LE CPUs? Well, I'll anyway double check the data for all sample_buf16/sample_buf32 buffer/non-buffer use cases.

Quoted 12 lines

Quoted 12 lines

drivers/iio/adc/ltc2378.c new file +11 -0

+	else
+		sample = st->scan.data.sample_buf16;
+
+	if (scan_type->format == IIO_SCAN_FORMAT_SIGNED_INT)
+		*val = sign_extend32(sample, scan_type->realbits - 1);
+	else
+		*val = sample;
+
+	return 0;
+}
+  

...

Quoted 14 lines

case IIO_CHAN_INFO_RAW: {

drivers/iio/adc/ltc2378.c line 203

Quoted 10 lines

drivers/iio/adc/ltc2378.c new file +10 -0

+		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
+		if (IIO_DEV_ACQUIRE_FAILED(claim))
+			return -EBUSY;
+
+		ret = ltc2378_channel_single_read(chan, st, val);
+		if (ret)
+			return ret;
+
+		return IIO_VAL_INT;
+  

}

Quoted 6 lines

As that IIO_DEV_ACQUIRE_DIRECT_MODE() is declaring a local variable so there is something go out of scope and result in cleanup. LLVM moans about this, GCC just does the wrong thing which can in theory at least result in an underflow.
You'll get build bot warnings on this - bug sashiko caught it.

Oops I guess I started mis-squashing commits after a certain number of rebases XD

Will fix this and all other suggestions.

Thanks

Make use of SPI transfer offloading to speed up data capture, enabling data acquisition at faster sample rates (up to 2 MSPS).

Signed-off-by Marcelo Schmitt <[email protected]>

---
Change log v1 -> v2:
- Set loop count to prevent CPU stall when calculating PWM parameters.
- Hardcode set specific offload supported amount of data element bits.
- Fixed devm_spi_offload_get() error path.
- Initialize init scan_type according to buffer selection.
- Offload attributes now are channel based instead of device based.
- Wrapped comments close to 80 columns.

I haven't manage to code an is_visible() filter for device attributes specific of offload usage.
Using DEFINE_SYSFS_GROUP_VISIBLE() didn't work out as the sampling_frequency_available attribute would still appear even without offload. Using DEFINE_SYSFS_GROUP_VISIBLE() and sysfs attribute specific visibility function resulted in kernel error (Invalid permissions 01). Instead, I made them channel shared by all attributes.

I tried a lib-like code arrangement like ADIS IMU but didn't manage to get it to work. Separated the code into ltc2378.h, ltc2378.c (lib), ltc2378-core.c (base driver), and ltc2378-offload.c with lib and core built as module and offload.c builtin. Though, I ran into different build and linkage errors depending on how ltc2378-offload.c utilities were encapsulated. Having read through IMU ADIS code, I now think LTC2378 is different and doesn't require a code design that much elaborated. Differently from the separate code for supporting specific adis devices, all ltc2378-like devices can be supported by the same set of functions from ltc2378.c. We can maybe have an ops struct with pointers to buffer specific routines (e.g. offload vs triggered). That might be worth it if we would want to switch between buffer types at runtime. For v2, I'm keeping the module design similar to v1. I appreciate additional examples if a module redesign is still recommended.

drivers/iio/adc/ltc2378-offload-buffer.c new file +22 -0

new file mode 100644
index 000000000000..8ad2d319f669
 
+ */
+static int ltc2378_update_conversion_rate(struct ltc2378_state *st, int freq_Hz)
+{
+	struct spi_offload_trigger_config *config = &st->offload_trigger_config;
+	unsigned int min_read_offset, offload_period_ns;
+	struct pwm_waveform cnv_wf = { };
+	u64 target = LTC2378_TCNV_HIGH_NS;
+	unsigned int count = 0;
+	u64 offload_offset_ns;
+	int ret;
+
+	if (freq_Hz == 0)
+		return -EINVAL;
+
+	if (freq_Hz < 1 || freq_Hz > st->info->max_sample_rate_hz)
+		return -ERANGE;
+
+	/* Configure CNV PWM waveform */
+	cnv_wf.period_length_ns = DIV_ROUND_CLOSEST(NSEC_PER_SEC, freq_Hz);
+
+	/*
+	 * Ensure CNV high time meets minimum requirement (20ns). The PWM

drivers/iio/adc/ltc2378-offload-buffer.c new file +11 -0

+
+	/*
+	 * Configure SPI offload PWM trigger.
+	 * The trigger should fire after tBUSYLH + tCONV + tDSDOBUSYL.
+	 * Minimum time needed: TBUSYLH (13ns) + TCONV (part-specific) + TDSDOBUSYL (5ns)
+	 *
+	 * Use the same period as CNV PWM to avoid timing issues.
+	 * Convert back from period to frequency for the SPI offload API.
+	 */
+	offload_period_ns = cnv_wf.period_length_ns;
+	config->periodic.frequency_hz = DIV_ROUND_UP(HZ_PER_GHZ, offload_period_ns);

drivers/iio/adc/ltc2378-offload-buffer.c new file +6 -0

+
+	st->cnv_wf = cnv_wf;
+	st->cnv_Hz = DIV_ROUND_CLOSEST_ULL(HZ_PER_GHZ, cnv_wf.period_length_ns);
+
+	return 0;
+}
 

drivers/iio/adc/ltc2378-offload-buffer.c new file +7 -0

+		return IIO_AVAIL_RANGE;
+	default:
+		return -EINVAL;
+	}
+}
+EXPORT_SYMBOL_NS_GPL(ltc2378_read_avail, "IIO_LTC2378");
 
 
 
+

drivers/iio/adc/ltc2378-offload-buffer.c new file +9 -0

+
+	return 0;
+}
+
+static const struct spi_offload_config ltc2378_offload_config = {
+	.capability_flags = SPI_OFFLOAD_CAP_TRIGGER |
+			    SPI_OFFLOAD_CAP_RX_STREAM_DMA,
+};
+

drivers/iio/adc/ltc2378-offload-buffer.c new file +32 -0

+
+	ret = ltc2378_spi_offload_setup(indio_dev, st);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to setup SPI offload\n");
+
+	ret = ltc2378_pwm_get(st);
+	if (ret)
+		return ret;
+
+	st->sample_freq_range[0] = 1; /* min */
+	st->sample_freq_range[1] = 1; /* step */
+	st->sample_freq_range[2] = st->info->max_sample_rate_hz; /* max */
+
+	/*
+	 * Start with a slower sampling rate so there is some room for
+	 * adjusting the sampling frequency without hitting the maximum
+	 * conversion rate.
+	 */
+	ret = ltc2378_update_conversion_rate(st, st->info->max_sample_rate_hz >> 4);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to sampling frequency\n");
+
+	ret = ltc2378_prepare_offload_message(&spi->dev, st);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to optimize SPI message\n");
+
+	return 0;
+}
+EXPORT_SYMBOL_NS_GPL(ltc2378_offload_buffer_setup, "IIO_LTC2378");
+
+MODULE_IMPORT_NS("IIO_LTC2378");

drivers/iio/adc/ltc2378.c +1 -1

index bdff98157979..6b01d8e96cc6 100644
@@ -190,7 +230,7 @@ static int ltc2378_read_raw(struct iio_dev *indio_dev,
 	int ret;
 
 	switch (info) {
-	case IIO_CHAN_INFO_RAW:
+	case IIO_CHAN_INFO_RAW: {
 		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
 		if (IIO_DEV_ACQUIRE_FAILED(claim))
 			return -EBUSY;

drivers/iio/adc/ltc2378.c +0 -0

 	case IIO_CHAN_INFO_SCALE:
 
 

static int ltc2378_probe(struct spi_device *spi)

st->xfer.bits_per_word = st->info->resolution > 16 ? 32 : 16;

drivers/iio/adc/ltc2378.h +3 -0

+{
+	return -EOPNOTSUPP;
+}

Enable users to run triggered data captures with LTC2378 and similar ADCs.

Signed-off-by Marcelo Schmitt <[email protected]>

This patch series adds support for LTC2378 and similar low noise, low power, high speed, successive approximation register (SAR) ADCs. These ADCs are similar among each other, varying mainly on the amount of precision bits, maximum sample rate, and input configuration (either fully differential or pseudo-differential).

The initial support patch enables single-shot sample read with a GPIO connected to the CNV pin.

The second support patch enables high-speed data captures with SPI offloading. The setup is similar to AD4030, with a specialized PWM generator being used both for SPI offload triggering and conversion start signaling.

The last support patch enables running buffered data captures without SPI offloading.

Some structures and variables are introduced earlier to reduce diff in latter patches.

The initial version of the LTC2378 driver was developed by Ioan-Daniel. Though, despite of the many changes I made to the code, I've kept him as module author to provide credit for his work.

Link to v1: https://lore.kernel.org/linux-iio/[email protected]/

Quoted 14 lines · Marcelo Schmitt

This patch series adds support for LTC2378 and similar low noise, low power, high speed, successive approximation register (SAR) ADCs. These ADCs are similar among each other, varying mainly on the amount of precision bits, maximum sample rate, and input configuration (either fully differential or pseudo-differential).

The initial support patch enables single-shot sample read with a GPIO connected to the CNV pin.

The second support patch enables high-speed data captures with SPI offloading. The setup is similar to AD4030, with a specialized PWM generator being used both for SPI offload triggering and conversion start signaling.

The last support patch enables running buffered data captures without SPI offloading.

Quoted 5 lines

Some structures and variables are introduced earlier to reduce diff in latter patches.

The initial version of the LTC2378 driver was developed by Ioan-Daniel. Though, despite of the many changes I made to the code, I've kept him as module author to provide credit for his work.

No datasheet link, no explanation why the brand new driver is needed. No need to resend, just answer the above questions.

Quoted 2 lines

Link to v1: https://lore.kernel.org/linux-iio/[email protected]/

Signature · 2 lines

With Best Regards,
Andy Shevchenko