Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

[Hans de Goede <hdegoede@redhat.com>]

H5,

On 01/30/2018 06:38 PM, Andy Shevchenko wrote:
> On Tue, Jan 30, 2018 at 7:25 PM, Steve Presser <steve@pressers.name> wrote:
>> Andy,
>>
>> Where did the assertion the second device is a magnetometer come from? Just
>> the data sheet?
> 
> Yep. See chapter 8.2. Isn't enough proof? Or you believe in two
> accelerometers with off-by-one conflicting address on a cheap laptop
> with left unused two magnetometers on the same time?

This is not a cheap device, this has been seen on a Lenovo Yoga 11e,
the yoga's typically have an accelerometer in both the base and the display
and have no use for a magnetometer. Not saying that you're wrong,
but my expectations are different. Anyways we need to find someone to
test this, I asked Jeremy to write a patch for this because we had
Yoga 11e user (Lars Kellogg-Stedman in the CC) asking question and
Jeremy did ask that Lars to test.

It looks like we will need to reach out to Lars and get some testing done
to figure this out one way or the other.

Lars if you're reading this can you please reply. If you've trouble
building your own kernels for testing, would you be willing to install
Fedora so that we can provide test kernels for you?

Regards,

Hans

p.s.

For reference here is the relevant DSDT blurb from the Yoga 11e:

             Device (ACC)
             {
                 Name (_ADR, Zero)  // _ADR: Address
                 Name (_HID, "BOSC0200")  // _HID: Hardware ID
                 Name (_CID, "BOSC0200")  // _CID: Compatible ID
                 Name (_DDN, "Accelerometer")  // _DDN: DOS Device Name
                 Name (_UID, One)  // _UID: Unique ID
                 Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                 {
                     Name (RBUF, ResourceTemplate ()
                     {
                         I2cSerialBusV2 (0x0019, ControllerInitiated, 0x00061A80,
                             AddressingMode7Bit, "\\_SB.PCI0.I2C3",
                             0x00, ResourceConsumer, , Exclusive,
                             )
                         I2cSerialBusV2 (0x0018, ControllerInitiated, 0x00061A80,
                             AddressingMode7Bit, "\\_SB.PCI0.I2C3",
                             0x00, ResourceConsumer, , Exclusive,
                             )
                     })
                     Return (RBUF) /* \_SB_.PCI0.I2C3.ACC_._CRS.RBUF */
                 }





> 
> And we have a driver for magnetometer separately.
> 
> So, it looks like we need to move ACPI ID to a new "kinda I2C mfd" IIO
> driver under drivers/iio/imu/bmc150_i2c.c
> 
> 
>> Steve
>>
>>
>> On Tue, Jan 30, 2018, 12:05 PM Andy Shevchenko <andy.shevchenko@gmail.com>
>> wrote:
>>>
>>> On Tue, Jan 30, 2018 at 6:40 PM, Andy Shevchenko
>>> <andy.shevchenko@gmail.com> wrote:
>>>> On Tue, Jan 30, 2018 at 6:01 PM, Jonathan Cameron
>>>> <Jonathan.Cameron@huawei.com> wrote:
>>>>> On Mon, 29 Jan 2018 16:07:02 +0200
>>>>> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>>>
>>>>>>> But that would take much longer.  Feel free to propose it and a
>>>>>>> patch
>>>>>>> removing the ifdef fun if you like!
>>>>
>>>>>> Where can I see the patch?
>>>>
>>>>> Doh. I clearly forgot to push out.  Should be able to push to
>>>>> iio.git on kernel.org later.
>>>>
>>>> Thanks, I can see it now.
>>>>
>>>> This patch almost wrong. Not by functionality it brings, but by style.
>>>
>>> Oy vey, the second device is *not* accelerometer, it is a magnetometer
>>> [1].
>>>
>>> [1]: https://www.mouser.com/ds/2/783/BST-BMC150-DS000-04-786477.pdf
>>>
>>>> I'll send soon a series of fixes to the driver (compile tested only)
>>>> to provide my view on the matters.
>>>>
>>>> P.S. In the future (I have some kind of deja vu I have told this
>>>> already to someone), please, Cc one or more of Rafael, Mika and/or me
>>>> for ACPI matters.
>>>
>>> --
>>> With Best Regards,
>>> Andy Shevchenko
> 
> 
>