[PATCH v3 0/2] iio: adc: Add support for Texas Instruments ADS112C04

[PATCH v3 0/2] iio: adc: Add support for Texas Instruments ADS112C04

[Kyle Hsieh]

This patch series introduces support for the Texas Instruments ADS112C04
Analog-to-Digital Converters.

The ADS112C04 (16-bit) is precision, low-power, delta-sigma ADCs with
an I2C interface. They feature a flexible input multiplexer supporting
single-ended and differential measurements, a programmable gain amplifier,
and an internal voltage reference.

Note: While this chip shares similarities with the ADS112C14 (currently 
being upstreamed by David Lechner), the register maps and feature sets 
are sufficiently different to warrant a separate driver. However, the
DT bindings and channel parsing logic have been aligned with the
ADS112C14 conventions.

This initial submission provides a minimal feature set (single-shot 
conversions and basic DRDY interrupt) covering current use cases.

Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
---
Changes in v3:
- dt-bindings: iio: adc: ti,ads112c04:
  - Resolved dt_binding_check errors by removing redundant $ref for
    standard unit suffixes and fixing YAML array syntax.
  - Added full hardware capability descriptions (excitation-channels,
    excitation-current-nanoamp, burn-out-current-nanoamp,
    reference-sources) as suggested by David Lechner.
  - Restricted the reg maximum to 11 and updated the regex to
    ^channel@[0-9a-b]$ to accurately reflect the 12 possible MUX
    combinations.

- iio: adc: ti-ads112c04:
  - Transitioned all I2C read/write wrappers to use SMBus APIs
    (i2c_smbus_read_byte_data, i2c_smbus_read_word_data, etc.) to
    gracefully handle I2C errors, NACKs, and Repeated Starts, addressing
    feedback from Joshua Crofts and Jonathan Cameron.
  - Added forward compatibility checks in probe() and parse_channels()
    using dev_err_probe() to return -EOPNOTSUPP for unimplemented DT
    properties.
  - Reverted devm_request_irq() flags to 0 to let the driver inherit the
    trigger type strictly from the DT, per Jonathan Cameron's advice.
  - Reduced the data wait timeout to 100ms, reflecting the chip's slowest
    data rate of 20 SPS.
  - Fixed #include alphabetical sorting, grouped <linux/iio/*> headers,
    and added missing headers.
  - Fixed variable declaration ordering (reverse xmas tree) and updated
    variable naming to vref_mV (SI unit exception).
  - Optimized GPIO reset logic using GPIOD_OUT_HIGH.
- Link to v2: https://lore.kernel.org/r/20260731-ti-ads112c04-driver-v2-0-aab0168c3c01@gmail.com

Changes in v2:
- Replaced `vref-supply` with `refp-supply` and `refn-supply` to accurately reflect hardware.
- Refactored the driver to dynamically parse channel configurations and routing from DT child nodes.
- Modernized the driver using kernel macros.
- Handled endianness elegantly.
- Added hardware reset fallback logic.
- Inherited IRQ trigger type from device tree instead of hardcoding.
- Fixed a bug where the MUX software cache could desync from hardware if the I2C write failed.
- Added strict return value checking for all I2C writes during probe.
- Updated the `i2c_device_id` array to use C99 named initializers.
- Link to v1: https://lore.kernel.org/r/20260728-ti-ads112c04-driver-v1-0-475efe4e2b78@gmail.com

---
Kyle Hsieh (2):
      dt-bindings: iio: adc: ti,ads112c04: Add binding for ADS112C04
      iio: adc: ti-ads112c04: Add support for TI ADS112C04

 .../devicetree/bindings/iio/adc/ti,ads112c04.yaml  | 146 +++++++
 drivers/iio/adc/Kconfig                            |  10 +
 drivers/iio/adc/Makefile                           |   1 +
 drivers/iio/adc/ti-ads112c04.c                     | 423 +++++++++++++++++++++
 4 files changed, 580 insertions(+)
---
base-commit: 4539944e515183668109bdf4d0c3d7d228383d88
change-id: 20260724-ti-ads112c04-driver-be7e89047834

Best regards,
-- 
Kyle Hsieh <kylehsieh1995@gmail.com>

[PATCH v3 1/2] dt-bindings: iio: adc: ti,ads112c04: Add binding for ADS112C04

[Kyle Hsieh]

Add device tree binding documentation for Texas Instruments ADS112C04
I2C Analog-to-Digital Converters.

These devices provide 4-channel, 16-bit delta-sigma ADCs with an I2C
interface, programmable gain amplifier (PGA), and data-ready (DRDY)
interrupt output.

The binding uses child nodes to dynamically define the connected
single-ended or differential channels.

Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
---
 .../devicetree/bindings/iio/adc/ti,ads112c04.yaml  | 146 +++++++++++++++++++++
 1 file changed, 146 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c04.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c04.yaml
new file mode 100644
index 000000000000..ff079bb5b3dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c04.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,ads112c04.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ADS112C04 ADC
+
+maintainers:
+  - Kyle Hsieh <kylehsieh1995@gmail.com>
+
+description:
+  The ADS112C04 (16-bit) are precision analog-to-digital converters (ADCs)
+  with an I2C interface. They feature a flexible input multiplexer, a
+  low-noise programmable gain amplifier (PGA), two programmable excitation
+  current sources, a voltage reference, and a precision temperature sensor.
+
+properties:
+  compatible:
+    enum:
+      - ti,ads112c04
+
+  reg:
+    maxItems: 1
+    description: I2C address of the device.
+
+  interrupts:
+    maxItems: 1
+    description: Data ready (DRDY) interrupt output.
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+  reset-gpios:
+    maxItems: 1
+    description: GPIO connected to the RESET pin. Active low.
+
+  avdd-supply: true
+  dvdd-supply: true
+
+  refp-supply: true
+  refn-supply: true
+
+  ti,refp-refn-resistor-ohms:
+    description: Resistance of the external resistor between REFP and REFN.
+
+patternProperties:
+  "^channel@[0-9a-b]$":
+    $ref: adc.yaml
+    unevaluatedProperties: false
+    properties:
+      reg:
+        items:
+          - maximum: 11
+
+      single-channel:
+        maximum: 3
+
+      diff-channels:
+        items:
+          maximum: 3
+
+      excitation-channels:
+        maxItems: 2
+        items:
+          maximum: 3
+
+      excitation-current-nanoamp:
+        maxItems: 2
+        items:
+          enum: [10000, 50000, 100000, 250000, 500000, 1000000, 1500000]
+
+      burn-out-current-nanoamp:
+        items:
+          - enum: [10000]
+
+      reference-sources:
+        items:
+          - enum: [internal-2.048v, external, avdd]
+            default: internal-2.048v
+
+    dependencies:
+      excitation-channels: [ excitation-current-nanoamp ]
+      excitation-current-nanoamp: [ excitation-channels ]
+
+    oneOf:
+      - required: [ single-channel ]
+      - required: [ diff-channels ]
+
+required:
+  - compatible
+  - reg
+  - avdd-supply
+  - dvdd-supply
+
+dependencies:
+  refn-supply: [ refp-supply ]
+
+oneOf:
+  - required:
+      - refp-supply
+  - required:
+      - ti,refp-refn-resistor-ohms
+  - properties:
+      refp-supply: false
+      refn-supply: false
+      ti,refp-refn-resistor-ohms: false
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/gpio/gpio.h>
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        adc@40 {
+            compatible = "ti,ads112c04";
+            reg = <0x40>;
+            interrupt-parent = <&gpio>;
+            interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+
+            reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+            avdd-supply = <&vdd_3v3_reg>;
+            dvdd-supply = <&vdd_3v3_reg>;
+            refp-supply = <&vref_reg>;
+
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            channel@0 {
+                reg = <0>;
+                diff-channels = <0>, <1>;
+            };
+
+            channel@1 {
+                reg = <1>;
+                single-channel = <2>;
+            };
+        };
+    };

-- 
2.34.1

[PATCH v3 2/2] iio: adc: ti-ads112c04: Add support for TI ADS112C04

[Kyle Hsieh]

Add IIO driver support for the Texas Instruments ADS112C04 (16-bit)
delta-sigma ADCs.

The driver implements:
- Single-shot conversions using the IIO raw read interface.
- Dynamic parsing of single-ended and differential channels from
  device tree child nodes.
- Hardware interrupt support via the DRDY pin, falling back to
  software polling if no IRQ is provided.
- Scale calculation based on the internal 2.048V reference.
- Dynamic reference voltage scaling via the regulator subsystem
  (refp-supply/refn-supply), falling back to the internal 2.048V
  reference if not specified.
- Hardware reset fallback using GPIO.

Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
---
 drivers/iio/adc/Kconfig        |  10 +
 drivers/iio/adc/Makefile       |   1 +
 drivers/iio/adc/ti-ads112c04.c | 423 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 434 insertions(+)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 3755a81c1efd..402e841bc083 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1789,6 +1789,16 @@ config TI_ADS1119
          This driver can also be built as a module. If so, the module will be
          called ti-ads1119.
 
+config TI_ADS112C04
+	tristate "Texas Instruments ADS112C04 ADC"
+	depends on I2C
+	help
+	  If you say yes here you get support for Texas Instruments
+	  ADS112C04 (16-bit) I2C analog to digital converters.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called ti-ads112c04.
+
 config TI_ADS124S08
 	tristate "Texas Instruments ADS124S08"
 	depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 707dd708912f..ebf9d4047a5a 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -153,6 +153,7 @@ obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
 obj-$(CONFIG_TI_ADS1018) += ti-ads1018.o
 obj-$(CONFIG_TI_ADS1100) += ti-ads1100.o
 obj-$(CONFIG_TI_ADS1119) += ti-ads1119.o
+obj-$(CONFIG_TI_ADS112C04)	+= ti-ads112c04.o
 obj-$(CONFIG_TI_ADS124S08) += ti-ads124s08.o
 obj-$(CONFIG_TI_ADS1298) += ti-ads1298.o
 obj-$(CONFIG_TI_ADS131E08) += ti-ads131e08.o
diff --git a/drivers/iio/adc/ti-ads112c04.c b/drivers/iio/adc/ti-ads112c04.c
new file mode 100644
index 000000000000..64af866f615d
--- /dev/null
+++ b/drivers/iio/adc/ti-ads112c04.c
@@ -0,0 +1,423 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Texas Instruments ADS112C04 16-bit I2C ADC driver
+ *
+ * Copyright (c) 2026 Kyle Hsieh <kylehsieh1995@gmail.com>
+ *
+ * Datasheet: https://www.ti.com/lit/ds/symlink/ads112c04.pdf
+ * Based on TI Reference Code and standard Linux IIO framework.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/iopoll.h>
+#include <linux/jiffies.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/types.h>
+#include <linux/units.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define ADS112C04_CMD_RESET         0x06
+#define ADS112C04_CMD_START_SYNC    0x08
+#define ADS112C04_CMD_POWERDOWN     0x02
+#define ADS112C04_CMD_RDATA         0x10
+#define ADS112C04_CMD_RREG(reg)     (0x20 | ((reg) << 2))
+#define ADS112C04_CMD_WREG(reg)     (0x40 | ((reg) << 2))
+
+#define ADS112C04_REG_CONFIG0       0x00
+#define ADS112C04_REG_CONFIG1       0x01
+#define ADS112C04_REG_CONFIG2       0x02
+#define ADS112C04_REG_CONFIG3       0x03
+
+#define ADS112C04_CONFIG0_MUX         GENMASK(7, 4)
+#define ADS112C04_CONFIG0_PGA_BYPASS  BIT(0)
+#define ADS112C04_CONFIG2_DRDY        BIT(7)
+
+struct ads112c04_state {
+	struct i2c_client *client;
+	/* Protects concurrent ADC reads and device configuration */
+	struct mutex lock;
+	struct completion completion;
+	struct regulator *vref_reg;
+	int vref_mV;
+	u8 config0;
+	u8 config1;
+};
+
+static int ads112c04_write_cmd(struct i2c_client *client, u8 cmd)
+{
+	int ret;
+
+	ret = i2c_smbus_write_byte(client, cmd);
+
+	return ret < 0 ? ret : 0;
+}
+
+static int ads112c04_read_reg(struct i2c_client *client, u8 reg, u8 *val)
+{
+	int ret;
+
+	ret = i2c_smbus_read_byte_data(client, ADS112C04_CMD_RREG(reg));
+	if (ret < 0)
+		return ret;
+
+	*val = ret;
+
+	return 0;
+}
+
+static int ads112c04_write_reg(struct i2c_client *client, u8 reg, u8 val)
+{
+	int ret;
+
+	ret = i2c_smbus_write_byte_data(client, ADS112C04_CMD_WREG(reg), val);
+
+	return ret < 0 ? ret : 0;
+}
+
+static int ads112c04_wait_for_data(struct ads112c04_state *st)
+{
+	int ret, err;
+	u8 val;
+
+	if (st->client->irq > 0) {
+		/* Timeout is 100ms (slowest data rate is 20 SPS) */
+		ret = wait_for_completion_timeout(&st->completion,
+						  msecs_to_jiffies(100));
+		if (!ret)
+			return -ETIMEDOUT;
+		return 0;
+	}
+
+	err = read_poll_timeout(ads112c04_read_reg, ret,
+				(ret < 0 || (val & ADS112C04_CONFIG2_DRDY)),
+				1000, 100 * USEC_PER_MSEC, false,
+				st->client, ADS112C04_REG_CONFIG2, &val);
+
+	if (ret < 0)
+		return ret;
+
+	return err;
+}
+
+static int ads112c04_read_data(struct ads112c04_state *st, int *val)
+{
+	int ret;
+
+	ret = i2c_smbus_read_word_data(st->client, ADS112C04_CMD_RDATA);
+	if (ret < 0)
+		return ret;
+
+	*val = sign_extend32(be16_to_cpu(ret), 15);
+
+	return 0;
+}
+
+static int ads112c04_get_adc_result(struct ads112c04_state *st,
+				    struct iio_chan_spec const *chan,
+				    int *val)
+{
+	u8 new_config0;
+	int ret;
+
+	new_config0 = st->config0 & ~ADS112C04_CONFIG0_MUX;
+	new_config0 |= FIELD_PREP(ADS112C04_CONFIG0_MUX, chan->address);
+
+	if (st->config0 != new_config0) {
+		ret = ads112c04_write_reg(st->client, ADS112C04_REG_CONFIG0, new_config0);
+		if (ret < 0)
+			return ret;
+		st->config0 = new_config0;
+	}
+
+	reinit_completion(&st->completion);
+
+	ret = ads112c04_write_cmd(st->client, ADS112C04_CMD_START_SYNC);
+	if (ret < 0)
+		return ret;
+
+	ret = ads112c04_wait_for_data(st);
+	if (ret < 0)
+		return ret;
+
+	return ads112c04_read_data(st, val);
+}
+
+static int ads112c04_read_raw(struct iio_dev *indio_dev,
+			      struct iio_chan_spec const *chan,
+			      int *val, int *val2, long mask)
+{
+	struct ads112c04_state *st = iio_priv(indio_dev);
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		mutex_lock(&st->lock);
+		ret = ads112c04_get_adc_result(st, chan, val);
+		mutex_unlock(&st->lock);
+
+		if (ret < 0)
+			return ret;
+		return IIO_VAL_INT;
+
+	case IIO_CHAN_INFO_SCALE:
+		*val = st->vref_mV;
+		*val2 = 15;
+		return IIO_VAL_FRACTIONAL_LOG2;
+
+	default:
+		return -EINVAL;
+	}
+}
+
+static irqreturn_t ads112c04_irq_handler(int irq, void *private)
+{
+	struct iio_dev *indio_dev = private;
+	struct ads112c04_state *st = iio_priv(indio_dev);
+
+	complete(&st->completion);
+
+	return IRQ_HANDLED;
+}
+
+static const struct iio_info ads112c04_info = {
+	.read_raw = ads112c04_read_raw,
+};
+
+static void ads112c04_regulator_disable(void *data)
+{
+	regulator_disable(data);
+}
+
+static int ads112c04_parse_channels(struct iio_dev *indio_dev)
+{
+	struct device *dev = indio_dev->dev.parent;
+	struct iio_chan_spec *channels;
+	u32 num_channels, pair[2];
+	int ret, i = 0;
+
+	num_channels = device_get_named_child_node_count(dev, "channel");
+	if (!num_channels)
+		return -EINVAL;
+
+	channels = devm_kcalloc(dev, num_channels, sizeof(*channels), GFP_KERNEL);
+	if (!channels)
+		return -ENOMEM;
+
+	device_for_each_named_child_node_scoped(dev, child, "channel") {
+		struct iio_chan_spec *spec = &channels[i];
+
+		if (fwnode_property_present(child, "excitation-channels") ||
+		    fwnode_property_present(child, "reference-sources"))
+			return dev_err_probe(dev, -EOPNOTSUPP,
+					     "advanced channel properties are not supported yet\n");
+
+		spec->type = IIO_VOLTAGE;
+		spec->indexed = 1;
+		spec->info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE);
+
+		if (fwnode_property_present(child, "single-channel")) {
+			ret = fwnode_property_read_u32(child, "single-channel", &pair[0]);
+			if (ret)
+				return dev_err_probe(dev, ret,
+						     "failed to read single-channel property\n");
+
+			if (pair[0] > 3)
+				return dev_err_probe(dev, -EINVAL,
+						     "single-channel must be 0-3\n");
+
+			spec->channel = pair[0];
+			spec->address = 0x08 + pair[0];
+		} else if (fwnode_property_present(child, "diff-channels")) {
+			ret = fwnode_property_read_u32_array(child, "diff-channels", pair, 2);
+			if (ret)
+				return dev_err_probe(dev, ret,
+						     "failed to read diff-channels property\n");
+
+			if (pair[0] > 3 || pair[1] > 3)
+				return dev_err_probe(dev, -EINVAL,
+						     "diff-channels must be 0-3\n");
+
+			spec->channel = pair[0];
+			spec->channel2 = pair[1];
+			spec->differential = 1;
+
+			if (pair[0] == 0 && pair[1] == 1)
+				spec->address = 0x00;
+			else if (pair[0] == 0 && pair[1] == 2)
+				spec->address = 0x01;
+			else if (pair[0] == 0 && pair[1] == 3)
+				spec->address = 0x02;
+			else if (pair[0] == 1 && pair[1] == 0)
+				spec->address = 0x03;
+			else if (pair[0] == 1 && pair[1] == 2)
+				spec->address = 0x04;
+			else if (pair[0] == 1 && pair[1] == 3)
+				spec->address = 0x05;
+			else if (pair[0] == 2 && pair[1] == 3)
+				spec->address = 0x06;
+			else if (pair[0] == 3 && pair[1] == 2)
+				spec->address = 0x07;
+			else
+				return dev_err_probe(dev, -EINVAL,
+						     "invalid diff-channels combination\n");
+		} else {
+			return dev_err_probe(dev, -EINVAL,
+					     "channel node must have single-channel or diff-channels\n");
+		}
+		i++;
+	}
+
+	indio_dev->channels = channels;
+	indio_dev->num_channels = i;
+
+	return 0;
+}
+
+static int ads112c04_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct iio_dev *indio_dev;
+	struct ads112c04_state *st;
+	struct gpio_desc *reset_gpio;
+	int ret, refp_mV = 2048;
+
+	indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
+	if (!indio_dev)
+		return -ENOMEM;
+
+	st = iio_priv(indio_dev);
+	st->client = client;
+
+	ret = devm_mutex_init(dev, &st->lock);
+	if (ret)
+		return ret;
+
+	init_completion(&st->completion);
+
+	indio_dev->name = "ads112c04";
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->info = &ads112c04_info;
+
+	/* Forward compatibility checks for unimplemented DT properties */
+	if (device_property_present(dev, "refn-supply") ||
+	    device_property_present(dev, "ti,refp-refn-resistor-ohms"))
+		return dev_err_probe(dev, -EOPNOTSUPP,
+				     "refn-supply and external resistors are not supported yet\n");
+
+	ret = ads112c04_parse_channels(indio_dev);
+	if (ret)
+		return ret;
+
+	ret = devm_regulator_get_enable(dev, "avdd");
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to get avdd regulator\n");
+
+	ret = devm_regulator_get_enable(dev, "dvdd");
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to get dvdd regulator\n");
+
+	st->vref_reg = devm_regulator_get_optional(dev, "refp");
+	if (IS_ERR(st->vref_reg)) {
+		ret = PTR_ERR(st->vref_reg);
+		if (ret == -ENODEV)
+			st->config1 = 0x00;
+		else
+			return ret;
+
+	} else {
+		ret = regulator_enable(st->vref_reg);
+		if (ret)
+			return ret;
+
+		ret = devm_add_action_or_reset(dev, ads112c04_regulator_disable,
+					       st->vref_reg);
+		if (ret)
+			return ret;
+
+		ret = regulator_get_voltage(st->vref_reg);
+		if (ret < 0)
+			return ret;
+
+		refp_mV = ret / (MICRO / MILLI);
+		st->config1 = 0x02;
+	}
+
+	st->vref_mV = refp_mV;
+
+	/* Power-On Reset (POR) delay */
+	fsleep(50000);
+
+	/* Requesting OUT_HIGH asserts the active-low reset pin immediately */
+	reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(reset_gpio))
+		return PTR_ERR(reset_gpio);
+
+	if (reset_gpio) {
+		fsleep(1000);
+		gpiod_set_value_cansleep(reset_gpio, 0);
+	} else {
+		ret = ads112c04_write_cmd(client, ADS112C04_CMD_RESET);
+		if (ret < 0)
+			return ret;
+	}
+
+	fsleep(1000);
+
+	/* Bypass PGA for now to allow full-scale single-ended measurements */
+	st->config0 = ADS112C04_CONFIG0_PGA_BYPASS;
+	ret = ads112c04_write_reg(client, ADS112C04_REG_CONFIG0, st->config0);
+	if (ret)
+		return ret;
+
+	ret = ads112c04_write_reg(client, ADS112C04_REG_CONFIG1, st->config1);
+	if (ret)
+		return ret;
+
+	if (client->irq > 0) {
+		ret = devm_request_irq(dev, client->irq,
+				       ads112c04_irq_handler,
+				       0,
+				       indio_dev->name, indio_dev);
+		if (ret)
+			return ret;
+	}
+
+	return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct i2c_device_id ads112c04_id[] = {
+	{ .name = "ads112c04" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, ads112c04_id);
+
+static const struct of_device_id ads112c04_of_match[] = {
+	{ .compatible = "ti,ads112c04" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, ads112c04_of_match);
+
+static struct i2c_driver ads112c04_driver = {
+	.driver = {
+		.name = "ads112c04",
+		.of_match_table = ads112c04_of_match,
+	},
+	.probe = ads112c04_probe,
+	.id_table = ads112c04_id,
+};
+module_i2c_driver(ads112c04_driver);
+
+MODULE_AUTHOR("Kyle Hsieh <kylehsieh1995@gmail.com>");
+MODULE_DESCRIPTION("Texas Instruments ADS112C04 ADC driver");
+MODULE_LICENSE("GPL");

-- 
2.34.1

Re: [PATCH v3 2/2] iio: adc: ti-ads112c04: Add support for TI ADS112C04

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Incorrect byte swapping for 16-bit I2C word read causes data corruption on Big-Endian architectures.
- [High] The hardirq handler does not mask the interrupt or clear the hardware interrupt source, leading to an infinite interrupt storm if a level-triggered IRQ is used.
- [Medium] The commit message falsely claims support for dynamic reference voltage scaling via `refn-supply`.
- [Medium] A delayed hardware interrupt from a previously timed-out conversion can prematurely complete the wait for a new conversion, causing a read of stale data.
--

--- Patch [2]: [PATCH v3 2/2] iio: adc: ti-ads112c04: Add support for TI ADS112C04 ---
commit bffeb9c9d9c618f12635f25aeb7cd1053228824c
Author: Kyle Hsieh <kylehsieh1995@gmail.com>

iio: adc: ti-ads112c04: Add support for TI ADS112C04

Add IIO driver support for the Texas Instruments ADS112C04 (16-bit)
delta-sigma ADCs.

> - Single-shot conversions using the IIO raw read interface.
> - Dynamic parsing of single-ended and differential channels from
>   device tree child nodes.
> - Hardware interrupt support via the DRDY pin, falling back to
>   software polling if no IRQ is provided.
> - Scale calculation based on the internal 2.048V reference.
> - Dynamic reference voltage scaling via the regulator subsystem
>   (refp-supply/refn-supply), falling back to the internal 2.048V

[Severity: Medium]
The commit message mentions support for refn-supply, but does the code
actually support it?

Looking at ads112c04_probe(), it seems to explicitly reject refn-supply:

	if (device_property_present(dev, "refn-supply") ||
	    device_property_present(dev, "ti,refp-refn-resistor-ohms"))
		return dev_err_probe(dev, -EOPNOTSUPP,
				     "refn-supply and external resistors are not supported yet\n");

Could the commit message be updated to align with the implementation?

>   reference if not specified.
> - Hardware reset fallback using GPIO.
> 
> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>

[ ... ]

> diff --git a/drivers/iio/adc/ti-ads112c04.c b/drivers/iio/adc/ti-ads112c04.c
> new file mode 100644
> index 0000000000000..64af866f615de
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads112c04.c

[ ... ]

> +static int ads112c04_read_data(struct ads112c04_state *st, int *val)
> +{
> +	int ret;
> +
> +	ret = i2c_smbus_read_word_data(st->client, ADS112C04_CMD_RDATA);
> +	if (ret < 0)
> +		return ret;
> +
> +	*val = sign_extend32(be16_to_cpu(ret), 15);

[Severity: High]
Does this byte swapping work correctly on big-endian architectures?

i2c_smbus_read_word_data() returns the word already converted to host
endianness based on SMBus little-endian rules. If the device sends
big-endian data, using be16_to_cpu() on the result of
i2c_smbus_read_word_data() can cause data corruption on big-endian systems.

> +
> +	return 0;
> +}
> +
> +static int ads112c04_get_adc_result(struct ads112c04_state *st,
> +				    struct iio_chan_spec const *chan,
> +				    int *val)
> +{
> +	u8 new_config0;
> +	int ret;
> +
> +	new_config0 = st->config0 & ~ADS112C04_CONFIG0_MUX;
> +	new_config0 |= FIELD_PREP(ADS112C04_CONFIG0_MUX, chan->address);
> +
> +	if (st->config0 != new_config0) {
> +		ret = ads112c04_write_reg(st->client, ADS112C04_REG_CONFIG0, new_config0);
> +		if (ret < 0)
> +			return ret;
> +		st->config0 = new_config0;
> +	}
> +
> +	reinit_completion(&st->completion);
> +
> +	ret = ads112c04_write_cmd(st->client, ADS112C04_CMD_START_SYNC);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ads112c04_wait_for_data(st);

[Severity: Medium]
Is there a race condition here if a previous conversion timed out?

If a previous read timed out but the hardware conversion was still running,
a delayed interrupt from that previous conversion could fire immediately after
reinit_completion() is called. 

Would this cause ads112c04_wait_for_data() to return prematurely and read
stale data?

> +	if (ret < 0)
> +		return ret;
> +
> +	return ads112c04_read_data(st, val);
> +}

[ ... ]

> +static irqreturn_t ads112c04_irq_handler(int irq, void *private)
> +{
> +	struct iio_dev *indio_dev = private;
> +	struct ads112c04_state *st = iio_priv(indio_dev);
> +
> +	complete(&st->completion);
> +
> +	return IRQ_HANDLED;
> +}

[Severity: High]
If the device tree configures this interrupt as level-triggered, could this
handler cause an interrupt storm?

The hardirq handler completes the wait but returns IRQ_HANDLED without
masking the interrupt line or clearing the hardware interrupt source.
Since devm_request_irq() is called in ads112c04_probe() with irqflags=0,
it allows level-triggered configurations from the device tree which would
continually fire until the data is read.

Should this use a threaded interrupt, or mask the IRQ until the data is read?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805-ti-ads112c04-driver-v3-0-49f436829e01@gmail.com?part=2

Re: [PATCH v3 1/2] dt-bindings: iio: adc: ti,ads112c04: Add binding for ADS112C04

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Custom devicetree properties lack required vendor prefixes, missing explicit type definitions, and misuse array validation syntax for scalar values.
--

--- Patch [1]: [PATCH v3 1/2] dt-bindings: iio: adc: ti,ads112c04: Add binding for ADS112C04 ---
commit 3134bea94c0e8c33141972ee2792aabe8a1104e9
Author: Kyle Hsieh <kylehsieh1995@gmail.com>

dt-bindings: iio: adc: ti,ads112c04: Add binding for ADS112C04

Add device tree binding documentation for Texas Instruments ADS112C04
I2C Analog-to-Digital Converters. The binding uses child nodes to
dynamically define the connected single-ended or differential channels.

> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c04.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c04.yaml
> new file mode 100644
> index 0000000000000..ff079bb5b3dd9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c04.yaml

[ ... ]

> +patternProperties:
> +  "^channel@[0-9a-b]$":
> +    $ref: adc.yaml
> +    unevaluatedProperties: false
> +    properties:

[ ... ]

> +      excitation-channels:
> +        maxItems: 2
> +        items:
> +          maximum: 3
> +
> +      excitation-current-nanoamp:
> +        maxItems: 2
> +        items:
> +          enum: [10000, 50000, 100000, 250000, 500000, 1000000, 1500000]
> +
> +      burn-out-current-nanoamp:
> +        items:
> +          - enum: [10000]
> +
> +      reference-sources:
> +        items:
> +          - enum: [internal-2.048v, external, avdd]
> +            default: internal-2.048v

[Severity: Low]
Should these custom device-specific properties (excitation-channels,
excitation-current-nanoamp, burn-out-current-nanoamp, and reference-sources)
have a "ti," vendor prefix to avoid polluting the global namespace?

Also, burn-out-current-nanoamp and reference-sources appear to incorrectly use
YAML array tuple validation syntax instead of simple scalar schemas. Does
reference-sources also need an explicit type definition to prevent
dt_binding_check failures?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805-ti-ads112c04-driver-v3-0-49f436829e01@gmail.com?part=1

Re: [PATCH v3 1/2] dt-bindings: iio: adc: ti,ads112c04: Add binding for ADS112C04

[Rob Herring (Arm)]

On Wed, 05 Aug 2026 13:38:20 +0800, Kyle Hsieh wrote:
> Add device tree binding documentation for Texas Instruments ADS112C04
> I2C Analog-to-Digital Converters.
> 
> These devices provide 4-channel, 16-bit delta-sigma ADCs with an I2C
> interface, programmable gain amplifier (PGA), and data-ready (DRDY)
> interrupt output.
> 
> The binding uses child nodes to dynamically define the connected
> single-ended or differential channels.
> 
> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> ---
>  .../devicetree/bindings/iio/adc/ti,ads112c04.yaml  | 146 +++++++++++++++++++++
>  1 file changed, 146 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/iio/adc/ti,ads112c04.yaml: excitation-channels: missing type definition

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260805-ti-ads112c04-driver-v3-1-49f436829e01@gmail.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH v3 0/2] iio: adc: Add support for Texas Instruments ADS112C04

[Krzysztof Kozlowski]

On 05/08/2026 07:38, Kyle Hsieh wrote:
> This patch series introduces support for the Texas Instruments ADS112C04
> Analog-to-Digital Converters.
> 
> The ADS112C04 (16-bit) is precision, low-power, delta-sigma ADCs with
> an I2C interface. They feature a flexible input multiplexer supporting
> single-ended and differential measurements, a programmable gain amplifier,
> and an internal voltage reference.
> 
> Note: While this chip shares similarities with the ADS112C14 (currently 
> being upstreamed by David Lechner), the register maps and feature sets 
> are sufficiently different to warrant a separate driver. However, the
> DT bindings and channel parsing logic have been aligned with the
> ADS112C14 conventions.
> 
> This initial submission provides a minimal feature set (single-shot 
> conversions and basic DRDY interrupt) covering current use cases.
> 
> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> ---
> Changes in v3:
> - dt-bindings: iio: adc: ti,ads112c04:
>   - Resolved dt_binding_check errors by removing redundant $ref for
>     standard unit suffixes and fixing YAML array syntax.
Yet you still decided NOT TO TEST it before sending.

Best regards,
Krzysztof

Re: [PATCH v3 0/2] iio: adc: Add support for Texas Instruments ADS112C04

[Krzysztof Kozlowski]

On 05/08/2026 08:43, Krzysztof Kozlowski wrote:
> On 05/08/2026 07:38, Kyle Hsieh wrote:
>> This patch series introduces support for the Texas Instruments ADS112C04
>> Analog-to-Digital Converters.
>>
>> The ADS112C04 (16-bit) is precision, low-power, delta-sigma ADCs with
>> an I2C interface. They feature a flexible input multiplexer supporting
>> single-ended and differential measurements, a programmable gain amplifier,
>> and an internal voltage reference.
>>
>> Note: While this chip shares similarities with the ADS112C14 (currently 
>> being upstreamed by David Lechner), the register maps and feature sets 
>> are sufficiently different to warrant a separate driver. However, the
>> DT bindings and channel parsing logic have been aligned with the
>> ADS112C14 conventions.
>>
>> This initial submission provides a minimal feature set (single-shot 
>> conversions and basic DRDY interrupt) covering current use cases.
>>
>> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
>> ---
>> Changes in v3:
>> - dt-bindings: iio: adc: ti,ads112c04:
>>   - Resolved dt_binding_check errors by removing redundant $ref for
>>     standard unit suffixes and fixing YAML array syntax.
> Yet you still decided NOT TO TEST it before sending.

Although after further looking this could be using properties added in
iio tree, thus bot's report about failure.

Well, if that is the case, that's unfortunate because if previous
versions were not tested by you, this one cannot be tested by the bot,
thus I look at this one as also untested.

Best regards,
Krzysztof

Re: [PATCH v3 0/2] iio: adc: Add support for Texas Instruments ADS112C04

[Kyle Hsieh]

On Wed, Aug 5, 2026 at 2:46 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 05/08/2026 08:43, Krzysztof Kozlowski wrote:
> > On 05/08/2026 07:38, Kyle Hsieh wrote:
> >> This patch series introduces support for the Texas Instruments ADS112C04
> >> Analog-to-Digital Converters.
> >>
> >> The ADS112C04 (16-bit) is precision, low-power, delta-sigma ADCs with
> >> an I2C interface. They feature a flexible input multiplexer supporting
> >> single-ended and differential measurements, a programmable gain amplifier,
> >> and an internal voltage reference.
> >>
> >> Note: While this chip shares similarities with the ADS112C14 (currently
> >> being upstreamed by David Lechner), the register maps and feature sets
> >> are sufficiently different to warrant a separate driver. However, the
> >> DT bindings and channel parsing logic have been aligned with the
> >> ADS112C14 conventions.
> >>
> >> This initial submission provides a minimal feature set (single-shot
> >> conversions and basic DRDY interrupt) covering current use cases.
> >>
> >> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> >> ---
> >> Changes in v3:
> >> - dt-bindings: iio: adc: ti,ads112c04:
> >>   - Resolved dt_binding_check errors by removing redundant $ref for
> >>     standard unit suffixes and fixing YAML array syntax.
> > Yet you still decided NOT TO TEST it before sending.
>
> Although after further looking this could be using properties added in
> iio tree, thus bot's report about failure.
>
> Well, if that is the case, that's unfortunate because if previous
> versions were not tested by you, this one cannot be tested by the bot,
> thus I look at this one as also untested.
>
> Best regards,
> Krzysztof
Hi Krzysztof,

Thank you for the review and for following up in your second email.
I would like to clarify that I did indeed test v3 locally with `make
dt_binding_check`
before submitting, and it passed without any warnings on my end.

As you accurately pointed out in your follow-up, the CI bot failure
appears to be
a cross-tree dependency issue.  I apologize for not explicitly noting
this IIO tree
dependency in the cover letter to prevent the bot's confusion.

I have also just updated my local `dtschema` tool directly from the
devicetree-org
GitHub master branch, and running `make dt_binding_check` on my tree still
completes silently with zero errors.

Best regards,
Kyle Hsieh