linux-kernel - Re: BUG: iio: mpu3050: Wrong temperature scale

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]

Date:   Wed, 21 Apr 2021 00:26:28 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Svyatoslav Ryhel <clamor95@...il.com>,
        Nathan Royer <nroyer@...ensense.com>,
        Jean-Baptiste Maneyrol <jmaneyrol@...ensense.com>
Subject: Re: BUG: iio: mpu3050: Wrong temperature scale

19.04.2021 13:07, Linus Walleij пишет:
> On Mon, Apr 19, 2021 at 8:06 AM Dmitry Osipenko <digetx@...il.com> wrote:
> 
>> The driver uses
>> (x+23000)/280 formula for the conversion of raw temperature value, which
>> gives 82C for x=0, thus apparently formula is wrong because x=50000
>> should give us ~25C.
>>
>> I tried to search for the datasheet with the formula, but couldn't find it.
> 
> There is no public datasheet. I have never seen a non-public datasheet
> either.
> 
> As the initial submission of the driver says:
> 
> "This driver is based on information from the rough input driver
>  in drivers/input/misc/mpu3050.c and the scratch misc driver
>  posted by Nathan Royer in 2011. Some years have passed but this
>  is finally a fully-fledged driver for this gyroscope. It was
>  developed and tested on the Qualcomm APQ8060 Dragonboard."
> 
> Nathans submission:
> https://lore.kernel.org/lkml/1309486707-1658-1-git-send-email-nroyer@invensense.com/
> (you find the threads at the bottom)
> 
> This submission came from inside Invensense so it is the closest
> authoritative source we have.
> 
>> Linus, will you be able to check whether the formula used by the driver
>> is correct? Thanks in advance.
> 
> Sadly the code is the documentation when it comes to Invensense stuff,
> I am CC:ing Nathans Invensense address in the vain hope he is still
> working there and could help, also CC to Jean-Baptiste who was
> there last year and maybe can help out.
> 
> I don't anymore remember exactly how I found this equation,
> but it wasn't from any datasheet. I vaguely remember browsing
> through some Android userspace sensor code.
> 
> What I tend to do is dig around in old mobile
> phone Android trees, and there you sometimes find this information
> in different GPL code drops. I bet I got it from browsing some of
> those.
> 
> Here is an example (Tegra):
> https://android.googlesource.com/kernel/tegra/+/dba2740d025c8e7e7e3c61d84a4f964d2c1c0ac9/drivers/misc/inv_mpu
> 
> Worst case what one *can* do is to calibrate the scale, like put
> the device in a controlled environment of some two reasonably
> far apart temperatures and measure, assuming it is at least
> linear. Some professionals use controlled environment
> chambers for this. But I hope there is a better way.

Linus, thank you very much for the answer! I found a non-kernel example
which uses a similar equation [1], but in a different form. The main
difference is that the Arduino code interprets a raw temperature value
as a signed integer, while upstream assumes it's unsigned.

[1]
https://github.com/blaisejarrett/Arduino-Lib.MPU3050/blob/master/MPU3050lib.cpp#L111


Still, even if assume that the raw temperature is a signed s16 value, it
gives us ~35C in a result, which should be off by ~10C.

Certainly a manual calibration is an option, but we will try to wait for
the answer from Nathans and Jean-Baptiste before going that route.