[lkml]   [2020]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS
Hi Rafael,

On 11/6/20 13:06, Enric Balletbo i Serra wrote:
> Hi,
> On 11/6/20 0:43, Dmitry Torokhov wrote:
>> On Wed, Jun 10, 2020 at 09:52:12PM +0000, wrote:
>>>> -----Original Message-----
>>>> From: Dmitry Torokhov <>
>>>> Sent: Wednesday, June 10, 2020 4:41 PM
>>>> To: Limonciello, Mario
>>>> Cc:;;;
>>>> Subject: Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS
>>>> On Wed, Jun 10, 2020 at 09:28:36PM +0000, 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.

So, as the GGL prefix is a valid ID in the PNP ID list, is this a valid argument
to take in consideration this patch and resolves your concern regarding the ID?


> Thanks,
> Enric
> [1]
>> We internally can fix it (HID) for next generation of devices.
>> Thanks.

 \ /
  Last update: 2020-07-09 11:31    [W:0.048 / U:1.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site