Re: [PATCH v5 5/5] iio: adc: versal-sysmon: add oversampling support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The oversampling ratio software caches are initialized to 1 without synchronizing with the actual hardware state during probe.
--

commit 3a6a43bb24f0fd6d80e623d9f51baca549ff9147
Author: Salih Erim <salih.erim@amd.com>

iio: adc: versal-sysmon: add oversampling support

This commit adds support for reading and writing the oversampling ratio
through the IIO oversampling_ratio attribute. The hardware supports averaging
2, 4, 8, or 16 samples, plus a ratio of 1 (no averaging).

> diff --git a/drivers/iio/adc/versal-sysmon-core.c b/drivers/iio/adc/versal-sysmon-core.c
> index 5fbd509089bbd..389a88878115f 100644
> --- a/drivers/iio/adc/versal-sysmon-core.c
> +++ b/drivers/iio/adc/versal-sysmon-core.c

[ ... ]

> @@ -890,6 +1033,8 @@ int sysmon_core_probe(struct device *dev, struct regmap *regmap)
>  
>  	sysmon = iio_priv(indio_dev);
>  	sysmon->regmap = regmap;
> +	sysmon->temp_oversampling = 1;
> +	sysmon->supply_oversampling = 1;

[Severity: Medium]
Is it possible that the hardware was already configured with a different
oversampling ratio by the bootloader (FSBL) or retained state across a warm
reboot? 

The software cache is initialized to 1 here, but no corresponding hardware
synchronization or explicit register initialization occurs before the IIO
device is registered.

If the hardware is actively using averaging (e.g., OSR=16), could the IIO
sysfs interface incorrectly report 1, masking the true hardware configuration?
Would it be safer to either enforce this default state on the hardware or read
the current register values during initialization?

>  
>  	ret = devm_mutex_init(dev, &sysmon->lock);
>  	if (ret)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608183801.1257051-1-salih.erim@amd.com?part=5