From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752758AbbBSKCA (ORCPT ); Thu, 19 Feb 2015 05:02:00 -0500 Received: from mail-wg0-f43.google.com ([74.125.82.43]:59765 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752323AbbBSKB6 (ORCPT ); Thu, 19 Feb 2015 05:01:58 -0500 Date: Thu, 19 Feb 2015 11:01:51 +0100 From: Ingo Molnar To: Dan Williams Cc: Christoph Hellwig , Boaz Harrosh , Matthew Wilcox , Ingo Molnar , Ross Zwisler , x86@kernel.org, linux-kernel , "Roger C. Pao" , Thomas Gleixner , Linus Torvalds , linux-nvdimm , "H. Peter Anvin" Subject: Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips Message-ID: <20150219100151.GA591@gmail.com> References: <54E1CF5B.9020905@plexistor.com> <20150216220302.GF3364@wil.cx> <54E2FEF2.8060701@plexistor.com> <20150219004731.GA5477@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Dan Williams wrote: > On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig wrote: > > On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: > >> In fact it was originally "type-6" until ACPI 5 > >> claimed that number for official use, so these > >> platforms, with early proof-of-concept nvdimm support, > >> have already gone through one transition to a new > >> number. They need to do the same once an official > >> number for nvdimm support is published. > >> > >> Put another way, these early platforms are already > >> using out-of-tree patches for nvdimm enabling. They > >> can continue to do so, or switch to standard methods > >> when the standard is published. > > > > Not supporting hardware that is widely avaiable (I have > > some, too) is not very user friendly. > > Yes, as I agreed with Ingo, allowing a driver to assume > control of an unknown memory type with a warning or a > kernel taint seems fine. If someone cooks up such a patch I can apply it. Thanks, Ingo