Re: [PATCH v10 07/11] iio: adc: hx711: pass trailing pulse count into hx711_read

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The driver calls `gpiod_set_value()` inside a `local_irq_save()` block in `hx711_cycle()`. If the provided GPIO is on a sleeping bus (like an I2C or SPI expander), this will attempt to sleep with interrupts disabled, leading to a system panic or deadlock.
--

commit 06c110d4ea7407a2f984ef3a29933a8a8f62d351
Author: Piyush Patle <piyushpatle228@gmail.com>
Subject: iio: adc: hx711: pass trailing pulse count into hx711_read

This commit modifies hx711_read() to accept the number of trailing pulses
as a parameter. It moves the selection of trailing pulses from the read
function to its callers, preparing the driver for variant-specific code
without needing a separate read path.

> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> index 062d6860da7d6..a18ac3ecf2c59 100644
> --- a/drivers/iio/adc/hx711.c
> +++ b/drivers/iio/adc/hx711.c
> @@ -155,7 +155,7 @@ static int hx711_cycle(struct hx711_data *hx711_data)
>  	return gpiod_get_value(hx711_data->gpiod_dout);
>  }
>  
> -static int hx711_read(struct hx711_data *hx711_data)
> +static int hx711_read(struct hx711_data *hx711_data, int trailing_pulses)
>  {

[ ... ]

> -	for (i = 0; i < hx711_get_gain_to_pulse(hx711_data->gain_set); i++)
> +	for (i = 0; i < trailing_pulses; i++)
>  		hx711_cycle(hx711_data);

[Severity: High]
This is a pre-existing issue, but does this driver ensure the requested
GPIOs are not on a sleeping bus?

Looking at hx711_cycle(), the driver disables interrupts via
local_irq_save() to meet strict timing constraints, and then calls
gpiod_set_value() inside that atomic block:

hx711_cycle()
    local_irq_save(flags);
    gpiod_set_value(hx711_data->gpiod_pd_sck, 1);

If a user wires the HX711 to a GPIO controller on a sleeping bus (like
an I2C or SPI expander), calling gpiod_set_value() will trigger the
underlying controller's set operation, which might attempt to acquire a
mutex or wait for I/O completion.

Could this attempt to sleep inside an atomic context and trigger a
"scheduling while atomic" panic or deadlock?

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