Re: [PATCH 2/3] iio: adc: ltc2497: add LTC2499 internal temperature channel

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Potential division by zero kernel panic if regulator_get_voltage() returns 0 when reading the temperature offset.
- [High] Stack-allocated buffer passed to i2c_master_send() is not DMA-safe.
- [High] The 2-byte command inadvertently configures 50Hz-only rejection, breaking 60Hz rejection and causing a hardcoded 150ms conversion delay to time out.
--

--- Patch [2]: [PATCH 2/3] iio: adc: ltc2497: add LTC2499 internal temperature channel ---
commit 20bcf3fffe757278d79cfcae060ca4eaa317443e
Author: Andrei Stancovici <[email protected]>

iio: adc: ltc2497: add LTC2499 internal temperature channel

This commit adds support for the LTC2499's internal PTAT temperature sensor.
It exposes the sensor as an IIO_TEMP channel, utilizing a second I2C
configuration byte to enable temperature conversions and calculate the exact
temperature using the reference voltage.

> diff --git a/drivers/iio/adc/ltc2497-core.c b/drivers/iio/adc/ltc2497-core.c
> index 2dc5c70442694..4ca7271ca0071 100644
> --- a/drivers/iio/adc/ltc2497-core.c
> +++ b/drivers/iio/adc/ltc2497-core.c
[ ... ]
> @@ -95,10 +96,43 @@ static int ltc2497core_read_raw(struct iio_dev *indio_dev,
[ ... ]
> +	case IIO_CHAN_INFO_OFFSET:
> +		switch (chan->type) {
> +		case IIO_TEMP:
> +			ret = regulator_get_voltage(ddata->ref);
> +			if (ret < 0)
> +				return ret;
> +			/*
> +			 * 0 °C == 273.15 K must map to raw + offset such that
> +			 * (raw + offset) * scale == 0 m°C, i.e.
> +			 *   offset = -273150 / scale
> +			 *          = -273150 * 3140000 / Vref_uV
> +			 * Computed in 64-bit to avoid overflow.
> +			 */
> +			*val = div_s64(-273150LL * 3140000, ret);

[Severity: High]
If regulator_get_voltage() returns exactly 0 (for instance, via a dummy
regulator or misconfigured devicetree), will this trigger a divide-by-zero
panic? 

The check above handles negative error codes but appears to miss a
check for zero before the division.

> +			return IIO_VAL_INT;
> +		default:
> +			return -EINVAL;
> +		}
>  
>  	default:
>  		return -EINVAL;
[ ... ]
> diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c
> index eb9d521e86e54..4e0f5c7671f41 100644
> --- a/drivers/iio/adc/ltc2497.c
> +++ b/drivers/iio/adc/ltc2497.c
[ ... ]
> @@ -85,6 +85,36 @@ static int ltc2497_result_and_measure(struct ltc2497core_driverdata *ddata,
[ ... ]
> +	if (ddata->chip_info->has_temp) {
> +		u8 cmd[2];

[Severity: High]
Is this stack-allocated buffer safe to use with i2c_master_send()? 

If the underlying I2C adapter driver uses DMA for transfers, it might attempt
to map this stack memory. With CONFIG_VMAP_STACK enabled, stack memory is
allocated in vmalloc space and is not DMA-capable, which could lead to
memory corruption or mapping errors. 

Should this use a DMA-safe buffer instead?

> +
> +		if (address == LTC2497_TEMP_ADDR) {
> +			cmd[0] = LTC2497_ENABLE | LTC2497_CONFIG_DEFAULT;
> +			cmd[1] = LTC2499_EN2 | LTC2499_IM;
> +		} else {
> +			cmd[0] = LTC2497_ENABLE | address;
> +			cmd[1] = LTC2499_EN2;
> +		}

[Severity: High]
By omitting bits 5 (FA) and 4 (FB) in the second command byte, these
bits default to 0. According to the LTC2499 datasheet, does this inadvertently
configure the part for 50Hz-only noise rejection?

If so, 50Hz-only mode increases the maximum conversion time to 160.3ms.
Since the driver hardcodes the wait time to 150ms via
LTC2497_CONVERSION_TIME_MS, could this result in the I2C read transaction
being NACKed by the busy ADC, causing persistent read failures? 

Would explicitly setting the FA bit to maintain the 149.9ms simultaneous
50/60Hz rejection mode prevent this timeout?

> +
> +		ret = i2c_master_send(st->client, cmd, sizeof(cmd));
> +		if (ret < 0) {
> +			dev_err(&st->client->dev, "i2c transfer failed: %pe\n",
> +				ERR_PTR(ret));
> +			return ret;
> +		}
> +		return 0;
> +	}

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