On 01/30/2018 02:05 PM, Andy Shevchenko wrote: > On Tue, Jan 30, 2018 at 8:34 PM, Steven Presser 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