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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 332EFC47247 for ; Mon, 4 May 2020 09:41:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1DF432071C for ; Mon, 4 May 2020 09:41:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728453AbgEDJlK (ORCPT ); Mon, 4 May 2020 05:41:10 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2152 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726625AbgEDJlK (ORCPT ); Mon, 4 May 2020 05:41:10 -0400 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 015F3B768F29FFD504CC; Mon, 4 May 2020 10:41:08 +0100 (IST) Received: from localhost (10.47.88.153) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 4 May 2020 10:41:07 +0100 Date: Mon, 4 May 2020 10:40:48 +0100 From: Jonathan Cameron To: Andy Shevchenko CC: Jonathan Cameron , Hans de Goede , "Rafael J . Wysocki" , Len Brown , Darren Hart , Andy Shevchenko , ACPI Devel Maling List , Platform Driver , Linux Kernel Mailing List , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , linux-iio Subject: Re: [PATCH v3 10/11] iio: light: cm32181: Add support for parsing CPM0 and CPM1 ACPI tables Message-ID: <20200504104048.00003f35@Huawei.com> In-Reply-To: References: <20200428172923.567806-1-hdegoede@redhat.com> <20200428172923.567806-10-hdegoede@redhat.com> <20200503122237.4af34181@archlinux> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.88.153] X-ClientProxiedBy: lhreml739-chm.china.huawei.com (10.201.108.189) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 3 May 2020 19:25:20 +0300 Andy Shevchenko wrote: > On Sun, May 3, 2020 at 2:22 PM Jonathan Cameron wrote: > > On Tue, 28 Apr 2020 19:29:22 +0200 > > Hans de Goede wrote: > > ... > > > > This was tested on the following models: Acer Switch 10 SW5-012 (CM32181) > > > Asus T100TA (CM3218), Asus T100CHI (CM3218) and HP X2 10-n000nd (CM32181). > > > > I assume it's far too much to hope this CPM0 / CPM1 stuff is actually defined > > in a spec anywhere? > > > > There are standard way of adding vendor specific data blobs to ACPI and this > > isn't one of them (unless I'm missing something). People need to beat > > up vendors earlier about this stuff. > > > > Grumble over... > > > > Code looks fine to me, but I'd like an ACPI review ideally. > > ACPI didn't cover embedded world and has the following issues > a) where it should be strict (like how many I2CSerialBus() resources > can be given and for what type of devices, etc), it doesn't > b) they need to provides better validation tools, but they didn't > c) it's still windows oriented :-( > > Above is custom extension on how to add device properties (and note, > we have now _DSD() and still we have some M$ way of thinking how to > use them). > > Since the above approach is in the wild, I'm afraid we have not many > possibilities here (each of them with own problems): > 1/ shout at vendors to use ACPI properly and simple don't by broken > hardware (rather firmware) > 2/ try to support custom changes (may lead to several approaches for > the same thing) > 3/ create a lot of board files (something in between 1/ and 2/) > > As a result: > 1/ is obviously a best one, but I think it's an utopia. Let's keep the "shout" bit where possible :) Makes us feel better anyway. > 2/ in practice we don't have many deviations (luckily OEMs are quite > lazy to modify reference BIOSes and often reuse existing approaches) > 3/ may not work, because on cheap laptops the means of distinguishing > them (like DMI strings) may also been broken. > The UEFI forum are finally making steps in the right direction on how they develop their specs (sort of) so I guess interested companies should rock up and see if they can get some of this stuff fixed. (those that can attend meetings anyway - but that's a different issue). Spec meetings are fun and everyone loves the EDK2 source code :) J