From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"Knippers, Linda" <linda.knippers@hpe.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>
Subject: Re: [PATCH] Add support of NVDIMM memory error notification in ACPI 6.2
Date: Thu, 8 Jun 2017 18:26:36 +0000 [thread overview]
Message-ID: <1496946370.9288.7.camel@hpe.com> (raw)
In-Reply-To: <1496943475.9288.5.camel@hpe.com>
On Thu, 2017-06-08 at 11:37 -0600, Toshi Kani wrote:
> On Thu, 2017-06-08 at 10:34 -0700, Dan Williams wrote:
> > On Thu, Jun 8, 2017 at 10:30 AM, Linda Knippers <linda.knippers@hpe
> > .c
> > om> wrote:
> > [..]
> > > Wasn't Dan concerned about how the OS can know whether the FW
> > > supports that bit in the Start ARS?
> > >
> > > The Query ARS Capabilities DSM has a bit that tells the OS
> > > whether the platform supports the notification and the point of
> > > the notification was to tell the OS it could do a Start ARS with
> > > bit 1 set. Of course, if you get the notification then that
> > > means the platform has the capability to deliver it, but it might
> > > not hurt to check the flag from the Query Capabilities bit.
> >
> > Good point, yes, I think it is safe to assume that a BIOS that
> > claims to support un-correctable error notification also supports
> > this Start ARS flag.
>
> Yes, ACPI 6.2, section 9.20.7.2, defines that:
>
> Upon receiving the notification, the OSPM may decide to issue
> a Start ARS with Flags Bit [1] set to prepare for the retrieval
> of existing records and issue the Query ARS Status function to
> retrieve the records.
>
> So, I believe it is safe to assume that BIOS supporting 0x81 also
> supports flags Bit [1]. Sorry, this is what I should have said in my
> previous email...
To reiterate my thinking, I believe the statement above clarifies that
the OS can assume BIOS support of Flags Bit[1] upon receiving a 0x81
notification. Since BIOS may also support Flags Bit[1] without
supporting this 0x81 (in which case I do not know how to detect it, but
BIOS should simply ignore this bit when not supporting it), I am not
going to add a check/restriction that 0x81 support is necessary to set
Bit[1] in the scan function.
Thanks,
-Toshi
prev parent reply other threads:[~2017-06-08 18:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 18:49 [PATCH] Add support of NVDIMM memory error notification in ACPI 6.2 Toshi Kani
2017-06-07 19:09 ` Dan Williams
2017-06-07 20:57 ` Kani, Toshimitsu
2017-06-07 21:06 ` Dan Williams
2017-06-07 21:33 ` Kani, Toshimitsu
2017-06-08 17:30 ` Linda Knippers
2017-06-08 17:34 ` Dan Williams
2017-06-08 17:38 ` Kani, Toshimitsu
2017-06-08 18:26 ` Kani, Toshimitsu [this message]
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=1496946370.9288.7.camel@hpe.com \
--to=toshi.kani@hpe.com \
--cc=dan.j.williams@intel.com \
--cc=linda.knippers@hpe.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=rjw@rjwysocki.net \
--cc=vishal.l.verma@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox