On Wed, Jun 10, 2020 at 09:52:12PM +0000, Mario.Limonciello@xxxxxxxx wrote: > > -----Original Message----- > > From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > Sent: Wednesday, June 10, 2020 4:41 PM > > To: Limonciello, Mario > > Cc: enric.balletbo@xxxxxxxxxxxxx; rjw@xxxxxxxxxxxxx; rafael@xxxxxxxxxx; > > linux-kernel@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; lenb@xxxxxxxxxx; > > kernel@xxxxxxxxxxxxx; groeck@xxxxxxxxxxxx; bleung@xxxxxxxxxxxx; > > dtor@xxxxxxxxxxxx; gwendal@xxxxxxxxxxxx; vbendeb@xxxxxxxxxxxx; > > andy@xxxxxxxxxxxxx; ayman.bagabas@xxxxxxxxx; benjamin.tissoires@xxxxxxxxxx; > > blaz@xxxxxxx; dvhart@xxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; > > hdegoede@xxxxxxxxxx; jeremy@xxxxxxxxxxxx; 2pi@xxxxxx; > > mchehab+samsung@xxxxxxxxxx; rajatja@xxxxxxxxxx; > > srinivas.pandruvada@xxxxxxxxxxxxxxx; platform-driver-x86@xxxxxxxxxxxxxxx > > 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@xxxxxxxx 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. > > 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. We internally can fix it (HID) for next generation of devices. Thanks. -- Dmitry
