Re: [PATCH v7 2/3] dt-bindings: iio: adc: ti,ads1100: add support for ADS1110

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Logic error in ads1100_poll_data_ready causes a 7.5 second hang and -ETIMEDOUT on every configuration change
--

--- Patch [2]: [PATCH v7 2/3] dt-bindings: iio: adc: ti,ads1100: add support for ADS1110 ---
commit 020c9fd2512b9b8cdb2cbcd5179eab372c1ab0a5
Author: Jakub Szczudlo <jakubszczudlo40@gmail.com>

dt-bindings: iio: adc: ti,ads1100: add support for ADS1110
    
Register layouts are the same as for ADS1100 but ADS1110 have different
data rates and have internal voltage reference that is always 2.048V.
Also correct order of ads so they will be sorted alphabetically.

> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
> index 970ccab15e1ec..28c5e2dd0ad62 100644
> --- a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml

[ ... ]

[Severity: High]
Does this logic in ads1100_poll_data_ready() cause a timeout on every
configuration change?

In drivers/iio/adc/ti-ads1100.c:ads1100_poll_data_ready():

	ret = readx_poll_timeout(ads1100_new_data_is_ready, data,
				 data_ready, data_ready != 0,
				 wait_time_us, ADS1100_MAX_DRDY_TIMEOUT_US);
	if (ret)
		return ret;

And in ads1100_new_data_is_ready():

	return FIELD_GET(ADS1100_CFG_ST_BSY, buffer[2]);

When the device operates in continuous conversion mode (enforced by
ads1100_runtime_resume before the polling loop), the datasheet specifies
that the ST/BSY bit is always 0.

Since data_ready is always 0, the condition data_ready != 0 evaluates
to false on every iteration. Will the polling loop always block for the
maximum timeout of 7.5 seconds (ADS1100_MAX_DRDY_TIMEOUT_US) and return
-ETIMEDOUT?

This breaks sysfs writes to scale and sampling frequency, severely
impacting driver usability and causing large delays.

Furthermore, even if the device was in single-shot mode, breaking when
data_ready != 0 means it would exit immediately while BUSY (1), instead
of waiting for the conversion to complete (0).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714195528.597753-1-jakubszczudlo40@gmail.com?part=2