Re: [PATCH v2 1/4] iio: adc: ade9000: introduce chip_info structure

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Hardware interrupts are requested before the device is powered up and reset.
--

--- Patch [1]: [PATCH v2 1/4] iio: adc: ade9000: introduce chip_info structure ---
commit 00acfaee941c3f163617be410fa26e35179f3ffc
Author: Antoniu Miclaus <antoniu.miclaus@analog.com>

iio: adc: ade9000: introduce chip_info structure

The driver currently hardcodes the device name and the full-scale ADC codes
used to derive the IIO scale attributes. In preparation for supporting
additional parts of the ADE9000 family, move these part-specific values
into a new struct ade9000_chip_info and retrieve it via
spi_get_device_match_data() at probe time.

> diff --git a/drivers/iio/adc/ade9000.c b/drivers/iio/adc/ade9000.c
> index c6c3ea953feae..030bb9109ab6a 100644
> --- a/drivers/iio/adc/ade9000.c
> +++ b/drivers/iio/adc/ade9000.c
[ ... ]
> @@ -1726,7 +1757,7 @@ static int ade9000_probe(struct spi_device *spi)
>  	if (ret)
>  		return ret;
>  
> -	indio_dev->name = "ade9000";
> +	indio_dev->name = st->info->name;
>  	indio_dev->info = &ade9000_info;
>  	indio_dev->modes = INDIO_DIRECT_MODE;
>  	indio_dev->setup_ops = &ade9000_buffer_ops;
> @@ -1736,8 +1767,8 @@ static int ade9000_probe(struct spi_device *spi)

[Severity: High]
This is a pre-existing issue, but could we look at the interrupt
initialization ordering here?

Hardware interrupts are requested via devm_request_threaded_irq() without
IRQF_NO_AUTOEN earlier in ade9000_probe(), before this vdd regulator is
enabled.

If an interrupt line is active (for example, pulled low by the unpowered
chip or floating) at boot time, wouldn't the unmasked handler like
ade9000_irq1_thread() run immediately?

If that happens, the handler might attempt SPI register accesses while the
chip is still unpowered. Could this lead to SPI bus errors, controller
timeouts, or reading garbage data?

If that garbage data happens to have the ADE9000_ST1_RSTDONE_BIT set, could
it prematurely complete the reset process and lead to driver initialization
failure?

>  		return dev_err_probe(&spi->dev, ret,
>  				     "Failed to get and enable vdd regulator\n");
>  
> -	indio_dev->channels = ade9000_channels;
> -	indio_dev->num_channels = ARRAY_SIZE(ade9000_channels);
> +	indio_dev->channels = st->info->channels;
> +	indio_dev->num_channels = st->info->num_channels;
>  
>  	ret = devm_iio_kfifo_buffer_setup(dev, indio_dev,
>  					  &ade9000_buffer_ops);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731082951.1228-1-antoniu.miclaus@analog.com?part=1