On Tue, Nov 7, 2017 at 5:18 PM, wrote:
>
>
>> -Original Message-
>> From: Dan Williams [mailto:dan.j.willi...@intel.com]
>> Sent: Monday, November 6, 2017 5:32 PM
>> To: Pan, Lijun
>> Cc: linux-nvdimm@lists.01.org
>> Subject: Re: [PATCH] acpi/nfit: export read_only attribute of dimms
>>
> -Original Message-
> From: Dan Williams [mailto:dan.j.willi...@intel.com]
> Sent: Monday, November 6, 2017 5:32 PM
> To: Pan, Lijun
> Cc: linux-nvdimm@lists.01.org
> Subject: Re: [PATCH] acpi/nfit: export read_only attribute of dimms
>
> On Mon, Oct 30, 2017 at 1:41 PM, Lijun Pan wro
I think I've found a limitation in the badblocks implementation
(block/badblocks.c), which we now also use for nvdimm badblocks.
Consider the following operations:
badblocks_set(bb, 32, 1);
badblocks_set(bb, 34, 1);
badblocks_set(bb, 36, 1);
badblocks_show will now correctly report:
32 1
34 1
3
It was non-obvious that in the loop to add a new badblock, the entry
allocated was always consumed by adding it to the list. Ensure that it
happens by setting the 'bb' pointer to NULL when we add it to the list,
and at the end of the loop, free and error out if it was not added.
Cc: Dan Williams
The input/output size bounds being set in the various nd_bus_cmd_new_*
helpers for error injection commands were larger than they needed to be,
and platforms could reject these. Fix the bounds to be exactly as the
spec describes.
Cc: Dan Williams
Reported-by: Dariusz Dokupil
Signed-off-by: Visha
Ensure that the in/out sizes passed in the nd_cmd_package are sane for
the fixed output size commands (i.e. inject error and clear injected
error).
Cc: Dan Williams
Signed-off-by: Vishal Verma
---
tools/testing/nvdimm/test/nfit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
Hi
I am developing a driver that uses persistent memory for caching. A
persistent memory device can be mapped in several discontiguous ranges.
The kernel has a function vmap that takes an array of pointers to pages
and maps these pages to contiguous linear address space. However, it can't
be u
On Mon, Nov 6, 2017 at 6:50 PM, Elliott, Robert (Persistent Memory)
wrote:
>
>
>> -Original Message-
>> From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On
>> Behalf Of Dan Williams
>> Sent: Monday, November 06, 2017 5:32 PM
>> To: Lijun Pan
>> Cc: linux-nvdimm@lists.01.org
>
> >
> >
> >> [..]
> >> >> Yes, the GUID will specifically identify this range as "Virtio Shared
> >> >> Memory" (or whatever name survives after a bikeshed debate). The
> >> >> libnvdimm core then needs to grow a new region type that mostly
> >> >> behaves the same as a "pmem" region, but drivers/
