linux-kernel - Re: [PATCH v3 10/11] iio: light: cm32181: Add support for parsing CPM0 and CPM1 ACPI tables

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: <20200504104048.00003f35@Huawei.com>
Date:   Mon, 4 May 2020 10:40:48 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Jonathan Cameron <jic23@...nel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        linux-iio <linux-iio@...r.kernel.org>
Subject: Re: [PATCH v3 10/11] iio: light: cm32181: Add support for parsing
 CPM0 and CPM1 ACPI tables

On Sun, 3 May 2020 19:25:20 +0300
Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> On Sun, May 3, 2020 at 2:22 PM Jonathan Cameron <jic23@...nel.org> wrote:
> > On Tue, 28 Apr 2020 19:29:22 +0200
> > Hans de Goede <hdegoede@...hat.com> 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