lkml.org 
[lkml]   [2015]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linux-nvdimm] another pmem variant
On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote:
> On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig <hch@lst.de> 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


\
 
 \ /
  Last update: 2015-04-13 11:41    [W:0.090 / U:5.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site