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
WARNING: multiple messages have this Message-ID (diff)
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-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
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
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2017-06-08 18:26 UTC|newest]
Thread overview: 22+ 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 18:49 ` Toshi Kani
2017-06-07 19:09 ` Dan Williams
2017-06-07 19:09 ` Dan Williams
[not found] ` <CAPcyv4i7bLU17QEmdUBQrtWP3AZxPRyKK0NN105XrTj8K3nAAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-07 20:57 ` Kani, Toshimitsu
2017-06-07 20:57 ` Kani, Toshimitsu
2017-06-07 20:57 ` Kani, Toshimitsu
2017-06-07 21:06 ` Dan Williams
2017-06-07 21:06 ` Dan Williams
2017-06-07 21:33 ` Kani, Toshimitsu
2017-06-07 21:33 ` Kani, Toshimitsu
[not found] ` <1496871186.9288.3.camel-ZPxbGqLxI0U@public.gmane.org>
2017-06-08 17:30 ` Linda Knippers
2017-06-08 17:30 ` Linda Knippers
2017-06-08 17:30 ` Linda Knippers
[not found] ` <b91c4a7b-3e19-df5d-12e7-61cdf1bc2c84-ZPxbGqLxI0U@public.gmane.org>
2017-06-08 17:34 ` Dan Williams
2017-06-08 17:34 ` Dan Williams
2017-06-08 17:34 ` Dan Williams
[not found] ` <CAPcyv4hocL=1Mzqa+nJCdmRz7YgxUc3P1w-nn7F=uQG8wu94KA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-08 17:38 ` Kani, Toshimitsu
2017-06-08 17:38 ` Kani, Toshimitsu
2017-06-08 17:38 ` Kani, Toshimitsu
2017-06-08 18:26 ` Kani, Toshimitsu [this message]
2017-06-08 18:26 ` Kani, Toshimitsu
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 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.