From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E489C43460 for ; Wed, 5 May 2021 14:11:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 536AF613BC for ; Wed, 5 May 2021 14:11:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233883AbhEEOMn (ORCPT ); Wed, 5 May 2021 10:12:43 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:58735 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233840AbhEEOMa (ORCPT ); Wed, 5 May 2021 10:12:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620223893; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FQvZQgbJYVjNUMrC5yEbwcKD1FSVeRaVFPfvoK5S8OE=; b=A4QBzeHezj5//t51U/29EVfVc3LO9Wd8Yv/mKHYbAYpaqwfW1+6W2oY6ku73OhQ7T1+3qp 2JG8KYN+/2yGC2jP0LM52+H0VlkNXtT6MLdXGMVyA6m6eDisWnvcBR61lV06a7xQes9ZT4 VRx1RuUucnb1Hoy4ZJcGLdN+OTkxBq0= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-310-1OmVkmrFMKiiL_-DAWK_xQ-1; Wed, 05 May 2021 10:11:31 -0400 X-MC-Unique: 1OmVkmrFMKiiL_-DAWK_xQ-1 Received: by mail-ed1-f71.google.com with SMTP id i19-20020a05640242d3b0290388cea34ed3so906787edc.15 for ; Wed, 05 May 2021 07:11:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FQvZQgbJYVjNUMrC5yEbwcKD1FSVeRaVFPfvoK5S8OE=; b=PoXPvhPmn+dWbmGRm6OQDCN2QDMGw+UnNZbX/ospCd92ucKVLRH2Sz5nr2nPh1Auq0 qJFgKKo5c+/M/UnJXHwJviybqQbMtTSz4BGvZskwdNATD0gvwbrKDHzaSIHprQquUnlV 22oW/E1Kg8LTaPwqVOt0sLPkEwIQf+E8kMl953EE7R6jpMn2zCyz9iLjl2fh48OPzr1U EMB7K0V0llQJsVmI6vIn/9+aI2Zr88S3QPXN3b4uLjTzFuaX9ImUOV4kkFmwppPQ7f3q AGX3CaHZZjUWH48G3waXpQxJhT4NWX/IK4YZnjln37UsmP2xkKTKreCTuMm+KpxFIaQX 6zug== X-Gm-Message-State: AOAM531Ff2wh448hg6x6zNuvr+3QW6Zw2Uew5ThxuHyHvBAmWybns+Os YuO1fuyYAVtBigRS6kdevUK7K7ubQk263+QfamFU+4pUwqyhGuCU7XA9f5Ut4qJz254DC11Kzfh 6D/y6+yr43m8aKWnMMskBp8Xx X-Received: by 2002:a17:906:edc7:: with SMTP id sb7mr27368203ejb.443.1620223889776; Wed, 05 May 2021 07:11:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8MzGe5WOM9n6If5c8KORI8UnzDZLTgFfHOt+sLMiazC9FX6E0uLoehKR0Ri+zTkuZtoPzXQ== X-Received: by 2002:a17:906:edc7:: with SMTP id sb7mr27368174ejb.443.1620223889539; Wed, 05 May 2021 07:11:29 -0700 (PDT) Received: from x1.localdomain (2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:1054:9d19:e0f0:8214]) by smtp.gmail.com with ESMTPSA id g26sm2929567ejz.70.2021.05.05.07.11.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 07:11:29 -0700 (PDT) Subject: Re: [PATCH] iio: bme680_i2c: Make bme680_acpi_match depend on CONFIG_ACPI To: Andy Shevchenko Cc: Jonathan Cameron , "Rafael J. Wysocki" , ACPI Devel Maling List , Paul Menzel , Jacek Anaszewski , Pavel Machek , Guenter Roeck , Jonathan Cameron , linux-iio , Linux Kernel Mailing List , kernel test robot References: <20210504174019.2134652-1-linux@roeck-us.net> <8f8b6f33-4308-bfda-2238-9a54e19c3f9f@roeck-us.net> <20210505093235.00007c38@Huawei.com> <20210505093438.00005238@Huawei.com> <22212bbc-1dc7-c7e7-1954-ebb911754246@redhat.com> From: Hans de Goede Message-ID: Date: Wed, 5 May 2021 16:04:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 5/5/21 3:53 PM, Andy Shevchenko wrote: > On Wed, May 5, 2021 at 4:39 PM Hans de Goede wrote: >> On 5/5/21 3:22 PM, Andy Shevchenko wrote: >>> On Wed, May 5, 2021 at 11:36 AM Jonathan Cameron >>> wrote: >>>> On Wed, 5 May 2021 09:32:35 +0100 >>>> Jonathan Cameron wrote: >>>>> On Tue, 4 May 2021 11:00:52 -0700 >>>>> Guenter Roeck wrote: >>> >>> +Cc: Paul (I hope you are related to coreboot somehow and can >>> communicate this further), Pavel and Jacek (LED subsystem suffered >>> with this as well), Hans, Rafael and linux-acpi@ >>> >>>>> 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. >>> >>> I have counted ~60 users of acpi_device_id in IIO. Brief looking at >>> the IDs themselves rings an alarm about half of them. >>> >>> So, here we may have a chicken and egg problem, i.e. somebody has been >>> using (or used) fake IDs from Linux kernel in the real products. What >>> I can consider as a course of action is the following: >>> 1. Clean up (by removing as quickly as possible) the IDs that have no >>> proof to be real from the Linux kernel sources (perhaps marked as >>> stable material) >>> 2. Notify ASWG / UEFI forum about all IDs that abuse ACPI >>> specification and are in Linux kernel, so at least we can keep some >>> kind of "reserved/do not use" list on the official level (Rafael?) >>> 3. Do not accept any IDs without an evidence provided that they are >>> being in use in the real products (this should be done on Linux >>> maintainer level in all subsystems that accept drivers >> >> So my 2 cents on this are that we need to be very careful with >> removing "bogus" ACPI-ids. >> >> A couple of examples from a quick check under drivers/iio/accel: >> >> drivers/iio/accel/bmc150-accel-i2c.c: >> >> static const struct i2c_device_id bmc150_accel_id[] = { >> {"bmc150_accel", bmc150}, >> {"bmi055_accel", bmi055}, >> {"bma255", bma255}, >> {"bma250e", bma250e}, >> {"bma222", bma222}, >> {"bma222e", bma222e}, >> {"bma280", bma280}, >> {} >> }; >> >> static const struct acpi_device_id bmc150_accel_acpi_match[] = { >> {"BSBA0150", bmc150}, >> {"BMC150A", bmc150}, >> {"BMI055A", bmi055}, >> {"BMA0255", bma255}, >> {"BMA250E", bma250e}, >> {"BMA222", bma222}, >> {"BMA222E", bma222e}, >> {"BMA0280", bma280}, >> {"BOSC0200"}, >> { }, >> }; >> >> With the exception of the "BSBA0150" and "BOSC0200" >> ids, these look like they were invented. But at least the >> "BMA250E" one is actually being used! The other BMA###? >> ones are probably fake, but given that the "BMA250E" >> one is actually real ... >> >> drivers/iio/accel/bmc150-accel-spi.c >> >> This uses the same set of ACPI ids as bmc150-accel-i2c.c >> minus the "BOSC0200" one. I'm not aware if these >> being used in spi mode on any x86 devices, but again >> I'm not 100% sure ... >> >> drivers/iio/accel/da280.c >> >> static const struct acpi_device_id da280_acpi_match[] = { >> {"MIRAACC", da280}, >> {}, >> }; >> MODULE_DEVICE_TABLE(acpi, da280_acpi_match); >> >> This looks like a fake-id, but it was actually added >> in a separate commit adding ACPI support because the >> chip is used with this id on a Linx 820 Windows tablet. >> >> So figuring out of any ids are real or not is really tricky >> and removing them if they are real will lead to regressions. >> >> So summarizing IMHO we need to be careful and not just >> start removing a whole bunch of these... > > That's all true. However, I have a few hints on how to distinguish > them (fake ones): > 1. The ID has been added from day 1 with I2C or SPI ID table with just > capitalized name > 2. If there are a few drivers by the same author and at least one of > the contributions has confirmed fake ID > 3. The ID is single in the list and mimics the part number (capitalized form) > 4. Google/DuckDuckGo/etc searches give no meaningful results > > Either combination of the above can be a good hint to at least be > sceptical that it's being used May I suggest for accelerometers to also grep for the id in 60-sensors.hwdb from systemd ? E.g. the BMA250E id can be found there. > So, Hans, as you already noticed, drivers with a long list of IDs or > when ID added separately can be considered less fakish, but we really > want evidence of the hardware that has it. If you want to move ahead with pruning some of these please Cc me on the patches, then I'll check them against my collection of Bay and Cherry Trail DSDTs, which are devices where these sensors are often found. Regards, Hans