Date:   Thu, 9 Jul 2020 13:57:59 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Enric Balletbo i Serra <enric.balletbo@...labora.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Mario Limonciello <Mario.Limonciello@...l.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "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 <platform-driver-x86@...r.kernel.org>
Subject: Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS

On Thu, Jul 9, 2020 at 11:31 AM Enric Balletbo i Serra
<enric.balletbo@...labora.com> wrote:
>
> 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, 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.
> >
>
> 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?

Yes, it does, thanks!

Powered by blists - more mailing lists