linux-kernel - Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200610224305.GC248110@dtor-ws>
Date:   Wed, 10 Jun 2020 15:43:05 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Mario.Limonciello@...l.com
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

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.
> 
> 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