linux-kernel - Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS

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: <1e32b7db-5457-e0cf-5e5e-36f21d5a91eb@collabora.com>
Date:   Thu, 11 Jun 2020 13:06:58 +0200
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Mario.Limonciello@...l.com
Cc:     rjw@...ysocki.net, rafael@...nel.org, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, lenb@...nel.org, kernel@...labora.com,
        groeck@...omium.org, bleung@...omium.org, dtor@...omium.org,
        gwendal@...omium.org, vbendeb@...omium.org, andy@...radead.org,
        ayman.bagabas@...il.com, benjamin.tissoires@...hat.com,
        blaz@...n.io, dvhart@...radead.org, gregkh@...uxfoundation.org,
        hdegoede@...hat.com, jeremy@...tem76.com, 2pi@....nu,
        mchehab+samsung@...nel.org, rajatja@...gle.com,
        srinivas.pandruvada@...ux.intel.com,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS

Hi,

On 11/6/20 0:43, Dmitry Torokhov wrote:
> On Wed, Jun 10, 2020 at 09:52:12PM +0000, Mario.Limonciello@...l.com wrote:
>>> -----Original Message-----
>>> From: Dmitry Torokhov <dmitry.torokhov@...il.com>
>>> Sent: Wednesday, June 10, 2020 4:41 PM
>>> To: Limonciello, Mario
>>> Cc: enric.balletbo@...labora.com; rjw@...ysocki.net; rafael@...nel.org;
>>> linux-kernel@...r.kernel.org; linux-acpi@...r.kernel.org; lenb@...nel.org;
>>> kernel@...labora.com; groeck@...omium.org; bleung@...omium.org;
>>> dtor@...omium.org; gwendal@...omium.org; vbendeb@...omium.org;
>>> andy@...radead.org; ayman.bagabas@...il.com; benjamin.tissoires@...hat.com;
>>> blaz@...n.io; dvhart@...radead.org; gregkh@...uxfoundation.org;
>>> hdegoede@...hat.com; jeremy@...tem76.com; 2pi@....nu;
>>> mchehab+samsung@...nel.org; rajatja@...gle.com;
>>> srinivas.pandruvada@...ux.intel.com; platform-driver-x86@...r.kernel.org
>>> Subject: Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> On Wed, Jun 10, 2020 at 09:28:36PM +0000, Mario.Limonciello@...l.com wrote:
>>>>>
>>>>> To give you some references, if I'm not wrong, this prefix is used in
>>> all
>>>>> or
>>>>> almost all Intel Chromebook devices (auron, cyan, eve, fizz, hatch,
>>>>> octopus,
>>>>> poppy, strago ...) The ACPI source for this device can be found here
>>> [1],
>>>>> and,
>>>>> if not all, almost all Intel based Chromebooks are shipped with the
>>>>> firmware
>>>>> that supports this.
>>>>
>>>> You can potentially carry a small patch in your downstream kernel for the
>>>> legacy stuff until it reaches EOL.  At least for the new stuff you could
>>>> enact a process that properly reserves unique numbers and changes the
>>> driver
>>>> when the interface provided by the ACPI device has changed.
>>>
>>> If we use this prefix for hatch EOL is ~7 years from now.
>>>
>>
>> Isn't the whole point of the ACPI registry and choosing an ID?  You know internally
>> if you need to change the interface that a new ID is needed and a new driver will
>> be needed that comprehends that ID change.  So if you can't guarantee that 0001 is
>> the same driver interface in every firmware implementation google used then that is
>> where this falls apart.
>>

As far as I know GGL0001 has the same driver interface in every firmware
implementation Google used. But I'll ask to make sure.

>> I know there is a long support lifecycle but you're talking about rebasing
>> to new LTS kernels a handful of times between now and then.  If the interface really
>> is stable the patch should be small and it shouldn't be a large amount of technical
>> debt to carry downstream until EOL.
> 
> I think we are talking about different things actually. Let's forget
> about Chrome OS and downstream kernels. We have devices that have
> already been shipped and in hands of users. Some of them are old, some
> of them are new. We can't not enforce that firmware for these devices
> will be either released or updated. Therefore, if we want expose this
> device in mainline kernel, we need to have it handle "GGL0001" HID in
> addition to whatever proper HID we may select for it.
> 

FWIW, after investigate a bit more, although GGL is not in the ACPI ID list it
is in the PNP ID list [1]. So as far as I understand GGL0001 is valid ID. I know
that PNP ID is the legacy identifier but since this was here for long time and
will be here also for long time, I am wondering if we can take that as an
argument to have GGL0001 as a valid device to be exposed in the kernel.

Thanks,
 Enric

[1] https://uefi.org/pnp_id_list


> We internally can fix it (HID) for next generation of devices.
> 
> Thanks.
>