From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "dan.j.williams@intel.com" <dan.j.williams@intel.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: AQHS3770gIvIG2RgykSVdl0qpZhIVKIZw7kAgAAeJICAAAKEgIAAB20A
Date: Wed, 7 Jun 2017 21:33:31 +0000
Message-ID: <1496871186.9288.3.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>
In-Reply-To: <CAPcyv4hwhRc6+JW8m3zVn_tKz__wE9BHOfpjy69RS6OwiqV-PA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <343E154C7E43AF46AFC6168967726141@NAMPRD84.PROD.OUTLOOK.COM>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2017 21:33:31.2310
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0108
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 v57LYP2j022829
Content-Length: 1873
Lines: 48

On Wed, 2017-06-07 at 14:06 -0700, Dan Williams wrote:
> On Wed, Jun 7, 2017 at 1:57 PM, Kani, Toshimitsu <toshi.kani@hpe.com>
> wrote:
> > On Wed, 2017-06-07 at 12:09 -0700, Dan Williams wrote:
> > > On Wed, Jun 7, 2017 at 11:49 AM, Toshi Kani <toshi.kani@hpe.com>
> > > wrote:
> > 
> >  :
> > > > +
> > > > +static void acpi_nfit_uc_error_notify(struct device *dev,
> > > > acpi_handle handle)
> > > > +{
> > > > +       struct acpi_nfit_desc *acpi_desc =
> > > > dev_get_drvdata(dev);
> > > > +
> > > > +       acpi_nfit_ars_rescan(acpi_desc);
> > > 
> > > I wonder if we should gate re-scanning with a similar:
> > > 
> > >     if (acpi_desc->scrub_mode == HW_ERROR_SCRUB_ON)
> > > 
> > > ...check that we do in the mce notification case? Maybe not since
> > > we
> > > don't get an indication of where the error is without a rescan.
> > 
> > I think this mce case is different since the MCE handler already
> > knows where the new poison location is and can update badblocks
> > information for it.  Starting ARS is an optional precaution.
> > 
> > > However, at a minimum I think we need support for the new Start
> > > ARS flag ("If set to 1 the firmware shall return data from a
> > > previous scrub, if any, without starting a new scrub") and use
> > > that for this case.
> > 
> > That's an interesting idea.  But I wonder how users know if it is
> > OK to set this flag as it relies on BIOS implementation that is not
> > described in ACPI...
> 
> Ugh, you're right. We might need a revision-id=2 version of Start ARS
> so software knows that the BIOS is aware of the new flag.

My bad.  Looking at ACPI 6.2, it actually defines what you described. 
Start ARS now defines bit[1] in Flags which can be set to avoid
scanning for this notification.  I will update the patch to set this
flag when HW_ERROR_SCRUB_ON is not set.

Thanks,
-Toshi