Re: [PATCH v3 2/2] iio: light: add AS7343 multi-spectral sensor driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Device remains continuously active and measuring until the first sysfs read due to missing idle trigger in probe.
- [Low] Missing <linux/delay.h> include for msleep().
--

commit 11270e0cc23d66ee1d725cbe09a1342ed010ace3
Author: Chang Yu <marcus.yu.56@gmail.com>

iio: light: add AS7343 multi-spectral sensor driver

This commit adds a new driver for the AMS AS7343 14-channel multi-spectral
sensor. It exposes 12 spectral channels via the IIO sysfs interface and
supports basic suspend/resume power management functionality.

> diff --git a/drivers/iio/light/as7343.c b/drivers/iio/light/as7343.c
> new file mode 100644
> index 0000000000000..8982cd6ec5d88
> --- /dev/null
> +++ b/drivers/iio/light/as7343.c
[ ... ]
> +static int as7343_read_raw(struct iio_dev *indio_dev,
> +			   struct iio_chan_spec const *chan, int *val,
> +			   int *val2, long mask)
> +{
[ ... ]
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW: {
> +		/* Wait until integration time passes for all 3 cycles. */
> +		msleep(160);

[Severity: Low]
Does this msleep() call require including <linux/delay.h>?

Building the driver on architectures where the header is not implicitly
included by other headers might result in a build failure.

[ ... ]
> +static int as7343_probe(struct i2c_client *client)
> +{
[ ... ]
> +	ret = devm_pm_runtime_enable(dev);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to enable PM runtime\n");
> +
> +	/* Start measurements */
> +	ret = regmap_set_bits(data->regmap, AS7343_ENABLE, AS7343_ENABLE_SP_EN);
> +	if (ret)
> +		return ret;
> +
> +	return devm_iio_device_register(dev, indio_dev);
> +}

[Severity: Medium]
Does this probe function leave the device continuously active and measuring
until the first sysfs read?

The code marks the device as active and starts measurements, but does not
appear to drop its usage count or trigger an idle state. The power management
core may consider it active with a zero usage count, but never automatically
suspend it.

This seems to leave the sensor taking measurements and drawing power
indefinitely, only resolving when the first sysfs read invokes
pm_runtime_resume_and_get() followed by pm_runtime_put().

Could pm_runtime_idle() be called before probe finishes, or should the device
be transitioned to suspend instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910063813.56419-1-marcus.yu.56@gmail.com?part=2