This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 26 21:37:36 2024 >From mailfetcher Mon Jun 12 01:32:36 2017 Envelope-to: lkml@grols.ch Delivery-date: Thu, 08 Jun 2017 19:31:09 +0200 Received: from srv.grols.ch [5.172.41.101] by e326d15dcf49 with IMAP (fetchmail-6.3.26) for (single-drop); Mon, 12 Jun 2017 01:32:36 +0200 (CEST) Received: from vger.kernel.org ([209.132.180.67]) by home.grols.ch with esmtp (Exim 4.88) (envelope-from ) id 1dJ1H0-0004jC-Oj for lkml@grols.ch; Thu, 08 Jun 2017 19:31:09 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751331AbdFHRbE (ORCPT ); Thu, 8 Jun 2017 13:31:04 -0400 Received: from g9t1613g.houston.hpe.com ([15.241.32.99]:55687 "EHLO g9t1613g.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750914AbdFHRbC (ORCPT ); Thu, 8 Jun 2017 13:3 Received: from g2t2354.austin.hpe.com (g2t2354.austin.hpe.com [15.233.44.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by g9t1613g.houston.hpe.com (Postfix) with ESMTPS id 5F7D760984; Received: from G9W8455.americas.hpqcorp.net (g9w8455.houston.hp.com [16.216.161.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2354.austin.hpe.com (Postfix) with ESMTPS id 121569 Received: from G9W8454.americas.hpqcorp.net (2002:10d8:a104::10d8:a104) by G9W8455.americas.hpqcorp.net (2002:10d8:a15e::10d8:a15e) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 8 Jun 2017 17:30:59 +0000 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (15.241.52.10) by G9W8454.americas.hpqcorp.net (16.216.161.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4 via Frontend Transport; Thu, 8 Jun 2017 17:30:59 +0000 Authentication-Results: hpe.com; dkim=none (message not signed) header.d=none;hpe.com; dmarc=none action=none header.from=hpe.com; Received: from [192.168.1.9] (73.60.235.182) by CS1PR84MB0072.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Thu, 8 Jun 2017 17:30:57 +0000 Subject: Re: [PATCH] Add support of NVDIMM memory error notification in ACPI 6.2 To: "Kani, Toshimitsu" , "dan.j.williams@intel.com" References: <20170607184947.18733-1-toshi.kani@hpe.com> <1496869051.9288.1.camel@hpe.com> <1496871186.9288.3.camel@hpe.com> Cc: "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "linux-acpi@vger.kernel.org" , "rjw@rjwysocki.net" , "v From: Linda Knippers Message-Id: Date: Thu, 8 Jun 2017 13:30:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Mime-Version: 1.0 In-Reply-To: <1496871186.9288.3.camel@hpe.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [73.60.235.182] X-ClientProxiedBy: CY4PR1201CA0022.namprd12.prod.outlook.com (10.172.75.32) To CS1PR84MB0072.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.153) x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CS1PR84MB0072: x-ms-office365-filtering-correlation-id: abe90184-59de-4acd-565b-08d4ae942053 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081)(201703131423075)(201703031133081);SRVR:CS1PR84MB0072; X-Microsoft-Exchange-Diagnostics: 1;CS1PR84MB0072;3:HF7dih64ryPF0t3sbdhf0pPB3Y0Ig4x0yze4iHTqSQ1R7T4zpmv4fhtQx+lUB19KohRtmuzgJ42IYg7aqwdEP7bud05rBl5gvTuqhlHkhAw3Zr8xT342w1sO1JPIxl4cReDvhUoEhpdKETmRs1NcutwLVP40CwW5W+dIczzqeFrlvfWZBBmFk5KFPiQmFJoZT+Fd4V6wnWG8rgFhRUMUUMxnBQjlBvRaGLQ65rmlIqx1 X-Microsoft-Exchange-Diagnostics: 1;CS1PR84MB0072;31:Q3m1Glic6Wk1WXGWJinm3GgAEf38n33dmnyCGlQ2XEQJEm/rgnrRXOq09OtnRkm0N9LRlqpfNGFqWaVLoFSLbQ6wNDAEbm850pn+NmJd7DXTTZac1zTDa7mbZ7OBe7Ldq/5haLfn+qJqQj7gRZedH0mHCHxl9sY1xTJ3JqfxlpIH/4H6CVwevaZ91BX4FuCsURikljzDzfcWsZLs/NKwc8XQAwPeORb8vqalqm7Mo1A X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(227479698468861); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123555025) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDUzFQUjg0TUIwMDcyOzQ6Qk16MlZiaitQY0trdjBETVJHTVIrSlZGbHps?= =?utf-8?B?Z0tCQjN1RkxqZGh3dEZUb1BaVC9SZGNiZmhpTjR0eGxuUEdveXd0L2R2NExU?= =?utf-8?B?ZEJhTVA5WVZ1bllBeDNKaTNBWUNaczhHV3ZPeElDWGYxcGVPYjNTNlJiZDJJ?= =?utf-8?B?UHBubld5RGVzME45R2ZEMjU4T X-Forefront-PRVS: 0332AACBC3 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(39410400002)(39450400003)(39860400002)(39850400002)(39840400002)(39400400002)(24454002)(377424004)(377454003)(305945005)(229853002)(2870700001)(478600001)(7736002)(54356999)(76176999)(50986999)(290600 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDUzFQUjg0TUIwMDcyOzIzOlBSS1pwWURvWlgyS0NKVVNEcnQvMTAxVmY1?= =?utf-8?B?TW5CRXA2cHE3WjJSbjhIdEdyMnBCL016WlNjN3VEY1hLZVRreExNcWkwRlI3?= =?utf-8?B?NzRyQU1rbEJQcDllVURzNmlaL1V1dWZ2a0dMMzhaczBmeDRSNkVTZ0RUaThH?= =?utf-8?B?bW9EOFhMdnRvbGtIVU81Z2s4e X-Microsoft-Exchange-Diagnostics: 1;CS1PR84MB0072;6:mv2RrAyIn5AWym243wtMAFAyzOPPpBPha8Yv9IsHMTddms468UuewL6Qx0+q6odCMbf3G/bDbuJtAFYYc4lvSfF81dsNlyDj9qLW0x/C21eZkh6NTg1rujjfaOAvAArfodDkPRCVhzQLPoHw4sHYXAkx7P1yXBUqiPBsOiaNEvEb6yk9Vv6tob6HWteAAUHcjQ0HXGOMUeZQEQr3EgU9WEwbKTAeQoqkmJGI+ZeR2+S4 X-Microsoft-Exchange-Diagnostics: 1;CS1PR84MB0072;5:Ph9VDsxMOsI+EqEnQpqMuNrq4hmGuyZrtMrLG/L8j5Bd6YNN8dfYhUarONSuiQqlFj2XoEw+M94KuQTxGRL6TPmUmHopkNAJadkCiUpe40z6+uYg1y11eLek0gUFpC1oXAhk7X8Ij+db3tk7OfwTd4i0Qv/VzzUiAb8qX24+Os5I3/i/m8pOWXuzODtch1eqrECUoBCaYiWaZscUFw8atV47Tz437mDJ+Sq1bOmNncjb SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CS1PR84MB0072;7:RIxlxbujY+FAsih//NvS0VvhS5VtHGnz2Z9zglKqx8lmHBHh0XIYKLZQUjOq3FSbHLqZksa6k5qVXKqgGQJZWa4npgmMfQgKb7yaetdCBhdv+HNpUQg7rP5CjEWmvTsE0PaIuYzCTZph+7LDyMEavcjUHLXC0NSFyFzOy3RBlwFx77Bl0Rwyi5gcIOjJsA62f6pUY2PoBcae9fHZOn7xAci+o5mk0loZT7P3J7U07UEc X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2017 17:30:57.0734 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0072 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org Received-SPF: none client-ip=209.132.180.67; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org X-Spam-Score: 3.2 X-Spam-Score-Bar: +++ X-Spam-Action: no action X-Spam-Report: Action: no action Symbol: RCPT_COUNT_7(0.00) Symbol: MIME_GOOD(-0.10) Symbol: DMARC_NA(0.00) Symbol: R_SPF_NA(0.00) Symbol: R_DKIM_NA(0.00) Symbol: PRECEDENCE_BULK(0.00) Symbol: AUTH_NA(1.00) Symbol: RCVD_COUNT_8(0.00) Symbol: TO_DN_EQ_ADDR_SOME(0.00) Sy On 6/7/2017 5:33 PM, Kani, Toshimitsu wrote: > On Wed, 2017-06-07 at 14:06 -0700, Dan Williams wrote: >> On Wed, Jun 7, 2017 at 1:57 PM, Kani, Toshimitsu >> wrote: >>> On Wed, 2017-06-07 at 12:09 -0700, Dan Williams wrote: >>>> On Wed, Jun 7, 2017 at 11:49 AM, Toshi Kani >>>> 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. 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. If the spec isn't clear about the relationship between the bits, we could clarify that in the spec without bumping the revision number for the call. We could also check to see what a platform does if it gets a flag it doesn't know about. Would that be an Invalid Input Parameter? -- ljk > > Thanks, > -Toshi��칻�&�~�&���+-��ݶ��w��˛���m�b��Zr����^n�r���z���h����&���G���h�(�階�ݢj"���m�����z�ޖ���f���h���~�m� >