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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 30 Jan 2018 14:27:37 -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


On 01/30/2018 02:05 PM, Andy Shevchenko wrote:
> On Tue, Jan 30, 2018 at 8:34 PM, Steven Presser <steve@...ssers.name> wrote:
>> Andy,
>>
>> I apologize for the long response, but there's several issues to address
>> here.
> NP, it it a good explanation why. That's what commit message missed apparently.
Probably my fault anyway - I don't recall discussing with Jeremy exactly 
what chip was inside this little Frankenstein.
>
>> 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.
> Please do, I would really be on the safe side here.
Will do.  My digital notes indicate I worked from what was exposed back 
to what chip matched.  If you can give me through Friday evening, I'll 
crack it and do a visual verification.  (Alas, I'm traveling and won't 
be back to it until then).
>
>> 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.
> This makes a lot of sense.
>
>>   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.
> Bad, bad Lenovo. (DMI strings might help here)
What particular DMI strings would be helpful?  All of them?
>
>> 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.
> No need, the root cause is lack of description in the commit message.
>
> Nevertheless, the approach chosen I don't like. It looks like an ugly hack.
>
> What we can do here is:
> - do not contaminate core part with I2C/SPI/etc
> - do not create another driver via board_info, we already in *the same* driver,
> so, the better approach here AFAICS is to add DMI quirk into i2c-core-acpi
>
>
>
>> Steve
>>
>> [1]
>> https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMA250E-DS004-06.pdf



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