On 02/19/2015 02:47 AM, 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. > > I'll submit a patch allowing a nvdimm_type= kernel option that allows > to detect them, but will do nothing by default. The code needed is very > small and it would be very useful for all kinds of projects. >
I do not see why you need the nvdimm_type= kernel option at all. I have here a script that auto detects any NvDIMM. It works with all the chips that I have access to. And Also it has support for if you have memmap=sss\$aaa. For all these detected regions it will load a pmem device. It is easy to filter for any type of memory you want. What will the (annoying) kernel option give you? OK I might be jumping the guns, send the patch and I'll look at it. Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
