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
| ||
|
Date: Sat, 6 Jun 2020 11:04:35 -0700 From: Dmitry Torokhov <dmitry.torokhov@...il.com> To: "Rafael J. Wysocki" <rjw@...ysocki.net> Cc: Enric Balletbo i Serra <enric.balletbo@...labora.com>, "Rafael J. Wysocki" <rafael@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, Len Brown <lenb@...nel.org>, Collabora Kernel ML <kernel@...labora.com>, Guenter Roeck <groeck@...omium.org>, Benson Leung <bleung@...omium.org>, Dmitry Torokhov <dtor@...omium.org>, Gwendal Grignou <gwendal@...omium.org>, vbendeb@...omium.org, Andy Shevchenko <andy@...radead.org>, Ayman Bagabas <ayman.bagabas@...il.com>, Benjamin Tissoires <benjamin.tissoires@...hat.com>, Blaž Hrastnik <blaz@...n.io>, Darren Hart <dvhart@...radead.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Hans de Goede <hdegoede@...hat.com>, Jeremy Soller <jeremy@...tem76.com>, Mattias Jacobsson <2pi@....nu>, Mauro Carvalho Chehab <mchehab+samsung@...nel.org>, Rajat Jain <rajatja@...gle.com>, Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, platform-driver-x86@...r.kernel.org Subject: Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS Hi Rafael, On Fri, Jun 05, 2020 at 01:17:15PM +0200, Rafael J. Wysocki wrote: > > First off, GGL0001 is not a valid ACPI device ID, because the GGL prefix is not > present in the list at https://uefi.org/acpi_id_list > > There are two ways to address that. One would be to take the GOOG prefix > (present in the list above), append a proper unique number (if I were to > guess, I would say that 0001 had been reserved already) to it and then > put the resulting device ID into the firmware, to be returned _HID for the > device in question (you can add a _CID returning "GGL0001" so it can be > found by the old invalid ID at least from the kernel). This is not going to happen, as there are devices in the wild with such firmware (i.e. Samus - Google Pixel 2 - was shipped in 2015). Even if Google were to release updated firmware (which is quite unlikely), it does not mean that users who are not using Chrome OS would apply updated firmware. > The other one would > be to properly register the GGL prefix for Google and establish a process for > allocating IDs with that prefix internally. I think it depends on whether there are more instances of "GGL" prefix. I thought we mostly used GOOG for everything. Thanks. -- Dmitry
Powered by blists - more mailing lists