From: Huang Ying <ying.huang@intel.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Len Brown <lenb@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
"Luck, Tony" <tony.luck@intel.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] ACPI, APEI, Add APEI _OSC support
Date: Fri, 17 Jun 2011 09:40:17 +0800 [thread overview]
Message-ID: <4DFAB081.6050800@intel.com> (raw)
In-Reply-To: <20110617013442.GA30708@srcf.ucam.org>
On 06/17/2011 09:34 AM, Matthew Garrett wrote:
> On Fri, Jun 17, 2011 at 08:57:09AM +0800, Huang Ying wrote:
>> On 06/16/2011 09:57 AM, Matthew Garrett wrote:
>>> 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.
>
> If the kernel has been configured with support for the feature then I
> think we ought to be able to assume that the kernel will support it at
> runtime.
There may be error during driver initialization. That is what I am
concerned.
>> 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?
>
> I'm fine with that, providing that GHES isn't disabled purely because
> the WHEA UUID call wasn't successful.
Because we have not added the code to make generic _OSC call with "APEI
bit" now, so if WHEA UUID call failed, we have no firmware first mode
enabled. So I think it is safe to disable GHES if WHEA UUID call
failed. But in another hand, keeping GHES has no harm too. So I am OK
to keep GHES if WHEA UUID call failed.
Best Regards,
Huang Ying
next prev parent reply other threads:[~2011-06-17 1:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 6:05 [PATCH] ACPI, APEI, Add APEI _OSC support Huang Ying
2011-06-13 14:50 ` Don Zickus
2011-06-14 6:33 ` Chen Gong
2011-06-14 6:33 ` Chen Gong
2011-06-14 12:11 ` Don Zickus
2011-06-14 14:52 ` Matthew Garrett
2011-06-15 3:53 ` Huang Ying
2011-06-15 12:17 ` Matthew Garrett
2011-06-16 0:40 ` Huang Ying
2011-06-16 1:38 ` Matthew Garrett
2011-06-16 1:55 ` Huang Ying
2011-06-16 1:57 ` Matthew Garrett
2011-06-17 0:57 ` Huang Ying
2011-06-17 1:34 ` Matthew Garrett
2011-06-17 1:40 ` Huang Ying [this message]
2011-06-17 1:42 ` Matthew Garrett
2011-06-17 1:53 ` Huang Ying
2011-06-16 9:00 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DFAB081.6050800@intel.com \
--to=ying.huang@intel.com \
--cc=andi@firstfloor.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.