[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1371508629.523.3.camel@x230>
Date: Mon, 17 Jun 2013 22:37:10 +0000
From: Matthew Garrett <matthew.garrett@...ula.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"seth.forshee@...onical.com" <seth.forshee@...onical.com>,
"joeyli.kernel@...il.com" <joeyli.kernel@...il.com>,
"daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
"lenb@...nel.org" <lenb@...nel.org>,
Bob Moore <robert.moore@...el.com>
Subject: Re: [PATCH 2/3] ACPICA: Add interface for getting latest OS version
requested via _OSI
On Tue, 2013-06-18 at 00:31 +0200, Rafael J. Wysocki wrote:
> Hi Matthew,
>
> On Sunday, June 09, 2013 07:01:38 PM Matthew Garrett wrote:
> > Drivers may need to make policy decisions based on the OS that the firmware
> > believes it's interacting with. ACPI firmware will make a series of _OSI
> > calls, starting from the oldest OS version they support and ending with the
> > most recent. Add a function to return the last successful call so that
> > drivers know what the firmware's expecting.
> >
> > Based on a patch by Seth Forshee <seth.forshee@...onical.com>
>
> Bob (CCed) would prefer us to access acpi_gbl_osi_data directly instead of
> adding the wrapper to ACPICA. He also thinks that the symbol definitions
> should go into include/acpi/actypes.h rather than into acpixf.h.
>
> Then, the only ACPICA change would be to move the symbols and we can
> add a Linux-specific patch on top of that adding the acpi_gbl_osi_data
> wrapper.
That sounds good to me. Do you want to respin that, or should I send an
updated set?
--
Matthew Garrett | mjg59@...f.ucam.org
Powered by blists - more mailing lists