From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753400AbbDMJBh (ORCPT ); Mon, 13 Apr 2015 05:01:37 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46516 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751526AbbDMJBg (ORCPT ); Mon, 13 Apr 2015 05:01:36 -0400 Date: Mon, 13 Apr 2015 11:01:33 +0200 From: Greg KH To: Dan Williams Cc: Christoph Hellwig , linux-nvdimm , linux-fsdevel , "linux-kernel@vger.kernel.org" , X86 ML , Jens Axboe Subject: Re: [Linux-nvdimm] another pmem variant Message-ID: <20150413090133.GA4928@kroah.com> References: <1427299449-26722-1-git-send-email-hch@lst.de> <20150325164428.GA1099@lst.de> 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 On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote: > On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig wrote: > > On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote: > >> This is mostly ok and does not collide too much with the upcoming ACPI > >> mechanism for this stuff. I do worry that the new > >> "memmap=nn[KMG]!ss[KMG]" kernel command line option will only be > >> relevant for at most one kernel cycle given the imminent publication > >> of the spec that unblocks our release. > > > > I don't think we can just get rid of it as legacy systems won't be > > upgraded to the new discovery mechanism. Or do you mean you plan to > > introduce a better override on the command line? In that case speak > > up now! > > The kernel command line would simply be the standard/existing memmap= > to reserve a memory range. Then, when the platform device loads, it > does a request_firmware() to inject a binary table that further carves > memory into ranges to which the pmem driver attaches. No need for the > legacy system BIOS to be upgraded to the "new way". Um, what parses that "binary table"? The kernel better not be doing that, as that's not what the firmware interface is for. The firmware interface is for "pass through" only directly to hardware. thanks, greg k-h