linux-kernel - Re: [PATCH v5 2/3] iio: accel: Support Kionix/ROHM KX022A accelerometer

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20231019121226.000078fe@Huawei.com>
Date:   Thu, 19 Oct 2023 12:12:26 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Matti Vaittinen <mazziesaccount@...il.com>
CC:     Jonathan Cameron <jic23@...nel.org>,
        Jagath Jog J <jagathjog1996@...il.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Dmitry Rokosov <DDRokosov@...rdevices.ru>,
        Cosmin Tanislav <demonsingur@...il.com>,
        <linux-iio@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Mehdi Djait <mehdi.djait.k@...il.com>
Subject: Re: [PATCH v5 2/3] iio: accel: Support Kionix/ROHM KX022A
 accelerometer

On Thu, 19 Oct 2023 08:53:31 +0300
Matti Vaittinen <mazziesaccount@...il.com> wrote:

> On 10/18/23 22:34, Jonathan Cameron wrote:
> > On Wed, 18 Oct 2023 01:37:12 +0530
> > Jagath Jog J <jagathjog1996@...il.com> wrote:  
> 
> Hi Jagath - and thanks!
> 
> >> Hi Matti,
> >>
> >> On Mon, Oct 24, 2022 at 6:10 PM Matti Vaittinen
> >> <mazziesaccount@...il.com> wrote:  
> >>>
> >>> KX022A is a 3-axis accelerometer from ROHM/Kionix. The sensor features
> >>> include variable ODRs, I2C and SPI control, FIFO/LIFO with watermark IRQ,
> >>> tap/motion detection, wake-up & back-to-sleep events, four acceleration
> >>> ranges (2, 4, 8 and 16g), and probably some other cool features.  
> >>
> >> This is a nice driver, and I found it very helpful as a reference.
> >> One question regarding scale please see below.
> >>  
> >>> + * range is typically +-2G/4G/8G/16G, distributed over the amount of bits.
> >>> + * The scale table can be calculated using
> >>> + *     (range / 2^bits) * g = (range / 2^bits) * 9.80665 m/s^2
> >>> + *     => KX022A uses 16 bit (HiRes mode - assume the low 8 bits are zeroed
> >>> + *     in low-power mode(?) )
> >>> + *     => +/-2G  => 4 / 2^16 * 9,80665 * 10^6 (to scale to micro)
> >>> + *     => +/-2G  - 598.550415
> >>> + *        +/-4G  - 1197.10083
> >>> + *        +/-8G  - 2394.20166
> >>> + *        +/-16G - 4788.40332
> >>> + */
> >>> +static const int kx022a_scale_table[][2] = {
> >>> +       { 598, 550415 },
> >>> +       { 1197, 100830 },
> >>> +       { 2394, 201660 },
> >>> +       { 4788, 403320 },
> >>> +};  
> >>
> >> Given that the integer part is non-zero, and
> >> IIO_VAL_INT_PLUS_MICRO is returned for read_scale,
> >> As raw value will never be fractional how does this
> >> correspond to a reading of 9.8 m/s² for the Z-axis?  
> > 
> > Definitely suspicious as should be in m/s^2 for an acceleration and
> > it should be
> > 
> > 9.8*16/2^bits
> > 
> > So I think these are out by a factor of 10^6  
> I think you are right. Looks like I misinterpreted the meaning of 
> IIO_VAL_INT_PLUS_MICRO when I took my first tour in the IIO with this 
> driver. The comment above the scale table does support that assumption 
> ... 10^6 would match such a brainfart. (This is my first thought. I will 
> take better look at this later today and see if I can come up with a fix 
> if no-one else has sent a patch already).
> 
> I CC'd Mehdi who has also been working on this driver.
> 
> Regarding the KX022A - I am not aware of upstream users of this IC 
> (yet). May be you're the first lucky one :) Hence, I am tempted to just 
> fixing the driver - but it's Jonathan who will take the splatters when 
> **** hits the fan - so it's his call to decide whether we can still fix 
> this. _If_ there are users who have adapted to this buggy scale (users I 
> am not aware of) then fix will break their apps. Mehdi, do you know any 
> users of this upstream driver?

It's an ABI usage bug so allowed fix even if it has impacts...
Hopefully those aren't too painful for people to fix :(

So we fix and get it into stable asap.


> 
> I will ping the HQ guy who has contacts to those who might be using the 
> driver in a downstream repository and ask him to inform potential users.
> 
> It'd be very nice to get this fixed.
> 
> Sorry and thanks!
> 
> Yours,
> 	-- Matti
>