Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031011AbbD1U53 (ORCPT ); Tue, 28 Apr 2015 16:57:29 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:34624 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965988AbbD1U50 (ORCPT ); Tue, 28 Apr 2015 16:57:26 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150428181203.35812.60474.stgit@dwillia2-desk3.amr.corp.intel.com> <20150428182417.35812.92834.stgit@dwillia2-desk3.amr.corp.intel.com> Date: Tue, 28 Apr 2015 13:57:25 -0700 Message-ID: Subject: Re: [PATCH v2 01/20] e820, efi: add ACPI 6.0 persistent memory types From: Dan Williams To: Andy Lutomirski Cc: linux-nvdimm , Ingo Molnar , Boaz Harrosh , Andrew Morton , "linux-kernel@vger.kernel.org" , Christoph Hellwig , Jens Axboe , Borislav Petkov , "H. Peter Anvin" , Matthew Wilcox , Thomas Gleixner , Linus Torvalds , Ross Zwisler Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1671 Lines: 37 On Tue, Apr 28, 2015 at 1:49 PM, Andy Lutomirski wrote: > On Tue, Apr 28, 2015 at 11:24 AM, Dan Williams wrote: >> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c >> index 11cc7d54ec3f..d38b53a7e9b2 100644 >> --- a/arch/x86/kernel/e820.c >> +++ b/arch/x86/kernel/e820.c >> @@ -149,6 +149,7 @@ static void __init e820_print_type(u32 type) >> case E820_UNUSABLE: >> printk(KERN_CONT "unusable"); >> break; >> + case E820_PMEM: >> case E820_PRAM: >> printk(KERN_CONT "persistent (type %u)", type); >> break; > > I'd kind of like to make it more clear what's going on here. It > doesn't help that the spec chose poor names. > > How about "NVDIMM physical aperture" for E820_PMEM and "legacy > persistent RAM" for E820_PRAM? The term "aperture" to me implies this BLK (mmio-windowed) mode of accessing persistent media that the NFIT specification introduces. In fact, those ranges are mapped E820_RESERVED. E820_PMEM really is a memory range that happens to be persistent. > Otherwise this looks generaly sensible, although I don't really > understand why e820_type_to_string and e820_print_type are different. e820_type_to_string() appears in /proc/iomem and seems to afford being more descriptive than e820_print_type() that just scrolls by in dmesg, but I'm just guessing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/