Re: [PATCH] iio: bme680_i2c: Make bme680_acpi_match depend on CONFIG_ACPI
From: Guenter Roeck
Date: Wed May 05 2021 - 09:00:33 EST
On Wed, May 05, 2021 at 09:34:38AM +0100, Jonathan Cameron wrote:
> On Wed, 5 May 2021 09:32:35 +0100
> Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote:
> > On Tue, 4 May 2021 11:00:52 -0700
> > Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> > > On 5/4/21 10:44 AM, Andy Shevchenko wrote:
> > > > On Tue, May 4, 2021 at 8:40 PM Guenter Roeck <linux@xxxxxxxxxxxx> 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
> > > >
> > > >> Given the other patch, question of course is if this ACPI ID
> > > >> is real. A Google search suggests that this might not be the case.
> > > >> Should we remove it as well ? STK8312 has the same problem.
> > > >
> > > > For this one definitely removal. Looking into the code it suggests a
> > > > cargo cult taken that time by a few contributors to invent fake ACPI
> > > > IDs while submitting new drivers.
> > > > Feel free to add my tag or if you wish me I'll add it explicitly.
> > > >
> > >
> > > I'll resend and let you add the tag, and send a similar patch
> > > for STK8312. I'll wait until tomorrow, though - I sent a number of
> > > patches today already, and I want to avoid yet another "account
> > > suspended" notice from gmail.
> > If you find some valid ACPI entries that are hitting this problem,
> > I'd prefer we just got rid of the ACPI_PTR() usecases rather than
> > added IFDEF magic.
> > The space wasted by having these is trivial and I'd rather not
> > introduce ifdef around any of these tables.
> > Dropping the ones we are fairly sure are spurious is even better!
> If I get bored I'll just do a scrub of all the instances of this that
> you haven't already cleaned up. It's worth noting that we do
> know some highly suspicious looking entries are out there in the wild.
The ones reported by 0-day are AOS2315, BME0680, and STK8312.
You just accepted a patch for -next which claims that all users of
STK8312 would be ACPI, yet Andy says that STK8312 isn't a valid ACPI ID.
Not really sure from the above if I should send patches to remove
acpi support from those drivers or if you want to handle that yourself.
Other drivers such as FXOS8700 should also generate a warning with
CONFIG_ACPI=n but for some reason don't. I have not tried to track down
Anyway, for an "outsider" it seems all but impossible to determine if
an ACPI ID is real or made up. How does one know ?
Note that I didn't actually get any of your e-mails (nor, I notice, several
other e-mails I was copied on). I picked this one up from the linux-kernel
mailing list. My apologies if I don't reply to any of your e-mails;
that would be the reason.