On Tue, Jan 30, 2018 at 8:34 PM, Steven Presser <steve@xxxxxxxxxxxxx> wrote:Probably my fault anyway - I don't recall discussing with Jeremy exactly what chip was inside this little Frankenstein.
Andy,NP, it it a good explanation why. That's what commit message missed apparently.
I apologize for the long response, but there's several issues to address
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).
First, I believe the "bmc150" in the subject line is in some way a misnomer.Please do, I would really be on the safe side here.
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.
What particular DMI strings would be helpful? All of them?
Second, we're seeing a difference between what's in the data sheet andThis makes a lot of sense.
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 aBad, bad Lenovo. (DMI strings might help here)
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 myNo need, the root cause is lack of description in the commit message.
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.
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature