linux-kernel - Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

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] [thread-next>] [day] [month] [year] [list]
Message-ID: <f42f6acc-cb30-e36d-0c98-42b7e3d40457@pressers.name>
Date:   Tue, 30 Jan 2018 13:34:59 -0500
From:   Steven Presser <steve@...ssers.name>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Hartmut Knaack <knaack.h@....de>,
        Jeremy Cline <jeremy@...ine.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Jonathan Cameron <jic23@...23.retrosnub.co.uk>,
        Lars Kellogg-Stedman <lars@...bit.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Wolfram Sang <wsa@...-dreams.de>, linux-iio@...r.kernel.org
Subject: Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for
 BOSC0200

Andy,

I apologize for the long response, but there's several issues to address 
here.

First, I believe the "bmc150" in the subject line is in some way a 
misnomer.  You'd have to ask Jeremy for more details on what he intended 
it to refer to.  However, I believe the device in question is actually 
the bma250[1], which does not have a magnetometer component.  I'm 
unfortunately away from my notes, but I can check later if you need me 
to verify the exact chip.

Second, we're seeing a difference between what's in the data sheet and 
what's exposed in the wild via ACPI.  I own the laptop that started the 
process of building this patch and I did the original ACPI-tables 
investigation.

The device in question (BOSC0200) appears in the Lenovo Yoga 11e (and 
possibly other laptops - this happens to be the one I own). These 
laptops have a 360-degree hinge between the screen and the keyboard, 
letting them convert into tablets, if the user desires. The 11e 
implements this mode-switching by placing an accelerometer in each of 
the screen and keyboard, then doing math with the resulting vectors to 
figure out the angle between the two.  For whatever reason, Lenovo chose 
to expose these two (physically separate) accelerometers via a single 
ACPI device which presents two i2c devices at sequential addresses.

As part of my original investigation of the Yoga 11e, I wrote a 
proof-of-concept of pulling accelerometer data from the two devices 
exposed under the BOSC0200 ID and using that to calculate the position 
of the screen relative to the keyboard.  So based on my empirical 
experience, I can tell you the BOSC0200 device ID can expose two 
accelerometers at sequential addresses in the wild.

I don't understand why Lenovo has reused the BOSC0200 ACPI device ID for 
a device that is fundamentally different from the base device. The ID 
doesn't belong to them and we're (apparently) now stuck in this 
situation where this ACPI device ID could represent two different device 
layouts.

Finally - Andy, I apologize if I came across as challenging you in my 
initial mail.  I was trying to strike a balance between 
brevity/respecting your time and asking a question.  Evidently I struck 
the wrong balance and should have given you more background on why I was 
doubting what you saw.  This is my fault and you have my sincerest 
apologies for any offense I have caused.

Steve

[1] 
https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMA250E-DS004-06.pdf


On 01/30/2018 12:38 PM, Andy Shevchenko wrote:
> On Tue, Jan 30, 2018 at 7:25 PM, Steve Presser <steve@...ssers.name> wrote:
>> Andy,
>>
>> Where did the assertion the second device is a magnetometer come from? Just
>> the data sheet?
> Yep. See chapter 8.2. Isn't enough proof? Or you believe in two
> accelerometers with off-by-one conflicting address on a cheap laptop
> with left unused two magnetometers on the same time?
>
> And we have a driver for magnetometer separately.
>
> So, it looks like we need to move ACPI ID to a new "kinda I2C mfd" IIO
> driver under drivers/iio/imu/bmc150_i2c.c
>
>
>> Steve
>>
>>
>> On Tue, Jan 30, 2018, 12:05 PM Andy Shevchenko <andy.shevchenko@...il.com>
>> wrote:
>>> On Tue, Jan 30, 2018 at 6:40 PM, Andy Shevchenko
>>> <andy.shevchenko@...il.com> wrote:
>>>> On Tue, Jan 30, 2018 at 6:01 PM, Jonathan Cameron
>>>> <Jonathan.Cameron@...wei.com> wrote:
>>>>> On Mon, 29 Jan 2018 16:07:02 +0200
>>>>> Andy Shevchenko <andy.shevchenko@...il.com> wrote:
>>>>>>> But that would take much longer.  Feel free to propose it and a
>>>>>>> patch
>>>>>>> removing the ifdef fun if you like!
>>>>>> Where can I see the patch?
>>>>> Doh. I clearly forgot to push out.  Should be able to push to
>>>>> iio.git on kernel.org later.
>>>> Thanks, I can see it now.
>>>>
>>>> This patch almost wrong. Not by functionality it brings, but by style.
>>> Oy vey, the second device is *not* accelerometer, it is a magnetometer
>>> [1].
>>>
>>> [1]: https://www.mouser.com/ds/2/783/BST-BMC150-DS000-04-786477.pdf
>>>
>>>> I'll send soon a series of fixes to the driver (compile tested only)
>>>> to provide my view on the matters.
>>>>
>>>> P.S. In the future (I have some kind of deja vu I have told this
>>>> already to someone), please, Cc one or more of Rafael, Mika and/or me
>>>> for ACPI matters.
>>> --
>>> With Best Regards,
>>> Andy Shevchenko
>
>



Download attachment "smime.p7s" of type "application/pkcs7-signature" (4370 bytes)