linux-kernel - Re: [PATCH v2] iio: bme680

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210506135052.GB2267050@roeck-us.net>
Date:   Thu, 6 May 2021 06:50:52 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Jonathan Cameron <jic23@...nel.org>,
        linux-iio <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2] iio: bme680_i2c: Remove ACPI support

On Thu, May 06, 2021 at 03:42:08PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 5/6/21 3:37 PM, Guenter Roeck wrote:
> > On Thu, May 06, 2021 at 12:28:40PM +0300, Andy Shevchenko wrote:
> >> On Thu, May 6, 2021 at 6:43 AM Guenter Roeck <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.
> >>
> >> Reviewed-by: Andy Shevchenko <andy.shevchenko@...il.com>
> >>
> >> with the SPI part amended in the same way.
> >>
> > Right. I just sent a patch doing that. Oddly enough 0-day didn't complain
> > about that one to me, nor about many other drivers with the same problem.
> > No idea how it decides if and when to make noise.
> > 
> > Is there a way to determine invalid ACPI IDs ?
> 
> No, unfortunately not. There is a format which ACPI IDs are
> supposed to follow, but some "out in the wild" API ids don't
> follow this; and many fake (made up) ACPI ids do follow it...
> 
> We (mostly Andy and me) are not even 100% sure this one is
> a fake ACPI ID, but we do pretty strongly believe that it is.
> 

What a mess :-(

Guenter