[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1456379247.29791.20.camel@intel.com>
Date: Thu, 25 Feb 2016 05:47:31 +0000
From: "Williams, Dan J" <dan.j.williams@...el.com>
To: "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: [GIT PULL] libnvdimm, nfit: fixes for 4.5-rc6
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
...to receive:
1/ Two fixes for compatibility with the ACPI 6.1 specification.
Without these fixes multi-interface DIMMs will fail to be probed, and
address range scrub commands to find memory errors will give results
that the kernel will mis-interpret. For multi-interface DIMMs Linux
will accept either the original 6.0 implementation or 6.1. For address
range scrub we'll only support 6.1 since ACPI formalized this DSM
differently than the original example [1] implemented in v4.2. The
expectation is that production systems will only ever ship the ACPI 6.1
address range scrub command definition.
2/ The wider async address range scrub work targeting 4.6 discovered
that the original synchronous implementation in 4.5 is not sizing its
return buffer correctly.
3/ Arnd caught that my recent fix to the size of the pfn_t flags missed
updating the flags variable used in the pmem driver.
4/ Toshi found that we mishandle the memremap() return value in
devm_memremap().
This branch has received a clean build success notification from the
kbuild robot across 105 configs.
[1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865:
Linux 4.5-rc4 (2016-02-14 13:05:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
for you to fetch changes up to c45442055dfdeb265cc20c9eeaa9fd11a75fbf51:
nvdimm: use 'u64' for pfn flags (2016-02-23 17:17:20 -0800)
----------------------------------------------------------------
Arnd Bergmann (1):
nvdimm: use 'u64' for pfn flags
Dan Williams (3):
nfit: fix multi-interface dimm handling, acpi6.1 compatibility
libnvdimm, tools/testing/nvdimm: fix 'ars_status' output buffer sizing
nfit: update address range scrub commands to the acpi 6.1 format
Toshi Kani (1):
devm_memremap: Fix error value when memremap failed
drivers/acpi/nfit.c | 90 ++++++++++++++++++++--------------------
drivers/nvdimm/bus.c | 20 ++++-----
drivers/nvdimm/pmem.c | 2 +-
include/linux/libnvdimm.h | 3 +-
include/uapi/linux/ndctl.h | 11 ++++-
kernel/memremap.c | 4 +-
tools/testing/nvdimm/test/nfit.c | 8 +++-
7 files changed, 75 insertions(+), 63 deletions(-)
commit c45442055dfdeb265cc20c9eeaa9fd11a75fbf51
Author: Arnd Bergmann <arnd@...db.de>
Date: Mon Feb 22 22:58:34 2016 +0100
nvdimm: use 'u64' for pfn flags
A recent bugfix changed pfn_t to always be 64-bit wide, but did not
change the code in pmem.c, which is now broken on 32-bit architectures
as reported by gcc:
In file included from ../drivers/nvdimm/pmem.c:28:0:
drivers/nvdimm/pmem.c: In function 'pmem_alloc':
include/linux/pfn_t.h:15:17: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
#define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3))
This changes the intermediate pfn_flags in struct pmem_device to
be 64 bit wide as well, so they can store the flags correctly.
Signed-off-by: Arnd Bergmann <arnd@...db.de>
Fixes: db78c22230d0 ("mm: fix pfn_t vs highmem")
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit 93f834df9c2d4e362dfdc4b05daa0a4e18814836
Author: Toshi Kani <toshi.kani@....com>
Date: Sat Feb 20 14:32:24 2016 -0800
devm_memremap: Fix error value when memremap failed
devm_memremap() returns an ERR_PTR() value in case of error.
However, it returns NULL when memremap() failed. This causes
the caller, such as the pmem driver, to proceed and oops later.
Change devm_memremap() to return ERR_PTR(-ENXIO) when memremap()
failed.
Signed-off-by: Toshi Kani <toshi.kani@....com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: <stable@...r.kernel.org>
Reviewed-by: Ross Zwisler <ross.zwisler@...ux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit 4577b0665515e0abc7bc72562d6328d179598815
Author: Dan Williams <dan.j.williams@...el.com>
Date: Wed Feb 17 13:08:58 2016 -0800
nfit: update address range scrub commands to the acpi 6.1 format
The original format of these commands from the "NVDIMM DSM Interface
Example" [1] are superseded by the ACPI 6.1 definition of the "NVDIMM Root
Device _DSMs" [2].
[1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
[2]: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf
"9.20.7 NVDIMM Root Device _DSMs"
Changes include:
1/ New 'restart' fields in ars_status, unfortunately these are
implemented in the middle of the existing definition so this change
is not backwards compatible. The expectation is that shipping
platforms will only ever support the ACPI 6.1 definition.
2/ New status values for ars_start ('busy') and ars_status ('overflow').
Cc: Vishal Verma <vishal.l.verma@...el.com>
Cc: Linda Knippers <linda.knippers@....com>
Cc: <stable@...r.kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit 747ffe11b440ef9ea752888806d3aac677ca52a4
Author: Dan Williams <dan.j.williams@...el.com>
Date: Fri Feb 19 15:21:14 2016 -0800
libnvdimm, tools/testing/nvdimm: fix 'ars_status' output buffer sizing
Use the output length specified in the command to size the receive
buffer rather than the arbitrary 4K limit.
This bug was hiding the fact that the ndctl implementation of
ndctl_bus_cmd_new_ars_status() was not specifying an output buffer size.
Cc: <stable@...r.kernel.org>
Cc: Vishal Verma <vishal.l.verma@...el.com>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit 6697b2cf69d4363266ca47eaebc49ef13dabc1c9
Author: Dan Williams <dan.j.williams@...el.com>
Date: Thu Feb 4 16:51:00 2016 -0800
nfit: fix multi-interface dimm handling, acpi6.1 compatibility
ACPI 6.1 clarified that multi-interface dimms require multiple control
region entries (DCRs) per dimm. Previously we were assuming that a
control region is only present when block-data-windows are present.
This implementation was done with an eye to be compatibility with the
looser ACPI 6.0 interpretation of this table.
1/ When coalescing the memory device (MEMDEV) tables for a single dimm,
coalesce on device_handle rather than control region index.
2/ Whenever we disocver a control region with non-zero block windows
re-scan for block-data-window (BDW) entries.
We may need to revisit this if a DIMM ever implements a format interface
outside of blk or pmem, but that is not on the foreseeable horizon.
Cc: <stable@...r.kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
Powered by blists - more mailing lists