Re: [PATCH 1/1] iio: light: isl29018: support cover-glass gain compensation via DT

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Multiple 32-bit integer overflows in `isl29018_read_lux()` lead to incorrect, wrapped, or negative sensor readings.
--

commit 190a907a89f0aeaf207c50457cf9f79e29e324c2
Author: Herman van Hazendonk <github.com@herrie.org>

iio: light: isl29018: support cover-glass gain compensation via DT

This commit introduces a new device-tree property, "isil,cover-comp-gain",
to seed the in_illuminance0_calibscale value at probe time. This allows
hardware platforms to compensate for optical loss from tinted or coated
cover glass over the sensor. The default value is set to 1 to maintain
compatibility with existing systems.

[ ... ]

> diff --git a/drivers/iio/light/isl29018.c b/drivers/iio/light/isl29018.c
> --- a/drivers/iio/light/isl29018.c
> +++ b/drivers/iio/light/isl29018.c
> @@ -727,7 +727,16 @@ static int isl29018_probe(struct i2c_client *client)
>  	mutex_init(&chip->lock);
>  
>  	chip->type = dev_id;
> +	/*
> +	 * Allow boards that mount the sensor behind tinted / coated cover
> +	 * glass to bake the optical-loss compensation into firmware via
> +	 * "isil,cover-comp-gain", following the precedent set by
> +	 * tsl2563.c. The value seeds calibscale (default 1), so userspace
> +	 * can still retune through in_illuminance0_calibscale.
> +	 */
>  	chip->calibscale = 1;
> +	device_property_read_u32(&client->dev, "isil,cover-comp-gain",
> +				 &chip->calibscale);

[Severity: High]
This is a pre-existing issue, but does setting a large calibscale here
exacerbate an integer overflow in isl29018_read_lux()?

In isl29018_read_lux(), the calculations for data_x_range and the final *lux
value rely on 32-bit unsigned arithmetic:

drivers/iio/light/isl29018.c:isl29018_read_lux() {
    ...
	data_x_range = lux_data * chip->scale.scale +
		       lux_data * chip->scale.uscale / 1000000;
	*lux = data_x_range * chip->calibscale +
	       data_x_range * chip->ucalibscale / 1000000;
    ...
}

The multiplication lux_data * chip->scale.uscale can reach ~64 billion
(e.g., 65535 * 976,562), overflowing UINT_MAX (4,294,967,295) and losing
precision.

Furthermore, the subsequent multiplication data_x_range * chip->calibscale
easily exceeds 2 billion if calibscale is seeded to a high value (like 100,
as the commit message suggests). Because the result is stored in the signed
int *lux, exceeding 2 billion causes the value to wrap, resulting in massive
negative lux values being reported to userspace.

Could these 32-bit multiplications be updated to use 64-bit math or scaled
down to prevent overflow in bright light environments?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604054723.2983181-2-github.com@herrie.org?part=1