Re: [PATCH 1/4] iio: adc: ade9000: fix ADE9000 full-scale RMS and PCF codes

[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 defines `ADE9000_ST1_CROSSING_DEPTH` as 25, which limits the bitmap iteration in the IRQ handler, causing `ADE9000_ST1_DIPC_BIT` (bit index 25) to be silently ignored and never cleared.
--

commit 656c536a824cd57c69e995fb40cb1db36bf309ee
Author: Antoniu Miclaus <antoniu.miclaus@analog.com>

iio: adc: ade9000: fix ADE9000 full-scale RMS and PCF codes

The ADE9000 chip_info uses full-scale codes that do not match the datasheet.
This commit corrects the RMS and PCF full-scale codes to the values from the
ADE9000 datasheet, fixing a 0.3% reading error on the affected channels.

> diff --git a/drivers/iio/adc/ade9000.c b/drivers/iio/adc/ade9000.c
> index fd1362a980523..0f64bfb221da0 100644
> --- a/drivers/iio/adc/ade9000.c
> +++ b/drivers/iio/adc/ade9000.c
> @@ -677,9 +677,9 @@ static const struct ade9000_chip_info ade9000_chip_info = {
>  	.name = "ade9000",
>  	.channels = ade9000_channels,
>  	.num_channels = ARRAY_SIZE(ade9000_channels),
> -	.rms_full_scale_codes = 52866837,
> +	.rms_full_scale_codes = 52702092,
>  	.watt_full_scale_codes = 20694066,
> -	.pcf_full_scale_codes = 74770000,
> +	.pcf_full_scale_codes = 74532013,
>  };

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in
ade9000_irq1_thread() with how it handles the interrupts bitmap:

drivers/iio/adc/ade9000.c:ade9000_irq1_thread() {
...
	bitmap_from_arr32(interrupt_bits, &interrupts, ADE9000_ST1_CROSSING_DEPTH);
	for_each_set_bit_from(bit, interrupt_bits,
			      ADE9000_ST1_CROSSING_DEPTH) {
...
}

Since ADE9000_ST1_CROSSING_DEPTH is defined as 25, will this restrict the loop
bounds to bits 0-24, causing bit 25 (ADE9000_ST1_DIPC_BIT) to be completely
ignored?

If userspace enables the DIPC event and the threshold condition is met, bit 25
would be set in ADE9000_REG_STATUS1 asserting the IRQ. Because the handler
skips bit 25, the interrupt status bit is never cleared. Would this result in
an interrupt storm since the hardware register uses write-1-to-clear logic?

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