From: Randy Dunlap <rdunlap(a)infradead.org>
Do some wordsmithing and copy editing on the maintainer-entry-profile
profile (template, guide):
- fix punctuation
- fix some wording
- use "-rc" consistently
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Jonathan Corbet <corbet(a)lwn.net>
Documentation/maintainer/maintainer-entry-profile.rst | 12 +++++-----
1 file changed, 6 insertions(+), 6 deletions(-)
@@ -7,7 +7,7 @@ The Maintainer Entry Profile supplements
(submitting-patches, submitting drivers...) with
subsystem/device-driver-local customs as well as details about the patch
submission life-cycle. A contributor uses this document to level set
-their expectations and avoid common mistakes, maintainers may use these
+their expectations and avoid common mistakes; maintainers may use these
profiles to look across subsystems for opportunities to converge on
@@ -26,7 +26,7 @@ Example questions to consider:
- Does the subsystem have a patchwork instance? Are patchwork state
- Any bots or CI infrastructure that watches the list, or automated
- testing feedback that the subsystem gates acceptance?
+ testing feedback that the subsystem uses to gate acceptance?
- Git branches that are pulled into -next?
- What branch should contributors submit against?
- Links to any other Maintainer Entry Profiles? For example a
@@ -54,8 +54,8 @@ One of the common misunderstandings of s
sent at any time before the merge window closes and can still be
considered for the next -rc1. The reality is that most patches need to
be settled in soaking in linux-next in advance of the merge window
-opening. Clarify for the submitter the key dates (in terms rc release
-week) that patches might considered for merging and when patches need to
+opening. Clarify for the submitter the key dates (in terms of -rc release
+week) that patches might be considered for merging and when patches need to
wait for the next -rc. At a minimum:
- Last -rc for new feature submissions:
@@ -70,8 +70,8 @@ wait for the next -rc. At a minimum:
- Last -rc to merge features: Deadline for merge decisions
Indicate to contributors the point at which an as yet un-applied patch
set will need to wait for the NEXT+1 merge window. Of course there is no
- obligation to ever except any given patchset, but if the review has not
- concluded by this point the expectation the contributor should wait and
+ obligation to ever accept any given patchset, but if the review has not
+ concluded by this point the expectation is the contributor should wait and
resubmit for the following merge window.
Changes since v7 :
* Addressed various review comments from Aneesh, Ira and Mpe.
* Removed the 'payload_offset' field from 'struct nd_pdsm_cmd_pkg' and
replaced it with some reserved fields [ Aneesh ].
* Updated the doc and description for patch that fetches dimm health
information from PHYP clarifying bit-ordering [ Mpe and Ira ].
* Updated the patch title & description for patch exporting
'seq_buf_printf'. [ Christoph Hellwig ]
* Fix types of various newly introduced vars in papr_scm.c [ Ira ].
* Fixed a typo in 'papr_scm_pdsm.h' [ Ira ]
The PAPR standard provides mechanisms to query the health and
performance stats of an NVDIMM via various hcalls as described in
Ref. Until now these stats were never available nor exposed to the
user-space tools like 'ndctl'. This is partly due to PAPR platform not
having support for ACPI and NFIT. Hence 'ndctl' is unable to query and
report the dimm health status and a user had no way to determine the
current health status of a NDVIMM.
To overcome this limitation, this patch-set updates papr_scm kernel
module to query and fetch NVDIMM health stats using hcalls described
in Ref. This health and performance stats are then exposed to
userspace via sysfs and PAPR-NVDIMM-Specific-Methods(PDSM) issued by
These changes coupled with proposed ndtcl changes located at Ref
should provide a way for the user to retrieve NVDIMM health status
Below is a sample output using proposed kernel + ndctl for PAPR NVDIMM
in a emulation environment:
# ndctl list -DH
Dimm health report output on a pseries guest lpar with vPMEM or HMS
based NVDIMMs that are in perfectly healthy conditions:
# ndctl list -d nmem0 -H
PDSM requests are issued by vendor specific code in libndctl to
execute certain operations or fetch information from NVDIMMS. PDSMs
requests can be sent to papr_scm module via libndctl(userspace) and
libnvdimm (kernel) using the ND_CMD_CALL ioctl command which can be
handled in the dimm control function papr_scm_ndctl(). Current
patchset proposes a single PDSM to retrieve NVDIMM health, defined in
the newly introduced uapi header named 'papr_scm_pdsm.h'. Support for
more PDSMs will be added in future.
Structure of the patch-set
The patch-set starts with a doc patch documenting details of hcall
H_SCM_HEALTH. Second patch exports kernel symbol seq_buf_printf()
thats used in subsequent patches to generate sysfs attribute content.
Third patch implements support for fetching NVDIMM health information
from PHYP and partially exposing it to user-space via a NVDIMM sysfs
Fourth patches deal with implementing support for servicing PDSM
commands in papr_scm module.
Finally the last patch implements support for servicing PDSM
'PAPR_SCM_PDSM_HEALTH' that returns the NVDIMM health information to
 "Power Architecture Platform Reference"
 commit 58b278f568f0
("powerpc: Provide initial documentation for PAPR hcalls")
 "Linux on Power Architecture Platform Reference"
Vaibhav Jain (5):
powerpc: Document details on H_SCM_HEALTH hcall
seq_buf: Export seq_buf_printf
powerpc/papr_scm: Fetch nvdimm health information from PHYP
ndctl/papr_scm,uapi: Add support for PAPR nvdimm specific methods
powerpc/papr_scm: Implement support for PAPR_SCM_PDSM_HEALTH
Documentation/ABI/testing/sysfs-bus-papr-scm | 27 ++
Documentation/powerpc/papr_hcalls.rst | 45 ++-
arch/powerpc/include/uapi/asm/papr_scm_pdsm.h | 175 +++++++++
arch/powerpc/platforms/pseries/papr_scm.c | 363 +++++++++++++++++-
include/uapi/linux/ndctl.h | 1 +
lib/seq_buf.c | 1 +
6 files changed, 599 insertions(+), 13 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-papr-scm
create mode 100644 arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
Here's a copy your invoice! We appreciate your prompt payment.
Thanks for your business
------------------------ Invoice Summary --------------------------
Invoice Date: 06/01/2020
Amount Due: $1,150.00
The complete version has been provided as an attachment to this email.
Hello stable team,
These patches have been shipping in mainline since v5.7-rc1 with no
reported issues. They address long standing problems in libnvdimm's
handling of namespace provisioning relative to alignment constraints
including crashes trying to even load the driver on some PowerPC
I did fold one build fix  into "libnvdimm/region: Introduce an 'align'
attribute" so as to not convey the bisection breakage to -stable.
Please consider them for v5.4-stable. They do pass the latest
version of the ndctl unit tests.
: 04ff4863e126 libnvdimm/region: Fix build error
Original cover letter for the series:
Aneesh reports that PowerPC requires 16MiB alignment for the address
range passed to devm_memremap_pages(), and Jeff reports that it is
possible to create a misaligned namespace which blocks future namespace
creation in that region. Both of these issues require namespace
alignment to be managed at the region level rather than padding at the
namespace level which has been a broken approach to date.
Introduce memremap_compat_align() to indicate the hard requirements of
an arch's memremap_pages() implementation. Use the maximum known
memremap_compat_align() to set the default namespace alignment for
libnvdimm. Consult that alignment when allocating free space. Finally,
allow the default region alignment to be overridden to maintain the same
namespace creation capability as previous kernels (modulo dax operation
not being supported with a non-zero start_pad).
Aneesh Kumar K.V (1):
libnvdimm/pfn_dev: Don't clear device memmap area during generic namespace probe
Dan Williams (6):
mm/memremap_pages: Kill unused __devm_memremap_pages()
mm/memremap_pages: Introduce memremap_compat_align()
libnvdimm/pfn: Prevent raw mode fallback if pfn-infoblock valid
libnvdimm/namespace: Enforce memremap_compat_align()
libnvdimm/region: Introduce NDD_LABELING
libnvdimm/region: Introduce an 'align' attribute
arch/powerpc/Kconfig | 1
arch/powerpc/mm/ioremap.c | 21 +++++
arch/powerpc/platforms/pseries/papr_scm.c | 2
drivers/acpi/nfit/core.c | 4 +
drivers/nvdimm/dimm.c | 2
drivers/nvdimm/dimm_devs.c | 95 +++++++++++++++++----
drivers/nvdimm/namespace_devs.c | 28 ++++++
drivers/nvdimm/nd.h | 3 -
drivers/nvdimm/pfn.h | 12 +++
drivers/nvdimm/pfn_devs.c | 48 +++++++++--
drivers/nvdimm/region_devs.c | 130 ++++++++++++++++++++++++++---
include/linux/io.h | 2
include/linux/libnvdimm.h | 2
include/linux/memremap.h | 8 ++
include/linux/mmzone.h | 1
lib/Kconfig | 3 +
mm/memremap.c | 23 +++++
17 files changed, 335 insertions(+), 50 deletions(-)
Do you want a Mobile Apps (Android/iOS app)for your Business?
We develop low cost mobile applications forglobal enterprises that help them grow their business.
We are an IT company, which focuseson App development, iOS appdevelopment, Android app development, HTML5 app, Mac OSX app, Mobile appdevelopment and Custom Web apps.
(Create app for your business)
If interested, please write me back with yourrequirement and ideas,