Re: [PATCH v4 6/8] iio: adc: add ti-ads112c14 driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The polling loop for the single-shot conversion exits immediately because it checks the active-low `~DRDY` bit incorrectly.
- [Medium] Uninitialized kernel stack memory is leaked to user space due to unhandled short reads from `i2c_smbus_read_i2c_block_data()`.
--

--- Patch [6]: [PATCH v4 6/8] iio: adc: add ti-ads112c14 driver ---
commit 399c7e84626ba31d27ae803b5704a50020c2c856
Author: David Lechner (TI) <dlechner@baylibre.com>
Date:   Tue Jul 14 23:21:28 2026 +0000

    iio: adc: add ti-ads112c14 driver
    
    Add a new driver for the TI ADS112C14/ADS122C14 ADC chips.
    
    This first step is adding a very basic driver that only supports power
    on/reset and reading the system monitor channels.

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

[ ... ]

> @@ -267,14 +267,14 @@ static int ads112c14_single_conversion(struct ads112c14_data *data,
>  		if (ret)
>  			return ret;
>  	}
>  
>  	ret = regmap_write(data->regmap, ADS112C14_REG_CONVERSION_CTRL,
>  			   ADS112C14_CONVERSION_CTRL_START);
>  	if (ret)
>  		return ret;
>  
>  	ret = regmap_read_poll_timeout(data->regmap,
>  				       ADS112C14_REG_STATUS_MSB, reg_val,
>  				       FIELD_GET(ADS112C14_STATUS_MSB_DRDY, reg_val),
>  				       1 * USEC_PER_MSEC, 100 * USEC_PER_MSEC);

[Severity: High]
Does this polling loop exit prematurely when the device is still busy?

The data ready bit (~DRDY) is active-low (0 = ready, 1 = busy).

FIELD_GET(ADS112C14_STATUS_MSB_DRDY, reg_val) evaluates to true immediately
while the device is busy, causing the loop to exit before the conversion
has actually completed.

>  	if (ret)
>  		return ret;
>  
>  	return i2c_smbus_read_i2c_block_data(client, ADS112C14_CMD_RDATA,
>  					     BITS_TO_BYTES(data->chip_info->resolution_bits),
>  					     buf);
>  }
>  
>  static int ads112c14_read_raw(struct iio_dev *indio_dev,
>  			      struct iio_chan_spec const *chan,
>  			      int *val, int *val2, long mask)
>  {

[ ... ]

> @@ -304,18 +304,18 @@ static int ads112c14_read_raw(struct iio_dev *indio_dev,
>  		fsr_bits = data->chip_info->resolution_bits - 1;
>  	}
>  
>  	switch (mask) {
>  	case IIO_CHAN_INFO_RAW: {
>  		u8 buf[3];
>  		int ret;
>  
>  		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
>  		if (IIO_DEV_ACQUIRE_FAILED(claim))
>  			return -EBUSY;
>  
>  		ret = ads112c14_single_conversion(data, chan, buf);
>  		if (ret < 0)
>  			return ret;

[Severity: Medium]
Can this leak uninitialized stack memory to userspace on a short read?

i2c_smbus_read_i2c_block_data() can return a positive short byte count if
the I2C transfer completes partially.

Since this code only checks if (ret < 0), a short read will proceed to decode
the uninitialized bytes in buf:

drivers/iio/adc/ti-ads112c14.c:ads112c14_read_raw() {
    ...
    switch (data->chip_info->resolution_bits) {
    case 16:
        *val = get_unaligned_be16(buf);
    ...
}

Could this check verify that ret exactly matches the requested number of
bytes instead of just checking for negative errors?

>  
>  		switch (data->chip_info->resolution_bits) {
>  		case 16:
>  			*val = get_unaligned_be16(buf);
>  			break;
>  		case 24:
>  			*val = get_unaligned_be24(buf);
>  			break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-iio-adc-ti-ads122c14-v4-0-25f8e3084485@baylibre.com?part=6