On 01/30/2018 02:05 PM, Andy Shevchenko wrote:
Probably my fault anyway - I don't recall discussing with Jeremy exactly what chip was inside this little Frankenstein.On Tue, Jan 30, 2018 at 8:34 PM, Steven Presser <steve@xxxxxxxxxxxxx> 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.
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. 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.
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-acpiSteve [1] https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMA250E-DS004-06.pdf
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
