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:   Sun, 4 Feb 2018 12:58:11 -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

All,

I had a chance to sit back down with the machine.  I didn't take it all 
the way apart - there are pieces that I'm afraid of breaking without 
directions on how to properly disassemble them.

However, I did recover an exact chip ID - the chips in use are BMA255s 
[1].  Rather than take the machine apart (and because the chips are 
2mmx2mm), I queried the chip over SMBus.  On page 50 of the below 
document, you can see that register 0x00 is a read-only chip ID.  This 
chipID is unique per Bosch product.  So, using SMBus, I asked the chip 
for it's chip ID (0xFA, in this case) and then searched likely products 
until I found the matching chipID.

Does this suffice to settle which chips are in use?  If not, I can 
finish taking the machine apart, I'd just prefer to avoid the risk of 
breaking something.

As soon as I finish screwing everything back together, I'll grab the 
other software IDs asked for and build the branch referenced elsewhere.

Steve


[1] 
https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMA255-DS004-05_published.pdf


On 01/30/2018 03:12 PM, Andy Shevchenko wrote:
> On Tue, Jan 30, 2018 at 9:27 PM, Steven Presser <steve@...ssers.name> wrote:
>> 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:
>>>> 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).
> We are in the merge window anyway, so, no hurry.
>
> I'm looking right now in the clean solution. Looks promising.
>
>>> Bad, bad Lenovo. (DMI strings might help here)
>> What particular DMI strings would be helpful?  All of them?
> Let's do this way. Create a bug on kernel bugzilla, attach output of
>
> % acpidump -o tables.dat # tables.dat file
> % grep -H 15 /sys/bus/acpi/devices/*/status
> % dmidecode
>
> and share the number here. I will take it.
>



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