[PATCH] iio: light: veml6075: fix UV index reported at half value

[PATCH] iio: light: veml6075: fix UV index reported at half value

[Shardul Deshpande]

veml6075_get_uvi_micro() normalises the UV index for the configured
integration time by dividing the summed, responsivity-weighted UVA/UVB
components by the integration-time scale factor relative to the 50 ms
base case (which is returned undivided).

The supported integration times are 50, 100, 200, 400 and 800 ms, i.e.
the register field index int_index in 0..4 selects (50 << int_index) ms,
so the correct scale factor is 2^int_index == (1 << int_index).

The code instead divides by (2 << int_index) == 2^(int_index + 1), which
is twice the correct value. The reported UV index is therefore half of
the true value for every integration time except 50 ms (handled as a
separate case). As the driver powers up with VEML6075_IT_100_MS, the UV
index is reported at half value out of the box.

Divide by (1 << int_index) instead; this also matches the undivided
50 ms case (1 << 0 == 1).

Fixes: 3b82f43238ae ("iio: light: add VEML6075 UVA and UVB light sensor driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shardul Deshpande <iamsharduld@gmail.com>
---
 drivers/iio/light/veml6075.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/light/veml6075.c b/drivers/iio/light/veml6075.c
index 59187244a..af71df69f 100644
--- a/drivers/iio/light/veml6075.c
+++ b/drivers/iio/light/veml6075.c
@@ -244,7 +244,7 @@ static int veml6075_get_uvi_micro(struct veml6075_data *data, int uva_comp,
 	case VEML6075_IT_200_MS:
 	case VEML6075_IT_400_MS:
 	case VEML6075_IT_800_MS:
-		return (uvia_micro + uvib_micro) / (2 << int_index);
+		return (uvia_micro + uvib_micro) / (1 << int_index);
 	default:
 		return -EINVAL;
 	}
-- 
2.50.1 (Apple Git-155)

Re: [PATCH] iio: light: veml6075: fix UV index reported at half value

[Andy Shevchenko]

On Fri, Jun 26, 2026 at 04:34:00PM +0530, Shardul Deshpande wrote:
> veml6075_get_uvi_micro() normalises the UV index for the configured
> integration time by dividing the summed, responsivity-weighted UVA/UVB
> components by the integration-time scale factor relative to the 50 ms
> base case (which is returned undivided).
> 
> The supported integration times are 50, 100, 200, 400 and 800 ms, i.e.
> the register field index int_index in 0..4 selects (50 << int_index) ms,
> so the correct scale factor is 2^int_index == (1 << int_index).
> 
> The code instead divides by (2 << int_index) == 2^(int_index + 1), which
> is twice the correct value. The reported UV index is therefore half of
> the true value for every integration time except 50 ms (handled as a
> separate case). As the driver powers up with VEML6075_IT_100_MS, the UV
> index is reported at half value out of the box.
> 
> Divide by (1 << int_index) instead; this also matches the undivided
> 50 ms case (1 << 0 == 1).

Can you add more datasheet references to this?
Also I assume you possess such a sensor and you have seen this IRL, correct?


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] iio: light: veml6075: fix UV index reported at half value

[Javier Carrasco]

On Fri Jun 26, 2026 at 1:04 PM CEST, Shardul Deshpande wrote:
> veml6075_get_uvi_micro() normalises the UV index for the configured
> integration time by dividing the summed, responsivity-weighted UVA/UVB
> components by the integration-time scale factor relative to the 50 ms
> base case (which is returned undivided).
>
> The supported integration times are 50, 100, 200, 400 and 800 ms, i.e.
> the register field index int_index in 0..4 selects (50 << int_index) ms,
> so the correct scale factor is 2^int_index == (1 << int_index).
>
> The code instead divides by (2 << int_index) == 2^(int_index + 1), which
> is twice the correct value. The reported UV index is therefore half of
> the true value for every integration time except 50 ms (handled as a
> separate case). As the driver powers up with VEML6075_IT_100_MS, the UV
> index is reported at half value out of the box.
>
> Divide by (1 << int_index) instead; this also matches the undivided
> 50 ms case (1 << 0 == 1).
>
> Fixes: 3b82f43238ae ("iio: light: add VEML6075 UVA and UVB light sensor driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shardul Deshpande <iamsharduld@gmail.com>
> ---
>  drivers/iio/light/veml6075.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/light/veml6075.c b/drivers/iio/light/veml6075.c
> index 59187244a..af71df69f 100644
> --- a/drivers/iio/light/veml6075.c
> +++ b/drivers/iio/light/veml6075.c
> @@ -244,7 +244,7 @@ static int veml6075_get_uvi_micro(struct veml6075_data *data, int uva_comp,
>  	case VEML6075_IT_200_MS:
>  	case VEML6075_IT_400_MS:
>  	case VEML6075_IT_800_MS:
> -		return (uvia_micro + uvib_micro) / (2 << int_index);
> +		return (uvia_micro + uvib_micro) / (1 << int_index);
>  	default:
>  		return -EINVAL;
>  	}

Hi Shardul, thank you for your patch.

I agree with your reasoning, but why don't you get rid of the switch
once the operation is the same for all cases?

Best regards,
Javier

[PATCH v2] iio: light: veml6075: fix UV index reported at half value

[Shardul Deshpande]

veml6075_get_uvi_micro() normalises the UV index for the configured
integration time. The raw UVA/UVB counts scale linearly with the
integration time, so the responsivity-weighted sum must be divided by the
integration-time scale factor relative to the 50 ms base case (which is
returned undivided).

Per the VEML6075 datasheet the UV_IT field selects the integration time
as 50, 100, 200, 400 and 800 ms for field values 0..4, i.e.
(50 << int_index) ms: each step doubles the integration time and hence
the accumulated counts. The correct scale factor relative to the 50 ms
base is therefore 2^int_index == (1 << int_index). (See also the Vishay
application note "Designing the VEML6075 Into an Application" for the
UV-index responsivity calculation that these constants implement.)

The code instead divided by (2 << int_index) == 2^(int_index + 1), i.e.
twice the correct value, so the reported UV index was half of the true
value for every integration time except 50 ms. As the driver powers up
with VEML6075_IT_100_MS, the UV index was reported at half value out of
the box.

Divide by (1 << int_index) instead. int_index is already bounded to 0..4
by veml6075_read_int_time_index(), and (1 << 0) == 1 reproduces the
undivided 50 ms case, so the per-integration-time switch collapses to a
single expression.

Fixes: 3b82f43238ae ("iio: light: add VEML6075 UVA and UVB light sensor driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shardul Deshpande <iamsharduld@gmail.com>
---
Changes in v2:
- Collapse the per-integration-time switch into a single divide now that
  all cases share the same expression -- int_index is bounded to 0..4 by
  veml6075_read_int_time_index() and (1 << 0) reproduces the 50 ms case.
  (Javier Carrasco)
- Add VEML6075 datasheet (UV_IT integration-time table) and application-
  note references for the integration-time scaling in the changelog.

Link to v1:
https://lore.kernel.org/linux-iio/20260626110400.68885-1-iamsharduld@gmail.com/

 drivers/iio/light/veml6075.c | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/light/veml6075.c b/drivers/iio/light/veml6075.c
index 59187244a..d0ec06eeb 100644
--- a/drivers/iio/light/veml6075.c
+++ b/drivers/iio/light/veml6075.c
@@ -237,17 +237,13 @@ static int veml6075_get_uvi_micro(struct veml6075_data *data, int uva_comp,
 	if (int_index < 0)
 		return int_index;
 
-	switch (int_index) {
-	case VEML6075_IT_50_MS:
-		return uvia_micro + uvib_micro;
-	case VEML6075_IT_100_MS:
-	case VEML6075_IT_200_MS:
-	case VEML6075_IT_400_MS:
-	case VEML6075_IT_800_MS:
-		return (uvia_micro + uvib_micro) / (2 << int_index);
-	default:
-		return -EINVAL;
-	}
+	/*
+	 * The raw counts scale linearly with the integration time, which
+	 * doubles at each step (50, 100, 200, 400, 800 ms == 50 << int_index
+	 * ms; int_index is bounded to 0..4 above). Normalise to the 50 ms
+	 * base by dividing by 2^int_index; (1 << 0) == 1 leaves 50 ms as-is.
+	 */
+	return (uvia_micro + uvib_micro) / (1 << int_index);
 }
 
 static int veml6075_read_uvi(struct veml6075_data *data, int *val, int *val2)
-- 
2.50.1 (Apple Git-155)

Re: [PATCH v2] iio: light: veml6075: fix UV index reported at half value

[Javier Carrasco]

On Sat Jun 27, 2026 at 10:53 AM CEST, Shardul Deshpande wrote:
> veml6075_get_uvi_micro() normalises the UV index for the configured
> integration time. The raw UVA/UVB counts scale linearly with the
> integration time, so the responsivity-weighted sum must be divided by the
> integration-time scale factor relative to the 50 ms base case (which is
> returned undivided).
>
> Per the VEML6075 datasheet the UV_IT field selects the integration time
> as 50, 100, 200, 400 and 800 ms for field values 0..4, i.e.
> (50 << int_index) ms: each step doubles the integration time and hence
> the accumulated counts. The correct scale factor relative to the 50 ms
> base is therefore 2^int_index == (1 << int_index). (See also the Vishay
> application note "Designing the VEML6075 Into an Application" for the
> UV-index responsivity calculation that these constants implement.)
>
> The code instead divided by (2 << int_index) == 2^(int_index + 1), i.e.
> twice the correct value, so the reported UV index was half of the true
> value for every integration time except 50 ms. As the driver powers up
> with VEML6075_IT_100_MS, the UV index was reported at half value out of
> the box.
>
> Divide by (1 << int_index) instead. int_index is already bounded to 0..4
> by veml6075_read_int_time_index(), and (1 << 0) == 1 reproduces the
> undivided 50 ms case, so the per-integration-time switch collapses to a
> single expression.
>
> Fixes: 3b82f43238ae ("iio: light: add VEML6075 UVA and UVB light sensor driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shardul Deshpande <iamsharduld@gmail.com>
> ---
> Changes in v2:
> - Collapse the per-integration-time switch into a single divide now that
>   all cases share the same expression -- int_index is bounded to 0..4 by
>   veml6075_read_int_time_index() and (1 << 0) reproduces the 50 ms case.
>   (Javier Carrasco)
> - Add VEML6075 datasheet (UV_IT integration-time table) and application-
>   note references for the integration-time scaling in the changelog.
>
> Link to v1:
> https://lore.kernel.org/linux-iio/20260626110400.68885-1-iamsharduld@gmail.com/
>
>  drivers/iio/light/veml6075.c | 18 +++++++-----------
>  1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/light/veml6075.c b/drivers/iio/light/veml6075.c
> index 59187244a..d0ec06eeb 100644
> --- a/drivers/iio/light/veml6075.c
> +++ b/drivers/iio/light/veml6075.c
> @@ -237,17 +237,13 @@ static int veml6075_get_uvi_micro(struct veml6075_data *data, int uva_comp,
>  	if (int_index < 0)
>  		return int_index;
>
> -	switch (int_index) {
> -	case VEML6075_IT_50_MS:
> -		return uvia_micro + uvib_micro;
> -	case VEML6075_IT_100_MS:
> -	case VEML6075_IT_200_MS:
> -	case VEML6075_IT_400_MS:
> -	case VEML6075_IT_800_MS:
> -		return (uvia_micro + uvib_micro) / (2 << int_index);
> -	default:
> -		return -EINVAL;
> -	}
> +	/*
> +	 * The raw counts scale linearly with the integration time, which
> +	 * doubles at each step (50, 100, 200, 400, 800 ms == 50 << int_index
> +	 * ms; int_index is bounded to 0..4 above). Normalise to the 50 ms
> +	 * base by dividing by 2^int_index; (1 << 0) == 1 leaves 50 ms as-is.
> +	 */
> +	return (uvia_micro + uvib_micro) / (1 << int_index);
>  }
>
>  static int veml6075_read_uvi(struct veml6075_data *data, int *val, int *val2)

Hello Shardul, thank your for your patch.

Please give potential reviewers more time to take a look at your
patches. It's been less than 24 hours between v1 and v2, and that
reduces the amount of people who could review and potentially improve
your patches.

In my opinion, the comment you added is way too verbose, and it includes
information that is well known within the driver like the possible
values for the integration time. Once it is fixed, it is clear that it
is normalised to 50 ms because it is index 0. To be honest, I would even
drop the comment completely.

Best regards,
Javier