Re: [PATCH v9 10/11] iio: adc: hx711: pass iio_chan_spec to hx711_reset_read

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Triggering the buffer with the soft timestamp channel enabled causes a bogus physical hardware read, leading to severe latency spikes and sample rate degradation.
--

commit ca51c74e19ecc54987d0605c8007f8dcdc337783
Author: Piyush Patle <piyushpatle228@gmail.com>

iio: adc: hx711: pass iio_chan_spec to hx711_reset_read

Change hx711_reset_read() to accept the channel descriptor directly and
update its callers accordingly.

> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> index d7987c70beec2..8ec4dee1f451e 100644
> --- a/drivers/iio/adc/hx711.c
> +++ b/drivers/iio/adc/hx711.c
[ ... ]
> @@ -391,8 +406,8 @@ static irqreturn_t hx711_trigger(int irq, void *p)
>  	memset(&hx711_data->buffer, 0, sizeof(hx711_data->buffer));
>  
>  	iio_for_each_active_channel(indio_dev, i) {
> -		hx711_data->buffer.channel[j] = hx711_reset_read(hx711_data,
> -					indio_dev->channels[i].channel);
> +		hx711_data->buffer.channel[j] =
> +			hx711_reset_read(hx711_data, &indio_dev->channels[i]);
>  		j++;
>  	}

Does this loop cause a bogus physical hardware read when the soft timestamp
channel is enabled?

Because iio_for_each_active_channel() iterates over all bits set in the
active_scan_mask, it includes the soft timestamp channel, passing it
directly into hx711_reset_read().

For the timestamp channel, chan->channel is -1. When passed down to
hx711_set_gain_for_channel(), any non-zero channel is treated as the
secondary physical channel (Channel B), forcing a hardware channel switch.

Since switching channels on the HX711 requires a dummy read and up to a 400ms
settling time handled in hx711_wait_for_ready(), toggling between Channel A
and the Timestamp channel on every trigger could introduce an ~800ms
blocking delay per sample.

Is it necessary to explicitly skip the timestamp channel during the hardware
read loop here, perhaps by checking chan->type != IIO_TIMESTAMP?

A related concern originally flagged an out-of-bounds array write to
buffer.channel[2] here, leading to a UBSAN panic. While that specific memory
safety issue is fixed later in the series by commit "iio: adc: hx711: add
support for HX710B" which safely bounds the buffer using
IIO_DECLARE_BUFFER_WITH_TS(), the underlying logic error of triggering a bogus
hardware read for the timestamp channel appears to remain unfixed.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518220228.63322-1-piyushpatle228@gmail.com?part=10