[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DFAA665.8070305@intel.com>
Date: Fri, 17 Jun 2011 08:57:09 +0800
From: Huang Ying <ying.huang@...el.com>
To: Matthew Garrett <mjg59@...f.ucam.org>
CC: Len Brown <lenb@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andi Kleen <andi@...stfloor.org>,
"Luck, Tony" <tony.luck@...el.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH] ACPI, APEI, Add APEI _OSC support
On 06/16/2011 09:57 AM, Matthew Garrett wrote:
> On Thu, Jun 16, 2011 at 09:55:58AM +0800, Huang Ying wrote:
>> On 06/16/2011 09:38 AM, Matthew Garrett wrote:
>>> I think we probably need to make the HEST decision early, and use that
>>> to decide how to make the generic call. Our experience has been that
>>> many firmware vendors only expect _OSC to be called once with any given
>>> UUID - multiple calls can result in unexpected behaviour.
>>
>> acpi_bus_osc_support is called via subsys_initcall. It is a little hard
>> to do all checking before that. Is it possible to call
>> acpi_bus_osc_support later?
>
> Yeah, this is going to be a problem. We have the HEST available at this
> point so we ought to be able to parse it, though. I'll take a look
> tomorrow.
We can check the HEST table before _OSC evaluating. But it is much
harder to check software part, because we have implemented GHES support
(Generic Hardware Error Source, the handler of firmware first mode
hardware error notification) as device driver and module.
So I think we can do that in 2 steps. At first, we just enable WHEA
UUID, because that is easier to do. Then we find a way to implement
"APEI bit" in generic _OSC call. Do you think that is a good idea?
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists