Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752522AbbDBUXZ (ORCPT ); Thu, 2 Apr 2015 16:23:25 -0400 Received: from mail-ie0-f178.google.com ([209.85.223.178]:33929 "EHLO mail-ie0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751083AbbDBUXX (ORCPT ); Thu, 2 Apr 2015 16:23:23 -0400 MIME-Version: 1.0 In-Reply-To: <1427872339-6688-2-git-send-email-hch@lst.de> References: <1427872339-6688-1-git-send-email-hch@lst.de> <1427872339-6688-2-git-send-email-hch@lst.de> Date: Thu, 2 Apr 2015 13:23:22 -0700 X-Google-Sender-Auth: zr6_ah7EoKLAwQWYOsWuJAbBRGk Message-ID: Subject: Re: [PATCH 1/2] x86: add support for the non-standard protected e820 type From: Yinghai Lu To: Christoph Hellwig Cc: linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, Linux Kernel Mailing List , "the arch/x86 maintainers" , Jens Axboe , ross.zwisler@linux.intel.com, Boaz Harrosh 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: 2317 Lines: 63 On Wed, Apr 1, 2015 at 12:12 AM, Christoph Hellwig wrote: > Various recent BIOSes support NVDIMMs or ADR using a non-standard > e820 memory type, and Intel supplied reference Linux code using this > type to various vendors. > > Wire this e820 table type up to export platform devices for the pmem > driver so that we can use it in Linux. > > Based on arlier work from Dave Jiang and > Dan Williams . > ... > @@ -748,7 +758,7 @@ u64 __init early_reserve_e820(u64 size, u64 align) > /* > * Find the highest page frame number we have available > */ > -static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned type) > +static unsigned long __init e820_end_pfn(unsigned long limit_pfn) > { > int i; > unsigned long last_pfn = 0; > @@ -759,7 +769,11 @@ static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned type) > unsigned long start_pfn; > unsigned long end_pfn; > > - if (ei->type != type) > + /* > + * Persistent memory is accounted as ram for purposes of > + * establishing max_pfn and mem_map. > + */ > + if (ei->type != E820_RAM && ei->type != E820_PRAM) > continue; > > start_pfn = ei->addr >> PAGE_SHIFT; > @@ -784,12 +798,12 @@ static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned type) > } > unsigned long __init e820_end_of_ram_pfn(void) > { > - return e820_end_pfn(MAX_ARCH_PFN, E820_RAM); > + return e820_end_pfn(MAX_ARCH_PFN); > } > > unsigned long __init e820_end_of_low_ram_pfn(void) > { > - return e820_end_pfn(1UL<<(32 - PAGE_SHIFT), E820_RAM); > + return e820_end_pfn(1UL<<(32 - PAGE_SHIFT)); > } You are using iomap_nocache to access pmem. Do you still need to account E820_PRAM to get those end_of_ram ? You should not need that to help to set kernel mapping. So please drop those not needed changes. Thanks Yinghai -- 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/