iio: adc: Add support for LTC2378 and similar ADCs

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Holding CNV high during SPI transfer breaks 3-wire SPI wiring mode. --

--- Patch [2]: [PATCH v9 2/6] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs --- commit 4d4231cee28f9742280dd61ed84f85cf3b4e0386
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.

Quoted 4 lines

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

new file mode 100644

[ ... ]

drivers/iio/adc/ltc2378.c line 187

Quoted 8 lines

drivers/iio/adc/ltc2378.c new file +8 -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(LTC2378_MAX_DATA_WAIT_US);
+	ret = spi_sync_transfer(st->spi, &st->xfer, 1);

[Severity: High]
Does holding CNV high during the SPI transfer break 3-wire SPI wiring mode? In 3-wire mode (where SDI is tied to GND), the SDO pin of the ADC remains in a high-impedance state as long as the CNV pin is held high.

Since the CNV pin remains high throughout the SPI transfer, could the SPI controller clock in garbage data from a floating bus?

Would lowering CNV after the fsleep() wait and before calling spi_sync_transfer() correctly enable SDO for 3-wire mode while remaining compatible with 4-wire (CS) mode?

Quoted 5 lines

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

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

[ ... ]

Signature · 1 line

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

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Declaring a variable immediately after a switch case label without a block statement causes a compilation error. --

--- Patch [5]: [PATCH v9 5/6] iio: adc: ltc2378: Add support for LTC2338-18 --- commit 29728b1d34f34b2970657e2d83536de22940ee2e
Author: Marcelo Schmitt <[email protected]>

iio: adc: ltc2378: Add support for LTC2338-18

This commit adds support for the LTC2338-18 ADC to the existing ltc2378 driver. It extends the driver to handle the internal voltage reference and input signal attenuation specific to this part.

Quoted 3 lines

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

[ ... ]

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

Quoted 5 lines

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

@@ -383,7 +395,10 @@ static int ltc2378_read_raw(struct iio_dev *indio_dev,
 		return IIO_VAL_INT;
 	}
 	case IIO_CHAN_INFO_SCALE:
+		struct u32_fract fract = st->info->internal_div;

[Severity: Low]
Does this declaration cause a build error?

Declaring a variable immediately
after a switch case label without a block statement is not a valid statement in C and usually causes a compiler error. Could this case be wrapped in a block to scope the variable, or the declaration be moved to the top of the function?

Quoted 6 lines

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

 		*val = st->ref_uV / MILLI;
+		if (fract.numerator && fract.denominator)
+			*val = mult_frac(*val, fract.numerator, fract.denominator);
 		/*
 		 * For all LTC2378-like devices, the amount of bits that express
 		 * voltage magnitude depend on the polarity / output code format:

Signature · 1 line

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

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

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Declaring a variable immediately after a switch case label without a block statement causes a compilation error. --

--- Patch [5]: [PATCH v9 5/6] iio: adc: ltc2378: Add support for LTC2338-18 --- commit 29728b1d34f34b2970657e2d83536de22940ee2e
Author: Marcelo Schmitt <[email protected]>

iio: adc: ltc2378: Add support for LTC2338-18

This commit adds support for the LTC2338-18 ADC to the existing ltc2378 driver. It extends the driver to handle the internal voltage reference and input signal attenuation specific to this part.

Quoted 3 lines

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

[ ... ]

Quoted 8 lines

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

Quoted 5 lines

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

@@ -383,7 +395,10 @@ static int ltc2378_read_raw(struct iio_dev *indio_dev,
 		return IIO_VAL_INT;
 	}
 	case IIO_CHAN_INFO_SCALE:
+		struct u32_fract fract = st->info->internal_div;  

[Severity: Low]
Does this declaration cause a build error?

No, at least not when I built with clang/llvm-22.

Quoted 16 lines

Declaring a variable immediately
after a switch case label without a block statement is not a valid statement in C and usually causes a compiler error. Could this case be wrapped in a block to scope the variable, or the declaration be moved to the top of the function?

Quoted 6 lines

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

 		*val = st->ref_uV / MILLI;
+		if (fract.numerator && fract.denominator)
+			*val = mult_frac(*val, fract.numerator, fract.denominator);
 		/*
 		 * For all LTC2378-like devices, the amount of bits that express
 		 * voltage magnitude depend on the polarity / output code format:  

Signature · 1 line

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

LTC2338-18 is similar to LTC2378-18, differentiating from the already supported part mainly on the embedment of an internal voltage reference and addition of a resistor divider network connected to the input signal path. Extend the device driver, handling the internal reference and input signal attenuation, enabling it to also support LTC2338-18.

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

+}

Quoted 5 lines · Marcelo Schmitt

LTC2338-18 is similar to LTC2378-18, differentiating from the already supported part mainly on the embedment of an internal voltage reference and addition of a resistor divider network connected to the input signal path. Extend the device driver, handling the internal reference and input signal attenuation, enabling it to also support LTC2338-18.

...

Quoted 10 lines

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

drivers/iio/adc/ltc2378.c static const struct spi_offload_config ltc2378_offload_config = { · line 678

Quoted 10 lines

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

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

I'm not sure about others' preferences, but I would do it as if-else-if and remove dup return 0.

	if (ret == -ENODEV) /* refin is optional */
		st->ref_uV = st->info->internal_ref_uV * 2;
	else if (ret < 0)
		return dev_err_probe(dev, ret, "failed to read refin regulator\n");
	else
		st->ref_uV = ret * 2;

	return 0;

It also makes code shorter (in amount of LoC).

Quoted 27 lines

Quoted 6 lines

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

+	/*
+	 * 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 */

drivers/iio/adc/ltc2378.c static const struct spi_offload_config ltc2378_offload_config = { · line 678

Quoted 10 lines

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

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

I'm not sure about others' preferences, but I would do it as if-else-if and remove dup return 0.

	if (ret == -ENODEV) /* refin is optional */
		st->ref_uV = st->info->internal_ref_uV * 2;
	else if (ret < 0)
		return dev_err_probe(dev, ret, "failed to read refin regulator\n");
	else
		st->ref_uV = ret * 2;

Quoted 3 lines

	return 0;

It also makes code shorter (in amount of LoC).

This has already been applied to IIO testing. I do send another version of this specific patch if that's okay.

On Mon, Aug 10, 2026 at 11:45:55PM -0300, Marcelo Schmitt wrote:

...

Quoted 29 lines

Quoted 29 lines

Quoted 6 lines

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

+	/*
+	 * 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 */

drivers/iio/adc/ltc2378.c static const struct spi_offload_config ltc2378_offload_config = { · line 678

Quoted 10 lines

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

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

I'm not sure about others' preferences, but I would do it as if-else-if and remove dup return 0.

	if (ret == -ENODEV) /* refin is optional */
		st->ref_uV = st->info->internal_ref_uV * 2;
	else if (ret < 0)
		return dev_err_probe(dev, ret, "failed to read refin regulator\n");
	else
		st->ref_uV = ret * 2;

	return 0;

Quoted 4 lines

Quoted 1 line

It also makes code shorter (in amount of LoC).

This has already been applied to IIO testing. I do send another version of this specific patch if that's okay.

Jonathan can replace it there, as rebase is inevitable anyway. Let's ask his
opinion: Jonathan, do you want a followup that can be folded or a new version of this patch?

So far, parts that could only do differential voltage measurements were only required to have a consistent labeling of their channels by complying either to voltageY or to voltageY-voltageZ ABI. Over time, code maintainers came to the conclusion that the voltageY-voltageZ ABI is better suited for differential-only chips as it provides a simple indication to users that the channels measure the difference of two inputs.

Adjust the ABI documentation to recommend using the voltageY-voltageZ ABI for chips that do only differential voltage measurements.

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

---
No changes in v9.

 Documentation/ABI/testing/sysfs-bus-iio | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Documentation/ABI/testing/sysfs-bus-iio +5 -4

index 5cc2e82c4997..7446e07b9ab2 100644
@@ -162,10 +162,11 @@ Contact:	[email protected]
 Description:
 		Raw (unscaled) differential voltage measurement equivalent to
 		channel Y - channel Z where these channel numbers apply to the
-		physically equivalent inputs when non differential readings are
-		separately available. In differential only parts, then all that
-		is required is a consistent labeling.  Units after application
-		of scale and offset are millivolts.
+		physically equivalent inputs when non-differential readings are
+		separately available. Even though differential-only parts had
+		been merely required to have consistent channel labeling, this
+		ABI is preferred over the non-differential one for those chips.
+		Units after application of scale and offset are millivolts.
 
 What:		/sys/bus/iio/devices/iio:deviceX/in_altvoltageY_rms_raw
 KernelVersion:	6.18

Quoted 11 lines · On Mon, 27 Jul 2026 18:32:18 -0300 Marcelo Schmitt…

So far, parts that could only do differential voltage measurements were only required to have a consistent labeling of their channels by complying either to voltageY or to voltageY-voltageZ ABI. Over time, code maintainers came to the conclusion that the voltageY-voltageZ ABI is better suited for differential-only chips as it provides a simple indication to users that the channels measure the difference of two inputs.

Adjust the ABI documentation to recommend using the voltageY-voltageZ ABI for chips that do only differential voltage measurements.

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

Hi Marcelo

Whilst looking at another series, I noticed we did something different again in the devicetree bindings for those devices that have restrictive muxes that means the positive and negative lines always change together. For those we let

diff-channels = <1 1>
which tends to map to

in_voltageX-voltageX_raw

I'm not sure if we want to explicitly call that out as an option. There is nothing in your new text saying we can't do that.

Worth also noting there are short circuit parts where you really do connect both ends of the differential ADC to the same input pin. I think it can be useful for testing / calibration?

Jonathan

Quoted 27 lines

---
No changes in v9.

 Documentation/ABI/testing/sysfs-bus-iio | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Documentation/ABI/testing/sysfs-bus-iio +5 -4

index 5cc2e82c4997..7446e07b9ab2 100644
@@ -162,10 +162,11 @@ Contact:	[email protected]
 Description:
 		Raw (unscaled) differential voltage measurement equivalent to
 		channel Y - channel Z where these channel numbers apply to the
-		physically equivalent inputs when non differential readings are
-		separately available. In differential only parts, then all that
-		is required is a consistent labeling.  Units after application
-		of scale and offset are millivolts.
+		physically equivalent inputs when non-differential readings are
+		separately available. Even though differential-only parts had
+		been merely required to have consistent channel labeling, this
+		ABI is preferred over the non-differential one for those chips.
+		Units after application of scale and offset are millivolts.
 
 What:		/sys/bus/iio/devices/iio:deviceX/in_altvoltageY_rms_raw
 KernelVersion:	6.18

Quoted 21 lines · Jonathan Cameron

Quoted 11 lines · On Mon, 27 Jul 2026 18:32:18 -0300 Marcelo Schmitt…

So far, parts that could only do differential voltage measurements were only required to have a consistent labeling of their channels by complying either to voltageY or to voltageY-voltageZ ABI. Over time, code maintainers came to the conclusion that the voltageY-voltageZ ABI is better suited for differential-only chips as it provides a simple indication to users that the channels measure the difference of two inputs.

Adjust the ABI documentation to recommend using the voltageY-voltageZ ABI for chips that do only differential voltage measurements.

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

Hi Marcelo

Whilst looking at another series, I noticed we did something different again in the devicetree bindings for those devices that have restrictive muxes that means the positive and negative lines always change together. For those we let

Quoted 4 lines

diff-channels = <1 1>
which tends to map to

in_voltageX-voltageX_raw

Hmm, that sounds awesome. Probably a much more accurate way of presenting the channel(s) to user space. Wish I had realized that earlier.

Quoted 3 lines

I'm not sure if we want to explicitly call that out as an option. There is nothing in your new text saying we can't do that.

I'd say probably best to mention the voltageX-X case. These fully differential inputs (that have the positive and negative lines changing together) are not uncommon. Sure, let me write something more comprehensive.

It would also be best to use that notation for ltc2378. IIRC, it's okay to not specify the ADC channels in dt if all channels have the same properties so no need to update the dt-doc. For the IIO driver, we have the channel sysfs entries changing name. Will send v10 in case there's still any chance to get it updated. Also okay to wait for the next release cycle if possible.

Quoted 8 lines

Worth also noting there are short circuit parts where you really do connect both ends of the differential ADC to the same input pin. I think it can be useful for testing / calibration?

Jonathan

Thanks,
Marcelo

Quoted 28 lines

Quoted 27 lines

---
No changes in v9.

 Documentation/ABI/testing/sysfs-bus-iio | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Documentation/ABI/testing/sysfs-bus-iio +5 -4

index 5cc2e82c4997..7446e07b9ab2 100644
@@ -162,10 +162,11 @@ Contact:	[email protected]
 Description:
 		Raw (unscaled) differential voltage measurement equivalent to
 		channel Y - channel Z where these channel numbers apply to the
-		physically equivalent inputs when non differential readings are
-		separately available. In differential only parts, then all that
-		is required is a consistent labeling.  Units after application
-		of scale and offset are millivolts.
+		physically equivalent inputs when non-differential readings are
+		separately available. Even though differential-only parts had
+		been merely required to have consistent channel labeling, this
+		ABI is preferred over the non-differential one for those chips.
+		Units after application of scale and offset are millivolts.
 
 What:		/sys/bus/iio/devices/iio:deviceX/in_altvoltageY_rms_raw
 KernelVersion:	6.18