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] [day] [month] [year] [list]

Message-ID: <bdda37a2-5151-409e-9df1-c0cbfc8a5093@gmail.com>
Date: Tue, 14 Jan 2025 16:26:16 +0200
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Javier Carrasco <javier.carrasco.cruz@...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 14/01/2025 15:02, Javier Carrasco wrote:
> 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):

Yes. X denoted the value by which the count needs to be multiplied to 
get the lux (when total gain "in the terms of gts" is x1. I think in 
this particular case the "gain is x1" is a bit confusing as it appears 
this really means the hardware gain is 1/8, right?). Anyways, lux/count 
it is, so in short - yes. :)

> 
> /* 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;

Yes. This is what I was thinking of.

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

gah. I didn't consider representing the micro portion. Staring this 
makes me feel dizzy :) Well, it looks correct, and I guess the precision 
is not lost by the division(?) But yes, you did perfectly get what I was 
after!

Jonathan, do you think I am just guiding Javier to make a mess? :)

If not, then this might be the way to go.

Yours,
	-- Matti