iio: adc: Add support for LTC2378 and similar ADCs

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Compatible strings with required fallbacks are incorrectly allowed as standalone strings. --

commit fff47614872c95c6a481f63da8b14dfcedd0bb53
Author: Marcelo Schmitt <[email protected]>

dt-bindings: iio: adc: Add ltc2378

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

Quoted 4 lines

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml new file +0 -0

new file mode 100644

[ ... ]

Quoted 4 lines

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml new file +4 -0

+properties:
+  compatible:
+    oneOf:
+      # Single compatible string match.

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml line 51

Quoted 10 lines

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml new file +10 -0

+      - enum:
+          - adi,ltc2338-18
+          - adi,ltc2364-16
+          - adi,ltc2364-18
+          - adi,ltc2367-16
+          - adi,ltc2367-18
+          - adi,ltc2368-16
+          - adi,ltc2368-18
+          - adi,ltc2369-18
+          - adi,ltc2370-16

[Severity: Low]
Does this standalone enum allow devices that should require a fallback to pass schema validation with only a single compatible string?

Because parts like "adi,ltc2370-16" and "adi,ltc2367-16" are listed here in the single enum match, a device tree node specifying only compatible = "adi,ltc2370-16" will satisfy this block and successfully pass schema validation.

This seems to bypass the fallback requirements defined below in the items blocks:

[ ... ]

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml line 70

Quoted 7 lines

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml new file +7 -0

+      # Low sample rate fallback for 16-bit unipolar sensors.
+      - items:
+          - enum:
+              - adi,ltc2370-16 # 2 MSPS
+              - adi,ltc2368-16 # 1 MSPS
+              - adi,ltc2367-16 # 500 kSPS
+          - const: adi,ltc2364-16 # fallback (250 kSPS)

Should the parts that require a fallback be removed from the single compatible string enum so the schema correctly enforces the fallback?

Signature · 2 lines

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

Quoted 52 lines · On 07/02, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Compatible strings with required fallbacks are incorrectly allowed as standalone strings. --

commit fff47614872c95c6a481f63da8b14dfcedd0bb53
Author: Marcelo Schmitt <[email protected]>

dt-bindings: iio: adc: Add ltc2378

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

Quoted 4 lines

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml new file +0 -0

new file mode 100644

[ ... ]

Quoted 4 lines

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml new file +4 -0

+properties:
+  compatible:
+    oneOf:
+      # Single compatible string match.

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml line 51

Quoted 10 lines

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml new file +10 -0

+      - enum:
+          - adi,ltc2338-18
+          - adi,ltc2364-16
+          - adi,ltc2364-18
+          - adi,ltc2367-16
+          - adi,ltc2367-18
+          - adi,ltc2368-16
+          - adi,ltc2368-18
+          - adi,ltc2369-18
+          - adi,ltc2370-16  

[Severity: Low]
Does this standalone enum allow devices that should require a fallback to pass schema validation with only a single compatible string?

Because parts like "adi,ltc2370-16" and "adi,ltc2367-16" are listed here in the single enum match, a device tree node specifying only compatible = "adi,ltc2370-16" will satisfy this block and successfully pass schema validation.

This seems to bypass the fallback requirements defined below in the items blocks:

[ ... ]

Quoted 7 lines

Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml new file +7 -0

+      # Low sample rate fallback for 16-bit unipolar sensors.
+      - items:
+          - enum:
+              - adi,ltc2370-16 # 2 MSPS
+              - adi,ltc2368-16 # 1 MSPS
+              - adi,ltc2367-16 # 500 kSPS
+          - const: adi,ltc2364-16 # fallback (250 kSPS)  

Quoted 2 lines

Should the parts that require a fallback be removed from the single compatible string enum so the schema correctly enforces the fallback?

Why? Should users be prevented to specify a single specific compatible string?

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Hardware protocol violation: CNV is held high during SPI read
- [High] SPI bus not locked during ADC conversion phase
- [Medium] Incorrect scale calculation for LTC2338-18 and similar ADCs
- [Low] Undefined direct mode macros lead to build failure
--

commit b74b536d18af0084ea31bd1e1e8cf9454da5e29c
Author: Marcelo Schmitt <[email protected]>

iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs

This commit adds support for the Analog Devices LTC2378-20 and similar analog-to-digital converters. It introduces a new IIO driver using the SPI subsystem.

Quoted 6 lines

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

new file mode 100644
index 0000000000000..b5cf2e974daca
@@ -0,0 +1,404 @@

[ ... ]

Quoted 5 lines

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

+static const struct ltc2378_chip_info ltc2338_18_chip_info = {
+	.name = "ltc2338-18",
+	.internal_ref_uV = 4096000,
+	.chan = LTC2378_BIPOLAR_DIFF_CHANNEL(18),
+};

[ ... ]

drivers/iio/adc/ltc2378.c line 184

Quoted 7 lines

drivers/iio/adc/ltc2378.c new file +7 -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);
+	fsleep(4);

[Severity: High]
Can this sequence cause data corruption on a shared SPI bus?

The CNV pin is toggled and an fsleep(4) occurs before spi_sync_transfer() locks the bus. If another SPI transaction occurs during this sleep window, could it toggle the SCK line and prematurely clock data out of the ADC?

Should the conversion-and-read sequence be wrapped in spi_bus_lock() and spi_bus_unlock()?

drivers/iio/adc/ltc2378.c line 185

Quoted 2 lines

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

+	ret = spi_sync_transfer(st->spi, &st->xfer, 1);

[Severity: High]
Does reading from the SPI bus while CNV is held high violate the hardware protocol?

The ADC requires the CNV pin to be brought low to enable the SDO output before clocking out data via SPI, but spi_sync_transfer() happens before gpiod_set_value_cansleep(st->cnv_gpio, 0), which might result in reading high-impedance garbage data.

Quoted 5 lines

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

+	gpiod_set_value_cansleep(st->cnv_gpio, 0);
+
+	return ret;
+}

[ ... ]

drivers/iio/adc/ltc2378.c line 235

Quoted 12 lines

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

+static int ltc2378_read_raw(struct iio_dev *indio_dev,
+			    const struct iio_chan_spec *chan,
+			    int *val, int *val2, long mask)
+{
+	struct ltc2378_state *st = iio_priv(indio_dev);
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW: {
+		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
+		if (IIO_DEV_ACQUIRE_FAILED(claim))
+			return -EBUSY;

[Severity: Low]
Will this cause a build failure?

The macros IIO_DEV_ACQUIRE_DIRECT_MODE and IIO_DEV_ACQUIRE_FAILED appear to be undeclared in the kernel tree.

drivers/iio/adc/ltc2378.c line 244

Quoted 10 lines

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

+
+		ret = ltc2378_channel_single_read(chan, st, val);
+		if (ret)
+			return ret;
+
+		return IIO_VAL_INT;
+	}
+	case IIO_CHAN_INFO_SCALE:
+		*val = st->ref_uV / MILLI;

[Severity: Medium]
Does this calculate an incorrect IIO scale for the LTC2338-18?

Does this miss the 2.5x input span multiplier unique to the LTC2338-18 when calculating the IIO scale here?

Quoted 18 lines

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

+		/*
+		 * For all LTC2378-like devices, the amount of bits that express
+		 * voltage magnitude depend on the polarity / output code format:
+		 * - straight binary: All precision/resolution bits are used.
+		 * - 2's complement: One of the precision bits is used for sign.
+		 */
+		if (chan->scan_type.format == IIO_SCAN_FORMAT_SIGNED_INT)
+			*val2 = chan->scan_type.realbits - 1;
+		else
+			*val2 = chan->scan_type.realbits;
+
+		return IIO_VAL_FRACTIONAL_LOG2;
+
+	default:
+		return -EINVAL;
+	}
+}

[ ... ]

drivers/iio/adc/ltc2378.c line 277

Quoted 11 lines

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

+static int ltc2378_refin_setup(struct device *dev, struct ltc2378_state *st)
+{
+	int ret;
+
+	/*
+	 * The internal reference buffer amplifies both the internal reference
+	 * and REFIN by a factor of 2.
+	 */
+	ret = devm_regulator_get_enable_read_voltage(dev, "refin");
+	if (ret == -ENODEV) /* refin is optional */
+		st->ref_uV = st->info->internal_ref_uV * 2;

[Severity: Medium]
Does this incorrectly double the internal reference voltage?

The ltc2338_18_chip_info already defines internal_ref_uV as the post-buffer value of 4096000 (4.096V). Multiplying it by 2 here would result in an incorrect scale value.

Quoted 8 lines

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

+	else if (ret < 0)
+		return dev_err_probe(dev, ret, "failed to read refin regulator\n");
+	else
+		st->ref_uV = ret * 2;
+
+	return 0;
+}

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

Quoted 44 lines · On 07/02, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Hardware protocol violation: CNV is held high during SPI read
- [High] SPI bus not locked during ADC conversion phase
- [Medium] Incorrect scale calculation for LTC2338-18 and similar ADCs
- [Low] Undefined direct mode macros lead to build failure
--

commit b74b536d18af0084ea31bd1e1e8cf9454da5e29c
Author: Marcelo Schmitt <[email protected]>

iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs

This commit adds support for the Analog Devices LTC2378-20 and similar analog-to-digital converters. It introduces a new IIO driver using the SPI subsystem.

Quoted 6 lines

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

new file mode 100644
index 0000000000000..b5cf2e974daca
@@ -0,0 +1,404 @@  

[ ... ]

Quoted 5 lines

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

+static const struct ltc2378_chip_info ltc2338_18_chip_info = {
+	.name = "ltc2338-18",
+	.internal_ref_uV = 4096000,
+	.chan = LTC2378_BIPOLAR_DIFF_CHANNEL(18),
+};  

[ ... ]

drivers/iio/adc/ltc2378.c line 184

Quoted 7 lines

drivers/iio/adc/ltc2378.c new file +7 -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);
+	fsleep(4);  

[Severity: High]
Can this sequence cause data corruption on a shared SPI bus?

Quoted 3 lines

The CNV pin is toggled and an fsleep(4) occurs before spi_sync_transfer() locks the bus. If another SPI transaction occurs during this sleep window, could it toggle the SCK line and prematurely clock data out of the ADC?

Makes sense.

Quoted 3 lines

Should the conversion-and-read sequence be wrapped in spi_bus_lock() and spi_bus_unlock()?

Because these chips don't have CS line, it seems that locking the bus actually makes sense.

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

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

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

new file mode 100644
index 000000000000..b5cf2e974dac
@@ -0,0 +1,404 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Analog Devices LTC2378 ADC series driver
+ *
+ * Copyright (C) 2026 Analog Devices Inc.

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

+
+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;
+

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

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

+#include <linux/mod_devicetable.h>

Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:
- [Critical] Access to non-existent offset_ns field in struct spi_offload_trigger_periodic causes a build failure.
- [Critical] The macro HZ_PER_GHZ is used but never defined anywhere in the kernel, causing a build failure.
- [High] Mismatch between SPI offload transfer length and IIO channel storage bits for 16-bit devices causes buffer data corruption.
- [High] Unassigned length pointer in ltc2378_read_avail API callback leaves caller variable uninitialized.
- [High] Unpredictable phase shift between two independent PWM channels risks hardware data corruption.
- [High] Forcing unsupported bits_per_word breaks single-shot reads on standard SPI controllers.
- [Medium] st->offload_trigger_config is updated in-place and not rolled back on validation failure, corrupting driver state. --

commit 7c29c089819a4620f86fae01e267747bb7a266ff
Author: Marcelo Schmitt <[email protected]>

iio: adc: ltc2378: Enable high-speed data capture

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

Quoted 4 lines

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

index b5cf2e974daca..b25602d91bbe1 100644

[ ... ]

drivers/iio/adc/ltc2378.c line 66

Quoted 10 lines

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

@@ -46,10 +58,19 @@
 #define LTC2378_UNIPOLAR_DIFF_CHANNEL(_real_bits)				\
 	LTC2378_DIFF_CHANNEL(0, _real_bits, (((_real_bits) > 16) ? 32 : 16), 0)
 
+#define LTC2378_OFFLOAD_BIPOLAR_DIFF_CHANNEL(_real_bits)			\
+	LTC2378_DIFF_CHANNEL(1, (_real_bits), 32, 1)
+
+#define LTC2378_OFFLOAD_UNIPOLAR_DIFF_CHANNEL(_real_bits)			\
+	LTC2378_DIFF_CHANNEL(0, (_real_bits), 32, 1)
+

[Severity: High]
Does hardcoding the storagebits to 32 here mismatch with the SPI transfer length for 16-bit devices?

When ltc2378_prepare_offload_message() configures the transfer, it sets the length to spi_bpw_to_bytes(16), which is 2 bytes. Since the IIO subsystem expects 4 bytes per sample based on these channel definitions, could this cause buffer reads to be misaligned and return garbage data to userspace?

[ ... ]

Quoted 18 lines

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

@@ -254,7 +344,136 @@ static int ltc2378_read_raw(struct iio_dev *indio_dev,
 			*val2 = chan->scan_type.realbits;
 
 		return IIO_VAL_FRACTIONAL_LOG2;
+	case IIO_CHAN_INFO_SAMP_FREQ:
+		*val = st->cnv_Hz;
+		return IIO_VAL_INT;
+	default:
+		return -EINVAL;
+	}
+}
+
+static int ltc2378_read_avail(struct iio_dev *indio_dev,
+			      struct iio_chan_spec const *chan,
+			      const int **vals, int *type, int *length, long mask)
+{
+	struct ltc2378_state *st = iio_priv(indio_dev);
+

drivers/iio/adc/ltc2378.c static int ltc2378_read_raw(struct iio_dev *indio_dev, · line 365

Quoted 5 lines

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

+	switch (mask) {
+	case IIO_CHAN_INFO_SAMP_FREQ:
+		*vals = st->sample_freq_range;
+		*type = IIO_VAL_INT;
+		return IIO_AVAIL_RANGE;

[Severity: High]
Should this callback also initialize the length pointer?

Since this returns IIO_AVAIL_RANGE successfully but doesn't assign *length, callers like iio_read_channel_info_avail() in the core might use an uninitialized stack variable for the array size. Could this lead to out-of-bounds array reads?

Quoted 4 lines

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

+	default:
+		return -EINVAL;
+	}
+}

[ ... ]

Quoted 2 lines

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

+static int ltc2378_update_conversion_rate(struct ltc2378_state *st, int freq_Hz)
+{

[ ... ]

drivers/iio/adc/ltc2378.c static int ltc2378_read_raw(struct iio_dev *indio_dev, · line 437

Quoted 10 lines

drivers/iio/adc/ltc2378.c +10 -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);

[Severity: Critical]
Is HZ_PER_GHZ defined anywhere in the kernel?

Looking through the tree and include/linux/units.h, this macro doesn't appear to exist. Won't this cause an unconditional build failure?

drivers/iio/adc/ltc2378.c static int ltc2378_read_raw(struct iio_dev *indio_dev, · line 442

Quoted 5 lines

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

+	min_read_offset = LTC2378_TBUSYLH_NS + st->info->tconv_ns + LTC2378_TDSDOBUSYL_NS;
+	offload_offset_ns = min_read_offset;
+	count = 100;
+	do {
+		config->periodic.offset_ns = offload_offset_ns;

[Severity: Critical]
Does struct spi_offload_trigger_periodic actually have an offset_ns field?

According to include/linux/spi/offload/types.h, struct spi_offload_trigger_periodic only contains the frequency_hz field. This seems like it will cause a build error.

drivers/iio/adc/ltc2378.c static int ltc2378_read_raw(struct iio_dev *indio_dev, · line 445

Quoted 3 lines

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

+		ret = spi_offload_trigger_validate(st->offload_trigger, config);
+		if (ret)
+			return ret;

[Severity: Medium]
If validation fails here, does the in-place modification of the shared config struct get rolled back?

Since config points directly to st->offload_trigger_config, returning early leaves the device state with rejected values. If the IIO buffer is later enabled, could the driver use these invalid config values to start the offload trigger?

Quoted 3 lines

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

+		offload_offset_ns += 10;
+	} while (count-- && config->periodic.offset_ns < min_read_offset);

[ ... ]

drivers/iio/adc/ltc2378.c static const struct iio_info ltc2378_iio_info = { · line 518

Quoted 11 lines

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

+static int ltc2378_offload_buffer_postenable(struct iio_dev *indio_dev)
+{
+	struct ltc2378_state *st = iio_priv(indio_dev);
+	int ret;
+
+	ret = pwm_set_waveform_might_sleep(st->cnv_trigger, &st->cnv_wf, true);
+	if (ret)
+		return ret;
+
+	ret = spi_offload_trigger_enable(st->offload, st->offload_trigger,
+					 &st->offload_trigger_config);

[Severity: High]
Does starting these two clock sources sequentially result in an unpredictable phase shift?

Since st->cnv_trigger and st->offload_trigger are independent and enabled one after the other in software, CPU execution delays might cause an uncontrolled phase alignment. The LTC2378 datasheet forbids SCLK toggling during the conversion phase. Could this random phase shift cause SPI transactions to overlap with the conversion window and corrupt the sampled data?

Quoted 5 lines

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

+	if (ret)
+		goto out_pwm_disable;
+
+	return 0;

[ ... ]

Quoted 1 line

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

@@ -330,8 +653,53 @@ static int ltc2378_probe(struct spi_device *spi)

[ ... ]

drivers/iio/adc/ltc2378.c static int ltc2378_probe(struct spi_device *spi) · line 701

Quoted 6 lines

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

+		/*
+		 * Set single-read transfer bits_per_word so the SPI subsystem
+		 * rearanges data to CPU endianness, enabling us to reuse
+		 * offload_chan specifications for single-shot reads.
+		 */
+		st->xfer.bits_per_word = st->info->offload_chan.scan_type.realbits;

[Severity: High]
Is it safe to force this bits_per_word on the shared transfer struct used for regular single-shot reads?

Most generic SPI host controllers only natively support standard word widths (like 8, 16, 32). If bits_per_word is set to an arbitrary resolution like 18, won't the SPI core's __spi_validate reject the transfer with -EINVAL and break sysfs single-shot reads?

Quoted 5 lines

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

+	}
 
 	st->xfer.rx_buf = &st->scan.data;
 	st->xfer.len = spi_bpw_to_bytes(indio_dev->channels[0].scan_type.realbits);

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

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]>

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

index b5cf2e974dac..b25602d91bbe 100644
@@ -12,16 +12,28 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/gpio/consumer.h>
+#include <linux/math64.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/regulator/consumer.h>
+#include <linux/pwm.h>
 #include <linux/spi/spi.h>