From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751674AbbBPWD2 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 16 Feb 2015 17:03:28 -0500
Received: from mga09.intel.com ([134.134.136.24]:54266 "EHLO mga09.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751494AbbBPWD1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Feb 2015 17:03:27 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.09,590,1418112000"; 
   d="scan'208";a="528349864"
Date: Mon, 16 Feb 2015 17:03:02 -0500
From: Matthew Wilcox <willy@linux.intel.com>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: Ingo Molnar <mingo@redhat.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>, x86@kernel.org,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "Roger C. Pao" <rcpao.enmotus@gmail.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-nvdimm <linux-nvdimm@ml01.01.org>,
        "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
Message-ID: <20150216220302.GF3364@wil.cx>
References: <54E1CF5B.9020905@plexistor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54E1CF5B.9020905@plexistor.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 16, 2015 at 01:07:07PM +0200, Boaz Harrosh wrote:
> 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)

Hang on.  NV-DIMM chips don't know anyhing about E820 tables.  They don't
have anything in them that says "I am type 12!".  How they are reported
is up to the BIOS.  Just because your BIOS vendor has chosen to report
tham as type 12 doesn't mean that any other BIOS vedor is going to have
done the same thing.

Fortunately, the BIOS people have all got together and decided what
they're going to do, and it's not type 12.  Unfortunately, I think
I'm bound by various agreements to not say what they are going to do
until they do.  But putting this temporary workaround in the kernel to
accomodate one BIOS vendor's unreleased experimental code seems like
entirely the wrong idea.