linux-kernel - Re: [PATCH 2/2] iio: light: veml6030: fix scale to conform to ABI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D71TEJCQD9XK.5FNF9SJLFJ94@gmail.com>
Date: Tue, 14 Jan 2025 14:02:50 +0100
From: "Javier Carrasco" <javier.carrasco.cruz@...il.com>
To: "Matti Vaittinen" <mazziesaccount@...il.com>
Cc: "Jonathan Cameron" <jic23@...nel.org>, "Lars-Peter Clausen"
 <lars@...afoo.de>, "Rishi Gupta" <gupt21@...il.com>,
 <linux-iio@...r.kernel.org>, <linux-kernel@...r.kernel.org>, "Jonathan
 Cameron" <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH 2/2] iio: light: veml6030: fix scale to conform to ABI

On Tue Jan 14, 2025 at 7:43 AM CET, Matti Vaittinen wrote:
...
> > I will give you a simple example, so you can tell me where my reasoning
> > fails:
> >
> > raw = 100 counts
> > scale = 2.1504 lux/count (when IT=25ms and GAIN=1/8)
> > processed = 215.04 lux (raw * scale, ABI compliant for IIO_LIGHT)
>
> Your reasoning does not fail. But, the scale = 1 / (N * total_gain),
> right? (N here depends on how we choose the scale/gain values) Here,
> the total_gain means the effect of both the hardware_gain and the
> integration time.
>
> Hence,
> processed =  X * (raw * scale)
>
> => processed = X * (raw * (1 / (N * total_gain))
> => processed = X * raw / (N * total_gain);
>
> Hence I thought you might be able to get rid of this 64bit division by
> using the total_gain from the iio_gts_get_total_gain() instead of
> using the scale. Or, am I missing something?
>

I am not sure by X you mean the maximum resolution, but if that is the
case, the following would work (pseudo-code):

/* Maximum resolution (2.1504 lux/count) * 10000 */
#define VEML6030_MAX_RES 21504

total_gain = iio_gts_get_total_gain();
processed_int = raw * VEML6030_MAX_RES / total_gain / 10000;
processed_micro = ((raw * VEML6030_MAX_RES / total_gain) % 10000) * 100;

return INT_PLUS_MICRO;

Is that what you meant? For my previous example (100 counts, IT=25ms,
GAIN=1/8 → total_gain = 1 * 1):
processed_int = 100 * 21504 / 1 / 10000; (215)
processed_micro = 100 * 21504 / 1 % 10000 * 100; (40000)
The expected value was 215.04 lux

For IT=800ms, GAIN=2 → total_gain = 32 * 16 = 512
processed_int = 100 * 21504 / 512 / 10000; (0)
processed_micro = 100 * 21504 / 512 % 10000 * 100; (420000)
That is also the expected value: 0.42 lux

Given that the driver supports multiple devices with different maximum
scales (currently 2), it will have to be added to the chip data.

If we are now on the same page, I will implement it like that to drop
64-bit divisions.

Thanks again!

Best regards,
Javier Carrasco