From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Huang Ying <ying.huang@intel.com>
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 02:42:13 +0100 [thread overview]
Message-ID: <20110617014213.GA30826@srcf.ucam.org> (raw)
In-Reply-To: <4DFAB081.6050800@intel.com>
On Fri, Jun 17, 2011 at 09:40:17AM +0800, Huang Ying wrote:
> On 06/17/2011 09:34 AM, Matthew Garrett wrote:
> > 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.
That's true of any _OSC functionality.
> >> 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.
I see your point. But this does need to be fixed in the long run.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2011-06-17 1:42 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
2011-06-17 1:42 ` Matthew Garrett [this message]
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=20110617014213.GA30826@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=andi@firstfloor.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=ying.huang@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.