On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote: > On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig <[email protected]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
