Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752507AbbBWM3p (ORCPT ); Mon, 23 Feb 2015 07:29:45 -0500 Received: from mail-we0-f179.google.com ([74.125.82.179]:41997 "EHLO mail-we0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751898AbbBWM3o (ORCPT ); Mon, 23 Feb 2015 07:29:44 -0500 Message-ID: <54EB1D33.3050107@plexistor.com> Date: Mon, 23 Feb 2015 14:29:39 +0200 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ingo Molnar , Ross Zwisler , x86@kernel.org, linux-kernel , "Roger C. Pao" , Dan Williams , Thomas Gleixner , Linus Torvalds , linux-nvdimm , "H. Peter Anvin" , Matthew Wilcox , Andy Lutomirski , Christoph Hellwig Subject: [PATCH 0/3 v2] e820: Fix handling of NvDIMM chips Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2268 Lines: 62 Hi [v2] * Added warning at bring up about unknown type * Added an extra patch to warn-print in request_resource * changed name from NvDIMM-12 => unknown-12 I wish we would reconsider this. So we need to suffer until some unknown future when ACPI decides to reuse type-12. When this happens we can fix it then, NO? * Now based on 4.0-rc1 If someone still has objections to [PATCH 3A/3] which is the most simple thing to do, then We will be forced to do [PATCH 3B/3] ugliness. Ingo your call. [v1] There is a deficiency in current e820.c handling where unknown new memory-chip types come up as a BUSY resource when some other driver (like pmem) tries to call request_mem_region_exclusive() on that resource. Even though, actually there is nothing using it. >From inspecting the code and the history of e820.c it looks like a BUG. In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use) The patches below first fixes the above problem for any future type memory, so external drivers can access these mem chips. I then also add the NvDIMM type-12 memory constant so it comes up nice in dprints and at /proc/iomem Just as before all these chips are very much usable with the pmem driver. This lets us remove the hack for type-12 NvDIMMs that ignores the return code from request_mem_region_exclusive() in pmem.c. For all the pmem people. I maintain a tree with these patches and latest pmem code here: git://git.open-osd.org/pmem.git [web-view:http://git.open-osd.org/gitweb.cgi?p=pmem.git;a=summary] List of patches: [PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY The main fix [PATCH 2/3] resource: Add new flag IORESOURCE_WARN (64bit) Warn in request_resource [PATCH 3A/3] e820: Add the unknown-12 Memory type (DDR3-NvDIMM) Please accept this simple patch [PATCH 3B/3] e820: dynamic unknown-xxx names (for DDR3-NvDIMM) Else we need this crap Thanks Boaz -- 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/