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]
Date:   Thu, 22 Apr 2021 04:10:25 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Maxim Schwalm <maxim.schwalm@...il.com>,
        Svyatoslav Ryhel <clamor95@...il.com>,
        linux-iio <linux-iio@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] iio: gyro: mpu3050: Fix reported temperature value

22.04.2021 03:38, Linus Walleij пишет:
> On Thu, Apr 22, 2021 at 1:49 AM Dmitry Osipenko <digetx@...il.com> wrote:
> 
>> The raw temperature value is a signed 16bit integer. The sign casting
>> is missed in the code, which results in a wrong temperature reported by
>> userspace tools, fix it.
>>
>> Cc: stable@...r.kernel.org
>> Link: https://www.cdiweb.com/datasheets/invensense/mpu-3000a.pdf
>> Tested-by: Maxim Schwalm <maxim.schwalm@...il.com> # Asus TF700T
>> Tested-by: Svyatoslav Ryhel <clamor95@...il.com> # Asus TF201
>> Reported-by: Svyatoslav Ryhel <clamor95@...il.com>
>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
> 
> +/- Andy's comments:
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
> 
> I never thought this driver would have so many users (3 people signed
> testing it!) but I realize it is more widely deployed than I thought.
> 
> I have totally ignored the MPU3050's ability to act as a "sensor hub"
> and talk to accelerometers and magnetometers directly. I always
> thought it would be better to just route the I2C right through it and
> put Linux in direct control, but I realize this was not Invensese's
> intention. I don't know if it can be actually utilized in some generic
> way, all kernels using that have separate hacky drivers for all the
> sub-sensors duplicating the kernel drivers we already have ...

I don't think that MPU3050 could talk to the sensors behind it directly.
It's has "I2C gate" which allows to route the I2C communication to the
chained sensors, which is done in order to reduce noise on the I2C bus
such that only one sensor is active at a time. Those chained sensors are
working good using upstream kernel drivers, the accelerometer is
particularly useful for display autorotation. Modern DEs like Gnome and
KDE are using iio-sensor-proxy library that knows how to work with the
mainline sensor drivers.

Thank you and Andy for the review, I'll prepare v2.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ