Hi, On 11/6/20 0:43, Dmitry Torokhov wrote: > On Wed, Jun 10, 2020 at 09:52:12PM +0000, mario.limoncie...@dell.com wrote: >>> -----Original Message----- >>> From: Dmitry Torokhov <dmitry.torok...@gmail.com> >>> Sent: Wednesday, June 10, 2020 4:41 PM >>> To: Limonciello, Mario >>> Cc: enric.balle...@collabora.com; r...@rjwysocki.net; raf...@kernel.org; >>> linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; l...@kernel.org; >>> ker...@collabora.com; gro...@chromium.org; ble...@chromium.org; >>> d...@chromium.org; gwen...@chromium.org; vben...@chromium.org; >>> a...@infradead.org; ayman.baga...@gmail.com; benjamin.tissoi...@redhat.com; >>> b...@mxxn.io; dvh...@infradead.org; gre...@linuxfoundation.org; >>> hdego...@redhat.com; jer...@system76.com; 2...@mok.nu; >>> mchehab+sams...@kernel.org; raja...@google.com; >>> srinivas.pandruv...@linux.intel.com; platform-driver-...@vger.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.limoncie...@dell.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. >
