[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0627cf17-c902-02a7-40d7-2f4b6fb4754e@redhat.com>
Date: Sat, 8 May 2021 11:47:20 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
Guenter Roeck <linux@...ck-us.net>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Jonathan Cameron <jic23@...nel.org>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2] iio: bme680_i2c: Remove ACPI support
Hi again,
On 5/8/21 11:41 AM, Hans de Goede wrote:
> Hi,
>
> On 5/8/21 9:48 AM, Andy Shevchenko wrote:
>>
>>
>> On Saturday, May 8, 2021, Guenter Roeck <linux@...ck-us.net <mailto:linux@...ck-us.net>> wrote:
>>
>> On Fri, May 07, 2021 at 10:31:54AM +0100, Jonathan Cameron wrote:
>> > On Wed, 5 May 2021 20:43:32 -0700
>> > Guenter Roeck <linux@...ck-us.net <mailto:linux@...ck-us.net>> wrote:
>> >
>> > > With CONFIG_ACPI=n and -Werror, 0-day reports:
>> > >
>> > > drivers/iio/chemical/bme680_i2c.c:46:36: error:
>> > > 'bme680_acpi_match' defined but not used
>> > >
>> > > Apparently BME0680 is not a valid ACPI ID. Remove it and with it
>> > > ACPI support from the bme680_i2c driver.
>> > >
>> > > Reported-by: kernel test robot <lkp@...el.com <mailto:lkp@...el.com>>
>> > > Cc: Andy Shevchenko <andy.shevchenko@...il.com <mailto:andy.shevchenko@...il.com>>
>> > > Cc: Hans de Goede <hdegoede@...hat.com <mailto:hdegoede@...hat.com>>
>> > > Signed-off-by: Guenter Roeck <linux@...ck-us.net <mailto:linux@...ck-us.net>>
>> >
>> > A note for these is that I'll change the patch titles when applying.
>> > We aren't removing ACPI support from the drivers, we are simply
>> > removing the ACPI ID table entries. For most of these PRP0001 magic
>> > will work just fine with the OF table. That's probably the
>> > right way for small companies etc to use these in products without
>> > having to jump through the hoops of getting an ACPI ID.
>> >
>>
>> Below is what Coccinelle tells me about ACPI IDs in drivers/iio.
>> The script (tries) to do a prefix match of all ACPI IDs it finds against
>> the PNP and ACPI ID databases from https://uefi.org/PNP_ACPI_Registry <https://uefi.org/PNP_ACPI_Registry>.
>>
>> Andy, Hans, does that look about right ?
>>
>>
>>
>> The result looks nice for the first step!
>>
>>
>>
>> Next question is what to do with the mismatches and with false
>> negatives such as:
>>
>> drivers/iio/accel/stk8312.c
>> STK8312: match (prefix) against STK (SANTAK CORP.)
>> drivers/iio/light/isl29018.c
>> ISL29018: match (prefix) against ISL (Isolation Systems)
>> ISL29023: match (prefix) against ISL (Isolation Systems)
>> ISL29035: match (prefix) against ISL (Isolation Systems)
>> drivers/iio/gyro/bmg160_i2c.c
>>
>>
>>
>>
>> BMI055B: match (prefix) against BMI (Benson Medical Instruments Company)
>> BMI088B: match (prefix) against BMI (Benson Medical Instruments Company)
>>
>>
>> These I think the real ones from the existing devices.
>
> No that is wrong, these are Bosch sensors, so the BOSC0200 entry for
> the companion accelerometer is the only entry using the official company
> prefix. At least "BMA" ("BMA250E") and "BSG" ("BSG1160", "BSG2150") are
> also know to be used as prefixes for ACPI HIDs which are in active
> use for Bosch sensors :|
>
> And Benson Medical Instruments Company has nothing to do with these
> sensors :|
p.s.
And there also is the Lenovo Yoga 300 11IBR convertible laptop which has
2 Bosch accelerometers, 1 in the display and 1 in the base/keyboard
described in a single ACPI "Device (ACC1) {}" ACPI fwnode (so not 1 fwnode
per sensor), and this single node to describe 2 separate I2C connected
ICs has a ACPI HID of "DUAL250E" (*), how is that for sticking to the HID
naming spec ?
I really have the feeling that the naming spec is not worth much more
then the paper it is written on, it is really really easy to find a ton
of examples out in the field which don't adhere to it.
Regards,
Hans
*) I recently got my hands on one of these and I still need to add support
for this to the kernel
Powered by blists - more mailing lists