linux-kernel - Re: [PATCH] iio: cros_ec: Fix gyro scale calculation

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: <7d36153b-65e9-6702-e72f-caaeeb032077@collabora.com>
Date:   Fri, 22 Feb 2019 11:24:24 +0100
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Gwendal Grignou <gwendal@...omium.org>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Guenter Roeck <groeck@...omium.org>,
        Benson Leung <bleung@...omium.org>,
        Lars-Peter Clausen <lars@...afoo.de>, kernel@...labora.com,
        Hartmut Knaack <knaack.h@....de>
Subject: Re: [PATCH] iio: cros_ec: Fix gyro scale calculation

Hi Jonathan,

On 20/2/19 17:01, Jonathan Cameron wrote:
> On Wed, 20 Feb 2019 16:03:00 +0100
> Enric Balletbo i Serra <enric.balletbo@...labora.com> wrote:
> 
>> From: Gwendal Grignou <gwendal@...omium.org>
>>
>> Calculation was copied from IIO_DEGREE_TO_RAD, but offset added to avoid
>> rounding error is wrong. It should be only half of the divider.
>>
>> Fixes: c14dca07a31d ("iio: cros_ec_sensors: add ChromeOS EC Contiguous Sensors driver")
>> Signed-off-by: Gwendal Grignou <gwendal@...omium.org>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>
> 
> This one is kind of interesting. See below.
> 
>> ---
>>
>>  drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
>> index 89cb0066a6e0..600942af9f9c 100644
>> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
>> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
>> @@ -103,7 +103,7 @@ static int cros_ec_sensors_read(struct iio_dev *indio_dev,
>>  			 * Do not use IIO_DEGREE_TO_RAD to avoid precision
>>  			 * loss. Round to the nearest integer.
>>  			 */
>> -			*val = div_s64(val64 * 314159 + 9000000ULL, 1000);
>> +			*val = div_s64(val64 * 314159 + 500ULL, 1000);
> That is only one of two divides going on.  Firstly we divide by 1000 here,
> then we provide it in fractional form which means that the actual value you get
> from sysfs etc is 
> val/val2.  It's this one we are protecting against rounding error on I guess.
> Now this is even less obviously because it's not 18000 either, but 
> 18000 * 2^CROS_EC_SENSOR_BITS.
> 
> Which ultimately means neither answer is correct. Hmm.
> Not totally sure what the right answer actually is..
> 

If I understood well the Gwendal's patch the problem that we're trying to solve
is that current calculation is not closer from the float calculation.

For 1000dps, the result should be:

    (1000 * pi ) / 180 >> 15 ~= 0.000532632218

But with current calculation we get

    $ cat scale
    0.000547890

With that patch (modifying the offset to avoid the rounding error) we get a
closer result

    $ cat scale
    0.000532631

So, what we're trying to do is have val/val2 closer to the real value. Makes
this sense to you or I'm missing something? I can improve the commit message if
it's not clear.

-- Enric

> Jonathan
> 
>>  			*val2 = 18000 << (CROS_EC_SENSOR_BITS - 1);
>>  			ret = IIO_VAL_FRACTIONAL;
>>  			break;
>