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: <adf9daaf08f1464684e48ec203194fe9@AUSX13MPC105.AMER.DELL.COM>
Date:   Wed, 10 Jun 2020 21:52:12 +0000
From:   <Mario.Limonciello@...l.com>
To:     <dmitry.torokhov@...il.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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ