Re: [PATCH 2/2] iio: light: tcs3472: Add TCS3400 support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] iio: light: tcs3472: data race when setting CALIBSCALE
- [Medium] iio: missing iio_device_claim_direct in write_raw
--

commit 71b07faf78f3ba40068aeff966e06035eb4c1e4f
Author: HuskerMinion <mocker-mug-unwoven@duck.com>
iio: light: tcs3472: Add TCS3400 support

This patch adds support for the AMS TCS3400 ambient light sensor to the
existing TCS3472 driver. It introduces a chip_info structure to handle
device-specific differences such as register auto-increment behavior,
gain steps, and interrupt clearing.

> diff --git a/drivers/iio/light/tcs3472.c b/drivers/iio/light/tcs3472.c
> index b392943e51c8b..fbd9a1b34ea17 100644
> --- a/drivers/iio/light/tcs3472.c
> +++ b/drivers/iio/light/tcs3472.c
[ ... ]
> @@ -396,8 +447,8 @@ static int tcs3472_write_raw(struct iio_dev *indio_dev,
>  	case IIO_CHAN_INFO_CALIBSCALE:
>  		if (val2 != 0)
>  			return -EINVAL;
> -		for (i = 0; i < ARRAY_SIZE(tcs3472_agains); i++) {
> -			if (val == tcs3472_agains[i]) {
> +		for (i = 0; i < ARRAY_SIZE(data->chip->agains); i++) {
> +			if (val == data->chip->agains[i]) {
>  				data->control &= ~TCS3472_CONTROL_AGAIN_MASK;
>  				data->control |= i;

[Severity: Medium]
Does this code introduce a data race when setting CALIBSCALE?

The shared data->control state is modified and written to the I2C device
locklessly here in tcs3472_write_raw(). If there are concurrent sysfs writes
to in_illuminance_calibscale, could they cause a read-modify-write data race
that corrupts the state and inadvertently applies an incorrect gain setting
(e.g., combining bits to apply a 64x gain) to the hardware?

[Severity: Medium]
Should tcs3472_write_raw() be calling iio_device_claim_direct() to serialize
sysfs writes against active buffered captures?

If userspace modifies device configuration parameters, such as CALIBSCALE or
SAMP_FREQ, while a triggered buffer capture is active, could it silently
alter the scale or timing of the captured samples, resulting in corrupted or
desynchronized data for the userspace consumer?

>  				return i2c_smbus_write_byte_data(
>  					data->client, TCS3472_CONTROL,
>  					data->control);
>  			}
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-tcs3400-v1-0-3d79d2a7f449@duck.com?part=2