iio: adc: Add support for LTC2378 and similar ADCs

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The LTC2378_DIFF_CHANNEL macro defines an IIO channel that is intended to be differential but lacks the .differential = 1, .indexed = 1, .channel = 0, and .channel2 = 1 attributes. --

--- Patch [2]: [PATCH v7 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs --- commit 5710d5f25b45906977e2522567c1964b1d3219f8
Author: Marcelo Schmitt <[email protected]>

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

This commit adds a new driver for the Analog Devices LTC2378-20 and similar analog-to-digital converters.

Quoted 6 lines

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

new file mode 100644
index 0000000000000..5600c820c7f45
@@ -0,0 +1,416 @@

[ ... ]

drivers/iio/adc/ltc2378.c line 36

Quoted 6 lines

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

+#define LTC2378_DIFF_CHANNEL(_sign, _real_bits, _storage_bits)			\
+{										\
+	.type = IIO_VOLTAGE,							\
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |				\
+			      BIT(IIO_CHAN_INFO_SCALE),				\
+	.scan_index = 0,							\

[Severity: Medium]
Does this macro need to set .differential = 1, .indexed = 1, .channel = 0, and .channel2 = 1? The name suggests these are differential channels, but without these attributes, the IIO ABI will expose them as single-ended (e.g., in_voltage_raw instead of in_voltage0-voltage1_raw).

Quoted 17 lines

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

+	.scan_type = {								\
+		.format = _sign ? IIO_SCAN_FORMAT_SIGNED_INT :			\
+				  IIO_SCAN_FORMAT_UNSIGNED_INT,			\
+		.realbits = _real_bits,						\
+		.storagebits = _storage_bits,					\
+		.shift = _storage_bits - _real_bits,				\
+		.endianness = IIO_BE,						\
+	},									\
+}
+
+#define LTC2378_BIPOLAR_DIFF_CHANNEL(_real_bits)				\
+	LTC2378_DIFF_CHANNEL(1, _real_bits, (((_real_bits) > 16) ? 32 : 16))
+
+#define LTC2378_UNIPOLAR_DIFF_CHANNEL(_real_bits)				\
+	LTC2378_DIFF_CHANNEL(0, _real_bits, (((_real_bits) > 16) ? 32 : 16))
+

[ ... ]

Signature · 1 line

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

Quoted 20 lines · On 07/16, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The LTC2378_DIFF_CHANNEL macro defines an IIO channel that is intended to be differential but lacks the .differential = 1, .indexed = 1, .channel = 0, and .channel2 = 1 attributes. --

--- Patch [2]: [PATCH v7 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs --- commit 5710d5f25b45906977e2522567c1964b1d3219f8
Author: Marcelo Schmitt <[email protected]>

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

This commit adds a new driver for the Analog Devices LTC2378-20 and similar analog-to-digital converters.

Quoted 6 lines

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

new file mode 100644
index 0000000000000..5600c820c7f45
@@ -0,0 +1,416 @@  

[ ... ]

Quoted 12 lines

drivers/iio/adc/ltc2378.c line 36

Quoted 6 lines

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

+#define LTC2378_DIFF_CHANNEL(_sign, _real_bits, _storage_bits)			\
+{										\
+	.type = IIO_VOLTAGE,							\
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |				\
+			      BIT(IIO_CHAN_INFO_SCALE),				\
+	.scan_index = 0,							\  

[Severity: Medium]
Does this macro need to set .differential = 1, .indexed = 1, .channel = 0, and .channel2 = 1? The name suggests these are differential channels, but without these attributes, the IIO ABI will expose them as single-ended (e.g., in_voltage_raw instead of in_voltage0-voltage1_raw).

For parts with multiple inputs and configurable differential channels (e.g. AD4130-8, MCP3561/2/4R, NAFE13388 [1, 2, 3]), the voltageY-voltageZ ABI helps clarifying what physical inputs make up a channel. For differential only parts, the ABI seems to be flexible by only requiring a 'consistent labeling' (either voltageY or voltageY-voltageZ IIUC). Will set the channel with the differential ABI if maintainers believe that's the best way to have it. Might slightly tweak the channel macros to keep .differential = 0 for pseudo-differential chips (e.g.LTC2369-18).

[1]: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4130-8.pdf
[2]: https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3561_2_4R-Data-Sheet-DS200006391C.pdf
[3]: https://www.nxp.com/docs/en/data-sheet/NAFE13388.pdf

Quoted 21 lines

Quoted 17 lines

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

+	.scan_type = {								\
+		.format = _sign ? IIO_SCAN_FORMAT_SIGNED_INT :			\
+				  IIO_SCAN_FORMAT_UNSIGNED_INT,			\
+		.realbits = _real_bits,						\
+		.storagebits = _storage_bits,					\
+		.shift = _storage_bits - _real_bits,				\
+		.endianness = IIO_BE,						\
+	},									\
+}
+
+#define LTC2378_BIPOLAR_DIFF_CHANNEL(_real_bits)				\
+	LTC2378_DIFF_CHANNEL(1, _real_bits, (((_real_bits) > 16) ? 32 : 16))
+
+#define LTC2378_UNIPOLAR_DIFF_CHANNEL(_real_bits)				\
+	LTC2378_DIFF_CHANNEL(0, _real_bits, (((_real_bits) > 16) ? 32 : 16))
+  

[ ... ]

Signature · 1 line

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

Quoted 34 lines · On Fri, 17 Jul 2026 13:38:07 -0300 Marcelo Schmitt…

Quoted 20 lines · On 07/16, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The LTC2378_DIFF_CHANNEL macro defines an IIO channel that is intended to be differential but lacks the .differential = 1, .indexed = 1, .channel = 0, and .channel2 = 1 attributes. --

--- Patch [2]: [PATCH v7 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs --- commit 5710d5f25b45906977e2522567c1964b1d3219f8
Author: Marcelo Schmitt <[email protected]>

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

This commit adds a new driver for the Analog Devices LTC2378-20 and similar analog-to-digital converters.

Quoted 6 lines

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

new file mode 100644
index 0000000000000..5600c820c7f45
@@ -0,0 +1,416 @@  

[ ... ]

Quoted 12 lines

drivers/iio/adc/ltc2378.c line 36

Quoted 6 lines

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

+#define LTC2378_DIFF_CHANNEL(_sign, _real_bits, _storage_bits)			\
+{										\
+	.type = IIO_VOLTAGE,							\
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |				\
+			      BIT(IIO_CHAN_INFO_SCALE),				\
+	.scan_index = 0,							\  

[Severity: Medium]
Does this macro need to set .differential = 1, .indexed = 1, .channel = 0, and .channel2 = 1? The name suggests these are differential channels, but without these attributes, the IIO ABI will expose them as single-ended (e.g., in_voltage_raw instead of in_voltage0-voltage1_raw).

Quoted 8 lines

For parts with multiple inputs and configurable differential channels (e.g. AD4130-8, MCP3561/2/4R, NAFE13388 [1, 2, 3]), the voltageY-voltageZ ABI helps clarifying what physical inputs make up a channel. For differential only parts, the ABI seems to be flexible by only requiring a 'consistent labeling' (either voltageY or voltageY-voltageZ IIUC). Will set the channel with the differential ABI if maintainers believe that's the best way to have it. Might slightly tweak the channel macros to keep .differential = 0 for pseudo-differential chips (e.g.LTC2369-18).

Whilst I get your point on differential only cases not really requiring the specification of two inputs, I think that does provide a simple indication to users that they are differential channel.

I would prefer that we make them 'look' like differential channels so make up a suitable number for the negative side.

TL;DR: Will switch to voltageY-voltageZ ABI.

Quoted 46 lines · Jonathan Cameron

Quoted 34 lines · On Fri, 17 Jul 2026 13:38:07 -0300 Marcelo Schmitt…

Quoted 20 lines · On 07/16, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The LTC2378_DIFF_CHANNEL macro defines an IIO channel that is intended to be differential but lacks the .differential = 1, .indexed = 1, .channel = 0, and .channel2 = 1 attributes. --

--- Patch [2]: [PATCH v7 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs --- commit 5710d5f25b45906977e2522567c1964b1d3219f8
Author: Marcelo Schmitt <[email protected]>

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

This commit adds a new driver for the Analog Devices LTC2378-20 and similar analog-to-digital converters.

Quoted 6 lines

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

new file mode 100644
index 0000000000000..5600c820c7f45
@@ -0,0 +1,416 @@    

[ ... ]

Quoted 12 lines

drivers/iio/adc/ltc2378.c line 36

Quoted 6 lines

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

+#define LTC2378_DIFF_CHANNEL(_sign, _real_bits, _storage_bits)			\
+{										\
+	.type = IIO_VOLTAGE,							\
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |				\
+			      BIT(IIO_CHAN_INFO_SCALE),				\
+	.scan_index = 0,							\    

[Severity: Medium]
Does this macro need to set .differential = 1, .indexed = 1, .channel = 0, and .channel2 = 1? The name suggests these are differential channels, but without these attributes, the IIO ABI will expose them as single-ended (e.g., in_voltage_raw instead of in_voltage0-voltage1_raw).

Quoted 8 lines

For parts with multiple inputs and configurable differential channels (e.g. AD4130-8, MCP3561/2/4R, NAFE13388 [1, 2, 3]), the voltageY-voltageZ ABI helps clarifying what physical inputs make up a channel. For differential only parts, the ABI seems to be flexible by only requiring a 'consistent labeling' (either voltageY or voltageY-voltageZ IIUC). Will set the channel with the differential ABI if maintainers believe that's the best way to have it. Might slightly tweak the channel macros to keep .differential = 0 for pseudo-differential chips (e.g.LTC2369-18).

Quoted 3 lines

Whilst I get your point on differential only cases not really requiring the specification of two inputs, I think that does provide a simple indication to users that they are differential channel.

Agree. The first ADCs I've worked with were single-ended so having to provide the negative input when working with differential ones was something noticeable to me. Though, one applications engineer once called me out for the voltageY-voltageZ naming arguing that a differential channel provided only one input to his application and thus it should be labeled only 'voltageY' or even just 'voltage'. Despite understanding that argument, I share the opinion that an indication of differential channel is helpful. Anyways, besides the possibility for application to display channel names differently in user space, I see we now have .read_label so the whole discussion seems pointless.

Quoted 1 line

Quoted 2 lines

I would prefer that we make them 'look' like differential channels so make up a suitable number for the negative side.

Would it make sense to adjust the ABI doc to encourage the dual numbering for differential channels? So I don't fall the temptation of single index in the future :)

Thanks,
Marcelo

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

Reviewed-by David Lechner <[email protected]>

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

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

new file mode 100644
index 000000000000..5600c820c7f4
 
+static int ltc2378_refin_setup(struct device *dev, struct ltc2378_state *st)
+{
+	int ret;

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

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

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Integer divide-by-zero leading to kernel panic in ltc2378_update_conversion_rate when a sampling frequency of 1 Hz is requested and the PWM driver rounds the period length above 1 second. --

--- Patch [3]: [PATCH v7 3/4] iio: adc: ltc2378: Enable high-speed data capture --- commit ef54f2c79f2cac1649922032814adc7fcc5f9684
Author: Marcelo Schmitt <[email protected]>
Subject: iio: adc: ltc2378: Enable high-speed data capture

This commit enables high-speed data capture for the ltc2378 ADC driver by utilizing SPI transfer offloading. It allows data acquisition at faster sample rates up to 2 MSPS.

Quoted 4 lines

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

index 5600c820c7f45..7d29f021cb7b4 100644

[ ... ]

Quoted 17 lines

drivers/iio/adc/ltc2378.c +17 -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_u64(HZ_PER_GHZ, offload_period_ns);
+	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;
+		ret = spi_offload_trigger_validate(st->offload_trigger, &config);
+		if (ret)

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

Quoted 10 lines

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

+			return ret;
+		offload_offset_ns += 10;
+	} while (count-- && config.periodic.offset_ns < min_read_offset);
+
+	/* Check the minimum CNV to SCLK delay is met */
+	if (config.periodic.offset_ns < min_read_offset)
+		return -EDOM;
+
+	/* Check the PWM periods remain the same */
+	offload_period_ns = div64_u64(HZ_PER_GHZ, config.periodic.frequency_hz);

[Severity: High]
Could this result in a kernel panic due to an integer division by zero?

If a user writes 1 to the IIO in_voltage_sampling_frequency sysfs attribute, ltc2378_update_conversion_rate() is called with freq_Hz = 1, and the initial requested PWM period is calculated as 1,000,000,000 ns.

If the underlying hardware PWM driver rounds the period slightly upwards (e.g., to 1,000,000,001 ns) during pwm_round_waveform_might_sleep() due to clock granularity, offload_period_ns will exceed HZ_PER_GHZ.

This causes config.periodic.frequency_hz = div_u64(HZ_PER_GHZ, offload_period_ns) to evaluate to 0.

When div64_u64(HZ_PER_GHZ, config.periodic.frequency_hz) is subsequently called, it divides by zero.

Quoted 10 lines

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

+	if (cnv_wf.period_length_ns != offload_period_ns)
+		return -EDOM;
+
+	st->offload_trigger_config = config;
+	st->cnv_wf = cnv_wf;
+	st->cnv_Hz = DIV_ROUND_CLOSEST_ULL(HZ_PER_GHZ, cnv_wf.period_length_ns);
+
+	return 0;
+}

Signature · 1 line

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

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).

Patch 1 adds device tree documentation for LTC2378.

Patch 2 enables single-shot sample read with a GPIO connected to the LTC2378 CNV pin.

Patch 3 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.

Patch 4 enables running buffered data captures without SPI offloading.

Even though these parts are somewhat similar to AD4000, the wiring configuration for LTC parts is different as well as the available HDL for high speed sample rate mode. Because of that, I propose creating a new device driver for supporting LTC2378-like devices.