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
Thread-Topic: [PATCH] Add support of NVDIMM memory error notification in ACPI
 6.2
Thread-Index: AQHS3770gIvIG2RgykSVdl0qpZhIVKIZw7kAgAAeJICAAAKEgIAAB20AgAFOpoCAAAD8AIAAAP6AgAANewA=
Date: Thu, 8 Jun 2017 18:26:36 +0000
Message-ID: <1496946370.9288.7.camel@hpe.com>
References: <20170607184947.18733-1-toshi.kani@hpe.com>
         <CAPcyv4i7bLU17QEmdUBQrtWP3AZxPRyKK0NN105XrTj8K3nAAQ@mail.gmail.com>
         <1496869051.9288.1.camel@hpe.com>
         <CAPcyv4hwhRc6+JW8m3zVn_tKz__wE9BHOfpjy69RS6OwiqV-PA@mail.gmail.com>
         <1496871186.9288.3.camel@hpe.com>
         <b91c4a7b-3e19-df5d-12e7-61cdf1bc2c84@hpe.com>
         <CAPcyv4hocL=1Mzqa+nJCdmRz7YgxUc3P1w-nn7F=uQG8wu94KA@mail.gmail.com>
         <1496943475.9288.5.camel@hpe.com>
In-Reply-To: <1496943475.9288.5.camel@hpe.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <EA02CCD3A76813468F1EC96C779BC808@NAMPRD84.PROD.OUTLOOK.COM>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 18:26:36.7204
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0076
X-OriginatorOrg: hpe.com
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v58IQqN8030975
Content-Length: 1860
Lines: 41

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