linux-nvdimm.lists.01.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-11 15:48 Dan Williams
  2019-09-11 15:48 ` [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams
                   ` (4 more replies)
  0 siblings, 5 replies; 53+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
  To: linux-kernel
  Cc: Alexandre Belloni, ksummit-discuss, Jonathan Corbet,
	Daniel Vetter, linux-nvdimm, Greg Kroah-Hartman, Olof Johansson,
	Steve French, Joe Perches, Thomas Gleixner,
	Mauro Carvalho Chehab, Linus Torvalds, Dmitry Vyukov,
	Tobin C. Harding

Changes since v1 [1]:
- Simplify the profile to a hopefully non-controversial set of
  attributes that address the most common sources of contributor
  confusion, or maintainer frustration.
- Rename "Subsystem Profile" to "Maintainer Entry Profile". Not every
  entry in MAINTAINERS represents a full subsystem. There may be driver
  local considerations to communicate to a submitter in addition to wider
  subsystem guidelines. 
- Delete the old P: tag in MAINTAINERS rather than convert to a new E:
  tag (Joe Perches).
[1]:  http://lore.kernel.org/r/154225759358.2499188.15268218778137905050.stgit@dwillia2-desk3.amr.corp.intel.com

---

At last years Plumbers Conference I proposed the Maintainer Entry
Profile as a document that a maintainer can provide to set contributor
expectations and provide fodder for a discussion between maintainers
about the merits of different maintainer policies.

For those that did not attend, the goal of the Maintainer Entry Profile,
and the Maintainer Handbook more generally, is to provide a desk
reference for maintainers both new and experienced. The session
introduction was:

    The first rule of kernel maintenance is that there are no hard and
    fast rules. That state of affairs is both a blessing and a curse. It
    has served the community well to be adaptable to the different
    people and different problem spaces that inhabit the kernel
    community. However, that variability also leads to inconsistent
    experiences for contributors, little to no guidance for new
    contributors, and unnecessary stress on current maintainers. There
    are quite a few of people who have been around long enough to make
    enough mistakes that they have gained some hard earned proficiency.
    However if the kernel community expects to keep growing it needs to
    be able both scale the maintainers it has and ramp new ones without
    necessarily let them make a decades worth of mistakes to learn the
    ropes. 

To be clear, the proposed document does not impose or suggest new
rules. Instead it provides an outlet to document the unwritten rules
and policies in effect for each subsystem, and that each subsystem
might decide differently for whatever reason.


---

Dan Williams (3):
      MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
      Maintainer Handbook: Maintainer Entry Profile
      libnvdimm, MAINTAINERS: Maintainer Entry Profile


 Documentation/maintainer/index.rst                 |    1 
 .../maintainer/maintainer-entry-profile.rst        |   99 ++++++++++++++++++++
 Documentation/nvdimm/maintainer-entry-profile.rst  |   64 +++++++++++++
 MAINTAINERS                                        |   20 ++--
 4 files changed, 175 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/maintainer/maintainer-entry-profile.rst
 create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
  2019-09-11 15:48 [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
@ 2019-09-11 15:48 ` Dan Williams
  2019-09-13 15:37   ` [Ksummit-discuss] " Mauro Carvalho Chehab
  2019-09-11 15:48 ` [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 53+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
  To: linux-kernel; +Cc: Joe Perches, ksummit-discuss, linux-nvdimm

Fixup some P: entries to be M: and delete the others that do not include an
email address. The P: tag will be used to indicate the location of a
Profile for a given MAINTAINERS entry.

Cc: Joe Perches <joe@perches.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 MAINTAINERS |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e7a47b5210fd..3f171339df53 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -76,7 +76,6 @@ trivial patch so apply some common sense.
 
 Descriptions of section entries:
 
-	P: Person (obsolete)
 	M: Mail patches to: FullName <address@domain>
 	R: Designated reviewer: FullName <address@domain>
 	   These reviewers should be CCed on patches.
@@ -811,7 +810,7 @@ S:	Orphan
 F:	drivers/usb/gadget/udc/amd5536udc.*
 
 AMD GEODE PROCESSOR/CHIPSET SUPPORT
-P:	Andres Salomon <dilinger@queued.net>
+M:	Andres Salomon <dilinger@queued.net>
 L:	linux-geode@lists.infradead.org (moderated for non-subscribers)
 W:	http://www.amd.com/us-en/ConnectivitySolutions/TechnicalResources/0,,50_2334_2452_11363,00.html
 S:	Supported
@@ -10085,7 +10084,6 @@ F:	drivers/staging/media/tegra-vde/
 
 MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
 M:	Mauro Carvalho Chehab <mchehab@kernel.org>
-P:	LinuxTV.org Project
 L:	linux-media@vger.kernel.org
 W:	https://linuxtv.org
 Q:	http://patchwork.kernel.org/project/linux-media/list/
@@ -13452,7 +13450,6 @@ S:	Maintained
 F:	arch/mips/ralink
 
 RALINK RT2X00 WIRELESS LAN DRIVER
-P:	rt2x00 project
 M:	Stanislaw Gruszka <sgruszka@redhat.com>
 M:	Helmut Schaa <helmut.schaa@googlemail.com>
 L:	linux-wireless@vger.kernel.org
@@ -13787,7 +13784,6 @@ S:	Supported
 F:	drivers/net/ethernet/rocker/
 
 ROCKETPORT DRIVER
-P:	Comtrol Corp.
 W:	http://www.comtrol.com
 S:	Maintained
 F:	Documentation/driver-api/serial/rocket.rst
@@ -14668,15 +14664,13 @@ F:	drivers/video/fbdev/simplefb.c
 F:	include/linux/platform_data/simplefb.h
 
 SIMTEC EB110ATX (Chalice CATS)
-P:	Ben Dooks
-P:	Vincent Sanders <vince@simtec.co.uk>
+M:	Vincent Sanders <vince@simtec.co.uk>
 M:	Simtec Linux Team <linux@simtec.co.uk>
 W:	http://www.simtec.co.uk/products/EB110ATX/
 S:	Supported
 
 SIMTEC EB2410ITX (BAST)
-P:	Ben Dooks
-P:	Vincent Sanders <vince@simtec.co.uk>
+M:	Vincent Sanders <vince@simtec.co.uk>
 M:	Simtec Linux Team <linux@simtec.co.uk>
 W:	http://www.simtec.co.uk/products/EB2410ITX/
 S:	Supported

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply related	[flat|nested] 53+ messages in thread

* [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
  2019-09-11 15:48 [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
  2019-09-11 15:48 ` [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams
@ 2019-09-11 15:48 ` Dan Williams
  2019-09-11 17:34   ` [Ksummit-discuss] " Verma, Vishal L
                     ` (2 more replies)
  2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
                   ` (2 subsequent siblings)
  4 siblings, 3 replies; 53+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
  To: linux-kernel
  Cc: Alexandre Belloni, ksummit-discuss, Jonathan Corbet,
	Greg Kroah-Hartman, linux-nvdimm, Joe Perches, Dmitry Vyukov,
	Daniel Vetter, Olof Johansson, Thomas Gleixner,
	Mauro Carvalho Chehab, Linus Torvalds, Steve French,
	Tobin C. Harding

As presented at the 2018 Linux Plumbers conference [1], the Maintainer
Entry Profile (formerly Subsystem Profile) is proposed as a way to reduce
friction between committers and maintainers and encourage conversations
amongst maintainers about common best practices. While coding-style,
submit-checklist, and submitting-drivers lay out some common expectations
there remain local customs and maintainer preferences that vary by
subsystem.

The profile contains short answers to some of the common policy questions a
contributor might have that are local to the subsystem / device-driver, or
otherwise not covered by the top-level process documents.

Overview: General introduction to how the subsystem operates
Submit Checklist Addendum: Mechanical items that gate submission staging
Key Cycle Dates:
 - Last -rc for new feature submissions: Expected lead time for submissions
 - Last -rc to merge features: Deadline for merge decisions
Coding Style Addendum: Clarifications of local style preferences
Resubmit Cadence: When to ping the maintainer
Checkpatch / Style Cleanups: Policy on pure cleanup patches

See Documentation/maintainer/maintainer-entry-profile.rst for more details,
and a follow-on example profile for the libnvdimm subsystem.

[1]: https://linuxplumbersconf.org/event/2/contributions/59/

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Steve French <stfrench@microsoft.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tobin C. Harding <me@tobin.cc>
Cc: Olof Johansson <olof@lixom.net>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joe Perches <joe@perches.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 Documentation/maintainer/index.rst                 |    1 
 .../maintainer/maintainer-entry-profile.rst        |   99 ++++++++++++++++++++
 MAINTAINERS                                        |    4 +
 3 files changed, 104 insertions(+)
 create mode 100644 Documentation/maintainer/maintainer-entry-profile.rst

diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst
index 56e2c09dfa39..d904e74e1159 100644
--- a/Documentation/maintainer/index.rst
+++ b/Documentation/maintainer/index.rst
@@ -12,4 +12,5 @@ additions to this manual.
    configure-git
    rebasing-and-merging
    pull-requests
+   maintainer-entry-profile
 
diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst
new file mode 100644
index 000000000000..aaedf4d6dbf7
--- /dev/null
+++ b/Documentation/maintainer/maintainer-entry-profile.rst
@@ -0,0 +1,99 @@
+.. _maintainerentryprofile:
+
+Maintainer Entry Profile
+========================
+
+The Maintainer Entry Profile supplements the top-level process documents
+(coding-style, submitting-patches...) with subsystem/device-driver-local
+customs as well as details about the patch submission lifecycle. A
+contributor uses this document to level set their expectations and avoid
+common mistakes, maintainers may use these profiles to look across
+subsystems for opportunities to converge on common practices.
+
+
+Overview
+--------
+Provide an introduction to how the subsystem operates. While MAINTAINERS
+tells the contributor where to send patches for which files, it does not
+convey other subsystem-local infrastructure and mechanisms that aid
+development.
+Example questions to consider:
+- Are there notifications when patches are applied to the local tree, or
+  merged upstream?
+- Does the subsystem have a patchwork instance?
+- Any bots or CI infrastructure that watches the list?
+- Git branches that are pulled into -next?
+- What branch should contributors submit against?
+- Links to any other Maintainer Entry Profiles? For example a
+  device-driver may point to an entry for its parent subsystem. This makes
+  the contributor aware of obligations a maintainer may have have for
+  other maintainers in the submission chain.
+
+
+Submit Checklist Addendum
+-------------------------
+List mandatory and advisory criteria, beyond the common "submit-checklist",
+for a patch to be considered healthy enough for maintainer attention.
+For example: "pass checkpatch.pl with no errors, or warning. Pass the
+unit test detailed at $URI".
+
+
+Key Cycle Dates
+---------------
+One of the common misunderstandings of submitters is that patches can be
+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
+wait for the next -rc. At a minimum:
+- Last -rc for new feature submissions:
+  New feature submissions targeting the next merge window should have
+  their first posting for consideration before this point. Patches that
+  are submitted after this point should be clear that they are targeting
+  the NEXT+1 merge window, or should come with sufficient justification
+  why they should be considered on an expedited schedule. A general
+  guideline is to set expectation with contributors that new feature
+  submissions should appear before -rc5.
+
+- 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
+  resubmit for the following merge window.
+
+Optional:
+- First -rc at which the development baseline branch, listed in the
+  overview section, should be considered ready for new submissions.
+
+
+Coding Style Addendum
+---------------------
+While the top-level "coding-style" document covers most style
+considerations there are still discrepancies and local preferences
+across subsystems. If a submitter should be aware of incremental / local
+style guidelines like x-mas tree variable declarations, indentation
+for multi line statements, function definition style, etc., list them
+here.
+
+
+Review Cadence
+--------------
+One of the largest sources of contributor angst is how soon to ping
+after a patchset has been posted without receiving any feedback. In
+addition to specifying how long to wait before a resubmission this
+section can also indicate a preferred style of update like, resend the
+full series, or privately send a reminder email. This section might also
+list how review works for this code area and methods to get feedback
+that are not directly from the maintainer.
+
+
+Style Cleanup Patches
+---------------------
+For subsystems with long standing code bases it is reasonable to decline
+to accept pure coding-style fixup patches. This is where you can let
+contributors know "Standalone style-cleanups are welcome",
+"Style-cleanups to existing code only welcome with other feature
+changes", or “Standalone style-cleanups to existing code are not
+welcome".
diff --git a/MAINTAINERS b/MAINTAINERS
index 3f171339df53..e5d111a86e61 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -98,6 +98,10 @@ Descriptions of section entries:
 	   Obsolete:	Old code. Something tagged obsolete generally means
 			it has been replaced by a better system and you
 			should be using that.
+	P: Subsystem Profile document for more details submitting
+	   patches to the given subsystem. This is either an in-tree file,
+	   or a URI. See Documentation/maintainer/maintainer-entry-profile.rst
+	   for details.
 	F: Files and directories with wildcard patterns.
 	   A trailing slash includes all files and subdirectory files.
 	   F:	drivers/net/	all files in and below drivers/net

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply related	[flat|nested] 53+ messages in thread

* [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 15:48 [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
  2019-09-11 15:48 ` [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams
  2019-09-11 15:48 ` [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
@ 2019-09-11 15:48 ` Dan Williams
  2019-09-11 17:42   ` [Ksummit-discuss] " Vishal Verma
                     ` (3 more replies)
  2019-09-11 16:40 ` [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen
  2019-09-12 13:10 ` Bart Van Assche
  4 siblings, 4 replies; 53+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
  To: linux-kernel; +Cc: ksummit-discuss, linux-nvdimm

Document the basic policies of the libnvdimm subsystem and provide a first
example of a Maintainer Entry Profile for others to duplicate and edit.

Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 Documentation/nvdimm/maintainer-entry-profile.rst |   64 +++++++++++++++++++++
 MAINTAINERS                                       |    4 +
 2 files changed, 68 insertions(+)
 create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst

diff --git a/Documentation/nvdimm/maintainer-entry-profile.rst b/Documentation/nvdimm/maintainer-entry-profile.rst
new file mode 100644
index 000000000000..c102950f2257
--- /dev/null
+++ b/Documentation/nvdimm/maintainer-entry-profile.rst
@@ -0,0 +1,64 @@
+LIBNVDIMM Maintainer Entry Profile
+==================================
+
+Overview
+--------
+The libnvdimm subsystem manages persistent memory across multiple
+architectures. The mailing list, is tracked by patchwork here:
+https://patchwork.kernel.org/project/linux-nvdimm/list/
+...and that instance is configured to give feedback to submitters on
+patch acceptance and upstream merge. Patches are merged to either the
+'libnvdimm-fixes', or 'libnvdimm-for-next' branch. Those branches are
+available here:
+https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/
+
+In general patches can be submitted against the latest -rc, however if
+the incoming code change is dependent on other pending changes then the
+patch should be based on the libnvdimm-for-next branch. However, since
+persistent memory sits at the intersection of storage and memory there
+are cases where patches are more suitable to be merged through a
+Filesystem or the Memory Management tree. When in doubt copy the nvdimm
+list and the maintainers will help route.
+
+Submissions will be exposed to the kbuild robot for compile regression
+testing. It helps to get a success notification from that infrastructure
+before submitting, but it is not required.
+
+
+Submit Checklist Addendum
+-------------------------
+There are unit tests for the subsystem via the ndctl utility:
+https://github.com/pmem/ndctl
+Those tests need to be passed before the patches go upstream, but not
+necessarily before initial posting. Contact the list if you need help
+getting the test environment set up.
+
+
+Key Cycle Dates
+---------------
+New submissions can be sent at any time, but if they intend to hit the
+next merge window they should be sent before -rc4, and ideally
+stabilized in the libnvdimm-for-next branch by -rc6. Of course if a
+patch set requires more than 2 weeks of review -rc4 is already too late
+and some patches may require multiple development cycles to review.
+
+
+Coding Style Addendum
+---------------------
+libnvdimm expects multi-line statements to be double indented. I.e.
+
+        if (x...
+                        && ...y) {
+
+
+Review Cadence
+--------------
+In general, please wait up to one week before pinging for feedback. A
+private mail reminder is preferred. Alternatively ask for other
+developers that have Reviewed-by tags for libnvdimm changes to take a
+look and offer their opinion.
+
+
+Style Cleanup Patches
+---------------------
+Standalone style-cleanups are welcome.
diff --git a/MAINTAINERS b/MAINTAINERS
index e5d111a86e61..2be1e18a368e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9185,6 +9185,7 @@ M:	Dan Williams <dan.j.williams@intel.com>
 M:	Vishal Verma <vishal.l.verma@intel.com>
 M:	Dave Jiang <dave.jiang@intel.com>
 L:	linux-nvdimm@lists.01.org
+P:	Documentation/nvdimm/maintainer-entry-profile.rst
 Q:	https://patchwork.kernel.org/project/linux-nvdimm/list/
 S:	Supported
 F:	drivers/nvdimm/blk.c
@@ -9195,6 +9196,7 @@ M:	Vishal Verma <vishal.l.verma@intel.com>
 M:	Dan Williams <dan.j.williams@intel.com>
 M:	Dave Jiang <dave.jiang@intel.com>
 L:	linux-nvdimm@lists.01.org
+P:	Documentation/nvdimm/maintainer-entry-profile.rst
 Q:	https://patchwork.kernel.org/project/linux-nvdimm/list/
 S:	Supported
 F:	drivers/nvdimm/btt*
@@ -9204,6 +9206,7 @@ M:	Dan Williams <dan.j.williams@intel.com>
 M:	Vishal Verma <vishal.l.verma@intel.com>
 M:	Dave Jiang <dave.jiang@intel.com>
 L:	linux-nvdimm@lists.01.org
+P:	Documentation/nvdimm/maintainer-entry-profile.rst
 Q:	https://patchwork.kernel.org/project/linux-nvdimm/list/
 S:	Supported
 F:	drivers/nvdimm/pmem*
@@ -9223,6 +9226,7 @@ M:	Dave Jiang <dave.jiang@intel.com>
 M:	Keith Busch <keith.busch@intel.com>
 M:	Ira Weiny <ira.weiny@intel.com>
 L:	linux-nvdimm@lists.01.org
+P:	Documentation/nvdimm/maintainer-entry-profile.rst
 Q:	https://patchwork.kernel.org/project/linux-nvdimm/list/
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
 S:	Supported

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply related	[flat|nested] 53+ messages in thread

* Re: [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-11 15:48 [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
                   ` (2 preceding siblings ...)
  2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
@ 2019-09-11 16:40 ` Martin K. Petersen
  2019-09-12 13:31   ` [Ksummit-discuss] " Bart Van Assche
  2019-09-12 13:10 ` Bart Van Assche
  4 siblings, 1 reply; 53+ messages in thread
From: Martin K. Petersen @ 2019-09-11 16:40 UTC (permalink / raw)
  To: Dan Williams
  Cc: Alexandre Belloni, ksummit-discuss, Jonathan Corbet,
	Daniel Vetter, linux-nvdimm, linux-kernel, Olof Johansson,
	Greg Kroah-Hartman, Steve French, Joe Perches, Thomas Gleixner,
	Mauro Carvalho Chehab, Linus Torvalds, Dmitry Vyukov,
	Tobin C. Harding


Hi Dan!

> At last years Plumbers Conference I proposed the Maintainer Entry
> Profile as a document that a maintainer can provide to set contributor
> expectations and provide fodder for a discussion between maintainers
> about the merits of different maintainer policies.

This looks pretty good to me.

After the Plumbers session last year I wrote this for SCSI based on a
prior version by Christoph. It's gone a bit stale but I'll update it to
match your template.

-- 
Martin K. Petersen	Oracle Linux Engineering



================================================
Linux SCSI Subsystem Patch Submission Guidelines
================================================
Martin K. Petersen <martin.petersen@oracle.com>


Release cycles and when to submit patches
=========================================
Each release cycle consists of:

* an 8 week submission window in which new core features and driver updates
  are added (scsi-queue)

* a 2 week merge window where it is customary not to post patches

* an 8 week stabilization window before final release where only bug fix
  patches are merged (scsi-fixes)

The submission/stabilization cycle may be shorter or longer than 8 weeks.
However, 8 weeks is the most common. Note that the code *submission window*
for the *next* kernel release overlaps with the *stabilization window* for the
*current* release:

+-------------+---------------------------------+-------------+-----------------
| Week  1 | 2 |  3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |  11  |  12  | 13 | 14 | .....
+-------------+---------------------------------+-------------+-----------------

+-------------+---------------------------------+-------------+
| 4.x merge   |    4.x stabilization window     | 4.x release |
| window      | rc1 rc2 rc3 rc4 rc5 rc6 rc7 rc8 |             |
+-------------+---------------------------------+-------------+
| Merge fixes | Big bug fixes.............small |   Stable    |
+-------------+---------------------------------+-------------+

              +---------------------------------+-------------+-----------------
              |    4.x+1 submission window      | 4.x+1 merge | 4.x+1 stabili-
              |                                 | window      | zation window
	      |                                 |             | rc1 rc2 rc3 ...
              +---------------------------------+-------------+-----------------
              | Big features/updates......small | Merge fixes | Big bug fixes..
              +---------------------------------+-------------+-----------------


Bug Fixes (4.x/scsi-fixes)
~~~~~~~~~~~~~~~~~~~~~~~~~~
During the two week merge window only fixes related to the merge process or
any critical functional deficiences discovered in the newly submitted code
will be merged.

During the subsequent stabilization window (rc cycle) the expectation is that
bug fix patches will become increasingly smaller and simpler. In other words:
There may be enough fallout from a merged driver update to justify sending a
5-patch remedial bug fix series during rc1/rc2. But at the end of the rc cycle
patches must be trivial one-liners.

After the final 4.x has been released, subsequent bug fixes will have to go
through the stable-kernel-rules.rst process.


New Features/Core Code Changes/Driver Updates (4.x+1/scsi-queue)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New features for 4.x+1 should be sent to linux-scsi once the merge window is
over. I.e. once rc1 has been released. This ensures there is enough time to
undergo several review cycles before the submission window is closed.

At the end of the submission window (rc7/rc8) the expectation is that posted
patches will be small and fairly simple. No patch series.

Only critical patches are merged during the last (rc8) submission window week
to ensure sufficient zeroday test robot and linux-next coverage before sending
Linus the final pull request.


GIT Trees
=========
The SCSI patch submission trees can be found at:

    git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git

There are two concurrently active branches:

* 4.x/scsi-fixes for bug fixes to the current kernel rc

* 4.x+1/scsi-queue for new features and driver submissions for the next merge
  window

Both trees are usually based on Linus' 4.x-rc1.

Patches accepted into 4.x/scsi-fixes are typically submitted to Linus on a
weekly basis. Patches accepted into 4.x+1/scsi-queue are submitted at the
beginning of the merge window.

It is sometimes necessary to set up a separate 4.x+1/scsi-postmerge branch
which contains patches that depend on newly merged functionality in other
subsystems such as block or libata. The postmerge tree will be submitted to
Linus at the end of the merge window once all external dependencies have been
merged.


Patch Submission Process
========================
* All modifications to files under drivers/scsi should go through the SCSI
  tree.

* Read Documentation/process/submitting-patches.rst

* Send the patch or patch series to linux-scsi@vger.kernel.org

* Please make sure to Cc: the maintainer of the driver/component you are
  changing.

* Do not use custom To: and Cc: for individual patches. We want to see the
  whole series, even patches that potentially need to go through a different
  subsystem tree.

* Clearly indicate in the introductory letter which tree your submission is
  aimed at (scsi-fixes or scsi-queue). For individual patches you can indicate
  the desired tree below the --- separator.

* As a rule of thumb, any patch that goes through the scsi-fixes tree should
  have a stable tag unless it was a regression introduced in the current
  release.

* If the patch is a bugfix, please add:

    Fixes: 1234deadbeef ("Implement foobarbaz")
    Cc: <stable@vger.kernel.org> # v4.x+

  Where the v4.x indicates when commit 1234deadbeef was added to the kernel.

* When posting a revised patch or series, please manually add any Acked-by:,
  Reviewed-by:, or Tested-by: tags you may have received. Tags are only valid
  if the patch has not changed significantly. Rebasing without conflicts and
  typo fixes are generally OK and do not invalidate tags.

* Please CC: everyone that provided feedback when posting a revised
  patch or series.

* Custom patch number formatting often confuses patchwork. Please use git
  send-email -v instead of manually adding version numbers to individual
  patches. To send version 3 of a 10 patch series from the tip of the current
  tree you can do:

    git send-email -10 -v3 --compose --to=linux-scsi@vger.kernel.org

* Please put a change log after a --- separator in each revised patch. If the
  reason for the repost is global (i.e. a rebase) it is fine to put the
  changelog in the cover letter.


Patch Acceptance Criteria
=========================
* A patch needs two positive reviews (non-author Signed-off-by:, Acked-by:,
  Reviewed-by:, or Tested-by:).

* A Tested-by: is worth a thousand reviews.

* For drivers, at least one review is required from somebody outside the
  submitting company.

* Nobody has expressed any concerns about the patch on linux-scsi.

* The patch must apply cleanly. Use checkpatch and git send-email.

* The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__")
  and does not incur any zeroday test robot complaints.

* The patch must have a commit message that describes, comprehensively and in
  plain English, what the patch does.

  - Do not link to vendor bugzilla entries that require special access
    credentials. If there is anything of importance in bugzilla, put it in the
    commit message.

  - The bigger and more intrusive the patch, the bigger the accompanying
    commit message needs to be. "fooscsi: Add PCI id for model XYZ" is fine as
    a one-liner. "fooscsi: Rewrite DMA allocation and queue setup" most likely
    needs several paragraphs of discussion in the commit message.


Patch Review Communities
========================
While core SCSI folks generally perform a cursory review of every patch,
it is imperative that contributors with an interest in a particular
component form small communities that can review and test each other's
code. Such informal communities exist for several components or
sub-subsystems underneath the SCSI tree.

The best way to facilitate that your patch gets merged is to review patches
submitted by your fellow contributors and hope that they return the favor.


Patch Reviewer Responsibilities
===============================
If you provide feedback to a patch and the patch author addresses your
concerns in a new version, you are expected to respond to the new
patch. Many code contributions series fail to make forward progress
because reviewers do not ack or nack the changes they requested to be
made. Please make sure to always follow up when your review comments are
being addressed.


Driver Maintainer Responsibilities
==================================
Many of the actively developed SCSI subsystem drivers have one or more
official maintainers. These maintainers are often employed by the company
manufacturing the hardware in question and therefore have a vested interest in
making sure the driver is working correctly.

A driver maintainer must review and respond to *all submitted patches* to the
driver in a timely manner (5 business days). This includes:

* Proposed functional changes to the driver code

* Security fixes

* Trivial and typo patches

* Changes compelled by kernel interface changes

* Patches required to work correctly on architectures not commercially
  supported by the hardware manufacturer


Patch Acceptance Status
=======================
* Submitted patches and their current status can be viewed in patchwork at:

    https://patchwork.kernel.org/project/linux-scsi/list/

* If a submitted patch is not visible in patchwork, it does not exist. Please
  repost.

* If only a portion of a patch series visible in patchwork, the series does
  not exist. Please repost.

* Once a patch has been merged, you will receive a mail indicating into which
  tree it has been accepted.

* Patches that have not received sufficient Acked-by:, Reviewed-by:, or
  Tested-by: tags after two weeks get moved to "Deferred" status. This
  indicates that it necessary to resubmit the patches to the linux-scsi list.

* Patches submitted to linux-scsi but which need to go through another
  subsystem tree will be set to "Not Applicable" status.

* Patches which require rework will be set to "Changes Requested" status.

* Patches which have been obsoleted by a later version will be set to
  "Superceded" status.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
  2019-09-11 15:48 ` [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
@ 2019-09-11 17:34   ` Verma, Vishal L
  2019-09-16 12:35   ` Jani Nikula
  2019-10-01 13:55   ` Jonathan Corbet
  2 siblings, 0 replies; 53+ messages in thread
From: Verma, Vishal L @ 2019-09-11 17:34 UTC (permalink / raw)
  To: Williams, Dan J, linux-kernel
  Cc: ksummit-discuss, linux-nvdimm, gregkh, dvyukov, mchehab, stfrench, me

On Wed, 2019-09-11 at 08:48 -0700, Dan Williams wrote:

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3f171339df53..e5d111a86e61 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -98,6 +98,10 @@ Descriptions of section entries:
>  	   Obsolete:	Old code. Something tagged obsolete generally means
>  			it has been replaced by a better system and you
>  			should be using that.
> +	P: Subsystem Profile document for more details submitting
> +	   patches to the given subsystem. This is either an in-tree file,
> +	   or a URI. See Documentation/maintainer/maintainer-entry-profile.rst
> +	   for details.

Considering each maintainer entry or driver may not have a subdirectory
under Documentation/ to put these under, would it be better to collect
them in one place, say Documentation/maintainer-entry-profiles/ ?
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
@ 2019-09-11 17:42   ` Vishal Verma
  2019-09-11 17:45   ` Dave Jiang
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 53+ messages in thread
From: Vishal Verma @ 2019-09-11 17:42 UTC (permalink / raw)
  To: Dan Williams, linux-kernel; +Cc: ksummit-discuss, linux-nvdimm

> Document the basic policies of the libnvdimm subsystem and provide a first
> example of a Maintainer Entry Profile for others to duplicate and edit.
> 
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/nvdimm/maintainer-entry-profile.rst |   64 +++++++++++++++++++++
>  MAINTAINERS                                       |    4 +
>  2 files changed, 68 insertions(+)
>  create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst
> 
Looks good to me,
Acked-by: Vishal Verma <vishal.l.verma@intel.com>

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
  2019-09-11 17:42   ` [Ksummit-discuss] " Vishal Verma
@ 2019-09-11 17:45   ` Dave Jiang
  2019-09-11 18:43   ` [Ksummit-discuss] " Dan Carpenter
  2019-09-11 20:30   ` Joe Perches
  3 siblings, 0 replies; 53+ messages in thread
From: Dave Jiang @ 2019-09-11 17:45 UTC (permalink / raw)
  To: Dan Williams, linux-kernel; +Cc: ksummit-discuss, linux-nvdimm



On 9/11/19 8:48 AM, Dan Williams wrote:
> Document the basic policies of the libnvdimm subsystem and provide a first
> example of a Maintainer Entry Profile for others to duplicate and edit.
> 
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

Acked-by: Dave Jiang <dave.jiang@intel.com>

> ---
>  Documentation/nvdimm/maintainer-entry-profile.rst |   64 +++++++++++++++++++++
>  MAINTAINERS                                       |    4 +
>  2 files changed, 68 insertions(+)
>  create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst
> 
> diff --git a/Documentation/nvdimm/maintainer-entry-profile.rst b/Documentation/nvdimm/maintainer-entry-profile.rst
> new file mode 100644
> index 000000000000..c102950f2257
> --- /dev/null
> +++ b/Documentation/nvdimm/maintainer-entry-profile.rst
> @@ -0,0 +1,64 @@
> +LIBNVDIMM Maintainer Entry Profile
> +==================================
> +
> +Overview
> +--------
> +The libnvdimm subsystem manages persistent memory across multiple
> +architectures. The mailing list, is tracked by patchwork here:
> +https://patchwork.kernel.org/project/linux-nvdimm/list/
> +...and that instance is configured to give feedback to submitters on
> +patch acceptance and upstream merge. Patches are merged to either the
> +'libnvdimm-fixes', or 'libnvdimm-for-next' branch. Those branches are
> +available here:
> +https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/
> +
> +In general patches can be submitted against the latest -rc, however if
> +the incoming code change is dependent on other pending changes then the
> +patch should be based on the libnvdimm-for-next branch. However, since
> +persistent memory sits at the intersection of storage and memory there
> +are cases where patches are more suitable to be merged through a
> +Filesystem or the Memory Management tree. When in doubt copy the nvdimm
> +list and the maintainers will help route.
> +
> +Submissions will be exposed to the kbuild robot for compile regression
> +testing. It helps to get a success notification from that infrastructure
> +before submitting, but it is not required.
> +
> +
> +Submit Checklist Addendum
> +-------------------------
> +There are unit tests for the subsystem via the ndctl utility:
> +https://github.com/pmem/ndctl
> +Those tests need to be passed before the patches go upstream, but not
> +necessarily before initial posting. Contact the list if you need help
> +getting the test environment set up.
> +
> +
> +Key Cycle Dates
> +---------------
> +New submissions can be sent at any time, but if they intend to hit the
> +next merge window they should be sent before -rc4, and ideally
> +stabilized in the libnvdimm-for-next branch by -rc6. Of course if a
> +patch set requires more than 2 weeks of review -rc4 is already too late
> +and some patches may require multiple development cycles to review.
> +
> +
> +Coding Style Addendum
> +---------------------
> +libnvdimm expects multi-line statements to be double indented. I.e.
> +
> +        if (x...
> +                        && ...y) {
> +
> +
> +Review Cadence
> +--------------
> +In general, please wait up to one week before pinging for feedback. A
> +private mail reminder is preferred. Alternatively ask for other
> +developers that have Reviewed-by tags for libnvdimm changes to take a
> +look and offer their opinion.
> +
> +
> +Style Cleanup Patches
> +---------------------
> +Standalone style-cleanups are welcome.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e5d111a86e61..2be1e18a368e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9185,6 +9185,7 @@ M:	Dan Williams <dan.j.williams@intel.com>
>  M:	Vishal Verma <vishal.l.verma@intel.com>
>  M:	Dave Jiang <dave.jiang@intel.com>
>  L:	linux-nvdimm@lists.01.org
> +P:	Documentation/nvdimm/maintainer-entry-profile.rst
>  Q:	https://patchwork.kernel.org/project/linux-nvdimm/list/
>  S:	Supported
>  F:	drivers/nvdimm/blk.c
> @@ -9195,6 +9196,7 @@ M:	Vishal Verma <vishal.l.verma@intel.com>
>  M:	Dan Williams <dan.j.williams@intel.com>
>  M:	Dave Jiang <dave.jiang@intel.com>
>  L:	linux-nvdimm@lists.01.org
> +P:	Documentation/nvdimm/maintainer-entry-profile.rst
>  Q:	https://patchwork.kernel.org/project/linux-nvdimm/list/
>  S:	Supported
>  F:	drivers/nvdimm/btt*
> @@ -9204,6 +9206,7 @@ M:	Dan Williams <dan.j.williams@intel.com>
>  M:	Vishal Verma <vishal.l.verma@intel.com>
>  M:	Dave Jiang <dave.jiang@intel.com>
>  L:	linux-nvdimm@lists.01.org
> +P:	Documentation/nvdimm/maintainer-entry-profile.rst
>  Q:	https://patchwork.kernel.org/project/linux-nvdimm/list/
>  S:	Supported
>  F:	drivers/nvdimm/pmem*
> @@ -9223,6 +9226,7 @@ M:	Dave Jiang <dave.jiang@intel.com>
>  M:	Keith Busch <keith.busch@intel.com>
>  M:	Ira Weiny <ira.weiny@intel.com>
>  L:	linux-nvdimm@lists.01.org
> +P:	Documentation/nvdimm/maintainer-entry-profile.rst
>  Q:	https://patchwork.kernel.org/project/linux-nvdimm/list/
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
>  S:	Supported
> 
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
  2019-09-11 17:42   ` [Ksummit-discuss] " Vishal Verma
  2019-09-11 17:45   ` Dave Jiang
@ 2019-09-11 18:43   ` Dan Carpenter
  2019-09-11 22:11     ` Jens Axboe
  2019-09-13  2:11     ` Aneesh Kumar K.V
  2019-09-11 20:30   ` Joe Perches
  3 siblings, 2 replies; 53+ messages in thread
From: Dan Carpenter @ 2019-09-11 18:43 UTC (permalink / raw)
  To: Dan Williams; +Cc: ksummit-discuss, linux-nvdimm, linux-kernel, bpf

On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
> +Coding Style Addendum
> +---------------------
> +libnvdimm expects multi-line statements to be double indented. I.e.
> +
> +        if (x...
> +                        && ...y) {

That looks horrible and it causes a checkpatch warning.  :(  Why not
do it the same way that everyone else does it.

	if (blah_blah_x && <-- && has to be on the first line for checkpatch
	    blah_blah_y) { <-- [tab][space][space][space][space]blah

Now all the conditions are aligned visually which makes it readable.
They aren't aligned with the indent block so it's easy to tell the
inside from the if condition.

I kind of hate all this extra documentation because now everyone thinks
they can invent new hoops to jump through.

Speaking of hoops, the BPF documentation says that you have to figure
out which tree a patch applies to instead of just working against
linux-next.  Is there an automated way to do that?  I looked through my
inbox and there are a bunch of patches marked as going through the
bpf-next tree but about half were marked incorrectly so it looks like
everyone who tries to tag their patches is going to do it badly anyway.

regards,
dan carpenter

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
                     ` (2 preceding siblings ...)
  2019-09-11 18:43   ` [Ksummit-discuss] " Dan Carpenter
@ 2019-09-11 20:30   ` Joe Perches
  3 siblings, 0 replies; 53+ messages in thread
From: Joe Perches @ 2019-09-11 20:30 UTC (permalink / raw)
  To: Dan Williams, linux-kernel; +Cc: ksummit-discuss, linux-nvdimm

On Wed, 2019-09-11 at 08:48 -0700, Dan Williams wrote:
> Document the basic policies of the libnvdimm subsystem and provide a first
> example of a Maintainer Entry Profile for others to duplicate and edit.
[]
> +Coding Style Addendum
> +---------------------
> +libnvdimm expects multi-line statements to be double indented. I.e.
> +
> +        if (x...
> +                        && ...y) {

I don't find a good reason to do this.

> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -9185,6 +9185,7 @@ M:	Dan Williams <dan.j.williams@intel.com>
>  M:	Vishal Verma <vishal.l.verma@intel.com>
>  M:	Dave Jiang <dave.jiang@intel.com>
>  L:	linux-nvdimm@lists.01.org
> +P:	Documentation/nvdimm/maintainer-entry-profile.rst

I also think the indirection to a separate
file is not a good thing.

Separate styles for individual subsystems is
not something I would want to encourage.

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 18:43   ` [Ksummit-discuss] " Dan Carpenter
@ 2019-09-11 22:11     ` Jens Axboe
  2019-09-12  7:41       ` Dan Williams
                         ` (2 more replies)
  2019-09-13  2:11     ` Aneesh Kumar K.V
  1 sibling, 3 replies; 53+ messages in thread
From: Jens Axboe @ 2019-09-11 22:11 UTC (permalink / raw)
  To: Dan Carpenter, Dan Williams
  Cc: ksummit-discuss, linux-nvdimm, linux-kernel, bpf

On 9/11/19 12:43 PM, Dan Carpenter wrote:
> On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
>> +Coding Style Addendum
>> +---------------------
>> +libnvdimm expects multi-line statements to be double indented. I.e.
>> +
>> +        if (x...
>> +                        && ...y) {
> 
> That looks horrible and it causes a checkpatch warning.  :(  Why not
> do it the same way that everyone else does it.
> 
> 	if (blah_blah_x && <-- && has to be on the first line for checkpatch
> 	    blah_blah_y) { <-- [tab][space][space][space][space]blah
> 
> Now all the conditions are aligned visually which makes it readable.
> They aren't aligned with the indent block so it's easy to tell the
> inside from the if condition.
> 
> I kind of hate all this extra documentation because now everyone thinks
> they can invent new hoops to jump through.

FWIW, I completely agree with Dan (Carpenter) here. I absolutely
dislike having these kinds of files, and with subsystems imposing weird
restrictions on style (like the quoted example, yuck).

Additionally, it would seem saner to standardize rules around when
code is expected to hit the maintainers hands for kernel releases. Both
yours and Martins deals with that, there really shouldn't be the need
to have this specified in detail per sub-system.

-- 
Jens Axboe

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 22:11     ` Jens Axboe
@ 2019-09-12  7:41       ` Dan Williams
  2019-09-12  8:24         ` Miguel Ojeda
  2019-09-13  7:09       ` Jonathan Corbet
  2019-09-13 21:44       ` Martin K. Petersen
  2 siblings, 1 reply; 53+ messages in thread
From: Dan Williams @ 2019-09-12  7:41 UTC (permalink / raw)
  To: Jens Axboe
  Cc: ksummit, linux-nvdimm, Linux Kernel Mailing List, bpf, Dan Carpenter

On Wed, Sep 11, 2019 at 3:11 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 9/11/19 12:43 PM, Dan Carpenter wrote:
> > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
> >> +Coding Style Addendum
> >> +---------------------
> >> +libnvdimm expects multi-line statements to be double indented. I.e.
> >> +
> >> +        if (x...
> >> +                        && ...y) {
> >
> > That looks horrible and it causes a checkpatch warning.  :(  Why not
> > do it the same way that everyone else does it.
> >
> >       if (blah_blah_x && <-- && has to be on the first line for checkpatch
> >           blah_blah_y) { <-- [tab][space][space][space][space]blah
> >
> > Now all the conditions are aligned visually which makes it readable.
> > They aren't aligned with the indent block so it's easy to tell the
> > inside from the if condition.
> >
> > I kind of hate all this extra documentation because now everyone thinks
> > they can invent new hoops to jump through.
>
> FWIW, I completely agree with Dan (Carpenter) here. I absolutely
> dislike having these kinds of files, and with subsystems imposing weird
> restrictions on style (like the quoted example, yuck).
>
> Additionally, it would seem saner to standardize rules around when
> code is expected to hit the maintainers hands for kernel releases. Both
> yours and Martins deals with that, there really shouldn't be the need
> to have this specified in detail per sub-system.

So this is *the* point of the exercise.

I picked up this indentation habit a long while back in response to
review feedback on a patch to a subsystem that formatted code this
way. At the time CodingStyle did not contradict the maintainer's
preference, so I adopted it across the board.

Now I come to find that CodingStyle has settled on clang-format (in
the last 15 months) as the new standard which is a much better answer
to me than a manually specified style open to interpretation. I'll
take a look at getting libnvdimm converted over.

If we can take that further and standardize all of the places where
contributors see variations across subsystems on the fundamental
questions of style, timing, follow-up, and unit test invocation the
Maintainer Entry Profile can be superseded with common guidelines.

Otherwise, yes I completely agree with you that a "Maintainer Entry
Profile" is a sad comment on the state of what contributors need to
navigate, but that's today's reality that needs to be addressed.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-12  7:41       ` Dan Williams
@ 2019-09-12  8:24         ` Miguel Ojeda
  2019-09-12 10:18           ` Joe Perches
  0 siblings, 1 reply; 53+ messages in thread
From: Miguel Ojeda @ 2019-09-12  8:24 UTC (permalink / raw)
  To: Dan Williams
  Cc: Jens Axboe, ksummit, linux-nvdimm, Linux Kernel Mailing List,
	bpf, Dan Carpenter

On Thu, Sep 12, 2019 at 9:43 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> Now I come to find that CodingStyle has settled on clang-format (in
> the last 15 months) as the new standard which is a much better answer
> to me than a manually specified style open to interpretation. I'll
> take a look at getting libnvdimm converted over.

Note that clang-format cannot do everything as we want within the
kernel just yet, but it is a close enough approximation -- it is near
the point where we could simply agree to use it and stop worrying
about styling issues. However, that would mean everyone needs to have
a recent clang-format available, which I think is the biggest obstacle
at the moment.

Cheers,
Miguel
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-12  8:24         ` Miguel Ojeda
@ 2019-09-12 10:18           ` Joe Perches
  2019-09-12 11:02             ` Joe Perches
  2019-09-12 14:42             ` Miguel Ojeda
  0 siblings, 2 replies; 53+ messages in thread
From: Joe Perches @ 2019-09-12 10:18 UTC (permalink / raw)
  To: Miguel Ojeda, Dan Williams
  Cc: Jens Axboe, ksummit, linux-nvdimm, Linux Kernel Mailing List,
	bpf, Dan Carpenter

On Thu, 2019-09-12 at 10:24 +0200, Miguel Ojeda wrote:
> On Thu, Sep 12, 2019 at 9:43 AM Dan Williams <dan.j.williams@intel.com> wrote:
> > Now I come to find that CodingStyle has settled on clang-format (in
> > the last 15 months) as the new standard which is a much better answer
> > to me than a manually specified style open to interpretation. I'll
> > take a look at getting libnvdimm converted over.
> 
> Note that clang-format cannot do everything as we want within the
> kernel just yet, but it is a close enough approximation -- it is near
> the point where we could simply agree to use it and stop worrying
> about styling issues. However, that would mean everyone needs to have
> a recent clang-format available, which I think is the biggest obstacle
> at the moment.

I don't think that's close to true yet for clang-format.

For instance: clang-format does not do anything with
missing braces, or coalescing multi-part strings,
or any number of other nominal coding style defects
like all the for_each macros, aligning or not aligning
columnar contents appropriately, etc...

clang-format as yet has no taste.

I believe it'll take a lot of work to improve it to a point
where its formatting is acceptable and appropriate.

An AI rather than a table based system like clang-format is
more likely to be a real solution, but training that AI
isn't a thing that I want to do.

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-12 10:18           ` Joe Perches
@ 2019-09-12 11:02             ` Joe Perches
  2019-09-12 14:17               ` Dan Williams
  2019-09-12 14:42             ` Miguel Ojeda
  1 sibling, 1 reply; 53+ messages in thread
From: Joe Perches @ 2019-09-12 11:02 UTC (permalink / raw)
  To: Miguel Ojeda, Dan Williams
  Cc: Linux Kernel Mailing List, Dan Carpenter, linux-nvdimm

(cut down the cc-list)

On Thu, 2019-09-12 at 03:18 -0700, Joe Perches wrote:
> On Thu, 2019-09-12 at 10:24 +0200, Miguel Ojeda wrote:
> > On Thu, Sep 12, 2019 at 9:43 AM Dan Williams <dan.j.williams@intel.com> wrote:
> > > Now I come to find that CodingStyle has settled on clang-format (in
> > > the last 15 months) as the new standard which is a much better answer
> > > to me than a manually specified style open to interpretation. I'll
> > > take a look at getting libnvdimm converted over.
> > 
> > Note that clang-format cannot do everything as we want within the
> > kernel just yet, but it is a close enough approximation -- it is near
> > the point where we could simply agree to use it and stop worrying
> > about styling issues. However, that would mean everyone needs to have
> > a recent clang-format available, which I think is the biggest obstacle
> > at the moment.
> 
> I don't think that's close to true yet for clang-format.
> 
> For instance: clang-format does not do anything with
> missing braces, or coalescing multi-part strings,
> or any number of other nominal coding style defects
> like all the for_each macros, aligning or not aligning
> columnar contents appropriately, etc...
> 
> clang-format as yet has no taste.
> 
> I believe it'll take a lot of work to improve it to a point
> where its formatting is acceptable and appropriate.
.

Just fyi:

Here's the difference that clang-format produces from the current
nvdimm sources to the patch series I posted.

clang-format does some OK, some not OK, some really bad.
(e.g.: __stringify)

My git branch for my patches is 20190911_nvdimm, and
using Stephen Rothwell's git tree for -next:

$ git checkout next-20190904
$ clang-format -i drivers/nvdimm/*.[ch]
$ git diff --stat -p 20190911_nvdimm -- drivers/nvdimm/ > nvdimm.clang-diff
---
 drivers/nvdimm/badrange.c       |  37 ++--
 drivers/nvdimm/blk.c            |  39 ++--
 drivers/nvdimm/btt.c            | 144 +++++++-------
 drivers/nvdimm/btt.h            |  62 +++----
 drivers/nvdimm/btt_devs.c       |  42 ++---
 drivers/nvdimm/bus.c            |  68 ++++---
 drivers/nvdimm/claim.c          |  26 ++-
 drivers/nvdimm/core.c           |  32 ++--
 drivers/nvdimm/dax_devs.c       |   3 +-
 drivers/nvdimm/dimm_devs.c      | 111 ++++++-----
 drivers/nvdimm/e820.c           |   3 +-
 drivers/nvdimm/label.c          | 205 ++++++++++----------
 drivers/nvdimm/label.h          |  35 ++--
 drivers/nvdimm/namespace_devs.c | 403 +++++++++++++++++++---------------------
 drivers/nvdimm/nd-core.h        |  40 ++--
 drivers/nvdimm/nd.h             |  72 ++++---
 drivers/nvdimm/nd_virtio.c      |  19 +-
 drivers/nvdimm/of_pmem.c        |   7 +-
 drivers/nvdimm/pfn_devs.c       | 101 +++++-----
 drivers/nvdimm/pmem.c           |  65 ++++---
 drivers/nvdimm/pmem.h           |  22 +--
 drivers/nvdimm/region.c         |  22 ++-
 drivers/nvdimm/region_devs.c    | 113 +++++------
 drivers/nvdimm/security.c       | 130 +++++++------
 drivers/nvdimm/virtio_pmem.c    |  30 ++-
 25 files changed, 895 insertions(+), 936 deletions(-)

diff --git a/drivers/nvdimm/badrange.c b/drivers/nvdimm/badrange.c
index 4d231643c095..fdd0f5cb873b 100644
--- a/drivers/nvdimm/badrange.c
+++ b/drivers/nvdimm/badrange.c
@@ -24,8 +24,8 @@ void badrange_init(struct badrange *badrange)
 EXPORT_SYMBOL_GPL(badrange_init);
 
 static void append_badrange_entry(struct badrange *badrange,
-				  struct badrange_entry *bre,
-				  u64 addr, u64 length)
+				  struct badrange_entry *bre, u64 addr,
+				  u64 length)
 {
 	lockdep_assert_held(&badrange->lock);
 	bre->start = addr;
@@ -33,8 +33,8 @@ static void append_badrange_entry(struct badrange *badrange,
 	list_add_tail(&bre->list, &badrange->list);
 }
 
-static int alloc_and_append_badrange_entry(struct badrange *badrange,
-					   u64 addr, u64 length, gfp_t flags)
+static int alloc_and_append_badrange_entry(struct badrange *badrange, u64 addr,
+					   u64 length, gfp_t flags)
 {
 	struct badrange_entry *bre;
 
@@ -66,7 +66,7 @@ static int add_badrange(struct badrange *badrange, u64 addr, u64 length)
 	 * This will be the common case as ARS_STATUS returns all known
 	 * errors in the SPA space, and we can't query it per region
 	 */
-	list_for_each_entry(bre, &badrange->list, list)
+	list_for_each_entry (bre, &badrange->list, list)
 		if (bre->start == addr) {
 			/* If length has changed, update this list entry */
 			if (bre->length != length)
@@ -116,13 +116,13 @@ void badrange_forget(struct badrange *badrange, phys_addr_t start,
 	 * split into two based on the overlap characteristics
 	 */
 
-	list_for_each_entry_safe(bre, next, badrange_list, list) {
+	list_for_each_entry_safe (bre, next, badrange_list, list) {
 		u64 bre_end = bre->start + bre->length - 1;
 
 		/* Skip intervals with no intersection */
 		if (bre_end < start)
 			continue;
-		if (bre->start >  clr_end)
+		if (bre->start > clr_end)
 			continue;
 		/* Delete completely overlapped badrange entries */
 		if ((bre->start >= start) && (bre_end <= clr_end)) {
@@ -165,12 +165,12 @@ EXPORT_SYMBOL_GPL(badrange_forget);
 
 static void set_badblock(struct badblocks *bb, sector_t s, int num)
 {
-	dev_dbg(bb->dev, "Found a bad range (0x%llx, 0x%llx)\n",
-		(u64)s * 512, (u64)num * 512);
+	dev_dbg(bb->dev, "Found a bad range (0x%llx, 0x%llx)\n", (u64)s * 512,
+		(u64)num * 512);
 	/* this isn't an error as the hardware will still throw an exception */
 	if (badblocks_set(bb, s, num, 1))
-		dev_info_once(bb->dev, "%s: failed for sector %llx\n",
-			      __func__, (u64)s);
+		dev_info_once(bb->dev, "%s: failed for sector %llx\n", __func__,
+			      (u64)s);
 }
 
 /**
@@ -207,26 +207,25 @@ static void __add_badblock_range(struct badblocks *bb, u64 ns_offset, u64 len)
 			remaining -= done;
 			s += done;
 		}
-	} else {
+	} else
 		set_badblock(bb, start_sector, num_sectors);
-	}
 }
 
-static void badblocks_populate(struct badrange *badrange,
-			       struct badblocks *bb, const struct resource *res)
+static void badblocks_populate(struct badrange *badrange, struct badblocks *bb,
+			       const struct resource *res)
 {
 	struct badrange_entry *bre;
 
 	if (list_empty(&badrange->list))
 		return;
 
-	list_for_each_entry(bre, &badrange->list, list) {
+	list_for_each_entry (bre, &badrange->list, list) {
 		u64 bre_end = bre->start + bre->length - 1;
 
 		/* Discard intervals with no intersection */
 		if (bre_end < res->start)
 			continue;
-		if (bre->start >  res->end)
+		if (bre->start > res->end)
 			continue;
 		/* Deal with any overlap after start of the namespace */
 		if (bre->start >= res->start) {
@@ -236,8 +235,8 @@ static void badblocks_populate(struct badrange *badrange,
 			if (bre_end <= res->end)
 				len = bre->length;
 			else
-				len = res->start + resource_size(res)
-					- bre->start;
+				len = res->start + resource_size(res) -
+				      bre->start;
 			__add_badblock_range(bb, start - res->start, len);
 			continue;
 		}
diff --git a/drivers/nvdimm/blk.c b/drivers/nvdimm/blk.c
index fc15aa9220c8..95281ba56691 100644
--- a/drivers/nvdimm/blk.c
+++ b/drivers/nvdimm/blk.c
@@ -62,12 +62,12 @@ static struct nd_blk_region *to_ndbr(struct nd_namespace_blk *nsblk)
 
 #ifdef CONFIG_BLK_DEV_INTEGRITY
 static int nd_blk_rw_integrity(struct nd_namespace_blk *nsblk,
-			       struct bio_integrity_payload *bip,
-			       u64 lba, int rw)
+			       struct bio_integrity_payload *bip, u64 lba,
+			       int rw)
 {
 	struct nd_blk_region *ndbr = to_ndbr(nsblk);
 	unsigned int len = nsblk_meta_size(nsblk);
-	resource_size_t	dev_offset, ns_offset;
+	resource_size_t dev_offset, ns_offset;
 	u32 internal_lbasize, sector_size;
 	int err = 0;
 
@@ -109,8 +109,8 @@ static int nd_blk_rw_integrity(struct nd_namespace_blk *nsblk,
 
 #else /* CONFIG_BLK_DEV_INTEGRITY */
 static int nd_blk_rw_integrity(struct nd_namespace_blk *nsblk,
-			       struct bio_integrity_payload *bip,
-			       u64 lba, int rw)
+			       struct bio_integrity_payload *bip, u64 lba,
+			       int rw)
 {
 	return 0;
 }
@@ -122,7 +122,7 @@ static int nsblk_do_bvec(struct nd_namespace_blk *nsblk,
 			 sector_t sector)
 {
 	struct nd_blk_region *ndbr = to_ndbr(nsblk);
-	resource_size_t	dev_offset, ns_offset;
+	resource_size_t dev_offset, ns_offset;
 	u32 internal_lbasize, sector_size;
 	int err = 0;
 	void *iobuf;
@@ -183,7 +183,7 @@ static blk_qc_t nd_blk_make_request(struct request_queue *q, struct bio *bio)
 	nsblk = q->queuedata;
 	rw = bio_data_dir(bio);
 	do_acct = nd_iostat_start(bio, &start);
-	bio_for_each_segment(bvec, bio, iter) {
+	bio_for_each_segment (bvec, bio, iter) {
 		unsigned int len = bvec.bv_len;
 
 		BUG_ON(len > PAGE_SIZE);
@@ -191,9 +191,9 @@ static blk_qc_t nd_blk_make_request(struct request_queue *q, struct bio *bio)
 				    bvec.bv_offset, rw, iter.bi_sector);
 		if (err) {
 			dev_dbg(&nsblk->common.dev,
-				"io error in %s sector %lld, len %d\n",
-				rw == READ ? "READ" : "WRITE",
-				(u64)iter.bi_sector, len);
+				"io error in %s sector %lld, len %d,\n",
+				(rw == READ) ? "READ" : "WRITE",
+				(unsigned long long)iter.bi_sector, len);
 			bio->bi_status = errno_to_blk_status(err);
 			break;
 		}
@@ -211,7 +211,7 @@ static int nsblk_rw_bytes(struct nd_namespace_common *ndns,
 {
 	struct nd_namespace_blk *nsblk = to_nd_namespace_blk(&ndns->dev);
 	struct nd_blk_region *ndbr = to_ndbr(nsblk);
-	resource_size_t	dev_offset;
+	resource_size_t dev_offset;
 
 	dev_offset = to_dev_offset(nsblk, offset, n);
 
@@ -269,10 +269,10 @@ static int nsblk_attach_disk(struct nd_namespace_blk *nsblk)
 	if (!disk)
 		return -ENOMEM;
 
-	disk->first_minor	= 0;
-	disk->fops		= &nd_blk_fops;
-	disk->queue		= q;
-	disk->flags		= GENHD_FL_EXT_DEVT;
+	disk->first_minor = 0;
+	disk->fops = &nd_blk_fops;
+	disk->queue = q;
+	disk->flags = GENHD_FL_EXT_DEVT;
 	nvdimm_namespace_disk_name(&nsblk->common, disk->disk_name);
 
 	if (devm_add_action_or_reset(dev, nd_blk_release_disk, disk))
@@ -305,16 +305,13 @@ static int nd_blk_probe(struct device *dev)
 	dev_set_drvdata(dev, nsblk);
 
 	ndns->rw_bytes = nsblk_rw_bytes;
-
 	if (is_nd_btt(dev))
 		return nvdimm_namespace_attach_btt(ndns);
-
-	if (nd_btt_probe(dev, ndns) == 0) {
+	else if (nd_btt_probe(dev, ndns) == 0) {
 		/* we'll come back as btt-blk */
 		return -ENXIO;
-	}
-
-	return nsblk_attach_disk(nsblk);
+	} else
+		return nsblk_attach_disk(nsblk);
 }
 
 static int nd_blk_remove(struct device *dev)
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index 6c18d7bba6af..b4281d91d70b 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -19,10 +19,7 @@
 #include "btt.h"
 #include "nd.h"
 
-enum log_ent_request {
-	LOG_NEW_ENT = 0,
-	LOG_OLD_ENT
-};
+enum log_ent_request { LOG_NEW_ENT = 0, LOG_OLD_ENT };
 
 static struct device *to_dev(struct arena_info *arena)
 {
@@ -206,9 +203,8 @@ static int btt_map_read(struct arena_info *arena, u32 lba, u32 *mapping,
 static int btt_log_group_read(struct arena_info *arena, u32 lane,
 			      struct log_group *log)
 {
-	return arena_read_bytes(arena,
-				arena->logoff + (lane * LOG_GRP_SIZE), log,
-				LOG_GRP_SIZE, 0);
+	return arena_read_bytes(arena, arena->logoff + (lane * LOG_GRP_SIZE),
+				log, LOG_GRP_SIZE, 0);
 }
 
 static struct dentry *debugfs_root;
@@ -229,24 +225,27 @@ static void arena_debugfs_init(struct arena_info *a, struct dentry *parent,
 		return;
 	a->debugfs_dir = d;
 
-	debugfs_create_x64("size", 0444, d, &a->size);
-	debugfs_create_x64("external_lba_start", 0444, d, &a->external_lba_start);
-	debugfs_create_x32("internal_nlba", 0444, d, &a->internal_nlba);
-	debugfs_create_u32("internal_lbasize", 0444, d, &a->internal_lbasize);
-	debugfs_create_x32("external_nlba", 0444, d, &a->external_nlba);
-	debugfs_create_u32("external_lbasize", 0444, d, &a->external_lbasize);
-	debugfs_create_u32("nfree", 0444, d, &a->nfree);
-	debugfs_create_u16("version_major", 0444, d, &a->version_major);
-	debugfs_create_u16("version_minor", 0444, d, &a->version_minor);
-	debugfs_create_x64("nextoff", 0444, d, &a->nextoff);
-	debugfs_create_x64("infooff", 0444, d, &a->infooff);
-	debugfs_create_x64("dataoff", 0444, d, &a->dataoff);
-	debugfs_create_x64("mapoff", 0444, d, &a->mapoff);
-	debugfs_create_x64("logoff", 0444, d, &a->logoff);
-	debugfs_create_x64("info2off", 0444, d, &a->info2off);
-	debugfs_create_x32("flags", 0444, d, &a->flags);
-	debugfs_create_u32("log_index_0", 0444, d, &a->log_index[0]);
-	debugfs_create_u32("log_index_1", 0444, d, &a->log_index[1]);
+	debugfs_create_x64("size", S_IRUGO, d, &a->size);
+	debugfs_create_x64("external_lba_start", S_IRUGO, d,
+			   &a->external_lba_start);
+	debugfs_create_x32("internal_nlba", S_IRUGO, d, &a->internal_nlba);
+	debugfs_create_u32("internal_lbasize", S_IRUGO, d,
+			   &a->internal_lbasize);
+	debugfs_create_x32("external_nlba", S_IRUGO, d, &a->external_nlba);
+	debugfs_create_u32("external_lbasize", S_IRUGO, d,
+			   &a->external_lbasize);
+	debugfs_create_u32("nfree", S_IRUGO, d, &a->nfree);
+	debugfs_create_u16("version_major", S_IRUGO, d, &a->version_major);
+	debugfs_create_u16("version_minor", S_IRUGO, d, &a->version_minor);
+	debugfs_create_x64("nextoff", S_IRUGO, d, &a->nextoff);
+	debugfs_create_x64("infooff", S_IRUGO, d, &a->infooff);
+	debugfs_create_x64("dataoff", S_IRUGO, d, &a->dataoff);
+	debugfs_create_x64("mapoff", S_IRUGO, d, &a->mapoff);
+	debugfs_create_x64("logoff", S_IRUGO, d, &a->logoff);
+	debugfs_create_x64("info2off", S_IRUGO, d, &a->info2off);
+	debugfs_create_x32("flags", S_IRUGO, d, &a->flags);
+	debugfs_create_u32("log_index_0", S_IRUGO, d, &a->log_index[0]);
+	debugfs_create_u32("log_index_1", S_IRUGO, d, &a->log_index[1]);
 }
 
 static void btt_debugfs_init(struct btt *btt)
@@ -254,12 +253,12 @@ static void btt_debugfs_init(struct btt *btt)
 	int i = 0;
 	struct arena_info *arena;
 
-	btt->debugfs_dir = debugfs_create_dir(dev_name(&btt->nd_btt->dev),
-					      debugfs_root);
+	btt->debugfs_dir =
+		debugfs_create_dir(dev_name(&btt->nd_btt->dev), debugfs_root);
 	if (IS_ERR_OR_NULL(btt->debugfs_dir))
 		return;
 
-	list_for_each_entry(arena, &btt->arena_list, list) {
+	list_for_each_entry (arena, &btt->arena_list, list) {
 		arena_debugfs_init(arena, btt->debugfs_dir, i);
 		i++;
 	}
@@ -335,8 +334,8 @@ static int btt_log_read(struct arena_info *arena, u32 lane,
 	old_ent = btt_log_get_old(arena, &log);
 	if (old_ent < 0 || old_ent > 1) {
 		dev_err(to_dev(arena),
-			"log corruption (%d): lane %d seq [%d, %d]\n",
-			old_ent, lane, log.ent[arena->log_index[0]].seq,
+			"log corruption (%d): lane %d seq [%d, %d]\n", old_ent,
+			lane, log.ent[arena->log_index[0]].seq,
 			log.ent[arena->log_index[1]].seq);
 		/* TODO set error state? */
 		return -EIO;
@@ -355,8 +354,8 @@ static int btt_log_read(struct arena_info *arena, u32 lane,
  * It does _not_ prepare the freelist entry for the next write
  * btt_flog_write is the wrapper for updating the freelist elements
  */
-static int __btt_log_write(struct arena_info *arena, u32 lane,
-			   u32 sub, struct log_entry *ent, unsigned long flags)
+static int __btt_log_write(struct arena_info *arena, u32 lane, u32 sub,
+			   struct log_entry *ent, unsigned long flags)
 {
 	int ret;
 	u32 group_slot = arena->log_index[sub];
@@ -365,7 +364,7 @@ static int __btt_log_write(struct arena_info *arena, u32 lane,
 	u64 ns_off;
 
 	ns_off = arena->logoff + (lane * LOG_GRP_SIZE) +
-		(group_slot * LOG_ENT_SIZE);
+		 (group_slot * LOG_ENT_SIZE);
 	/* split the 16B write into atomic, durable halves */
 	ret = arena_write_bytes(arena, ns_off, src, log_half, flags);
 	if (ret)
@@ -514,8 +513,8 @@ static int arena_clear_freelist_error(struct arena_info *arena, u32 lane)
 		while (len) {
 			unsigned long chunk = min(len, PAGE_SIZE);
 
-			ret = arena_write_bytes(arena, nsoff, zero_page,
-						chunk, 0);
+			ret = arena_write_bytes(arena, nsoff, zero_page, chunk,
+						0);
 			if (ret)
 				break;
 			len -= chunk;
@@ -534,8 +533,8 @@ static int btt_freelist_init(struct arena_info *arena)
 	struct log_entry log_new;
 	u32 i, map_entry, log_oldmap, log_newmap;
 
-	arena->freelist = kcalloc(arena->nfree, sizeof(struct free_entry),
-				  GFP_KERNEL);
+	arena->freelist =
+		kcalloc(arena->nfree, sizeof(struct free_entry), GFP_KERNEL);
 	if (!arena->freelist)
 		return -ENOMEM;
 
@@ -562,8 +561,9 @@ static int btt_freelist_init(struct arena_info *arena)
 			arena->freelist[i].has_err = 1;
 			ret = arena_clear_freelist_error(arena, i);
 			if (ret)
-				dev_err_ratelimited(to_dev(arena),
-						    "Unable to clear known errors\n");
+				dev_err_ratelimited(
+					to_dev(arena),
+					"Unable to clear known errors\n");
 		}
 
 		/* This implies a newly created or untouched flog entry */
@@ -589,8 +589,8 @@ static int btt_freelist_init(struct arena_info *arena)
 			 * to complete the map write. So fix up the map.
 			 */
 			ret = btt_map_write(arena, le32_to_cpu(log_new.lba),
-					    le32_to_cpu(log_new.new_map),
-					    0, 0, 0);
+					    le32_to_cpu(log_new.new_map), 0, 0,
+					    0);
 			if (ret)
 				return ret;
 		}
@@ -601,9 +601,8 @@ static int btt_freelist_init(struct arena_info *arena)
 
 static bool ent_is_padding(struct log_entry *ent)
 {
-	return (ent->lba == 0) &&
-		(ent->old_map == 0) && (ent->new_map == 0) &&
-		(ent->seq == 0);
+	return (ent->lba == 0) && (ent->old_map == 0) && (ent->new_map == 0) &&
+	       (ent->seq == 0);
 }
 
 /*
@@ -622,7 +621,7 @@ static bool ent_is_padding(struct log_entry *ent)
 static int log_set_indices(struct arena_info *arena)
 {
 	bool idx_set = false, initial_state = true;
-	int ret, log_index[2] = {-1, -1};
+	int ret, log_index[2] = { -1, -1 };
 	u32 i, j, next_idx = 0;
 	struct log_group log;
 	u32 pad_count = 0;
@@ -703,10 +702,9 @@ static int log_set_indices(struct arena_info *arena)
 	 * Only allow the known permutations of log/padding indices,
 	 * i.e. (0, 1), and (0, 2)
 	 */
-	if ((log_index[0] == 0) &&
-	    ((log_index[1] == 1) || (log_index[1] == 2))) {
+	if ((log_index[0] == 0) && ((log_index[1] == 1) || (log_index[1] == 2)))
 		; /* known index possibilities */
-	} else {
+	else {
 		dev_err(to_dev(arena), "Found an unknown padding scheme\n");
 		return -ENXIO;
 	}
@@ -731,8 +729,8 @@ static int btt_maplocks_init(struct arena_info *arena)
 {
 	u32 i;
 
-	arena->map_locks = kcalloc(arena->nfree, sizeof(struct aligned_lock),
-				   GFP_KERNEL);
+	arena->map_locks =
+		kcalloc(arena->nfree, sizeof(struct aligned_lock), GFP_KERNEL);
 	if (!arena->map_locks)
 		return -ENOMEM;
 
@@ -762,8 +760,8 @@ static struct arena_info *alloc_arena(struct btt *btt, size_t size,
 	arena->size = size;
 	arena->external_lba_start = start;
 	arena->external_lbasize = btt->lbasize;
-	arena->internal_lbasize = roundup(arena->external_lbasize,
-					  INT_LBASIZE_ALIGNMENT);
+	arena->internal_lbasize =
+		roundup(arena->external_lbasize, INT_LBASIZE_ALIGNMENT);
 	arena->nfree = BTT_DEFAULT_NFREE;
 	arena->version_major = btt->nd_btt->version_major;
 	arena->version_minor = btt->nd_btt->version_minor;
@@ -803,7 +801,7 @@ static void free_arenas(struct btt *btt)
 {
 	struct arena_info *arena, *next;
 
-	list_for_each_entry_safe(arena, next, &btt->arena_list, list) {
+	list_for_each_entry_safe (arena, next, &btt->arena_list, list) {
 		list_del(&arena->list);
 		kfree(arena->rtt);
 		kfree(arena->map_locks);
@@ -828,18 +826,18 @@ static void parse_arena_meta(struct arena_info *arena, struct btt_sb *super,
 	arena->version_major = le16_to_cpu(super->version_major);
 	arena->version_minor = le16_to_cpu(super->version_minor);
 
-	arena->nextoff = (super->nextoff == 0)
-		? 0
-		: arena_off + le64_to_cpu(super->nextoff);
+	arena->nextoff = (super->nextoff == 0) ?
+				 0 :
+				 (arena_off + le64_to_cpu(super->nextoff));
 	arena->infooff = arena_off;
 	arena->dataoff = arena_off + le64_to_cpu(super->dataoff);
 	arena->mapoff = arena_off + le64_to_cpu(super->mapoff);
 	arena->logoff = arena_off + le64_to_cpu(super->logoff);
 	arena->info2off = arena_off + le64_to_cpu(super->info2off);
 
-	arena->size = (le64_to_cpu(super->nextoff) > 0)
-		? le64_to_cpu(super->nextoff)
-		: arena->info2off - arena->infooff + BTT_PG_SIZE;
+	arena->size = (le64_to_cpu(super->nextoff) > 0) ?
+			      (le64_to_cpu(super->nextoff)) :
+			      (arena->info2off - arena->infooff + BTT_PG_SIZE);
 
 	arena->flags = le32_to_cpu(super->flags);
 }
@@ -1029,7 +1027,7 @@ static int btt_meta_init(struct btt *btt)
 	struct arena_info *arena;
 
 	mutex_lock(&btt->init_lock);
-	list_for_each_entry(arena, &btt->arena_list, list) {
+	list_for_each_entry (arena, &btt->arena_list, list) {
 		ret = btt_arena_write_layout(arena);
 		if (ret)
 			goto unlock;
@@ -1072,7 +1070,7 @@ static int lba_to_arena(struct btt *btt, sector_t sector, __u32 *premap,
 	struct arena_info *arena_list;
 	__u64 lba = div_u64(sector << SECTOR_SHIFT, btt->sector_size);
 
-	list_for_each_entry(arena_list, &btt->arena_list, list) {
+	list_for_each_entry (arena_list, &btt->arena_list, list) {
 		if (lba < arena_list->external_nlba) {
 			*arena = arena_list;
 			*premap = lba;
@@ -1117,8 +1115,8 @@ static int btt_data_read(struct arena_info *arena, struct page *page,
 	return ret;
 }
 
-static int btt_data_write(struct arena_info *arena, u32 lba,
-			  struct page *page, unsigned int off, u32 len)
+static int btt_data_write(struct arena_info *arena, u32 lba, struct page *page,
+			  unsigned int off, u32 len)
 {
 	int ret;
 	u64 nsoff = to_namespace_offset(arena, lba);
@@ -1322,7 +1320,7 @@ static int btt_write_pg(struct btt *btt, struct bio_integrity_payload *bip,
 		u32 cur_len;
 		int e_flag;
 
-retry:
+	retry:
 		lane = nd_region_acquire_lane(btt->nd_region);
 
 		ret = lba_to_arena(btt, sector, &premap, &arena);
@@ -1453,7 +1451,7 @@ static blk_qc_t btt_make_request(struct request_queue *q, struct bio *bio)
 		return BLK_QC_T_NONE;
 
 	do_acct = nd_iostat_start(bio, &start);
-	bio_for_each_segment(bvec, bio, iter) {
+	bio_for_each_segment (bvec, bio, iter) {
 		unsigned int len = bvec.bv_len;
 
 		if (len > PAGE_SIZE || len < btt->sector_size ||
@@ -1469,9 +1467,9 @@ static blk_qc_t btt_make_request(struct request_queue *q, struct bio *bio)
 				  bio_op(bio), iter.bi_sector);
 		if (err) {
 			dev_err(&btt->nd_btt->dev,
-				"io error in %s sector %lld, len %d\n",
-				op_is_write(bio_op(bio)) ? "WRITE" : "READ",
-				(u64)iter.bi_sector, len);
+				"io error in %s sector %lld, len %d,\n",
+				(op_is_write(bio_op(bio))) ? "WRITE" : "READ",
+				(unsigned long long)iter.bi_sector, len);
 			bio->bi_status = errno_to_blk_status(err);
 			break;
 		}
@@ -1508,10 +1506,10 @@ static int btt_getgeo(struct block_device *bd, struct hd_geometry *geo)
 }
 
 static const struct block_device_operations btt_fops = {
-	.owner =		THIS_MODULE,
-	.rw_page =		btt_rw_page,
-	.getgeo =		btt_getgeo,
-	.revalidate_disk =	nvdimm_revalidate_disk,
+	.owner = THIS_MODULE,
+	.rw_page = btt_rw_page,
+	.getgeo = btt_getgeo,
+	.revalidate_disk = nvdimm_revalidate_disk,
 };
 
 static int btt_blk_init(struct btt *btt)
@@ -1621,7 +1619,7 @@ static struct btt *btt_init(struct nd_btt *nd_btt, unsigned long long rawsize,
 		return NULL;
 	} else if (btt->init_state != INIT_READY) {
 		btt->num_arenas = (rawsize / ARENA_MAX_SIZE) +
-			((rawsize % ARENA_MAX_SIZE) ? 1 : 0);
+				  ((rawsize % ARENA_MAX_SIZE) ? 1 : 0);
 		dev_dbg(dev, "init: %d arenas for %llu rawsize\n",
 			btt->num_arenas, rawsize);
 
diff --git a/drivers/nvdimm/btt.h b/drivers/nvdimm/btt.h
index fb0f4546153f..e514a1380157 100644
--- a/drivers/nvdimm/btt.h
+++ b/drivers/nvdimm/btt.h
@@ -10,40 +10,36 @@
 #include <linux/badblocks.h>
 #include <linux/types.h>
 
-#define BTT_SIG_LEN		16
-#define BTT_SIG			"BTT_ARENA_INFO\0"
-#define MAP_ENT_SIZE		4
-#define MAP_TRIM_SHIFT		31
-#define MAP_TRIM_MASK		BIT(MAP_TRIM_SHIFT)
-#define MAP_ERR_SHIFT		30
-#define MAP_ERR_MASK		BIT(MAP_ERR_SHIFT)
-#define MAP_LBA_MASK		(~(MAP_TRIM_MASK | MAP_ERR_MASK))
-#define MAP_ENT_NORMAL		0xC0000000
-#define LOG_GRP_SIZE		sizeof(struct log_group)
-#define LOG_ENT_SIZE		sizeof(struct log_entry)
-#define ARENA_MIN_SIZE		BIT(24)		/* 16 MB */
-#define ARENA_MAX_SIZE		BIT_ULL(39)	/* 512 GB */
-#define RTT_VALID		BIT(31)
-#define RTT_INVALID		0
-#define BTT_PG_SIZE		4096
-#define BTT_DEFAULT_NFREE	ND_MAX_LANES
-#define LOG_SEQ_INIT		1
-
-#define IB_FLAG_ERROR		0x00000001
-#define IB_FLAG_ERROR_MASK	0x00000001
-
-#define ent_lba(ent)		((ent) & MAP_LBA_MASK)
-#define ent_e_flag(ent)		(!!((ent) & MAP_ERR_MASK))
-#define ent_z_flag(ent)		(!!((ent) & MAP_TRIM_MASK))
-#define set_e_flag(ent)		((ent) |= MAP_ERR_MASK)
+#define BTT_SIG_LEN 16
+#define BTT_SIG "BTT_ARENA_INFO\0"
+#define MAP_ENT_SIZE 4
+#define MAP_TRIM_SHIFT 31
+#define MAP_TRIM_MASK (1 << MAP_TRIM_SHIFT)
+#define MAP_ERR_SHIFT 30
+#define MAP_ERR_MASK (1 << MAP_ERR_SHIFT)
+#define MAP_LBA_MASK (~((1 << MAP_TRIM_SHIFT) | (1 << MAP_ERR_SHIFT)))
+#define MAP_ENT_NORMAL 0xC0000000
+#define LOG_GRP_SIZE sizeof(struct log_group)
+#define LOG_ENT_SIZE sizeof(struct log_entry)
+#define ARENA_MIN_SIZE (1UL << 24) /* 16 MB */
+#define ARENA_MAX_SIZE (1ULL << 39) /* 512 GB */
+#define RTT_VALID (1UL << 31)
+#define RTT_INVALID 0
+#define BTT_PG_SIZE 4096
+#define BTT_DEFAULT_NFREE ND_MAX_LANES
+#define LOG_SEQ_INIT 1
+
+#define IB_FLAG_ERROR 0x00000001
+#define IB_FLAG_ERROR_MASK 0x00000001
+
+#define ent_lba(ent) (ent & MAP_LBA_MASK)
+#define ent_e_flag(ent) (!!(ent & MAP_ERR_MASK))
+#define ent_z_flag(ent) (!!(ent & MAP_TRIM_MASK))
+#define set_e_flag(ent) (ent |= MAP_ERR_MASK)
 /* 'normal' is both e and z flags set */
-#define ent_normal(ent)		(ent_e_flag(ent) && ent_z_flag(ent))
+#define ent_normal(ent) (ent_e_flag(ent) && ent_z_flag(ent))
 
-enum btt_init_state {
-	INIT_UNCHECKED = 0,
-	INIT_NOTFOUND,
-	INIT_READY
-};
+enum btt_init_state { INIT_UNCHECKED = 0, INIT_NOTFOUND, INIT_READY };
 
 /*
  * A log group represents one log 'lane', and consists of four log entries.
@@ -167,7 +163,7 @@ struct aligned_lock {
  * IO, this struct is passed around for the duration of the IO.
  */
 struct arena_info {
-	u64 size;			/* Total bytes for this arena */
+	u64 size; /* Total bytes for this arena */
 	u64 external_lba_start;
 	u32 internal_nlba;
 	u32 internal_lbasize;
diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index b27993ade004..2d24d3408152 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -45,9 +45,8 @@ struct nd_btt *to_nd_btt(struct device *dev)
 }
 EXPORT_SYMBOL(to_nd_btt);
 
-static const unsigned long btt_lbasize_supported[] = {
-	512, 520, 528, 4096, 4104, 4160, 4224, 0
-};
+static const unsigned long btt_lbasize_supported[] = { 512,  520,  528,	 4096,
+						       4104, 4160, 4224, 0 };
 
 static ssize_t sector_size_show(struct device *dev,
 				struct device_attribute *attr, char *buf)
@@ -58,8 +57,8 @@ static ssize_t sector_size_show(struct device *dev,
 }
 
 static ssize_t sector_size_store(struct device *dev,
-				 struct device_attribute *attr,
-				 const char *buf, size_t len)
+				 struct device_attribute *attr, const char *buf,
+				 size_t len)
 {
 	struct nd_btt *nd_btt = to_nd_btt(dev);
 	ssize_t rc;
@@ -68,8 +67,8 @@ static ssize_t sector_size_store(struct device *dev,
 	nvdimm_bus_lock(dev);
 	rc = nd_size_select_store(dev, buf, &nd_btt->lbasize,
 				  btt_lbasize_supported);
-	dev_dbg(dev, "result: %zd wrote: %s%s",
-		rc, buf, buf[len - 1] == '\n' ? "" : "\n");
+	dev_dbg(dev, "result: %zd wrote: %s%s", rc, buf,
+		buf[len - 1] == '\n' ? "" : "\n");
 	nvdimm_bus_unlock(dev);
 	nd_device_unlock(dev);
 
@@ -77,8 +76,8 @@ static ssize_t sector_size_store(struct device *dev,
 }
 static DEVICE_ATTR_RW(sector_size);
 
-static ssize_t uuid_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
+static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
 {
 	struct nd_btt *nd_btt = to_nd_btt(dev);
 
@@ -95,8 +94,8 @@ static ssize_t uuid_store(struct device *dev, struct device_attribute *attr,
 
 	nd_device_lock(dev);
 	rc = nd_uuid_store(dev, &nd_btt->uuid, buf, len);
-	dev_dbg(dev, "result: %zd wrote: %s%s",
-		rc, buf, buf[len - 1] == '\n' ? "" : "\n");
+	dev_dbg(dev, "result: %zd wrote: %s%s", rc, buf,
+		buf[len - 1] == '\n' ? "" : "\n");
 	nd_device_unlock(dev);
 
 	return rc ? rc : len;
@@ -117,8 +116,8 @@ static ssize_t namespace_show(struct device *dev, struct device_attribute *attr,
 }
 
 static ssize_t namespace_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t len)
+			       struct device_attribute *attr, const char *buf,
+			       size_t len)
 {
 	struct nd_btt *nd_btt = to_nd_btt(dev);
 	ssize_t rc;
@@ -126,8 +125,8 @@ static ssize_t namespace_store(struct device *dev,
 	nd_device_lock(dev);
 	nvdimm_bus_lock(dev);
 	rc = nd_namespace_store(dev, &nd_btt->ndns, buf, len);
-	dev_dbg(dev, "result: %zd wrote: %s%s",
-		rc, buf, buf[len - 1] == '\n' ? "" : "\n");
+	dev_dbg(dev, "result: %zd wrote: %s%s", rc, buf,
+		buf[len - 1] == '\n' ? "" : "\n");
 	nvdimm_bus_unlock(dev);
 	nd_device_unlock(dev);
 
@@ -142,9 +141,9 @@ static ssize_t size_show(struct device *dev, struct device_attribute *attr,
 	ssize_t rc;
 
 	nd_device_lock(dev);
-	if (dev->driver) {
+	if (dev->driver)
 		rc = sprintf(buf, "%llu\n", nd_btt->size);
-	} else {
+	else {
 		/* no size to convey if the btt instance is disabled */
 		rc = -ENXIO;
 	}
@@ -162,12 +161,9 @@ static ssize_t log_zero_flags_show(struct device *dev,
 static DEVICE_ATTR_RO(log_zero_flags);
 
 static struct attribute *nd_btt_attributes[] = {
-	&dev_attr_sector_size.attr,
-	&dev_attr_namespace.attr,
-	&dev_attr_uuid.attr,
-	&dev_attr_size.attr,
-	&dev_attr_log_zero_flags.attr,
-	NULL,
+	&dev_attr_sector_size.attr,    &dev_attr_namespace.attr,
+	&dev_attr_uuid.attr,	       &dev_attr_size.attr,
+	&dev_attr_log_zero_flags.attr, NULL,
 };
 
 static struct attribute_group nd_btt_attribute_group = {
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 733b2a2117c0..b159138d5490 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -2,9 +2,7 @@
 /*
  * Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
  */
-
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
 #include <linux/libnvdimm.h>
 #include <linux/sched/mm.h>
 #include <linux/vmalloc.h>
@@ -89,8 +87,8 @@ static int nvdimm_bus_probe(struct device *dev)
 	if (!try_module_get(provider))
 		return -ENXIO;
 
-	dev_dbg(&nvdimm_bus->dev, "START: %s.probe(%s)\n",
-		dev->driver->name, dev_name(dev));
+	dev_dbg(&nvdimm_bus->dev, "START: %s.probe(%s)\n", dev->driver->name,
+		dev_name(dev));
 
 	nvdimm_bus_probe_start(nvdimm_bus);
 	debug_nvdimm_lock(dev);
@@ -103,8 +101,8 @@ static int nvdimm_bus_probe(struct device *dev)
 		nd_region_disable(nvdimm_bus, dev);
 	nvdimm_bus_probe_end(nvdimm_bus);
 
-	dev_dbg(&nvdimm_bus->dev, "END: %s.probe(%s) = %d\n",
-		dev->driver->name, dev_name(dev), rc);
+	dev_dbg(&nvdimm_bus->dev, "END: %s.probe(%s) = %d\n", dev->driver->name,
+		dev_name(dev), rc);
 
 	if (rc != 0)
 		module_put(provider);
@@ -125,8 +123,8 @@ static int nvdimm_bus_remove(struct device *dev)
 	}
 	nd_region_disable(nvdimm_bus, dev);
 
-	dev_dbg(&nvdimm_bus->dev, "%s.remove(%s) = %d\n",
-		dev->driver->name, dev_name(dev), rc);
+	dev_dbg(&nvdimm_bus->dev, "%s.remove(%s) = %d\n", dev->driver->name,
+		dev_name(dev), rc);
 	module_put(provider);
 	return rc;
 }
@@ -226,8 +224,7 @@ static void nvdimm_account_cleared_poison(struct nvdimm_bus *nvdimm_bus,
 		nvdimm_clear_badblocks_regions(nvdimm_bus, phys, cleared);
 }
 
-long nvdimm_clear_poison(struct device *dev, phys_addr_t phys,
-			 unsigned int len)
+long nvdimm_clear_poison(struct device *dev, phys_addr_t phys, unsigned int len)
 {
 	struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(dev);
 	struct nvdimm_bus_descriptor *nd_desc;
@@ -419,7 +416,7 @@ static void free_badrange_list(struct list_head *badrange_list)
 {
 	struct badrange_entry *bre, *next;
 
-	list_for_each_entry_safe(bre, next, badrange_list, list) {
+	list_for_each_entry_safe (bre, next, badrange_list, list) {
 		list_del(&bre->list);
 		kfree(bre);
 	}
@@ -677,8 +674,8 @@ struct attribute_group nd_device_attribute_group = {
 };
 EXPORT_SYMBOL_GPL(nd_device_attribute_group);
 
-static ssize_t numa_node_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
+static ssize_t numa_node_show(struct device *dev, struct device_attribute *attr,
+			      char *buf)
 {
 	return sprintf(buf, "%d\n", dev_to_node(dev));
 }
@@ -858,9 +855,9 @@ u32 nd_cmd_out_size(struct nvdimm *nvdimm, int cmd,
 
 	if (nvdimm && cmd == ND_CMD_GET_CONFIG_DATA && idx == 1)
 		return in_field[1];
-	if (nvdimm && cmd == ND_CMD_VENDOR && idx == 2)
+	else if (nvdimm && cmd == ND_CMD_VENDOR && idx == 2)
 		return out_field[1];
-	if (!nvdimm && cmd == ND_CMD_ARS_STATUS && idx == 2) {
+	else if (!nvdimm && cmd == ND_CMD_ARS_STATUS && idx == 2) {
 		/*
 		 * Per table 9-276 ARS Data in ACPI 6.1, out_field[1] is
 		 * "Size of Output Buffer in bytes, including this
@@ -877,8 +874,7 @@ u32 nd_cmd_out_size(struct nvdimm *nvdimm, int cmd,
 		if (out_field[1] - 4 == remainder)
 			return remainder;
 		return out_field[1] - 8;
-	}
-	if (cmd == ND_CMD_CALL) {
+	} else if (cmd == ND_CMD_CALL) {
 		struct nd_cmd_pkg *pkg = (struct nd_cmd_pkg *)in_field;
 
 		return pkg->nd_size_out;
@@ -897,8 +893,7 @@ void wait_nvdimm_bus_probe_idle(struct device *dev)
 			break;
 		nvdimm_bus_unlock(dev);
 		nd_device_unlock(dev);
-		wait_event(nvdimm_bus->wait,
-			   nvdimm_bus->probe_active == 0);
+		wait_event(nvdimm_bus->wait, nvdimm_bus->probe_active == 0);
 		nd_device_lock(dev);
 		nvdimm_bus_lock(dev);
 	} while (true);
@@ -931,9 +926,8 @@ static int nd_pmem_forget_poison_check(struct device *dev, void *data)
 
 		if (!ndns)
 			return 0;
-	} else {
+	} else
 		ndns = to_ndns(dev);
-	}
 
 	nsio = to_nd_namespace_io(&ndns->dev);
 	pstart = nsio->res.start + offset;
@@ -952,8 +946,8 @@ static int nd_ns_forget_poison_check(struct device *dev, void *data)
 
 /* set_config requires an idle interleave set */
 static int nd_cmd_clear_to_send(struct nvdimm_bus *nvdimm_bus,
-				struct nvdimm *nvdimm,
-				unsigned int cmd, void *data)
+				struct nvdimm *nvdimm, unsigned int cmd,
+				void *data)
 {
 	struct nvdimm_bus_descriptor *nd_desc = nvdimm_bus->nd_desc;
 
@@ -1027,9 +1021,9 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm,
 		case ND_CMD_ARS_START:
 		case ND_CMD_CLEAR_ERROR:
 		case ND_CMD_CALL:
-			dev_dbg(dev, "'%s' command while read-only\n",
-				nvdimm ? nvdimm_cmd_name(cmd)
-				: nvdimm_bus_cmd_name(cmd));
+			dev_dbg(dev, "'%s' command while read-only.\n",
+				nvdimm ? nvdimm_cmd_name(cmd) :
+					 nvdimm_bus_cmd_name(cmd));
 			return -EPERM;
 		default:
 			break;
@@ -1044,13 +1038,15 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm,
 
 		in_size = nd_cmd_in_size(nvdimm, cmd, desc, i, in_env);
 		if (in_size == UINT_MAX) {
-			dev_err(dev, "%s:%s unknown input size cmd: %s field: %d\n",
+			dev_err(dev,
+				"%s:%s unknown input size cmd: %s field: %d\n",
 				__func__, dimm_name, cmd_name, i);
 			rc = -ENXIO;
 			goto out;
 		}
 		if (in_len < ND_CMD_MAX_ENVELOPE)
-			copy = min_t(u32, ND_CMD_MAX_ENVELOPE - in_len, in_size);
+			copy = min_t(u32, ND_CMD_MAX_ENVELOPE - in_len,
+				     in_size);
 		else
 			copy = 0;
 		if (copy && copy_from_user(&in_env[in_len], p + in_len, copy)) {
@@ -1074,18 +1070,20 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm,
 	}
 
 	for (i = 0; i < desc->out_num; i++) {
-		u32 out_size = nd_cmd_out_size(nvdimm, cmd, desc, i,
-					       (u32 *)in_env, (u32 *)out_env, 0);
+		u32 out_size = nd_cmd_out_size(
+			nvdimm, cmd, desc, i, (u32 *)in_env, (u32 *)out_env, 0);
 		u32 copy;
 
 		if (out_size == UINT_MAX) {
-			dev_dbg(dev, "%s unknown output size cmd: %s field: %d\n",
+			dev_dbg(dev,
+				"%s unknown output size cmd: %s field: %d\n",
 				dimm_name, cmd_name, i);
 			rc = -EFAULT;
 			goto out;
 		}
 		if (out_len < ND_CMD_MAX_ENVELOPE)
-			copy = min_t(u32, ND_CMD_MAX_ENVELOPE - out_len, out_size);
+			copy = min_t(u32, ND_CMD_MAX_ENVELOPE - out_len,
+				     out_size);
 		else
 			copy = 0;
 		if (copy && copy_from_user(&out_env[out_len],
@@ -1098,8 +1096,8 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm,
 
 	buf_len = (u64)out_len + (u64)in_len;
 	if (buf_len > ND_IOCTL_MAX_BUFLEN) {
-		dev_dbg(dev, "%s cmd: %s buf_len: %llu > %d\n",
-			dimm_name, cmd_name, buf_len, ND_IOCTL_MAX_BUFLEN);
+		dev_dbg(dev, "%s cmd: %s buf_len: %llu > %d\n", dimm_name,
+			cmd_name, buf_len, ND_IOCTL_MAX_BUFLEN);
 		rc = -EINVAL;
 		goto out;
 	}
@@ -1174,7 +1172,7 @@ static long nd_ioctl(struct file *file, unsigned int cmd, unsigned long arg,
 
 	ro = ((file->f_flags & O_ACCMODE) == O_RDONLY);
 	mutex_lock(&nvdimm_bus_list_mutex);
-	list_for_each_entry(nvdimm_bus, &nvdimm_bus_list, list) {
+	list_for_each_entry (nvdimm_bus, &nvdimm_bus_list, list) {
 		if (mode == DIMM_IOCTL) {
 			struct device *dev;
 
diff --git a/drivers/nvdimm/claim.c b/drivers/nvdimm/claim.c
index 953029c240e5..b96a3f9226cc 100644
--- a/drivers/nvdimm/claim.c
+++ b/drivers/nvdimm/claim.c
@@ -26,8 +26,7 @@ void __nd_detach_ndns(struct device *dev, struct nd_namespace_common **_ndns)
 	put_device(&ndns->dev);
 }
 
-void nd_detach_ndns(struct device *dev,
-		    struct nd_namespace_common **_ndns)
+void nd_detach_ndns(struct device *dev, struct nd_namespace_common **_ndns)
 {
 	struct nd_namespace_common *ndns = *_ndns;
 
@@ -132,8 +131,8 @@ static void nd_detach_and_reset(struct device *dev,
 }
 
 ssize_t nd_namespace_store(struct device *dev,
-			   struct nd_namespace_common **_ndns,
-			   const char *buf, size_t len)
+			   struct nd_namespace_common **_ndns, const char *buf,
+			   size_t len)
 {
 	struct nd_namespace_common *ndns;
 	struct device *found;
@@ -149,7 +148,9 @@ ssize_t nd_namespace_store(struct device *dev,
 		return -ENOMEM;
 	strim(name);
 
-	if (!(strncmp(name, "namespace", 9) == 0 || strcmp(name, "") == 0)) {
+	if (strncmp(name, "namespace", 9) == 0 || strcmp(name, "") == 0)
+		/* pass */;
+	else {
 		len = -EINVAL;
 		goto out;
 	}
@@ -158,8 +159,7 @@ ssize_t nd_namespace_store(struct device *dev,
 	if (strcmp(name, "") == 0) {
 		nd_detach_and_reset(dev, _ndns);
 		goto out;
-	}
-	if (ndns) {
+	} else if (ndns) {
 		dev_dbg(dev, "namespace already set to: %s\n",
 			dev_name(&ndns->dev));
 		len = -EBUSY;
@@ -201,6 +201,7 @@ ssize_t nd_namespace_store(struct device *dev,
 	default:
 		len = -EBUSY;
 		goto out_attach;
+		break;
 	}
 
 	if (__nvdimm_namespace_capacity(ndns) < SZ_16M) {
@@ -211,8 +212,7 @@ ssize_t nd_namespace_store(struct device *dev,
 
 	WARN_ON_ONCE(!is_nvdimm_bus_locked(dev));
 	if (!__nd_attach_ndns(dev, ndns, _ndns)) {
-		dev_dbg(dev, "%s already claimed\n",
-			dev_name(&ndns->dev));
+		dev_dbg(dev, "%s already claimed\n", dev_name(&ndns->dev));
 		len = -EBUSY;
 	}
 
@@ -277,9 +277,8 @@ static int nsio_rw_bytes(struct nd_namespace_common *ndns,
 			long cleared;
 
 			might_sleep();
-			cleared = nvdimm_clear_poison(&ndns->dev,
-						      nsio->res.start + offset,
-						      size);
+			cleared = nvdimm_clear_poison(
+				&ndns->dev, nsio->res.start + offset, size);
 			if (cleared < size)
 				rc = -EIO;
 			if (cleared > 0 && cleared / 512) {
@@ -287,9 +286,8 @@ static int nsio_rw_bytes(struct nd_namespace_common *ndns,
 				badblocks_clear(&nsio->bb, sector, cleared);
 			}
 			arch_invalidate_pmem(nsio->addr + offset, size);
-		} else {
+		} else
 			rc = -EIO;
-		}
 	}
 
 	memcpy_flushcache(nsio->addr + offset, buf, size);
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index deb92c806abf..1ba19bef3334 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -68,14 +68,15 @@ static struct nvdimm_map *find_nvdimm_map(struct device *dev,
 	struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(dev);
 	struct nvdimm_map *nvdimm_map;
 
-	list_for_each_entry(nvdimm_map, &nvdimm_bus->mapping_list, list)
+	list_for_each_entry (nvdimm_map, &nvdimm_bus->mapping_list, list)
 		if (nvdimm_map->offset == offset)
 			return nvdimm_map;
 	return NULL;
 }
 
 static struct nvdimm_map *alloc_nvdimm_map(struct device *dev,
-					   resource_size_t offset, size_t size, unsigned long flags)
+					   resource_size_t offset, size_t size,
+					   unsigned long flags)
 {
 	struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(dev);
 	struct nvdimm_map *nvdimm_map;
@@ -92,8 +93,9 @@ static struct nvdimm_map *alloc_nvdimm_map(struct device *dev,
 	kref_init(&nvdimm_map->kref);
 
 	if (!request_mem_region(offset, size, dev_name(&nvdimm_bus->dev))) {
-		dev_err(&nvdimm_bus->dev, "failed to request %pa + %zd for %s\n",
-			&offset, size, dev_name(dev));
+		dev_err(&nvdimm_bus->dev,
+			"failed to request %pa + %zd for %s\n", &offset, size,
+			dev_name(dev));
 		goto err_request_region;
 	}
 
@@ -208,7 +210,9 @@ EXPORT_SYMBOL_GPL(to_nvdimm_bus_dev);
 
 static bool is_uuid_sep(char sep)
 {
-	return sep == '\n' || sep == '-' || sep == ':' || sep == '\0';
+	if (sep == '\n' || sep == '-' || sep == ':' || sep == '\0')
+		return true;
+	return false;
 }
 
 static int nd_uuid_parse(struct device *dev, u8 *uuid_out, const char *buf,
@@ -220,9 +224,8 @@ static int nd_uuid_parse(struct device *dev, u8 *uuid_out, const char *buf,
 
 	for (i = 0; i < 16; i++) {
 		if (!isxdigit(str[0]) || !isxdigit(str[1])) {
-			dev_dbg(dev, "pos: %d buf[%zd]: %c buf[%zd]: %c\n",
-				i, str - buf, str[0],
-				str + 1 - buf, str[1]);
+			dev_dbg(dev, "pos: %d buf[%zd]: %c buf[%zd]: %c\n", i,
+				str - buf, str[0], str + 1 - buf, str[1]);
 			return -EINVAL;
 		}
 
@@ -283,7 +286,8 @@ ssize_t nd_size_select_show(unsigned long current_size,
 }
 
 ssize_t nd_size_select_store(struct device *dev, const char *buf,
-			     unsigned long *current_size, const unsigned long *supported)
+			     unsigned long *current_size,
+			     const unsigned long *supported)
 {
 	unsigned long lbasize;
 	int rc, i;
@@ -307,14 +311,14 @@ ssize_t nd_size_select_store(struct device *dev, const char *buf,
 	}
 }
 
-static ssize_t commands_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t commands_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	int cmd, len = 0;
 	struct nvdimm_bus *nvdimm_bus = to_nvdimm_bus(dev);
 	struct nvdimm_bus_descriptor *nd_desc = nvdimm_bus->nd_desc;
 
-	for_each_set_bit(cmd, &nd_desc->cmd_mask, BITS_PER_LONG)
+	for_each_set_bit (cmd, &nd_desc->cmd_mask, BITS_PER_LONG)
 		len += sprintf(buf + len, "%s ", nvdimm_bus_cmd_name(cmd));
 	len += sprintf(buf + len, "\n");
 	return len;
@@ -334,8 +338,8 @@ static const char *nvdimm_bus_provider(struct nvdimm_bus *nvdimm_bus)
 		return "unknown";
 }
 
-static ssize_t provider_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t provider_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nvdimm_bus *nvdimm_bus = to_nvdimm_bus(dev);
 
diff --git a/drivers/nvdimm/dax_devs.c b/drivers/nvdimm/dax_devs.c
index 46230eb35b90..6d22b0f83b3b 100644
--- a/drivers/nvdimm/dax_devs.c
+++ b/drivers/nvdimm/dax_devs.c
@@ -125,9 +125,8 @@ int nd_dax_probe(struct device *dev, struct nd_namespace_common *ndns)
 	if (rc < 0) {
 		nd_detach_ndns(dax_dev, &nd_pfn->ndns);
 		put_device(dax_dev);
-	} else {
+	} else
 		__nd_device_register(dax_dev);
-	}
 
 	return rc;
 }
diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index 35a6c20d30fd..415b03ca458a 100644
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -2,9 +2,7 @@
 /*
  * Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
  */
-
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
 #include <linux/moduleparam.h>
 #include <linux/vmalloc.h>
 #include <linux/device.h>
@@ -84,8 +82,8 @@ int nvdimm_init_nsarea(struct nvdimm_drvdata *ndd)
 	return cmd_rc;
 }
 
-int nvdimm_get_config_data(struct nvdimm_drvdata *ndd, void *buf,
-			   size_t offset, size_t len)
+int nvdimm_get_config_data(struct nvdimm_drvdata *ndd, void *buf, size_t offset,
+			   size_t len)
 {
 	struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(ndd->dev);
 	struct nvdimm_bus_descriptor *nd_desc = nvdimm_bus->nd_desc;
@@ -131,8 +129,8 @@ int nvdimm_get_config_data(struct nvdimm_drvdata *ndd, void *buf,
 	return rc;
 }
 
-int nvdimm_set_config_data(struct nvdimm_drvdata *ndd, size_t offset,
-			   void *buf, size_t len)
+int nvdimm_set_config_data(struct nvdimm_drvdata *ndd, size_t offset, void *buf,
+			   size_t len)
 {
 	size_t max_cmd_size, buf_offset;
 	struct nd_cmd_set_config_hdr *cmd;
@@ -151,8 +149,8 @@ int nvdimm_set_config_data(struct nvdimm_drvdata *ndd, size_t offset,
 	if (!cmd)
 		return -ENOMEM;
 
-	for (buf_offset = 0; len; len -= cmd->in_length,
-		     buf_offset += cmd->in_length) {
+	for (buf_offset = 0; len;
+	     len -= cmd->in_length, buf_offset += cmd->in_length) {
 		size_t cmd_size;
 
 		cmd->in_offset = offset + buf_offset;
@@ -259,8 +257,7 @@ void nvdimm_drvdata_release(struct kref *kref)
 
 	dev_dbg(dev, "trace\n");
 	nvdimm_bus_lock(dev);
-	for_each_dpa_resource_safe(ndd, res, _r)
-		nvdimm_free_dpa(ndd, res);
+	for_each_dpa_resource_safe(ndd, res, _r) nvdimm_free_dpa(ndd, res);
 	nvdimm_bus_unlock(dev);
 
 	kvfree(ndd->data);
@@ -305,8 +302,8 @@ void *nvdimm_provider_data(struct nvdimm *nvdimm)
 }
 EXPORT_SYMBOL_GPL(nvdimm_provider_data);
 
-static ssize_t commands_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t commands_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nvdimm *nvdimm = to_nvdimm(dev);
 	int cmd, len = 0;
@@ -314,15 +311,15 @@ static ssize_t commands_show(struct device *dev,
 	if (!nvdimm->cmd_mask)
 		return sprintf(buf, "\n");
 
-	for_each_set_bit(cmd, &nvdimm->cmd_mask, BITS_PER_LONG)
+	for_each_set_bit (cmd, &nvdimm->cmd_mask, BITS_PER_LONG)
 		len += sprintf(buf + len, "%s ", nvdimm_cmd_name(cmd));
 	len += sprintf(buf + len, "\n");
 	return len;
 }
 static DEVICE_ATTR_RO(commands);
 
-static ssize_t flags_show(struct device *dev,
-			  struct device_attribute *attr, char *buf)
+static ssize_t flags_show(struct device *dev, struct device_attribute *attr,
+			  char *buf)
 {
 	struct nvdimm *nvdimm = to_nvdimm(dev);
 
@@ -363,17 +360,16 @@ static ssize_t available_slots_show(struct device *dev,
 	if (nfree - 1 > nfree) {
 		dev_WARN_ONCE(dev, 1, "we ate our last label?\n");
 		nfree = 0;
-	} else {
+	} else
 		nfree--;
-	}
 	rc = sprintf(buf, "%d\n", nfree);
 	nvdimm_bus_unlock(dev);
 	return rc;
 }
 static DEVICE_ATTR_RO(available_slots);
 
-__weak ssize_t security_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+__weak ssize_t security_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nvdimm *nvdimm = to_nvdimm(dev);
 
@@ -388,18 +384,17 @@ __weak ssize_t security_show(struct device *dev,
 	return -ENOTTY;
 }
 
-static ssize_t frozen_show(struct device *dev,
-			   struct device_attribute *attr, char *buf)
+static ssize_t frozen_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
 {
 	struct nvdimm *nvdimm = to_nvdimm(dev);
 
-	return sprintf(buf, "%d\n", test_bit(NVDIMM_SECURITY_FROZEN,
-					     &nvdimm->sec.flags));
+	return sprintf(buf, "%d\n",
+		       test_bit(NVDIMM_SECURITY_FROZEN, &nvdimm->sec.flags));
 }
 static DEVICE_ATTR_RO(frozen);
 
-static ssize_t security_store(struct device *dev,
-			      struct device_attribute *attr,
+static ssize_t security_store(struct device *dev, struct device_attribute *attr,
 			      const char *buf, size_t len)
 
 {
@@ -443,10 +438,8 @@ static umode_t nvdimm_visible(struct kobject *kobj, struct attribute *a, int n)
 
 	if (a == &dev_attr_security.attr) {
 		/* Are there any state mutation ops (make writable)? */
-		if (nvdimm->sec.ops->freeze ||
-		    nvdimm->sec.ops->disable ||
-		    nvdimm->sec.ops->change_key ||
-		    nvdimm->sec.ops->erase ||
+		if (nvdimm->sec.ops->freeze || nvdimm->sec.ops->disable ||
+		    nvdimm->sec.ops->change_key || nvdimm->sec.ops->erase ||
 		    nvdimm->sec.ops->overwrite)
 			return a->mode;
 		return 0444;
@@ -464,9 +457,11 @@ struct attribute_group nvdimm_attribute_group = {
 EXPORT_SYMBOL_GPL(nvdimm_attribute_group);
 
 struct nvdimm *__nvdimm_create(struct nvdimm_bus *nvdimm_bus,
-			       void *provider_data, const struct attribute_group **groups,
-			       unsigned long flags, unsigned long cmd_mask, int num_flush,
-			       struct resource *flush_wpq, const char *dimm_id,
+			       void *provider_data,
+			       const struct attribute_group **groups,
+			       unsigned long flags, unsigned long cmd_mask,
+			       int num_flush, struct resource *flush_wpq,
+			       const char *dimm_id,
 			       const struct nvdimm_security_ops *sec_ops)
 {
 	struct nvdimm *nvdimm = kzalloc(sizeof(*nvdimm), GFP_KERNEL);
@@ -523,11 +518,11 @@ int nvdimm_security_setup_events(struct device *dev)
 {
 	struct nvdimm *nvdimm = to_nvdimm(dev);
 
-	if (!nvdimm->sec.flags ||
-	    !nvdimm->sec.ops ||
+	if (!nvdimm->sec.flags || !nvdimm->sec.ops ||
 	    !nvdimm->sec.ops->overwrite)
 		return 0;
-	nvdimm->sec.overwrite_state = sysfs_get_dirent(dev->kobj.sd, "security");
+	nvdimm->sec.overwrite_state =
+		sysfs_get_dirent(dev->kobj.sd, "security");
 	if (!nvdimm->sec.overwrite_state)
 		return -ENOMEM;
 
@@ -554,7 +549,7 @@ int nvdimm_security_freeze(struct nvdimm *nvdimm)
 		return -EIO;
 
 	if (test_bit(NDD_SECURITY_OVERWRITE, &nvdimm->flags)) {
-		dev_warn(&nvdimm->dev, "Overwrite operation in progress\n");
+		dev_warn(&nvdimm->dev, "Overwrite operation in progress.\n");
 		return -EBUSY;
 	}
 
@@ -579,7 +574,7 @@ int alias_dpa_busy(struct device *dev, void *data)
 
 	nd_region = to_nd_region(dev);
 	for (i = 0; i < nd_region->ndr_mappings; i++) {
-		nd_mapping  = &nd_region->mapping[i];
+		nd_mapping = &nd_region->mapping[i];
 		if (nd_mapping->nvdimm == info->nd_mapping->nvdimm)
 			break;
 	}
@@ -596,17 +591,21 @@ int alias_dpa_busy(struct device *dev, void *data)
 	 * looking to validate against PMEM aliasing collision rules
 	 * (i.e. BLK is allocated after all aliased PMEM).
 	 */
-	if (info->res &&
-	    (info->res->start < nd_mapping->start ||
-	     info->res->start >= map_end))
-		return 0;
+	if (info->res) {
+		if (info->res->start >= nd_mapping->start &&
+		    info->res->start < map_end)
+			/* pass */;
+		else
+			return 0;
+	}
 
 retry:
 	/*
 	 * Find the free dpa from the end of the last pmem allocation to
 	 * the end of the interleave-set mapping.
 	 */
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		if (strncmp(res->name, "pmem", 4) != 0)
 			continue;
 		if ((res->start >= blk_start && res->start < map_end) ||
@@ -658,7 +657,8 @@ resource_size_t nd_blk_available_dpa(struct nd_region *nd_region)
 	device_for_each_child(&nvdimm_bus->dev, &info, alias_dpa_busy);
 
 	/* now account for busy blk allocations in unaliased dpa */
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		if (strncmp(res->name, "blk", 3) != 0)
 			continue;
 		info.available -= resource_size(res);
@@ -688,7 +688,8 @@ resource_size_t nd_pmem_max_contiguous_dpa(struct nd_region *nd_region,
 	nvdimm_bus = walk_to_nvdimm_bus(ndd->dev);
 	if (__reserve_free_pmem(&nd_region->dev, nd_mapping->nvdimm))
 		return 0;
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		if (strcmp(res->name, "pmem-reserve") != 0)
 			continue;
 		if (resource_size(res) > max)
@@ -728,17 +729,17 @@ resource_size_t nd_pmem_available_dpa(struct nd_region *nd_region,
 	map_start = nd_mapping->start;
 	map_end = map_start + nd_mapping->size - 1;
 	blk_start = max(map_start, map_end + 1 - *overlap);
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		if (res->start >= map_start && res->start < map_end) {
-			if (strncmp(res->name, "blk", 3) == 0) {
+			if (strncmp(res->name, "blk", 3) == 0)
 				blk_start = min(blk_start,
 						max(map_start, res->start));
-			} else if (res->end > map_end) {
+			else if (res->end > map_end) {
 				reason = "misaligned to iset";
 				goto err;
-			} else {
+			} else
 				busy += resource_size(res);
-			}
 		} else if (res->end >= map_start && res->end <= map_end) {
 			if (strncmp(res->name, "blk", 3) == 0) {
 				/*
@@ -747,9 +748,8 @@ resource_size_t nd_pmem_available_dpa(struct nd_region *nd_region,
 				 * be used for BLK.
 				 */
 				blk_start = map_start;
-			} else {
+			} else
 				busy += resource_size(res);
-			}
 		} else if (map_start > res->start && map_start < res->end) {
 			/* total eclipse of the mapping */
 			busy += nd_mapping->size;
@@ -776,8 +776,8 @@ void nvdimm_free_dpa(struct nvdimm_drvdata *ndd, struct resource *res)
 }
 
 struct resource *nvdimm_allocate_dpa(struct nvdimm_drvdata *ndd,
-				     struct nd_label_id *label_id, resource_size_t start,
-				     resource_size_t n)
+				     struct nd_label_id *label_id,
+				     resource_size_t start, resource_size_t n)
 {
 	char *name = kmemdup(label_id, sizeof(*label_id), GFP_KERNEL);
 	struct resource *res;
@@ -803,9 +803,8 @@ resource_size_t nvdimm_allocated_dpa(struct nvdimm_drvdata *ndd,
 	resource_size_t allocated = 0;
 	struct resource *res;
 
-	for_each_dpa_resource(ndd, res)
-		if (strcmp(res->name, label_id->id) == 0)
-			allocated += resource_size(res);
+	for_each_dpa_resource(ndd, res) if (strcmp(res->name, label_id->id) ==
+					    0) allocated += resource_size(res);
 
 	return allocated;
 }
diff --git a/drivers/nvdimm/e820.c b/drivers/nvdimm/e820.c
index adfeaf5c3c23..697df0a9baa4 100644
--- a/drivers/nvdimm/e820.c
+++ b/drivers/nvdimm/e820.c
@@ -71,7 +71,8 @@ static int e820_pmem_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, nvdimm_bus);
 
 	rc = walk_iomem_res_desc(IORES_DESC_PERSISTENT_MEMORY_LEGACY,
-				 IORESOURCE_MEM, 0, -1, nvdimm_bus, e820_register_one);
+				 IORESOURCE_MEM, 0, -1, nvdimm_bus,
+				 e820_register_one);
 	if (rc)
 		goto err;
 	return 0;
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index 9bf75dad8e93..3ecb05c2cd4e 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -34,7 +34,7 @@ static u32 best_seq(u32 a, u32 b)
 		return a;
 }
 
-unsigned int sizeof_namespace_label(struct nvdimm_drvdata *ndd)
+unsigned sizeof_namespace_label(struct nvdimm_drvdata *ndd)
 {
 	return ndd->nslabel_size;
 }
@@ -49,7 +49,7 @@ static int __nvdimm_num_label_slots(struct nvdimm_drvdata *ndd,
 				    size_t index_size)
 {
 	return (ndd->nsarea.config_size - index_size * 2) /
-		sizeof_namespace_label(ndd);
+	       sizeof_namespace_label(ndd);
 }
 
 int nvdimm_num_label_slots(struct nvdimm_drvdata *ndd)
@@ -78,7 +78,8 @@ size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
 	if (size <= space && nslot >= 2)
 		return size / 2;
 
-	dev_err(ndd->dev, "label area (%d) too small to host (%d byte) labels\n",
+	dev_err(ndd->dev,
+		"label area (%d) too small to host (%d byte) labels\n",
 		ndd->nsarea.config_size, sizeof_namespace_label(ndd));
 	return 0;
 }
@@ -135,16 +136,16 @@ static int __nd_label_validate(struct nvdimm_drvdata *ndd)
 		}
 
 		/* label sizes larger than 128 arrived with v1.2 */
-		version = __le16_to_cpu(nsindex[i]->major) * 100
-			+ __le16_to_cpu(nsindex[i]->minor);
+		version = __le16_to_cpu(nsindex[i]->major) * 100 +
+			  __le16_to_cpu(nsindex[i]->minor);
 		if (version >= 102)
 			labelsize = 1 << (7 + nsindex[i]->labelsize);
 		else
 			labelsize = 128;
 
 		if (labelsize != sizeof_namespace_label(ndd)) {
-			dev_dbg(dev, "nsindex%d labelsize %d invalid\n",
-				i, nsindex[i]->labelsize);
+			dev_dbg(dev, "nsindex%d labelsize %d invalid\n", i,
+				nsindex[i]->labelsize);
 			continue;
 		}
 
@@ -159,44 +160,48 @@ static int __nd_label_validate(struct nvdimm_drvdata *ndd)
 
 		seq = __le32_to_cpu(nsindex[i]->seq);
 		if ((seq & NSINDEX_SEQ_MASK) == 0) {
-			dev_dbg(dev, "nsindex%d sequence: %#x invalid\n",
-				i, seq);
+			dev_dbg(dev, "nsindex%d sequence: %#x invalid\n", i,
+				seq);
 			continue;
 		}
 
 		/* sanity check the index against expected values */
-		if (__le64_to_cpu(nsindex[i]->myoff)
-		    != i * sizeof_namespace_index(ndd)) {
-			dev_dbg(dev, "nsindex%d myoff: %#llx invalid\n",
-				i, (u64)__le64_to_cpu(nsindex[i]->myoff));
+		if (__le64_to_cpu(nsindex[i]->myoff) !=
+		    i * sizeof_namespace_index(ndd)) {
+			dev_dbg(dev, "nsindex%d myoff: %#llx invalid\n", i,
+				(unsigned long long)__le64_to_cpu(
+					nsindex[i]->myoff));
 			continue;
 		}
-		if (__le64_to_cpu(nsindex[i]->otheroff)
-		    != (!i) * sizeof_namespace_index(ndd)) {
-			dev_dbg(dev, "nsindex%d otheroff: %#llx invalid\n",
-				i, (u64)__le64_to_cpu(nsindex[i]->otheroff));
+		if (__le64_to_cpu(nsindex[i]->otheroff) !=
+		    (!i) * sizeof_namespace_index(ndd)) {
+			dev_dbg(dev, "nsindex%d otheroff: %#llx invalid\n", i,
+				(unsigned long long)__le64_to_cpu(
+					nsindex[i]->otheroff));
 			continue;
 		}
-		if (__le64_to_cpu(nsindex[i]->labeloff)
-		    != 2 * sizeof_namespace_index(ndd)) {
-			dev_dbg(dev, "nsindex%d labeloff: %#llx invalid\n",
-				i, (u64)__le64_to_cpu(nsindex[i]->labeloff));
+		if (__le64_to_cpu(nsindex[i]->labeloff) !=
+		    2 * sizeof_namespace_index(ndd)) {
+			dev_dbg(dev, "nsindex%d labeloff: %#llx invalid\n", i,
+				(unsigned long long)__le64_to_cpu(
+					nsindex[i]->labeloff));
 			continue;
 		}
 
 		size = __le64_to_cpu(nsindex[i]->mysize);
 		if (size > sizeof_namespace_index(ndd) ||
 		    size < sizeof(struct nd_namespace_index)) {
-			dev_dbg(dev, "nsindex%d mysize: %#llx invalid\n",
-				i, size);
+			dev_dbg(dev, "nsindex%d mysize: %#llx invalid\n", i,
+				size);
 			continue;
 		}
 
 		nslot = __le32_to_cpu(nsindex[i]->nslot);
-		if (nslot * sizeof_namespace_label(ndd)
-		    + 2 * sizeof_namespace_index(ndd)
-		    > ndd->nsarea.config_size) {
-			dev_dbg(dev, "nsindex%d nslot: %u invalid, config_size: %#x\n",
+		if (nslot * sizeof_namespace_label(ndd) +
+			    2 * sizeof_namespace_index(ndd) >
+		    ndd->nsarea.config_size) {
+			dev_dbg(dev,
+				"nsindex%d nslot: %u invalid, config_size: %#x\n",
 				i, nslot, ndd->nsarea.config_size);
 			continue;
 		}
@@ -290,9 +295,8 @@ static struct nd_namespace_label *to_label(struct nvdimm_drvdata *ndd, int slot)
 	return (struct nd_namespace_label *)label;
 }
 
-#define for_each_clear_bit_le(bit, addr, size)				\
-	for ((bit) = find_next_zero_bit_le((addr), (size), 0);		\
-	     (bit) < (size);						\
+#define for_each_clear_bit_le(bit, addr, size)                                 \
+	for ((bit) = find_next_zero_bit_le((addr), (size), 0); (bit) < (size); \
 	     (bit) = find_next_zero_bit_le((addr), (size), (bit) + 1))
 
 /**
@@ -333,16 +337,14 @@ static bool preamble_current(struct nvdimm_drvdata *ndd,
 			     struct nd_namespace_index **nsindex,
 			     unsigned long **free, u32 *nslot)
 {
-	return preamble_index(ndd, ndd->ns_current, nsindex,
-			      free, nslot);
+	return preamble_index(ndd, ndd->ns_current, nsindex, free, nslot);
 }
 
 static bool preamble_next(struct nvdimm_drvdata *ndd,
 			  struct nd_namespace_index **nsindex,
 			  unsigned long **free, u32 *nslot)
 {
-	return preamble_index(ndd, ndd->ns_next, nsindex,
-			      free, nslot);
+	return preamble_index(ndd, ndd->ns_next, nsindex, free, nslot);
 }
 
 static bool slot_valid(struct nvdimm_drvdata *ndd,
@@ -353,8 +355,8 @@ static bool slot_valid(struct nvdimm_drvdata *ndd,
 		return false;
 
 	/* check that DPA allocations are page aligned */
-	if ((__le64_to_cpu(nd_label->dpa)
-	     | __le64_to_cpu(nd_label->rawsize)) % SZ_4K)
+	if ((__le64_to_cpu(nd_label->dpa) | __le64_to_cpu(nd_label->rawsize)) %
+	    SZ_4K)
 		return false;
 
 	/* check checksum */
@@ -366,8 +368,9 @@ static bool slot_valid(struct nvdimm_drvdata *ndd,
 		sum = nd_fletcher64(nd_label, sizeof_namespace_label(ndd), 1);
 		nd_label->checksum = __cpu_to_le64(sum_save);
 		if (sum != sum_save) {
-			dev_dbg(ndd->dev, "fail checksum. slot: %d expect: %#llx\n",
-				slot, sum);
+			dev_dbg(ndd->dev,
+				"fail checksum. slot: %d expect: %#llx\n", slot,
+				sum);
 			return false;
 		}
 	}
@@ -384,7 +387,8 @@ int nd_label_reserve_dpa(struct nvdimm_drvdata *ndd)
 	if (!preamble_current(ndd, &nsindex, &free, &nslot))
 		return 0; /* no label, nothing to reserve */
 
-	for_each_clear_bit_le(slot, free, nslot) {
+	for_each_clear_bit_le(slot, free, nslot)
+	{
 		struct nvdimm *nvdimm = to_nvdimm(ndd->dev);
 		struct nd_namespace_label *nd_label;
 		struct nd_region *nd_region = NULL;
@@ -463,15 +467,15 @@ int nd_label_data_init(struct nvdimm_drvdata *ndd)
 	if (read_size < max_xfer) {
 		/* trim waste */
 		max_xfer -= ((max_xfer - 1) - (config_size - 1) % max_xfer) /
-			DIV_ROUND_UP(config_size, max_xfer);
+			    DIV_ROUND_UP(config_size, max_xfer);
 		/* make certain we read indexes in exactly 1 read */
 		if (max_xfer < read_size)
 			max_xfer = read_size;
 	}
 
 	/* Make our initial read size a multiple of max_xfer size */
-	read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,
-			config_size);
+	read_size =
+		min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, config_size);
 
 	/* Read the index data */
 	rc = nvdimm_get_config_data(ndd, ndd->data, 0, read_size);
@@ -514,8 +518,8 @@ int nd_label_data_init(struct nvdimm_drvdata *ndd)
 
 		/* determine how much more will be read after this next call. */
 		label_read_size = offset + ndd->nslabel_size - read_size;
-		label_read_size = DIV_ROUND_UP(label_read_size, max_xfer) *
-			max_xfer;
+		label_read_size =
+			DIV_ROUND_UP(label_read_size, max_xfer) * max_xfer;
 
 		/* truncate last read if needed */
 		if (read_size + label_read_size > config_size)
@@ -546,7 +550,8 @@ int nd_label_active_count(struct nvdimm_drvdata *ndd)
 	if (!preamble_current(ndd, &nsindex, &free, &nslot))
 		return 0;
 
-	for_each_clear_bit_le(slot, free, nslot) {
+	for_each_clear_bit_le(slot, free, nslot)
+	{
 		struct nd_namespace_label *nd_label;
 
 		nd_label = to_label(ndd, slot);
@@ -575,7 +580,8 @@ struct nd_namespace_label *nd_label_active(struct nvdimm_drvdata *ndd, int n)
 	if (!preamble_current(ndd, &nsindex, &free, &nslot))
 		return NULL;
 
-	for_each_clear_bit_le(slot, free, nslot) {
+	for_each_clear_bit_le(slot, free, nslot)
+	{
 		struct nd_namespace_label *nd_label;
 
 		nd_label = to_label(ndd, slot);
@@ -658,16 +664,16 @@ static int nd_label_write_index(struct nvdimm_drvdata *ndd, int index, u32 seq,
 	memset(&nsindex->flags, 0, 3);
 	nsindex->labelsize = sizeof_namespace_label(ndd) >> 8;
 	nsindex->seq = __cpu_to_le32(seq);
-	offset = (unsigned long)nsindex
-		- (unsigned long)to_namespace_index(ndd, 0);
+	offset = (unsigned long)nsindex -
+		 (unsigned long)to_namespace_index(ndd, 0);
 	nsindex->myoff = __cpu_to_le64(offset);
 	nsindex->mysize = __cpu_to_le64(sizeof_namespace_index(ndd));
-	offset = (unsigned long)to_namespace_index(ndd,
-						    nd_label_next_nsindex(index))
-		- (unsigned long)to_namespace_index(ndd, 0);
+	offset = (unsigned long)to_namespace_index(
+			 ndd, nd_label_next_nsindex(index)) -
+		 (unsigned long)to_namespace_index(ndd, 0);
 	nsindex->otheroff = __cpu_to_le64(offset);
-	offset = (unsigned long)nd_label_base(ndd)
-		- (unsigned long)to_namespace_index(ndd, 0);
+	offset = (unsigned long)nd_label_base(ndd) -
+		 (unsigned long)to_namespace_index(ndd, 0);
 	nsindex->labeloff = __cpu_to_le64(offset);
 	nsindex->nslot = __cpu_to_le32(nslot);
 	nsindex->major = __cpu_to_le16(1);
@@ -687,8 +693,8 @@ static int nd_label_write_index(struct nvdimm_drvdata *ndd, int index, u32 seq,
 	}
 	checksum = nd_fletcher64(nsindex, sizeof_namespace_index(ndd), 1);
 	nsindex->checksum = __cpu_to_le64(checksum);
-	rc = nvdimm_set_config_data(ndd, __le64_to_cpu(nsindex->myoff),
-				    nsindex, sizeof_namespace_index(ndd));
+	rc = nvdimm_set_config_data(ndd, __le64_to_cpu(nsindex->myoff), nsindex,
+				    sizeof_namespace_index(ndd));
 	if (rc < 0)
 		return rc;
 
@@ -708,21 +714,21 @@ static int nd_label_write_index(struct nvdimm_drvdata *ndd, int index, u32 seq,
 static unsigned long nd_label_offset(struct nvdimm_drvdata *ndd,
 				     struct nd_namespace_label *nd_label)
 {
-	return (unsigned long)nd_label
-		- (unsigned long)to_namespace_index(ndd, 0);
+	return (unsigned long)nd_label -
+	       (unsigned long)to_namespace_index(ndd, 0);
 }
 
 enum nvdimm_claim_class to_nvdimm_cclass(guid_t *guid)
 {
 	if (guid_equal(guid, &nvdimm_btt_guid))
 		return NVDIMM_CCLASS_BTT;
-	if (guid_equal(guid, &nvdimm_btt2_guid))
+	else if (guid_equal(guid, &nvdimm_btt2_guid))
 		return NVDIMM_CCLASS_BTT2;
-	if (guid_equal(guid, &nvdimm_pfn_guid))
+	else if (guid_equal(guid, &nvdimm_pfn_guid))
 		return NVDIMM_CCLASS_PFN;
-	if (guid_equal(guid, &nvdimm_dax_guid))
+	else if (guid_equal(guid, &nvdimm_dax_guid))
 		return NVDIMM_CCLASS_DAX;
-	if (guid_equal(guid, &guid_null))
+	else if (guid_equal(guid, &guid_null))
 		return NVDIMM_CCLASS_NONE;
 
 	return NVDIMM_CCLASS_UNKNOWN;
@@ -733,21 +739,20 @@ static const guid_t *to_abstraction_guid(enum nvdimm_claim_class claim_class,
 {
 	if (claim_class == NVDIMM_CCLASS_BTT)
 		return &nvdimm_btt_guid;
-	if (claim_class == NVDIMM_CCLASS_BTT2)
+	else if (claim_class == NVDIMM_CCLASS_BTT2)
 		return &nvdimm_btt2_guid;
-	if (claim_class == NVDIMM_CCLASS_PFN)
+	else if (claim_class == NVDIMM_CCLASS_PFN)
 		return &nvdimm_pfn_guid;
-	if (claim_class == NVDIMM_CCLASS_DAX)
+	else if (claim_class == NVDIMM_CCLASS_DAX)
 		return &nvdimm_dax_guid;
-	if (claim_class == NVDIMM_CCLASS_UNKNOWN) {
+	else if (claim_class == NVDIMM_CCLASS_UNKNOWN) {
 		/*
 		 * If we're modifying a namespace for which we don't
 		 * know the claim_class, don't touch the existing guid.
 		 */
 		return target;
-	}
-
-	return &guid_null;
+	} else
+		return &guid_null;
 }
 
 static void reap_victim(struct nd_mapping *nd_mapping,
@@ -763,8 +768,8 @@ static void reap_victim(struct nd_mapping *nd_mapping,
 
 static int __pmem_label_update(struct nd_region *nd_region,
 			       struct nd_mapping *nd_mapping,
-			       struct nd_namespace_pmem *nspm,
-			       int pos, unsigned long flags)
+			       struct nd_namespace_pmem *nspm, int pos,
+			       unsigned long flags)
 {
 	struct nd_namespace_common *ndns = &nspm->nsio.common;
 	struct nd_interleave_set *nd_set = nd_region->nd_set;
@@ -785,9 +790,8 @@ static int __pmem_label_update(struct nd_region *nd_region,
 
 	cookie = nd_region_interleave_set_cookie(nd_region, nsindex);
 	nd_label_gen_id(&label_id, nspm->uuid, 0);
-	for_each_dpa_resource(ndd, res)
-		if (strcmp(res->name, label_id.id) == 0)
-			break;
+	for_each_dpa_resource(ndd, res) if (strcmp(res->name, label_id.id) ==
+					    0) break;
 
 	if (!res) {
 		WARN_ON_ONCE(1);
@@ -837,12 +841,12 @@ static int __pmem_label_update(struct nd_region *nd_region,
 
 	/* Garbage collect the previous label */
 	mutex_lock(&nd_mapping->lock);
-	list_for_each_entry(label_ent, &nd_mapping->labels, list) {
+	list_for_each_entry (label_ent, &nd_mapping->labels, list) {
 		if (!label_ent->label)
 			continue;
 		if (test_and_clear_bit(ND_LABEL_REAP, &label_ent->flags) ||
 		    memcmp(nspm->uuid, label_ent->label->uuid,
-			      NSLABEL_UUID_LEN) == 0)
+			   NSLABEL_UUID_LEN) == 0)
 			reap_victim(nd_mapping, label_ent);
 	}
 
@@ -850,7 +854,7 @@ static int __pmem_label_update(struct nd_region *nd_region,
 	rc = nd_label_write_index(ndd, ndd->ns_next,
 				  nd_inc_seq(__le32_to_cpu(nsindex->seq)), 0);
 	if (rc == 0) {
-		list_for_each_entry(label_ent, &nd_mapping->labels, list)
+		list_for_each_entry (label_ent, &nd_mapping->labels, list)
 			if (!label_ent->label) {
 				label_ent->label = nd_label;
 				nd_label = NULL;
@@ -884,7 +888,8 @@ static struct resource *to_resource(struct nvdimm_drvdata *ndd,
 {
 	struct resource *res;
 
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		if (res->start != __le64_to_cpu(nd_label->dpa))
 			continue;
 		if (resource_size(res) != __le64_to_cpu(nd_label->rawsize))
@@ -902,8 +907,7 @@ static struct resource *to_resource(struct nvdimm_drvdata *ndd,
  */
 static int __blk_label_update(struct nd_region *nd_region,
 			      struct nd_mapping *nd_mapping,
-			      struct nd_namespace_blk *nsblk,
-			      int num_labels)
+			      struct nd_namespace_blk *nsblk, int num_labels)
 {
 	int i, alloc, victims, nfree, old_num_resources, nlabel, rc = -ENXIO;
 	struct nd_interleave_set *nd_set = nd_region->nd_set;
@@ -936,7 +940,8 @@ static int __blk_label_update(struct nd_region *nd_region,
 	 * disable and re-enable the parent region.
 	 */
 	alloc = 0;
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		if (strcmp(res->name, label_id.id) != 0)
 			continue;
 		if (!is_old_resource(res, old_res_list, old_num_resources))
@@ -951,7 +956,8 @@ static int __blk_label_update(struct nd_region *nd_region,
 			return -ENOMEM;
 
 		/* mark unused labels for garbage collection */
-		for_each_clear_bit_le(slot, free, nslot) {
+		for_each_clear_bit_le(slot, free, nslot)
+		{
 			nd_label = to_label(ndd, slot);
 			memcpy(uuid, nd_label->uuid, NSLABEL_UUID_LEN);
 			if (memcmp(uuid, nsblk->uuid, NSLABEL_UUID_LEN) != 0)
@@ -977,7 +983,8 @@ static int __blk_label_update(struct nd_region *nd_region,
 	/* assign all resources to the namespace before writing the labels */
 	nsblk->res = NULL;
 	nsblk->num_resources = 0;
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		if (strcmp(res->name, label_id.id) != 0)
 			continue;
 		if (!nsblk_add_resource(nd_region, ndd, nsblk, res->start)) {
@@ -1024,7 +1031,8 @@ static int __blk_label_update(struct nd_region *nd_region,
 		 */
 		if (namespace_label_has(ndd, type_guid)) {
 			if (i == min_dpa_idx) {
-				nd_label->nlabel = __cpu_to_le16(nsblk->num_resources);
+				nd_label->nlabel =
+					__cpu_to_le16(nsblk->num_resources);
 				nd_label->position = __cpu_to_le16(0);
 			} else {
 				nd_label->nlabel = __cpu_to_le16(0xffff);
@@ -1045,8 +1053,9 @@ static int __blk_label_update(struct nd_region *nd_region,
 			guid_copy(&nd_label->type_guid, &nd_set->type_guid);
 		if (namespace_label_has(ndd, abstraction_guid))
 			guid_copy(&nd_label->abstraction_guid,
-				  to_abstraction_guid(ndns->claim_class,
-						      &nd_label->abstraction_guid));
+				  to_abstraction_guid(
+					  ndns->claim_class,
+					  &nd_label->abstraction_guid));
 
 		if (namespace_label_has(ndd, checksum)) {
 			u64 sum;
@@ -1066,7 +1075,7 @@ static int __blk_label_update(struct nd_region *nd_region,
 	}
 
 	/* free up now unused slots in the new index */
-	for_each_set_bit(slot, victim_map, victim_map ? nslot : 0) {
+	for_each_set_bit (slot, victim_map, victim_map ? nslot : 0) {
 		dev_dbg(ndd->dev, "free: %d\n", slot);
 		nd_label_free_slot(ndd, slot);
 	}
@@ -1083,7 +1092,7 @@ static int __blk_label_update(struct nd_region *nd_region,
 	 */
 	nlabel = 0;
 	mutex_lock(&nd_mapping->lock);
-	list_for_each_entry_safe(label_ent, e, &nd_mapping->labels, list) {
+	list_for_each_entry_safe (label_ent, e, &nd_mapping->labels, list) {
 		nd_label = label_ent->label;
 		if (!nd_label)
 			continue;
@@ -1117,7 +1126,8 @@ static int __blk_label_update(struct nd_region *nd_region,
 		rc = -ENXIO;
 		goto out;
 	}
-	for_each_clear_bit_le(slot, free, nslot) {
+	for_each_clear_bit_le(slot, free, nslot)
+	{
 		nd_label = to_label(ndd, slot);
 		memcpy(uuid, nd_label->uuid, NSLABEL_UUID_LEN);
 		if (memcmp(uuid, nsblk->uuid, NSLABEL_UUID_LEN) != 0)
@@ -1125,7 +1135,8 @@ static int __blk_label_update(struct nd_region *nd_region,
 		res = to_resource(ndd, nd_label);
 		res->flags &= ~DPA_RESOURCE_ADJUSTED;
 		dev_vdbg(&nsblk->common.dev, "assign label slot: %d\n", slot);
-		list_for_each_entry_from(label_ent, &nd_mapping->labels, list) {
+		list_for_each_entry_from (label_ent, &nd_mapping->labels,
+					  list) {
 			if (label_ent->label)
 				continue;
 			label_ent->label = nd_label;
@@ -1164,7 +1175,7 @@ static int init_labels(struct nd_mapping *nd_mapping, int num_labels)
 	struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
 
 	mutex_lock(&nd_mapping->lock);
-	list_for_each_entry(label_ent, &nd_mapping->labels, list)
+	list_for_each_entry (label_ent, &nd_mapping->labels, list)
 		old_num_labels++;
 	mutex_unlock(&nd_mapping->lock);
 
@@ -1181,7 +1192,9 @@ static int init_labels(struct nd_mapping *nd_mapping, int num_labels)
 		mutex_unlock(&nd_mapping->lock);
 	}
 
-	if (ndd->ns_current != -1 && ndd->ns_next != -1)
+	if (ndd->ns_current == -1 || ndd->ns_next == -1)
+		/* pass */;
+	else
 		return max(num_labels, old_num_labels);
 
 	nsindex = to_namespace_index(ndd, 0);
@@ -1217,7 +1230,7 @@ static int del_labels(struct nd_mapping *nd_mapping, u8 *uuid)
 		return 0;
 
 	mutex_lock(&nd_mapping->lock);
-	list_for_each_entry_safe(label_ent, e, &nd_mapping->labels, list) {
+	list_for_each_entry_safe (label_ent, e, &nd_mapping->labels, list) {
 		struct nd_namespace_label *nd_label = label_ent->label;
 
 		if (!nd_label)
@@ -1264,9 +1277,8 @@ int nd_pmem_namespace_label_update(struct nd_region *nd_region,
 			continue;
 		}
 
-		for_each_dpa_resource(ndd, res)
-			if (strncmp(res->name, "pmem", 4) == 0)
-				count++;
+		for_each_dpa_resource(ndd, res) if (strncmp(res->name, "pmem",
+							    4) == 0) count++;
 		WARN_ON_ONCE(!count);
 
 		rc = init_labels(nd_mapping, count);
@@ -1305,8 +1317,7 @@ int nd_blk_namespace_label_update(struct nd_region *nd_region,
 	if (size == 0)
 		return del_labels(nd_mapping, nsblk->uuid);
 
-	for_each_dpa_resource(to_ndd(nd_mapping), res)
-		count++;
+	for_each_dpa_resource(to_ndd(nd_mapping), res) count++;
 
 	count = init_labels(nd_mapping, count);
 	if (count < 0)
diff --git a/drivers/nvdimm/label.h b/drivers/nvdimm/label.h
index a008ec92f78c..b67eb02811cf 100644
--- a/drivers/nvdimm/label.h
+++ b/drivers/nvdimm/label.h
@@ -10,24 +10,23 @@
 #include <linux/uuid.h>
 #include <linux/io.h>
 
-enum {
-	NSINDEX_SIG_LEN = 16,
-	NSINDEX_ALIGN = 256,
-	NSINDEX_SEQ_MASK = 0x3,
-	NSLABEL_UUID_LEN = 16,
-	NSLABEL_NAME_LEN = 64,
-	NSLABEL_FLAG_ROLABEL = 0x1,  /* read-only label */
-	NSLABEL_FLAG_LOCAL = 0x2,    /* DIMM-local namespace */
-	NSLABEL_FLAG_BTT = 0x4,      /* namespace contains a BTT */
-	NSLABEL_FLAG_UPDATING = 0x8, /* label being updated */
-	BTT_ALIGN = 4096,            /* all btt structures */
-	BTTINFO_SIG_LEN = 16,
-	BTTINFO_UUID_LEN = 16,
-	BTTINFO_FLAG_ERROR = 0x1,    /* error state (read-only) */
-	BTTINFO_MAJOR_VERSION = 1,
-	ND_LABEL_MIN_SIZE = 256 * 4, /* see sizeof_namespace_index() */
-	ND_LABEL_ID_SIZE = 50,
-	ND_NSINDEX_INIT = 0x1,
+enum { NSINDEX_SIG_LEN = 16,
+       NSINDEX_ALIGN = 256,
+       NSINDEX_SEQ_MASK = 0x3,
+       NSLABEL_UUID_LEN = 16,
+       NSLABEL_NAME_LEN = 64,
+       NSLABEL_FLAG_ROLABEL = 0x1, /* read-only label */
+       NSLABEL_FLAG_LOCAL = 0x2, /* DIMM-local namespace */
+       NSLABEL_FLAG_BTT = 0x4, /* namespace contains a BTT */
+       NSLABEL_FLAG_UPDATING = 0x8, /* label being updated */
+       BTT_ALIGN = 4096, /* all btt structures */
+       BTTINFO_SIG_LEN = 16,
+       BTTINFO_UUID_LEN = 16,
+       BTTINFO_FLAG_ERROR = 0x1, /* error state (read-only) */
+       BTTINFO_MAJOR_VERSION = 1,
+       ND_LABEL_MIN_SIZE = 256 * 4, /* see sizeof_namespace_index() */
+       ND_LABEL_ID_SIZE = 50,
+       ND_NSINDEX_INIT = 0x1,
 };
 
 /**
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index d53efe06d312..e08e05bb5f97 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -162,7 +162,7 @@ unsigned int pmem_sector_size(struct nd_namespace_common *ndns)
 
 		nspm = to_nd_namespace_pmem(&ndns->dev);
 		if (nspm->lbasize == 0 || nspm->lbasize == 512)
-			;	/* default */
+			/* default */;
 		else if (nspm->lbasize == 4096)
 			return 4096;
 		else
@@ -198,17 +198,17 @@ const char *nvdimm_namespace_disk_name(struct nd_namespace_common *ndns,
 		}
 
 		if (nsidx)
-			sprintf(name, "pmem%d.%d%s",
-				nd_region->id, nsidx, suffix ? suffix : "");
+			sprintf(name, "pmem%d.%d%s", nd_region->id, nsidx,
+				suffix ? suffix : "");
 		else
-			sprintf(name, "pmem%d%s",
-				nd_region->id, suffix ? suffix : "");
+			sprintf(name, "pmem%d%s", nd_region->id,
+				suffix ? suffix : "");
 	} else if (is_namespace_blk(&ndns->dev)) {
 		struct nd_namespace_blk *nsblk;
 
 		nsblk = to_nd_namespace_blk(&ndns->dev);
-		sprintf(name, "ndblk%d.%d%s",
-			nd_region->id, nsblk->id, suffix ? suffix : "");
+		sprintf(name, "ndblk%d.%d%s", nd_region->id, nsblk->id,
+			suffix ? suffix : "");
 	} else {
 		return NULL;
 	}
@@ -228,19 +228,17 @@ const u8 *nd_dev_to_uuid(struct device *dev)
 		struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
 
 		return nspm->uuid;
-	}
-	if (is_namespace_blk(dev)) {
+	} else if (is_namespace_blk(dev)) {
 		struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
 		return nsblk->uuid;
-	}
-
-	return null_uuid;
+	} else
+		return null_uuid;
 }
 EXPORT_SYMBOL(nd_dev_to_uuid);
 
-static ssize_t nstype_show(struct device *dev,
-			   struct device_attribute *attr, char *buf)
+static ssize_t nstype_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev->parent);
 
@@ -262,9 +260,8 @@ static ssize_t __alt_name_store(struct device *dev, const char *buf,
 		struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
 		ns_altname = &nsblk->alt_name;
-	} else {
+	} else
 		return -ENXIO;
-	}
 
 	if (dev->driver || to_ndns(dev)->claim)
 		return -EBUSY;
@@ -306,9 +303,8 @@ static resource_size_t nd_namespace_blk_size(struct nd_namespace_blk *nsblk)
 	if (!nsblk->uuid)
 		return 0;
 	nd_label_gen_id(&label_id, nsblk->uuid, NSLABEL_FLAG_LOCAL);
-	for_each_dpa_resource(ndd, res)
-		if (strcmp(res->name, label_id.id) == 0)
-			size += resource_size(res);
+	for_each_dpa_resource(ndd, res) if (strcmp(res->name, label_id.id) == 0)
+		size += resource_size(res);
 	return size;
 }
 
@@ -326,7 +322,8 @@ static bool __nd_namespace_blk_validate(struct nd_namespace_blk *nsblk)
 
 	count = 0;
 	nd_label_gen_id(&label_id, nsblk->uuid, NSLABEL_FLAG_LOCAL);
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		if (strcmp(res->name, label_id.id) != 0)
 			continue;
 		/*
@@ -345,11 +342,11 @@ static bool __nd_namespace_blk_validate(struct nd_namespace_blk *nsblk)
 	for (i = 0; i < nsblk->num_resources; i++) {
 		struct resource *found = NULL;
 
-		for_each_dpa_resource(ndd, res)
-			if (res == nsblk->res[i]) {
-				found = res;
-				break;
-			}
+		for_each_dpa_resource(ndd, res) if (res == nsblk->res[i])
+		{
+			found = res;
+			break;
+		}
 		/* stale resource */
 		if (!found)
 			return false;
@@ -387,25 +384,23 @@ static int nd_namespace_label_update(struct nd_region *nd_region,
 		resource_size_t size = resource_size(&nspm->nsio.res);
 
 		if (size == 0 && nspm->uuid)
-			;	/* delete allocation */
+			/* delete allocation */;
 		else if (!nspm->uuid)
 			return 0;
 
 		return nd_pmem_namespace_label_update(nd_region, nspm, size);
-	}
-	if (is_namespace_blk(dev)) {
+	} else if (is_namespace_blk(dev)) {
 		struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 		resource_size_t size = nd_namespace_blk_size(nsblk);
 
 		if (size == 0 && nsblk->uuid)
-			;	/* delete allocation */
+			/* delete allocation */;
 		else if (!nsblk->uuid || !nsblk->lbasize)
 			return 0;
 
 		return nd_blk_namespace_label_update(nd_region, nsblk, size);
-	}
-
-	return -ENXIO;
+	} else
+		return -ENXIO;
 }
 
 static ssize_t alt_name_store(struct device *dev, struct device_attribute *attr,
@@ -427,8 +422,8 @@ static ssize_t alt_name_store(struct device *dev, struct device_attribute *attr,
 	return rc < 0 ? rc : len;
 }
 
-static ssize_t alt_name_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t alt_name_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	char *ns_altname;
 
@@ -440,9 +435,8 @@ static ssize_t alt_name_show(struct device *dev,
 		struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
 		ns_altname = nsblk->alt_name;
-	} else {
+	} else
 		return -ENXIO;
-	}
 
 	return sprintf(buf, "%s\n", ns_altname ? ns_altname : "");
 }
@@ -460,9 +454,9 @@ static int scan_free(struct nd_region *nd_region, struct nd_mapping *nd_mapping,
 		resource_size_t new_start;
 
 		last = NULL;
-		for_each_dpa_resource(ndd, res)
-			if (strcmp(res->name, label_id->id) == 0)
-				last = res;
+		for_each_dpa_resource(ndd, res) if (strcmp(res->name,
+							   label_id->id) == 0)
+			last = res;
 		res = last;
 		if (!res)
 			return 0;
@@ -603,8 +597,7 @@ static void space_valid(struct nd_region *nd_region, struct nvdimm_drvdata *ndd,
 		return;
 
 	/* allocation needs to be contiguous with the existing namespace */
-	if (valid->start == exist->end + 1 ||
-	    valid->end == exist->start - 1)
+	if (valid->start == exist->end + 1 || valid->end == exist->start - 1)
 		return;
 
 invalid:
@@ -613,7 +606,10 @@ static void space_valid(struct nd_region *nd_region, struct nvdimm_drvdata *ndd,
 }
 
 enum alloc_loc {
-	ALLOC_ERR = 0, ALLOC_BEFORE, ALLOC_MID, ALLOC_AFTER,
+	ALLOC_ERR = 0,
+	ALLOC_BEFORE,
+	ALLOC_MID,
+	ALLOC_AFTER,
 };
 
 static resource_size_t scan_allocate(struct nd_region *nd_region,
@@ -628,17 +624,16 @@ static resource_size_t scan_allocate(struct nd_region *nd_region,
 	const resource_size_t to_allocate = n;
 	int first;
 
-	for_each_dpa_resource(ndd, res) {
-		if (strcmp(label_id->id, res->name) == 0)
-			exist = res;
-	}
+	for_each_dpa_resource(ndd, res) if (strcmp(label_id->id, res->name) ==
+					    0) exist = res;
 
 	valid.start = nd_mapping->start;
 	valid.end = mapping_end;
 	valid.name = "free space";
 retry:
 	first = 0;
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		struct resource *next = res->sibling, *new_res = NULL;
 		resource_size_t allocate, available = 0;
 		enum alloc_loc loc = ALLOC_ERR;
@@ -692,26 +687,24 @@ static resource_size_t scan_allocate(struct nd_region *nd_region,
 			if (strcmp(res->name, label_id->id) == 0) {
 				/* adjust current resource up */
 				rc = adjust_resource(res, res->start - allocate,
-						     resource_size(res) + allocate);
+						     resource_size(res) +
+							     allocate);
 				action = "cur grow up";
-			} else {
+			} else
 				action = "allocate";
-			}
 			break;
 		case ALLOC_MID:
 			if (strcmp(next->name, label_id->id) == 0) {
 				/* adjust next resource up */
-				rc = adjust_resource(next,
-						     next->start - allocate,
-						     resource_size(next)
-						     + allocate);
+				rc = adjust_resource(
+					next, next->start - allocate,
+					resource_size(next) + allocate);
 				new_res = next;
 				action = "next grow up";
 			} else if (strcmp(res->name, label_id->id) == 0) {
 				action = "grow down";
-			} else {
+			} else
 				action = "allocate";
-			}
 			break;
 		case ALLOC_AFTER:
 			if (strcmp(res->name, label_id->id) == 0)
@@ -743,8 +736,8 @@ static resource_size_t scan_allocate(struct nd_region *nd_region,
 		if (!new_res)
 			new_res = res;
 
-		nd_dbg_dpa(nd_region, ndd, new_res, "%s(%d) %d\n",
-			   action, loc, rc);
+		nd_dbg_dpa(nd_region, ndd, new_res, "%s(%d) %d\n", action, loc,
+			   rc);
 
 		if (rc)
 			return n;
@@ -759,9 +752,8 @@ static resource_size_t scan_allocate(struct nd_region *nd_region,
 			 * need to check this same resource again
 			 */
 			goto retry;
-		} else {
+		} else
 			return 0;
-		}
 	}
 
 	/*
@@ -774,8 +766,7 @@ static resource_size_t scan_allocate(struct nd_region *nd_region,
 	return n;
 }
 
-static int merge_dpa(struct nd_region *nd_region,
-		     struct nd_mapping *nd_mapping,
+static int merge_dpa(struct nd_region *nd_region, struct nd_mapping *nd_mapping,
 		     struct nd_label_id *label_id)
 {
 	struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
@@ -784,15 +775,14 @@ static int merge_dpa(struct nd_region *nd_region,
 	if (strncmp("pmem", label_id->id, 4) == 0)
 		return 0;
 retry:
-	for_each_dpa_resource(ndd, res) {
+	for_each_dpa_resource(ndd, res)
+	{
 		int rc;
 		struct resource *next = res->sibling;
 		resource_size_t end = res->start + resource_size(res);
 
-		if (!next ||
-		    strcmp(res->name, label_id->id) != 0 ||
-		    strcmp(next->name, label_id->id) != 0 ||
-		    end != next->start)
+		if (!next || strcmp(res->name, label_id->id) != 0 ||
+		    strcmp(next->name, label_id->id) != 0 || end != next->start)
 			continue;
 		end += resource_size(next);
 		nvdimm_free_dpa(ndd, next);
@@ -836,7 +826,8 @@ int __reserve_free_pmem(struct device *dev, void *data)
 		rem = scan_allocate(nd_region, nd_mapping, &label_id, n);
 		dev_WARN_ONCE(&nd_region->dev, rem,
 			      "pmem reserve underrun: %#llx of %#llx bytes\n",
-			      (u64)n - rem, (u64)n);
+			      (unsigned long long)n - rem,
+			      (unsigned long long)n);
 		return rem ? -ENXIO : 0;
 	}
 
@@ -849,9 +840,9 @@ void release_free_pmem(struct nvdimm_bus *nvdimm_bus,
 	struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
 	struct resource *res, *_res;
 
-	for_each_dpa_resource_safe(ndd, res, _res)
-		if (strcmp(res->name, "pmem-reserve") == 0)
-			nvdimm_free_dpa(ndd, res);
+	for_each_dpa_resource_safe(
+		ndd, res, _res) if (strcmp(res->name, "pmem-reserve") == 0)
+		nvdimm_free_dpa(ndd, res);
 }
 
 static int reserve_free_pmem(struct nvdimm_bus *nvdimm_bus,
@@ -904,8 +895,8 @@ static int grow_dpa_allocation(struct nd_region *nd_region,
 				if (rc)
 					return rc;
 			}
-			rem = scan_allocate(nd_region, nd_mapping,
-					    label_id, rem);
+			rem = scan_allocate(nd_region, nd_mapping, label_id,
+					    rem);
 			if (blk_only)
 				release_free_pmem(nvdimm_bus, nd_mapping);
 
@@ -916,7 +907,8 @@ static int grow_dpa_allocation(struct nd_region *nd_region,
 
 		dev_WARN_ONCE(&nd_region->dev, rem,
 			      "allocation underrun: %#llx of %#llx bytes\n",
-			      (u64)n - rem, (u64)n);
+			      (unsigned long long)n - rem,
+			      (unsigned long long)n);
 		if (rem)
 			return -ENXIO;
 
@@ -954,12 +946,13 @@ static void nd_namespace_pmem_set_resource(struct nd_region *nd_region,
 		nd_label_gen_id(&label_id, nspm->uuid, 0);
 
 		/* calculate a spa offset from the dpa allocation offset */
-		for_each_dpa_resource(ndd, res)
-			if (strcmp(res->name, label_id.id) == 0) {
-				offset = (res->start - nd_mapping->start)
-					* nd_region->ndr_mappings;
-				goto out;
-			}
+		for_each_dpa_resource(ndd, res) if (strcmp(res->name,
+							   label_id.id) == 0)
+		{
+			offset = (res->start - nd_mapping->start) *
+				 nd_region->ndr_mappings;
+			goto out;
+		}
 
 		WARN_ON_ONCE(1);
 		size = 0;
@@ -1128,18 +1121,14 @@ resource_size_t __nvdimm_namespace_capacity(struct nd_namespace_common *ndns)
 		struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
 
 		return resource_size(&nspm->nsio.res);
-	}
-
-	if (is_namespace_blk(dev))
+	} else if (is_namespace_blk(dev)) {
 		return nd_namespace_blk_size(to_nd_namespace_blk(dev));
-
-	if (is_namespace_io(dev)) {
+	} else if (is_namespace_io(dev)) {
 		struct nd_namespace_io *nsio = to_nd_namespace_io(dev);
 
 		return resource_size(&nsio->res);
-	}
-
-	WARN_ONCE(1, "unknown namespace type\n");
+	} else
+		WARN_ONCE(1, "unknown namespace type\n");
 	return 0;
 }
 
@@ -1175,11 +1164,12 @@ bool nvdimm_namespace_locked(struct nd_namespace_common *ndns)
 }
 EXPORT_SYMBOL(nvdimm_namespace_locked);
 
-static ssize_t size_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
+static ssize_t size_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
 {
-	return sprintf(buf, "%llu\n",
-		       (u64)nvdimm_namespace_capacity(to_ndns(dev)));
+	return sprintf(
+		buf, "%llu\n",
+		(unsigned long long)nvdimm_namespace_capacity(to_ndns(dev)));
 }
 static DEVICE_ATTR(size, 0444, size_show, size_store);
 
@@ -1189,18 +1179,16 @@ static u8 *namespace_to_uuid(struct device *dev)
 		struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
 
 		return nspm->uuid;
-	}
-	if (is_namespace_blk(dev)) {
+	} else if (is_namespace_blk(dev)) {
 		struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
 		return nsblk->uuid;
-	}
-
-	return ERR_PTR(-ENXIO);
+	} else
+		return ERR_PTR(-ENXIO);
 }
 
-static ssize_t uuid_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
+static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
 {
 	u8 *uuid = namespace_to_uuid(dev);
 
@@ -1219,8 +1207,8 @@ static ssize_t uuid_show(struct device *dev,
  * @old_uuid: reference to the uuid storage location in the namespace object
  */
 static int namespace_update_uuid(struct nd_region *nd_region,
-				 struct device *dev,
-				 u8 *new_uuid, u8 **old_uuid)
+				 struct device *dev, u8 *new_uuid,
+				 u8 **old_uuid)
 {
 	u32 flags = is_namespace_blk(dev) ? NSLABEL_FLAG_LOCAL : 0;
 	struct nd_label_id old_label_id;
@@ -1261,13 +1249,12 @@ static int namespace_update_uuid(struct nd_region *nd_region,
 		struct nd_label_ent *label_ent;
 		struct resource *res;
 
-		for_each_dpa_resource(ndd, res)
-			if (strcmp(res->name, old_label_id.id) == 0)
-				sprintf((void *)res->name, "%s",
-					new_label_id.id);
+		for_each_dpa_resource(
+			ndd, res) if (strcmp(res->name, old_label_id.id) == 0)
+			sprintf((void *)res->name, "%s", new_label_id.id);
 
 		mutex_lock(&nd_mapping->lock);
-		list_for_each_entry(label_ent, &nd_mapping->labels, list) {
+		list_for_each_entry (label_ent, &nd_mapping->labels, list) {
 			struct nd_namespace_label *nd_label = label_ent->label;
 			struct nd_label_id label_id;
 
@@ -1302,9 +1289,8 @@ static ssize_t uuid_store(struct device *dev, struct device_attribute *attr,
 		struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
 
 		ns_uuid = &nsblk->uuid;
-	} else {
+	} else
 		return -ENXIO;
-	}
 
 	nd_device_lock(dev);
 	nvdimm_bus_lock(dev);
@@ -1319,8 +1305,8 @@ static ssize_t uuid_store(struct device *dev, struct device_attribute *attr,
 		rc = nd_namespace_label_update(nd_region, dev);
 	else
 		kfree(uuid);
-	dev_dbg(dev, "result: %zd wrote: %s%s",
-		rc, buf, buf[len - 1] == '\n' ? "" : "\n");
+	dev_dbg(dev, "result: %zd wrote: %s%s", rc, buf,
+		buf[len - 1] == '\n' ? "" : "\n");
 	nvdimm_bus_unlock(dev);
 	nd_device_unlock(dev);
 
@@ -1328,8 +1314,8 @@ static ssize_t uuid_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RW(uuid);
 
-static ssize_t resource_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t resource_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct resource *res;
 
@@ -1341,24 +1327,20 @@ static ssize_t resource_show(struct device *dev,
 		struct nd_namespace_io *nsio = to_nd_namespace_io(dev);
 
 		res = &nsio->res;
-	} else {
+	} else
 		return -ENXIO;
-	}
 
 	/* no address to convey if the namespace has no allocation */
 	if (resource_size(res) == 0)
 		return -ENXIO;
-	return sprintf(buf, "%#llx\n", (u64)res->start);
+	return sprintf(buf, "%#llx\n", (unsigned long long)res->start);
 }
 static DEVICE_ATTR_RO(resource);
 
-static const unsigned long blk_lbasize_supported[] = {
-	512, 520, 528, 4096, 4104, 4160, 4224, 0
-};
+static const unsigned long blk_lbasize_supported[] = { 512,  520,  528,	 4096,
+						       4104, 4160, 4224, 0 };
 
-static const unsigned long pmem_lbasize_supported[] = {
-	512, 4096, 0
-};
+static const unsigned long pmem_lbasize_supported[] = { 512, 4096, 0 };
 
 static ssize_t sector_size_show(struct device *dev,
 				struct device_attribute *attr, char *buf)
@@ -1380,8 +1362,8 @@ static ssize_t sector_size_show(struct device *dev,
 }
 
 static ssize_t sector_size_store(struct device *dev,
-				 struct device_attribute *attr,
-				 const char *buf, size_t len)
+				 struct device_attribute *attr, const char *buf,
+				 size_t len)
 {
 	struct nd_region *nd_region = to_nd_region(dev->parent);
 	const unsigned long *supported;
@@ -1398,9 +1380,8 @@ static ssize_t sector_size_store(struct device *dev,
 
 		lbasize = &nspm->lbasize;
 		supported = pmem_lbasize_supported;
-	} else {
+	} else
 		return -ENXIO;
-	}
 
 	nd_device_lock(dev);
 	nvdimm_bus_lock(dev);
@@ -1410,8 +1391,7 @@ static ssize_t sector_size_store(struct device *dev,
 		rc = nd_size_select_store(dev, buf, lbasize, supported);
 	if (rc >= 0)
 		rc = nd_namespace_label_update(nd_region, dev);
-	dev_dbg(dev, "result: %zd %s: %s%s",
-		rc, rc < 0 ? "tried" : "wrote",
+	dev_dbg(dev, "result: %zd %s: %s%s", rc, rc < 0 ? "tried" : "wrote",
 		buf, buf[len - 1] == '\n' ? "" : "\n");
 	nvdimm_bus_unlock(dev);
 	nd_device_unlock(dev);
@@ -1451,9 +1431,9 @@ static ssize_t dpa_extents_show(struct device *dev,
 		struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
 		struct resource *res;
 
-		for_each_dpa_resource(ndd, res)
-			if (strcmp(res->name, label_id.id) == 0)
-				count++;
+		for_each_dpa_resource(ndd, res) if (strcmp(res->name,
+							   label_id.id) == 0)
+			count++;
 	}
 out:
 	nvdimm_bus_unlock(dev);
@@ -1482,9 +1462,9 @@ static int btt_claim_class(struct device *dev)
 		}
 
 		nsindex = to_namespace_index(ndd, ndd->ns_current);
-		if (nsindex == NULL) {
+		if (nsindex == NULL)
 			loop_bitmask |= 1;
-		} else {
+		else {
 			/* check whether existing labels are v1.1 or v1.2 */
 			if (__le16_to_cpu(nsindex->major) == 1 &&
 			    __le16_to_cpu(nsindex->minor) == 1)
@@ -1523,8 +1503,8 @@ static int btt_claim_class(struct device *dev)
 	}
 }
 
-static ssize_t holder_show(struct device *dev,
-			   struct device_attribute *attr, char *buf)
+static ssize_t holder_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
 {
 	struct nd_namespace_common *ndns = to_ndns(dev);
 	ssize_t rc;
@@ -1606,8 +1586,8 @@ static ssize_t holder_class_show(struct device *dev,
 }
 static DEVICE_ATTR_RW(holder_class);
 
-static ssize_t mode_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
+static ssize_t mode_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
 {
 	struct nd_namespace_common *ndns = to_ndns(dev);
 	struct device *claim;
@@ -1634,8 +1614,8 @@ static ssize_t mode_show(struct device *dev,
 static DEVICE_ATTR_RO(mode);
 
 static ssize_t force_raw_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t len)
+			       struct device_attribute *attr, const char *buf,
+			       size_t len)
 {
 	bool force_raw;
 	int rc = strtobool(buf, &force_raw);
@@ -1647,30 +1627,24 @@ static ssize_t force_raw_store(struct device *dev,
 	return len;
 }
 
-static ssize_t force_raw_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
+static ssize_t force_raw_show(struct device *dev, struct device_attribute *attr,
+			      char *buf)
 {
 	return sprintf(buf, "%d\n", to_ndns(dev)->force_raw);
 }
 static DEVICE_ATTR_RW(force_raw);
 
 static struct attribute *nd_namespace_attributes[] = {
-	&dev_attr_nstype.attr,
-	&dev_attr_size.attr,
-	&dev_attr_mode.attr,
-	&dev_attr_uuid.attr,
-	&dev_attr_holder.attr,
-	&dev_attr_resource.attr,
-	&dev_attr_alt_name.attr,
-	&dev_attr_force_raw.attr,
-	&dev_attr_sector_size.attr,
-	&dev_attr_dpa_extents.attr,
-	&dev_attr_holder_class.attr,
-	NULL,
+	&dev_attr_nstype.attr,	     &dev_attr_size.attr,
+	&dev_attr_mode.attr,	     &dev_attr_uuid.attr,
+	&dev_attr_holder.attr,	     &dev_attr_resource.attr,
+	&dev_attr_alt_name.attr,     &dev_attr_force_raw.attr,
+	&dev_attr_sector_size.attr,  &dev_attr_dpa_extents.attr,
+	&dev_attr_holder_class.attr, NULL,
 };
 
-static umode_t namespace_visible(struct kobject *kobj,
-				 struct attribute *a, int n)
+static umode_t namespace_visible(struct kobject *kobj, struct attribute *a,
+				 int n)
 {
 	struct device *dev = container_of(kobj, struct device, kobj);
 
@@ -1687,12 +1661,9 @@ static umode_t namespace_visible(struct kobject *kobj,
 		return a->mode;
 	}
 
-	if (a == &dev_attr_nstype.attr ||
-	    a == &dev_attr_size.attr ||
-	    a == &dev_attr_holder.attr ||
-	    a == &dev_attr_holder_class.attr ||
-	    a == &dev_attr_force_raw.attr ||
-	    a == &dev_attr_mode.attr)
+	if (a == &dev_attr_nstype.attr || a == &dev_attr_size.attr ||
+	    a == &dev_attr_holder.attr || a == &dev_attr_holder_class.attr ||
+	    a == &dev_attr_force_raw.attr || a == &dev_attr_mode.attr)
 		return a->mode;
 
 	return 0;
@@ -1730,7 +1701,7 @@ struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev)
 			return ERR_PTR(-ENODEV);
 
 		/*
-		 * Flush any in-progress probes / removals in the driver
+		 * Flush any in-progess probes / removals in the driver
 		 * for the raw personality of this namespace.
 		 */
 		nd_device_lock(&ndns->dev);
@@ -1742,8 +1713,7 @@ struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev)
 		}
 		if (dev_WARN_ONCE(&ndns->dev, ndns->claim != dev,
 				  "host (%s) vs claim (%s) mismatch\n",
-				  dev_name(dev),
-				  dev_name(ndns->claim)))
+				  dev_name(dev), dev_name(ndns->claim)))
 			return ERR_PTR(-ENXIO);
 	} else {
 		ndns = to_ndns(dev);
@@ -1818,8 +1788,8 @@ static struct device **create_namespace_io(struct nd_region *nd_region)
 	return devs;
 }
 
-static bool has_uuid_at_pos(struct nd_region *nd_region, u8 *uuid,
-			    u64 cookie, u16 pos)
+static bool has_uuid_at_pos(struct nd_region *nd_region, u8 *uuid, u64 cookie,
+			    u16 pos)
 {
 	struct nd_namespace_label *found = NULL;
 	int i;
@@ -1831,7 +1801,7 @@ static bool has_uuid_at_pos(struct nd_region *nd_region, u8 *uuid,
 		struct nd_label_ent *label_ent;
 		bool found_uuid = false;
 
-		list_for_each_entry(label_ent, &nd_mapping->labels, list) {
+		list_for_each_entry (label_ent, &nd_mapping->labels, list) {
 			struct nd_namespace_label *nd_label = label_ent->label;
 			u16 position, nlabel;
 			u64 isetcookie;
@@ -1851,7 +1821,8 @@ static bool has_uuid_at_pos(struct nd_region *nd_region, u8 *uuid,
 			if (namespace_label_has(ndd, type_guid) &&
 			    !guid_equal(&nd_set->type_guid,
 					&nd_label->type_guid)) {
-				dev_dbg(ndd->dev, "expect type_guid %pUb got %pUb\n",
+				dev_dbg(ndd->dev,
+					"expect type_guid %pUb got %pUb\n",
 					&nd_set->type_guid,
 					&nd_label->type_guid);
 				continue;
@@ -1890,11 +1861,12 @@ static int select_pmem_id(struct nd_region *nd_region, u8 *pmem_id)
 		struct nd_label_ent *label_ent;
 
 		lockdep_assert_held(&nd_mapping->lock);
-		list_for_each_entry(label_ent, &nd_mapping->labels, list) {
+		list_for_each_entry (label_ent, &nd_mapping->labels, list) {
 			nd_label = label_ent->label;
 			if (!nd_label)
 				continue;
-			if (memcmp(nd_label->uuid, pmem_id, NSLABEL_UUID_LEN) == 0)
+			if (memcmp(nd_label->uuid, pmem_id, NSLABEL_UUID_LEN) ==
+			    0)
 				break;
 			nd_label = NULL;
 		}
@@ -1912,8 +1884,10 @@ static int select_pmem_id(struct nd_region *nd_region, u8 *pmem_id)
 		hw_end = hw_start + nd_mapping->size;
 		pmem_start = __le64_to_cpu(nd_label->dpa);
 		pmem_end = pmem_start + __le64_to_cpu(nd_label->rawsize);
-		if (!(pmem_start >= hw_start && pmem_start < hw_end &&
-		      pmem_end <= hw_end && pmem_end > hw_start)) {
+		if (pmem_start >= hw_start && pmem_start < hw_end &&
+		    pmem_end <= hw_end && pmem_end > hw_start)
+			/* pass */;
+		else {
 			dev_dbg(&nd_region->dev, "%s invalid label for %pUb\n",
 				dev_name(ndd->dev), nd_label->uuid);
 			return -EINVAL;
@@ -2062,25 +2036,26 @@ static struct device *create_namespace_pmem(struct nd_region *nd_region,
 }
 
 struct resource *nsblk_add_resource(struct nd_region *nd_region,
-				    struct nvdimm_drvdata *ndd, struct nd_namespace_blk *nsblk,
+				    struct nvdimm_drvdata *ndd,
+				    struct nd_namespace_blk *nsblk,
 				    resource_size_t start)
 {
 	struct nd_label_id label_id;
 	struct resource *res;
 
 	nd_label_gen_id(&label_id, nsblk->uuid, NSLABEL_FLAG_LOCAL);
-	res = krealloc(nsblk->res,
-		       sizeof(void *) * (nsblk->num_resources + 1),
+	res = krealloc(nsblk->res, sizeof(void *) * (nsblk->num_resources + 1),
 		       GFP_KERNEL);
 	if (!res)
 		return NULL;
 	nsblk->res = (struct resource **)res;
-	for_each_dpa_resource(ndd, res)
-		if (strcmp(res->name, label_id.id) == 0 &&
-		    res->start == start) {
-			nsblk->res[nsblk->num_resources++] = res;
-			return res;
-		}
+	for_each_dpa_resource(ndd,
+			      res) if (strcmp(res->name, label_id.id) == 0 &&
+				       res->start == start)
+	{
+		nsblk->res[nsblk->num_resources++] = res;
+		return res;
+	}
 	return NULL;
 }
 
@@ -2254,8 +2229,7 @@ static struct device *create_namespace_blk(struct nd_region *nd_region,
 	if (namespace_label_has(ndd, type_guid)) {
 		if (!guid_equal(&nd_set->type_guid, &nd_label->type_guid)) {
 			dev_dbg(ndd->dev, "expect type_guid %pUb got %pUb\n",
-				&nd_set->type_guid,
-				&nd_label->type_guid);
+				&nd_set->type_guid, &nd_label->type_guid);
 			return ERR_PTR(-EAGAIN);
 		}
 
@@ -2275,8 +2249,7 @@ static struct device *create_namespace_blk(struct nd_region *nd_region,
 	dev->parent = &nd_region->dev;
 	nsblk->id = -1;
 	nsblk->lbasize = __le64_to_cpu(nd_label->lbasize);
-	nsblk->uuid = kmemdup(nd_label->uuid, NSLABEL_UUID_LEN,
-			      GFP_KERNEL);
+	nsblk->uuid = kmemdup(nd_label->uuid, NSLABEL_UUID_LEN, GFP_KERNEL);
 	if (namespace_label_has(ndd, abstraction_guid))
 		nsblk->common.claim_class =
 			to_nvdimm_cclass(&nd_label->abstraction_guid);
@@ -2284,8 +2257,7 @@ static struct device *create_namespace_blk(struct nd_region *nd_region,
 		goto blk_err;
 	memcpy(name, nd_label->name, NSLABEL_NAME_LEN);
 	if (name[0]) {
-		nsblk->alt_name = kmemdup(name, NSLABEL_NAME_LEN,
-					  GFP_KERNEL);
+		nsblk->alt_name = kmemdup(name, NSLABEL_NAME_LEN, GFP_KERNEL);
 		if (!nsblk->alt_name)
 			goto blk_err;
 	}
@@ -2334,15 +2306,18 @@ static struct device **scan_labels(struct nd_region *nd_region)
 	resource_size_t map_end = nd_mapping->start + nd_mapping->size - 1;
 
 	/* "safe" because create_namespace_pmem() might list_move() label_ent */
-	list_for_each_entry_safe(label_ent, e, &nd_mapping->labels, list) {
+	list_for_each_entry_safe (label_ent, e, &nd_mapping->labels, list) {
 		struct nd_namespace_label *nd_label = label_ent->label;
 		struct device **__devs;
-		bool localflag;
+		u32 flags;
 
 		if (!nd_label)
 			continue;
-		localflag = __le32_to_cpu(nd_label->flags) & NSLABEL_FLAG_LOCAL;
-		if (is_nd_blk(&nd_region->dev) != localflag)
+		flags = __le32_to_cpu(nd_label->flags);
+		if (is_nd_blk(&nd_region->dev) ==
+		    !!(flags & NSLABEL_FLAG_LOCAL))
+			/* pass, region matches label type */;
+		else
 			continue;
 
 		/* skip labels that describe extents outside of the region */
@@ -2362,14 +2337,15 @@ static struct device **scan_labels(struct nd_region *nd_region)
 		kfree(devs);
 		devs = __devs;
 
-		if (is_nd_blk(&nd_region->dev)) {
+		if (is_nd_blk(&nd_region->dev))
 			dev = create_namespace_blk(nd_region, nd_label, count);
-		} else {
+		else {
 			struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
 			struct nd_namespace_index *nsindex;
 
 			nsindex = to_namespace_index(ndd, ndd->ns_current);
-			dev = create_namespace_pmem(nd_region, nsindex, nd_label);
+			dev = create_namespace_pmem(nd_region, nsindex,
+						    nd_label);
 		}
 
 		if (IS_ERR(dev)) {
@@ -2383,14 +2359,13 @@ static struct device **scan_labels(struct nd_region *nd_region)
 			default:
 				goto err;
 			}
-		} else {
+		} else
 			devs[count++] = dev;
-		}
 	}
 
-	dev_dbg(&nd_region->dev, "discovered %d %s namespace%s\n",
-		count, is_nd_blk(&nd_region->dev)
-		? "blk" : "pmem", count == 1 ? "" : "s");
+	dev_dbg(&nd_region->dev, "discovered %d %s namespace%s\n", count,
+		is_nd_blk(&nd_region->dev) ? "blk" : "pmem",
+		count == 1 ? "" : "s");
 
 	if (count == 0) {
 		/* Publish a zero-sized namespace for userspace to configure. */
@@ -2433,7 +2408,7 @@ static struct device **scan_labels(struct nd_region *nd_region)
 			}
 
 			j = count;
-			list_for_each_safe(l, e, &nd_mapping->labels) {
+			list_for_each_safe (l, e, &nd_mapping->labels) {
 				if (!j--)
 					break;
 				list_move_tail(l, &list);
@@ -2503,21 +2478,20 @@ static int init_active_labels(struct nd_region *nd_region)
 		 * the region from being activated.
 		 */
 		if (!ndd) {
-			if (test_bit(NDD_LOCKED, &nvdimm->flags) ||
-					/* label data may be unreadable */
-			    test_bit(NDD_ALIASING, &nvdimm->flags)) {
-					/* labels needed to disambiguate dpa */
-
-				dev_err(&nd_region->dev,
-					"%s: is %s, failing probe\n",
-					dev_name(&nd_mapping->nvdimm->dev),
-					test_bit(NDD_LOCKED, &nvdimm->flags)
-					? "locked" : "disabled");
-				return -ENXIO;
-			}
-			return 0;
-		}
+			if (test_bit(NDD_LOCKED, &nvdimm->flags))
+				/* fail, label data may be unreadable */;
+			else if (test_bit(NDD_ALIASING, &nvdimm->flags))
+				/* fail, labels needed to disambiguate dpa */;
+			else
+				return 0;
 
+			dev_err(&nd_region->dev, "%s: is %s, failing probe\n",
+				dev_name(&nd_mapping->nvdimm->dev),
+				test_bit(NDD_LOCKED, &nvdimm->flags) ?
+					"locked" :
+					"disabled");
+			return -ENXIO;
+		}
 		nd_mapping->ndd = ndd;
 		atomic_inc(&nvdimm->busy);
 		get_ndd(ndd);
@@ -2606,9 +2580,8 @@ int nd_region_register_namespaces(struct nd_region *nd_region, int *err)
 			id = ida_simple_get(&nd_region->ns_ida, 0, 0,
 					    GFP_KERNEL);
 			nspm->id = id;
-		} else {
+		} else
 			id = i;
-		}
 
 		if (id < 0)
 			break;
diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h
index 15bbdf6bea24..0c0b84e2b98e 100644
--- a/drivers/nvdimm/nd-core.h
+++ b/drivers/nvdimm/nd-core.h
@@ -47,14 +47,14 @@ struct nvdimm {
 	struct delayed_work dwork;
 };
 
-static inline unsigned long nvdimm_security_flags(
-	struct nvdimm *nvdimm, enum nvdimm_passphrase_type ptype)
+static inline unsigned long
+nvdimm_security_flags(struct nvdimm *nvdimm, enum nvdimm_passphrase_type ptype)
 {
 	u64 flags;
-	const u64 state_flags = 1UL << NVDIMM_SECURITY_DISABLED
-		| 1UL << NVDIMM_SECURITY_LOCKED
-		| 1UL << NVDIMM_SECURITY_UNLOCKED
-		| 1UL << NVDIMM_SECURITY_OVERWRITE;
+	const u64 state_flags = 1UL << NVDIMM_SECURITY_DISABLED |
+				1UL << NVDIMM_SECURITY_LOCKED |
+				1UL << NVDIMM_SECURITY_UNLOCKED |
+				1UL << NVDIMM_SECURITY_OVERWRITE;
 
 	if (!nvdimm->sec.ops)
 		return 0;
@@ -62,21 +62,20 @@ static inline unsigned long nvdimm_security_flags(
 	flags = nvdimm->sec.ops->get_flags(nvdimm, ptype);
 	/* disabled, locked, unlocked, and overwrite are mutually exclusive */
 	dev_WARN_ONCE(&nvdimm->dev, hweight64(flags & state_flags) > 1,
-		      "reported invalid security state: %#llx\n", (u64)flags);
+		      "reported invalid security state: %#llx\n",
+		      (unsigned long long)flags);
 	return flags;
 }
-
 int nvdimm_security_freeze(struct nvdimm *nvdimm);
 #if IS_ENABLED(CONFIG_NVDIMM_KEYS)
 ssize_t nvdimm_security_store(struct device *dev, const char *buf, size_t len);
 void nvdimm_security_overwrite_query(struct work_struct *work);
 #else
-static inline ssize_t nvdimm_security_store(struct device *dev,
-					    const char *buf, size_t len)
+static inline ssize_t nvdimm_security_store(struct device *dev, const char *buf,
+					    size_t len)
 {
 	return -EOPNOTSUPP;
 }
-
 static inline void nvdimm_security_overwrite_query(struct work_struct *work)
 {
 }
@@ -107,12 +106,10 @@ static inline bool is_nd_region(struct device *dev)
 {
 	return is_nd_pmem(dev) || is_nd_blk(dev) || is_nd_volatile(dev);
 }
-
 static inline bool is_memory(struct device *dev)
 {
 	return is_nd_pmem(dev) || is_nd_volatile(dev);
 }
-
 struct nvdimm_bus *walk_to_nvdimm_bus(struct device *nd_dev);
 int __init nvdimm_bus_init(void);
 void nvdimm_bus_exit(void);
@@ -172,21 +169,20 @@ bool nd_attach_ndns(struct device *dev, struct nd_namespace_common *attach,
 bool __nd_attach_ndns(struct device *dev, struct nd_namespace_common *attach,
 		      struct nd_namespace_common **_ndns);
 ssize_t nd_namespace_store(struct device *dev,
-			   struct nd_namespace_common **_ndns,
-			   const char *buf, size_t len);
+			   struct nd_namespace_common **_ndns, const char *buf,
+			   size_t len);
 struct nd_pfn *to_nd_pfn_safe(struct device *dev);
 bool is_nvdimm_bus(struct device *dev);
 
 #ifdef CONFIG_PROVE_LOCKING
 extern struct class *nd_class;
 
-enum {
-	LOCK_BUS,
-	LOCK_NDCTL,
-	LOCK_REGION,
-	LOCK_DIMM = LOCK_REGION,
-	LOCK_NAMESPACE,
-	LOCK_CLAIM,
+enum { LOCK_BUS,
+       LOCK_NDCTL,
+       LOCK_REGION,
+       LOCK_DIMM = LOCK_REGION,
+       LOCK_NAMESPACE,
+       LOCK_CLAIM,
 };
 
 static inline void debug_nvdimm_lock(struct device *dev)
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index 852ce9591109..c64e4223711b 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -60,8 +60,8 @@ static inline void ndrd_set_flush_wpq(struct nd_region_data *ndrd, int dimm,
 	ndrd->flush_wpq[dimm * num + (hint & mask)] = flush;
 }
 
-static inline struct nd_namespace_index *to_namespace_index(
-	struct nvdimm_drvdata *ndd, int i)
+static inline struct nd_namespace_index *
+to_namespace_index(struct nvdimm_drvdata *ndd, int i)
 {
 	if (i < 0)
 		return NULL;
@@ -69,36 +69,36 @@ static inline struct nd_namespace_index *to_namespace_index(
 	return ndd->data + sizeof_namespace_index(ndd) * i;
 }
 
-static inline struct nd_namespace_index *to_current_namespace_index(
-	struct nvdimm_drvdata *ndd)
+static inline struct nd_namespace_index *
+to_current_namespace_index(struct nvdimm_drvdata *ndd)
 {
 	return to_namespace_index(ndd, ndd->ns_current);
 }
 
-static inline struct nd_namespace_index *to_next_namespace_index(
-	struct nvdimm_drvdata *ndd)
+static inline struct nd_namespace_index *
+to_next_namespace_index(struct nvdimm_drvdata *ndd)
 {
 	return to_namespace_index(ndd, ndd->ns_next);
 }
 
-unsigned int sizeof_namespace_label(struct nvdimm_drvdata *ndd);
+unsigned sizeof_namespace_label(struct nvdimm_drvdata *ndd);
 
-#define namespace_label_has(ndd, field)			\
-	(offsetof(struct nd_namespace_label, field)	\
-	 < sizeof_namespace_label(ndd))
+#define namespace_label_has(ndd, field)                                        \
+	(offsetof(struct nd_namespace_label, field) <                          \
+	 sizeof_namespace_label(ndd))
 
-#define nd_dbg_dpa(r, d, res, fmt, arg...)				\
-	dev_dbg((r) ? &(r)->dev : (d)->dev, "%s: %.13s: %#llx @ %#llx " fmt, \
-		(r) ? dev_name((d)->dev) : "", res ? res->name : "null", \
-		(u64)(res ? resource_size(res) : 0),	\
-		(u64)(res ? res->start : 0), ##arg)
+#define nd_dbg_dpa(r, d, res, fmt, arg...)                                     \
+	dev_dbg((r) ? &(r)->dev : (d)->dev, "%s: %.13s: %#llx @ %#llx " fmt,   \
+		(r) ? dev_name((d)->dev) : "", res ? res->name : "null",       \
+		(unsigned long long)(res ? resource_size(res) : 0),            \
+		(unsigned long long)(res ? res->start : 0), ##arg)
 
-#define for_each_dpa_resource(ndd, res)				\
+#define for_each_dpa_resource(ndd, res)                                        \
 	for (res = (ndd)->dpa.child; res; res = res->sibling)
 
-#define for_each_dpa_resource_safe(ndd, res, next)			\
-	for (res = (ndd)->dpa.child, next = res ? res->sibling : NULL;	\
-	     res; res = next, next = next ? next->sibling : NULL)
+#define for_each_dpa_resource_safe(ndd, res, next)                             \
+	for (res = (ndd)->dpa.child, next = res ? res->sibling : NULL; res;    \
+	     res = next, next = next ? next->sibling : NULL)
 
 struct nd_percpu_lane {
 	int count;
@@ -108,7 +108,6 @@ struct nd_percpu_lane {
 enum nd_label_flags {
 	ND_LABEL_REAP,
 };
-
 struct nd_label_ent {
 	struct list_head list;
 	unsigned long flags;
@@ -171,9 +170,9 @@ struct nd_blk_region {
 /*
  * Lookup next in the repeating sequence of 01, 10, and 11.
  */
-static inline unsigned int nd_inc_seq(unsigned int seq)
+static inline unsigned nd_inc_seq(unsigned seq)
 {
-	static const unsigned int next[] = { 0, 2, 3, 1 };
+	static const unsigned next[] = { 0, 2, 3, 1 };
 
 	return next[seq & 3];
 }
@@ -240,10 +239,10 @@ struct nvdimm_drvdata *to_ndd(struct nd_mapping *nd_mapping);
 int nvdimm_check_config_data(struct device *dev);
 int nvdimm_init_nsarea(struct nvdimm_drvdata *ndd);
 int nvdimm_init_config_data(struct nvdimm_drvdata *ndd);
-int nvdimm_get_config_data(struct nvdimm_drvdata *ndd, void *buf,
-			   size_t offset, size_t len);
-int nvdimm_set_config_data(struct nvdimm_drvdata *ndd, size_t offset,
-			   void *buf, size_t len);
+int nvdimm_get_config_data(struct nvdimm_drvdata *ndd, void *buf, size_t offset,
+			   size_t len);
+int nvdimm_set_config_data(struct nvdimm_drvdata *ndd, size_t offset, void *buf,
+			   size_t len);
 long nvdimm_clear_poison(struct device *dev, phys_addr_t phys,
 			 unsigned int len);
 void nvdimm_set_aliasing(struct device *dev);
@@ -365,8 +364,7 @@ int nd_label_reserve_dpa(struct nvdimm_drvdata *ndd);
 void nvdimm_free_dpa(struct nvdimm_drvdata *ndd, struct resource *res);
 struct resource *nvdimm_allocate_dpa(struct nvdimm_drvdata *ndd,
 				     struct nd_label_id *label_id,
-				     resource_size_t start,
-				     resource_size_t n);
+				     resource_size_t start, resource_size_t n);
 resource_size_t nvdimm_namespace_capacity(struct nd_namespace_common *ndns);
 bool nvdimm_namespace_locked(struct nd_namespace_common *ndns);
 struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev);
@@ -388,13 +386,11 @@ static inline int nvdimm_setup_pfn(struct nd_pfn *nd_pfn,
 {
 	return -ENXIO;
 }
-
 static inline int devm_nsio_enable(struct device *dev,
 				   struct nd_namespace_io *nsio)
 {
 	return -ENXIO;
 }
-
 static inline void devm_nsio_disable(struct device *dev,
 				     struct nd_namespace_io *nsio)
 {
@@ -415,27 +411,25 @@ static inline bool nd_iostat_start(struct bio *bio, unsigned long *start)
 			      &disk->part0);
 	return true;
 }
-
 static inline void nd_iostat_end(struct bio *bio, unsigned long start)
 {
 	struct gendisk *disk = bio->bi_disk;
 
 	generic_end_io_acct(disk->queue, bio_op(bio), &disk->part0, start);
 }
-
 static inline bool is_bad_pmem(struct badblocks *bb, sector_t sector,
 			       unsigned int len)
 {
-	sector_t first_bad;
-	int num_bad;
-
-	if (!bb->count)
-		return false;
+	if (bb->count) {
+		sector_t first_bad;
+		int num_bad;
 
+		return !!badblocks_check(bb, sector, len / 512, &first_bad,
+					 &num_bad);
+	}
 
-	return badblocks_check(bb, sector, len / 512, &first_bad, &num_bad);
+	return false;
 }
-
 resource_size_t nd_namespace_blk_validate(struct nd_namespace_blk *nsblk);
 const u8 *nd_dev_to_uuid(struct device *dev);
 bool pmem_should_map_pages(struct device *dev);
diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c
index 1a792fee8cfd..478194e86345 100644
--- a/drivers/nvdimm/nd_virtio.c
+++ b/drivers/nvdimm/nd_virtio.c
@@ -39,7 +39,7 @@ EXPORT_SYMBOL_GPL(virtio_pmem_host_ack);
 static int virtio_pmem_flush(struct nd_region *nd_region)
 {
 	struct virtio_device *vdev = nd_region->provider_data;
-	struct virtio_pmem *vpmem  = vdev->priv;
+	struct virtio_pmem *vpmem = vdev->priv;
 	struct virtio_pmem_request *req_data;
 	struct scatterlist *sgs[2], sg, ret;
 	unsigned long flags;
@@ -62,14 +62,16 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
 
 	spin_lock_irqsave(&vpmem->pmem_lock, flags);
 	/*
-	 * If virtqueue_add_sgs returns -ENOSPC then req_vq virtual
-	 * queue does not have free descriptor. We add the request
-	 * to req_list and wait for host_ack to wake us up when free
-	 * slots are available.
-	 */
+	  * If virtqueue_add_sgs returns -ENOSPC then req_vq virtual
+	  * queue does not have free descriptor. We add the request
+	  * to req_list and wait for host_ack to wake us up when free
+	  * slots are available.
+	  */
 	while ((err = virtqueue_add_sgs(vpmem->req_vq, sgs, 1, 1, req_data,
 					GFP_ATOMIC)) == -ENOSPC) {
-		dev_info(&vdev->dev, "failed to send command to virtio pmem device, no free slots in the virtqueue\n");
+		dev_info(
+			&vdev->dev,
+			"failed to send command to virtio pmem device, no free slots in the virtqueue\n");
 		req_data->wq_buf_avail = false;
 		list_add_tail(&req_data->list, &vpmem->req_list);
 		spin_unlock_irqrestore(&vpmem->pmem_lock, flags);
@@ -85,7 +87,8 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
 	 * do anything about that.
 	 */
 	if (err || !err1) {
-		dev_info(&vdev->dev, "failed to send command to virtio pmem device\n");
+		dev_info(&vdev->dev,
+			 "failed to send command to virtio pmem device\n");
 		err = -EIO;
 	} else {
 		/* A host repsonse results in "host_ack" getting called */
diff --git a/drivers/nvdimm/of_pmem.c b/drivers/nvdimm/of_pmem.c
index 03ffcbf601d4..95f72164ea85 100644
--- a/drivers/nvdimm/of_pmem.c
+++ b/drivers/nvdimm/of_pmem.c
@@ -55,7 +55,7 @@ static int of_pmem_region_probe(struct platform_device *pdev)
 
 	is_volatile = !!of_find_property(np, "volatile", NULL);
 	dev_dbg(&pdev->dev, "Registering %s regions from %pOF\n",
-		is_volatile ? "volatile" : "non-volatile",  np);
+		is_volatile ? "volatile" : "non-volatile", np);
 
 	for (i = 0; i < pdev->num_resources; i++) {
 		struct nd_region_desc ndr_desc;
@@ -79,7 +79,8 @@ static int of_pmem_region_probe(struct platform_device *pdev)
 			region = nvdimm_pmem_region_create(bus, &ndr_desc);
 
 		if (!region)
-			dev_warn(&pdev->dev, "Unable to register region %pR from %pOF\n",
+			dev_warn(&pdev->dev,
+				 "Unable to register region %pR from %pOF\n",
 				 ndr_desc.res, np);
 		else
 			dev_dbg(&pdev->dev, "Registered region %pR from %pOF\n",
@@ -101,7 +102,7 @@ static int of_pmem_region_remove(struct platform_device *pdev)
 
 static const struct of_device_id of_pmem_region_match[] = {
 	{ .compatible = "pmem-region" },
-	{ },
+	{},
 };
 
 static struct platform_driver of_pmem_region_driver = {
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 6ab72f8f4a66..47b578dd1a4c 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -46,8 +46,8 @@ struct nd_pfn *to_nd_pfn(struct device *dev)
 }
 EXPORT_SYMBOL(to_nd_pfn);
 
-static ssize_t mode_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
+static ssize_t mode_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 
@@ -69,26 +69,25 @@ static ssize_t mode_store(struct device *dev, struct device_attribute *attr,
 
 	nd_device_lock(dev);
 	nvdimm_bus_lock(dev);
-	if (dev->driver) {
+	if (dev->driver)
 		rc = -EBUSY;
-	} else {
+	else {
 		size_t n = len - 1;
 
 		if (strncmp(buf, "pmem\n", n) == 0 ||
 		    strncmp(buf, "pmem", n) == 0) {
 			nd_pfn->mode = PFN_MODE_PMEM;
 		} else if (strncmp(buf, "ram\n", n) == 0 ||
-			   strncmp(buf, "ram", n) == 0) {
+			   strncmp(buf, "ram", n) == 0)
 			nd_pfn->mode = PFN_MODE_RAM;
-		} else if (strncmp(buf, "none\n", n) == 0 ||
-			   strncmp(buf, "none", n) == 0) {
+		else if (strncmp(buf, "none\n", n) == 0 ||
+			 strncmp(buf, "none", n) == 0)
 			nd_pfn->mode = PFN_MODE_NONE;
-		} else {
+		else
 			rc = -EINVAL;
-		}
 	}
-	dev_dbg(dev, "result: %zd wrote: %s%s",
-		rc, buf, buf[len - 1] == '\n' ? "" : "\n");
+	dev_dbg(dev, "result: %zd wrote: %s%s", rc, buf,
+		buf[len - 1] == '\n' ? "" : "\n");
 	nvdimm_bus_unlock(dev);
 	nd_device_unlock(dev);
 
@@ -96,8 +95,8 @@ static ssize_t mode_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RW(mode);
 
-static ssize_t align_show(struct device *dev,
-			  struct device_attribute *attr, char *buf)
+static ssize_t align_show(struct device *dev, struct device_attribute *attr,
+			  char *buf)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 
@@ -127,8 +126,8 @@ static const unsigned long *nd_pfn_supported_alignments(void)
 	return data;
 }
 
-static ssize_t align_store(struct device *dev,
-			   struct device_attribute *attr, const char *buf, size_t len)
+static ssize_t align_store(struct device *dev, struct device_attribute *attr,
+			   const char *buf, size_t len)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 	ssize_t rc;
@@ -137,8 +136,8 @@ static ssize_t align_store(struct device *dev,
 	nvdimm_bus_lock(dev);
 	rc = nd_size_select_store(dev, buf, &nd_pfn->align,
 				  nd_pfn_supported_alignments());
-	dev_dbg(dev, "result: %zd wrote: %s%s",
-		rc, buf, buf[len - 1] == '\n' ? "" : "\n");
+	dev_dbg(dev, "result: %zd wrote: %s%s", rc, buf,
+		buf[len - 1] == '\n' ? "" : "\n");
 	nvdimm_bus_unlock(dev);
 	nd_device_unlock(dev);
 
@@ -146,8 +145,8 @@ static ssize_t align_store(struct device *dev,
 }
 static DEVICE_ATTR_RW(align);
 
-static ssize_t uuid_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
+static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 
@@ -156,24 +155,24 @@ static ssize_t uuid_show(struct device *dev,
 	return sprintf(buf, "\n");
 }
 
-static ssize_t uuid_store(struct device *dev,
-			  struct device_attribute *attr, const char *buf, size_t len)
+static ssize_t uuid_store(struct device *dev, struct device_attribute *attr,
+			  const char *buf, size_t len)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 	ssize_t rc;
 
 	nd_device_lock(dev);
 	rc = nd_uuid_store(dev, &nd_pfn->uuid, buf, len);
-	dev_dbg(dev, "result: %zd wrote: %s%s",
-		rc, buf, buf[len - 1] == '\n' ? "" : "\n");
+	dev_dbg(dev, "result: %zd wrote: %s%s", rc, buf,
+		buf[len - 1] == '\n' ? "" : "\n");
 	nd_device_unlock(dev);
 
 	return rc ? rc : len;
 }
 static DEVICE_ATTR_RW(uuid);
 
-static ssize_t namespace_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
+static ssize_t namespace_show(struct device *dev, struct device_attribute *attr,
+			      char *buf)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 	ssize_t rc;
@@ -186,8 +185,8 @@ static ssize_t namespace_show(struct device *dev,
 }
 
 static ssize_t namespace_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t len)
+			       struct device_attribute *attr, const char *buf,
+			       size_t len)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 	ssize_t rc;
@@ -195,8 +194,8 @@ static ssize_t namespace_store(struct device *dev,
 	nd_device_lock(dev);
 	nvdimm_bus_lock(dev);
 	rc = nd_namespace_store(dev, &nd_pfn->ndns, buf, len);
-	dev_dbg(dev, "result: %zd wrote: %s%s",
-		rc, buf, buf[len - 1] == '\n' ? "" : "\n");
+	dev_dbg(dev, "result: %zd wrote: %s%s", rc, buf,
+		buf[len - 1] == '\n' ? "" : "\n");
 	nvdimm_bus_unlock(dev);
 	nd_device_unlock(dev);
 
@@ -204,8 +203,8 @@ static ssize_t namespace_store(struct device *dev,
 }
 static DEVICE_ATTR_RW(namespace);
 
-static ssize_t resource_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t resource_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 	ssize_t rc;
@@ -219,7 +218,8 @@ static ssize_t resource_show(struct device *dev,
 		struct nd_namespace_io *nsio = to_nd_namespace_io(&ndns->dev);
 
 		rc = sprintf(buf, "%#llx\n",
-			     (u64)nsio->res.start + start_pad + offset);
+			     (unsigned long long)nsio->res.start + start_pad +
+				     offset);
 	} else {
 		/* no address to convey if the pfn instance is disabled */
 		rc = -ENXIO;
@@ -230,8 +230,8 @@ static ssize_t resource_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(resource);
 
-static ssize_t size_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
+static ssize_t size_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 	ssize_t rc;
@@ -246,8 +246,8 @@ static ssize_t size_show(struct device *dev,
 		struct nd_namespace_io *nsio = to_nd_namespace_io(&ndns->dev);
 
 		rc = sprintf(buf, "%llu\n",
-			     (u64)resource_size(&nsio->res)
-			     - start_pad - end_trunc - offset);
+			     (unsigned long long)resource_size(&nsio->res) -
+				     start_pad - end_trunc - offset);
 	} else {
 		/* no size to convey if the pfn instance is disabled */
 		rc = -ENXIO;
@@ -388,10 +388,10 @@ static int nd_pfn_clear_memmap_errors(struct nd_pfn *nd_pfn)
 		if (bb_present) {
 			dev_dbg(&nd_pfn->dev, "meta: %x badblocks at %llx\n",
 				num_bad, first_bad);
-			nsoff = ALIGN_DOWN((nd_region->ndr_start
-					    + (first_bad << 9))
-					   - nsio->res.start,
-					   PAGE_SIZE);
+			nsoff = ALIGN_DOWN(
+				(nd_region->ndr_start + (first_bad << 9)) -
+					nsio->res.start,
+				PAGE_SIZE);
 			zero_len = ALIGN(num_bad << 9, PAGE_SIZE);
 			while (zero_len) {
 				unsigned long chunk = min(zero_len, PAGE_SIZE);
@@ -508,8 +508,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 			dev_err(&nd_pfn->dev,
 				"init failed, settings mismatch\n");
 			dev_dbg(&nd_pfn->dev, "align: %lx:%lx mode: %d:%d\n",
-				nd_pfn->align, align, nd_pfn->mode,
-				mode);
+				nd_pfn->align, align, nd_pfn->mode, mode);
 			return -EINVAL;
 		}
 	}
@@ -537,8 +536,8 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
 	     !IS_ALIGNED(nsio->res.start + offset + start_pad, align)) ||
 	    !IS_ALIGNED(offset, PAGE_SIZE)) {
 		dev_err(&nd_pfn->dev,
-			"bad offset: %#llx dax disabled align: %#lx\n",
-			offset, align);
+			"bad offset: %#llx dax disabled align: %#lx\n", offset,
+			align);
 		return -ENXIO;
 	}
 
@@ -579,9 +578,8 @@ int nd_pfn_probe(struct device *dev, struct nd_namespace_common *ndns)
 	if (rc < 0) {
 		nd_detach_ndns(pfn_dev, &nd_pfn->ndns);
 		put_device(pfn_dev);
-	} else {
+	} else
 		__nd_device_register(pfn_dev);
-	}
 
 	return rc;
 }
@@ -648,9 +646,8 @@ static int __nvdimm_setup_pfn(struct nd_pfn *nd_pfn, struct dev_pagemap *pgmap)
 		altmap->free = PHYS_PFN(offset - reserve);
 		altmap->alloc = 0;
 		pgmap->flags |= PGMAP_ALTMAP_VALID;
-	} else {
+	} else
 		return -ENXIO;
-	}
 
 	return 0;
 }
@@ -712,14 +709,14 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
 		 * PMD_SIZE for most architectures.
 		 */
 		offset = ALIGN(start + SZ_8K + 64 * npfns, align) - start;
-	} else if (nd_pfn->mode == PFN_MODE_RAM) {
+	} else if (nd_pfn->mode == PFN_MODE_RAM)
 		offset = ALIGN(start + SZ_8K, align) - start;
-	} else {
+	else
 		return -ENXIO;
-	}
 
 	if (offset >= size) {
-		dev_err(&nd_pfn->dev, "%s unable to satisfy requested alignment\n",
+		dev_err(&nd_pfn->dev,
+			"%s unable to satisfy requested alignment\n",
 			dev_name(&ndns->dev));
 		return -ENXIO;
 	}
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 3f1add94144a..b764fffba49c 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -44,8 +44,8 @@ static struct nd_region *to_region(struct pmem_device *pmem)
 	return to_nd_region(to_dev(pmem)->parent);
 }
 
-static void hwpoison_clear(struct pmem_device *pmem,
-			   phys_addr_t phys, unsigned int len)
+static void hwpoison_clear(struct pmem_device *pmem, phys_addr_t phys,
+			   unsigned int len)
 {
 	unsigned long pfn_start, pfn_end, pfn;
 
@@ -85,7 +85,8 @@ static blk_status_t pmem_clear_poison(struct pmem_device *pmem,
 		hwpoison_clear(pmem, pmem->phys_addr + offset, cleared);
 		cleared /= 512;
 		dev_dbg(dev, "%#llx clear %ld sector%s\n",
-			(u64)sector, cleared, cleared > 1 ? "s" : "");
+			(unsigned long long)sector, cleared,
+			cleared > 1 ? "s" : "");
 		badblocks_clear(&pmem->bb, sector, cleared);
 		if (pmem->bb_state)
 			sysfs_notify_dirent(pmem->bb_state);
@@ -96,8 +97,8 @@ static blk_status_t pmem_clear_poison(struct pmem_device *pmem,
 	return rc;
 }
 
-static void write_pmem(void *pmem_addr, struct page *page,
-		       unsigned int off, unsigned int len)
+static void write_pmem(void *pmem_addr, struct page *page, unsigned int off,
+		       unsigned int len)
 {
 	unsigned int chunk;
 	void *mem;
@@ -149,9 +150,9 @@ static blk_status_t pmem_do_bvec(struct pmem_device *pmem, struct page *page,
 		bad_pmem = true;
 
 	if (!op_is_write(op)) {
-		if (unlikely(bad_pmem)) {
+		if (unlikely(bad_pmem))
 			rc = BLK_STS_IOERR;
-		} else {
+		else {
 			rc = read_pmem(page, off, pmem_addr, len);
 			flush_dcache_page(page);
 		}
@@ -196,7 +197,7 @@ static blk_qc_t pmem_make_request(struct request_queue *q, struct bio *bio)
 		ret = nvdimm_flush(nd_region, bio);
 
 	do_acct = nd_iostat_start(bio, &start);
-	bio_for_each_segment(bvec, bio, iter) {
+	bio_for_each_segment (bvec, bio, iter) {
 		rc = pmem_do_bvec(pmem, bvec.bv_page, bvec.bv_len,
 				  bvec.bv_offset, bio_op(bio), iter.bi_sector);
 		if (rc) {
@@ -223,8 +224,8 @@ static int pmem_rw_page(struct block_device *bdev, sector_t sector,
 	struct pmem_device *pmem = bdev->bd_queue->queuedata;
 	blk_status_t rc;
 
-	rc = pmem_do_bvec(pmem, page, hpage_nr_pages(page) * PAGE_SIZE,
-			  0, op, sector);
+	rc = pmem_do_bvec(pmem, page, hpage_nr_pages(page) * PAGE_SIZE, 0, op,
+			  sector);
 
 	/*
 	 * The ->rw_page interface is subtle and tricky.  The core
@@ -263,14 +264,13 @@ __weak long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
 }
 
 static const struct block_device_operations pmem_fops = {
-	.owner =		THIS_MODULE,
-	.rw_page =		pmem_rw_page,
-	.revalidate_disk =	nvdimm_revalidate_disk,
+	.owner = THIS_MODULE,
+	.rw_page = pmem_rw_page,
+	.revalidate_disk = nvdimm_revalidate_disk,
 };
 
-static long pmem_dax_direct_access(struct dax_device *dax_dev,
-				   pgoff_t pgoff, long nr_pages,
-				   void **kaddr, pfn_t *pfn)
+static long pmem_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
+				   long nr_pages, void **kaddr, pfn_t *pfn)
 {
 	struct pmem_device *pmem = dax_get_private(dax_dev);
 
@@ -344,9 +344,9 @@ static void pmem_pagemap_page_free(struct page *page)
 }
 
 static const struct dev_pagemap_ops fsdax_pagemap_ops = {
-	.page_free		= pmem_pagemap_page_free,
-	.kill			= pmem_pagemap_kill,
-	.cleanup		= pmem_pagemap_cleanup,
+	.page_free = pmem_pagemap_page_free,
+	.kill = pmem_pagemap_kill,
+	.cleanup = pmem_pagemap_cleanup,
 };
 
 static int pmem_attach_disk(struct device *dev,
@@ -410,8 +410,8 @@ static int pmem_attach_disk(struct device *dev,
 		addr = devm_memremap_pages(dev, &pmem->pgmap);
 		pfn_sb = nd_pfn->pfn_sb;
 		pmem->data_offset = le64_to_cpu(pfn_sb->dataoff);
-		pmem->pfn_pad = resource_size(res) -
-			resource_size(&pmem->pgmap.res);
+		pmem->pfn_pad =
+			resource_size(res) - resource_size(&pmem->pgmap.res);
 		pmem->pfn_flags |= PFN_MAP;
 		memcpy(&bb_res, &pmem->pgmap.res, sizeof(bb_res));
 		bb_res.start += pmem->data_offset;
@@ -426,8 +426,8 @@ static int pmem_attach_disk(struct device *dev,
 		if (devm_add_action_or_reset(dev, pmem_release_queue,
 					     &pmem->pgmap))
 			return -ENOMEM;
-		addr = devm_memremap(dev, pmem->phys_addr,
-				     pmem->size, ARCH_MEMREMAP_PMEM);
+		addr = devm_memremap(dev, pmem->phys_addr, pmem->size,
+				     ARCH_MEMREMAP_PMEM);
 		memcpy(&bb_res, &nsio->res, sizeof(bb_res));
 	}
 
@@ -450,9 +450,9 @@ static int pmem_attach_disk(struct device *dev,
 		return -ENOMEM;
 	pmem->disk = disk;
 
-	disk->fops		= &pmem_fops;
-	disk->queue		= q;
-	disk->flags		= GENHD_FL_EXT_DEVT;
+	disk->fops = &pmem_fops;
+	disk->queue = q;
+	disk->flags = GENHD_FL_EXT_DEVT;
 	disk->queue->backing_dev_info->capabilities |= BDI_CAP_SYNCHRONOUS_IO;
 	nvdimm_namespace_disk_name(ndns, disk->disk_name);
 	set_capacity(disk,
@@ -480,8 +480,8 @@ static int pmem_attach_disk(struct device *dev,
 
 	revalidate_disk(disk);
 
-	pmem->bb_state = sysfs_get_dirent(disk_to_dev(disk)->kobj.sd,
-					  "badblocks");
+	pmem->bb_state =
+		sysfs_get_dirent(disk_to_dev(disk)->kobj.sd, "badblocks");
 	if (!pmem->bb_state)
 		dev_warn(dev, "'badblocks' notification disabled\n");
 
@@ -506,8 +506,7 @@ static int nd_pmem_probe(struct device *dev)
 		return pmem_attach_disk(dev, ndns);
 
 	/* if we find a valid info-block we'll come back as that personality */
-	if (nd_btt_probe(dev, ndns) == 0 ||
-	    nd_pfn_probe(dev, ndns) == 0 ||
+	if (nd_btt_probe(dev, ndns) == 0 || nd_pfn_probe(dev, ndns) == 0 ||
 	    nd_dax_probe(dev, ndns) == 0)
 		return -ENXIO;
 
@@ -519,9 +518,9 @@ static int nd_pmem_remove(struct device *dev)
 {
 	struct pmem_device *pmem = dev_get_drvdata(dev);
 
-	if (is_nd_btt(dev)) {
+	if (is_nd_btt(dev))
 		nvdimm_namespace_detach_btt(to_nd_btt(dev));
-	} else {
+	else {
 		/*
 		 * Note, this assumes nd_device_lock() context to not
 		 * race nd_pmem_notify()
@@ -573,7 +572,7 @@ static void nd_pmem_notify(struct device *dev, enum nvdimm_event event)
 
 			ndns = nd_pfn->ndns;
 			offset = pmem->data_offset +
-				__le32_to_cpu(pfn_sb->start_pad);
+				 __le32_to_cpu(pfn_sb->start_pad);
 			end_trunc = __le32_to_cpu(pfn_sb->end_trunc);
 		} else {
 			ndns = to_ndns(dev);
diff --git a/drivers/nvdimm/pmem.h b/drivers/nvdimm/pmem.h
index f5ba2a9a68ed..ebece9dc1baf 100644
--- a/drivers/nvdimm/pmem.h
+++ b/drivers/nvdimm/pmem.h
@@ -10,20 +10,20 @@
 /* this definition is in it's own header for tools/testing/nvdimm to consume */
 struct pmem_device {
 	/* One contiguous memory region per device */
-	phys_addr_t		phys_addr;
+	phys_addr_t phys_addr;
 	/* when non-zero this device is hosting a 'pfn' instance */
-	phys_addr_t		data_offset;
-	u64			pfn_flags;
-	void			*virt_addr;
+	phys_addr_t data_offset;
+	u64 pfn_flags;
+	void *virt_addr;
 	/* immutable base size of the namespace */
-	size_t			size;
+	size_t size;
 	/* trim size when namespace capacity has been section aligned */
-	u32			pfn_pad;
-	struct kernfs_node	*bb_state;
-	struct badblocks	bb;
-	struct dax_device	*dax_dev;
-	struct gendisk		*disk;
-	struct dev_pagemap	pgmap;
+	u32 pfn_pad;
+	struct kernfs_node *bb_state;
+	struct badblocks bb;
+	struct dax_device *dax_dev;
+	struct gendisk *disk;
+	struct dev_pagemap pgmap;
 };
 
 long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
diff --git a/drivers/nvdimm/region.c b/drivers/nvdimm/region.c
index fdd67ff499c9..fc6d11c3ea2f 100644
--- a/drivers/nvdimm/region.c
+++ b/drivers/nvdimm/region.c
@@ -19,10 +19,12 @@ static int nd_region_probe(struct device *dev)
 	if (nd_region->num_lanes > num_online_cpus() &&
 	    nd_region->num_lanes < num_possible_cpus() &&
 	    !test_and_set_bit(0, &once)) {
-		dev_dbg(dev, "online cpus (%d) < concurrent i/o lanes (%d) < possible cpus (%d)\n",
+		dev_dbg(dev,
+			"online cpus (%d) < concurrent i/o lanes (%d) < possible cpus (%d)\n",
 			num_online_cpus(), nd_region->num_lanes,
 			num_possible_cpus());
-		dev_dbg(dev, "setting nr_cpus=%d may yield better libnvdimm device performance\n",
+		dev_dbg(dev,
+			"setting nr_cpus=%d may yield better libnvdimm device performance\n",
 			nd_region->num_lanes);
 	}
 
@@ -39,8 +41,8 @@ static int nd_region_probe(struct device *dev)
 
 		if (devm_init_badblocks(dev, &nd_region->bb))
 			return -ENODEV;
-		nd_region->bb_state = sysfs_get_dirent(nd_region->dev.kobj.sd,
-						       "badblocks");
+		nd_region->bb_state =
+			sysfs_get_dirent(nd_region->dev.kobj.sd, "badblocks");
 		if (!nd_region->bb_state)
 			dev_warn(&nd_region->dev,
 				 "'badblocks' notification disabled\n");
@@ -75,8 +77,8 @@ static int nd_region_probe(struct device *dev)
 	 * <regionX>/namespaces returns the current
 	 * "<async-registered>/<total>" namespace count.
 	 */
-	dev_err(dev, "failed to register %d namespace%s, continuing...\n",
-		err, err == 1 ? "" : "s");
+	dev_err(dev, "failed to register %d namespace%s, continuing...\n", err,
+		err == 1 ? "" : "s");
 	return 0;
 }
 
@@ -125,10 +127,10 @@ static void nd_region_notify(struct device *dev, enum nvdimm_event event)
 
 		if (is_nd_pmem(&nd_region->dev)) {
 			res.start = nd_region->ndr_start;
-			res.end = nd_region->ndr_start +
-				nd_region->ndr_size - 1;
-			nvdimm_badblocks_populate(nd_region,
-						  &nd_region->bb, &res);
+			res.end =
+				nd_region->ndr_start + nd_region->ndr_size - 1;
+			nvdimm_badblocks_populate(nd_region, &nd_region->bb,
+						  &res);
 			if (nd_region->bb_state)
 				sysfs_notify_dirent(nd_region->bb_state);
 		}
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index 6ed918e30cf9..0fb913c7a2c3 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -2,7 +2,6 @@
 /*
  * Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
  */
-
 #include <linux/scatterlist.h>
 #include <linux/highmem.h>
 #include <linux/sched.h>
@@ -45,8 +44,12 @@ static int nvdimm_map_flush(struct device *dev, struct nvdimm *nvdimm, int dimm,
 		}
 
 		if (j < i)
-			flush_page = (void __iomem *)
-				((unsigned long)ndrd_get_flush_wpq(ndrd, dimm, j) & PAGE_MASK);
+			flush_page =
+				(void __iomem *)((unsigned long)
+							 ndrd_get_flush_wpq(
+								 ndrd, dimm,
+								 j) &
+						 PAGE_MASK);
 		else
 			flush_page = devm_nvdimm_ioremap(dev, PFN_PHYS(pfn),
 							 PAGE_SIZE);
@@ -246,8 +249,8 @@ int nd_region_to_nstype(struct nd_region *nd_region)
 }
 EXPORT_SYMBOL(nd_region_to_nstype);
 
-static ssize_t size_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
+static ssize_t size_show(struct device *dev, struct device_attribute *attr,
+			 char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev);
 	unsigned long long size = 0;
@@ -277,8 +280,8 @@ static ssize_t deep_flush_show(struct device *dev,
 }
 
 static ssize_t deep_flush_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t len)
+				struct device_attribute *attr, const char *buf,
+				size_t len)
 {
 	bool flush;
 	int rc = strtobool(buf, &flush);
@@ -296,8 +299,8 @@ static ssize_t deep_flush_store(struct device *dev,
 }
 static DEVICE_ATTR_RW(deep_flush);
 
-static ssize_t mappings_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t mappings_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev);
 
@@ -305,8 +308,8 @@ static ssize_t mappings_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(mappings);
 
-static ssize_t nstype_show(struct device *dev,
-			   struct device_attribute *attr, char *buf)
+static ssize_t nstype_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev);
 
@@ -321,7 +324,9 @@ static ssize_t set_cookie_show(struct device *dev,
 	struct nd_interleave_set *nd_set = nd_region->nd_set;
 	ssize_t rc = 0;
 
-	if (!(is_memory(dev) && nd_set))
+	if (is_memory(dev) && nd_set)
+		/* pass, should be precluded by region_visible */;
+	else
 		return -ENXIO;
 
 	/*
@@ -374,15 +379,14 @@ resource_size_t nd_region_available_dpa(struct nd_region *nd_region)
 			return 0;
 
 		if (is_memory(&nd_region->dev)) {
-			available += nd_pmem_available_dpa(nd_region,
-							   nd_mapping, &overlap);
+			available += nd_pmem_available_dpa(
+				nd_region, nd_mapping, &overlap);
 			if (overlap > blk_max_overlap) {
 				blk_max_overlap = overlap;
 				goto retry;
 			}
-		} else if (is_nd_blk(&nd_region->dev)) {
+		} else if (is_nd_blk(&nd_region->dev))
 			available += nd_blk_available_dpa(nd_region);
-		}
 	}
 
 	return available;
@@ -486,8 +490,8 @@ static ssize_t namespace_seed_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(namespace_seed);
 
-static ssize_t btt_seed_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t btt_seed_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev);
 	ssize_t rc;
@@ -503,8 +507,8 @@ static ssize_t btt_seed_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(btt_seed);
 
-static ssize_t pfn_seed_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t pfn_seed_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev);
 	ssize_t rc;
@@ -520,8 +524,8 @@ static ssize_t pfn_seed_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(pfn_seed);
 
-static ssize_t dax_seed_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t dax_seed_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev);
 	ssize_t rc;
@@ -537,8 +541,8 @@ static ssize_t dax_seed_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(dax_seed);
 
-static ssize_t read_only_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
+static ssize_t read_only_show(struct device *dev, struct device_attribute *attr,
+			      char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev);
 
@@ -546,8 +550,8 @@ static ssize_t read_only_show(struct device *dev,
 }
 
 static ssize_t read_only_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t len)
+			       struct device_attribute *attr, const char *buf,
+			       size_t len)
 {
 	bool ro;
 	int rc = strtobool(buf, &ro);
@@ -578,8 +582,8 @@ static ssize_t region_badblocks_show(struct device *dev,
 }
 static DEVICE_ATTR(badblocks, 0444, region_badblocks_show, NULL);
 
-static ssize_t resource_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
+static ssize_t resource_show(struct device *dev, struct device_attribute *attr,
+			     char *buf)
 {
 	struct nd_region *nd_region = to_nd_region(dev);
 
@@ -656,8 +660,8 @@ static umode_t region_visible(struct kobject *kobj, struct attribute *a, int n)
 	}
 
 	if (a == &dev_attr_persistence_domain.attr) {
-		if ((nd_region->flags & (BIT(ND_REGION_PERSIST_CACHE)
-					 | BIT(ND_REGION_PERSIST_MEMCTRL))) == 0)
+		if ((nd_region->flags & (BIT(ND_REGION_PERSIST_CACHE) |
+					 BIT(ND_REGION_PERSIST_MEMCTRL))) == 0)
 			return 0;
 		return a->mode;
 	}
@@ -690,8 +694,7 @@ u64 nd_region_interleave_set_cookie(struct nd_region *nd_region,
 	if (!nd_set)
 		return 0;
 
-	if (nsindex &&
-	    __le16_to_cpu(nsindex->major) == 1 &&
+	if (nsindex && __le16_to_cpu(nsindex->major) == 1 &&
 	    __le16_to_cpu(nsindex->minor) == 1)
 		return nd_set->cookie1;
 	return nd_set->cookie2;
@@ -711,7 +714,7 @@ void nd_mapping_free_labels(struct nd_mapping *nd_mapping)
 	struct nd_label_ent *label_ent, *e;
 
 	lockdep_assert_held(&nd_mapping->lock);
-	list_for_each_entry_safe(label_ent, e, &nd_mapping->labels, list) {
+	list_for_each_entry_safe (label_ent, e, &nd_mapping->labels, list) {
 		list_del(&label_ent->list);
 		kfree(label_ent);
 	}
@@ -815,14 +818,13 @@ static ssize_t mappingN(struct device *dev, char *buf, int n)
 		       nd_mapping->position);
 }
 
-#define REGION_MAPPING(idx)						\
-static ssize_t mapping##idx##_show(struct device *dev,			\
-				   struct device_attribute *attr,	\
-				   char *buf)				\
-{									\
-	return mappingN(dev, buf, idx);					\
-}									\
-static DEVICE_ATTR_RO(mapping##idx)
+#define REGION_MAPPING(idx)                                                    \
+	static ssize_t mapping##idx##_show(                                    \
+		struct device *dev, struct device_attribute *attr, char *buf)  \
+	{                                                                      \
+		return mappingN(dev, buf, idx);                                \
+	}                                                                      \
+	static DEVICE_ATTR_RO(mapping##idx)
 
 /*
  * 32 should be enough for a while, even in the presence of socket
@@ -959,9 +961,8 @@ unsigned int nd_region_acquire_lane(struct nd_region *nd_region)
 		ndl_lock = per_cpu_ptr(nd_region->lane, lane);
 		if (ndl_count->count++ == 0)
 			spin_lock(&ndl_lock->lock);
-	} else {
+	} else
 		lane = cpu;
-	}
 
 	return lane;
 }
@@ -984,7 +985,8 @@ void nd_region_release_lane(struct nd_region *nd_region, unsigned int lane)
 EXPORT_SYMBOL(nd_region_release_lane);
 
 static struct nd_region *nd_region_create(struct nvdimm_bus *nvdimm_bus,
-					  struct nd_region_desc *ndr_desc, struct device_type *dev_type,
+					  struct nd_region_desc *ndr_desc,
+					  struct device_type *dev_type,
 					  const char *caller)
 {
 	struct nd_region *nd_region;
@@ -998,8 +1000,9 @@ static struct nd_region *nd_region_create(struct nvdimm_bus *nvdimm_bus,
 		struct nvdimm *nvdimm = mapping->nvdimm;
 
 		if ((mapping->start | mapping->size) % SZ_4K) {
-			dev_err(&nvdimm_bus->dev, "%s: %s mapping%d is not 4K aligned\n",
-				caller, dev_name(&nvdimm->dev), i);
+			dev_err(&nvdimm_bus->dev,
+				"%s: %s mapping%d is not 4K aligned\n", caller,
+				dev_name(&nvdimm->dev), i);
 
 			return NULL;
 		}
@@ -1009,8 +1012,9 @@ static struct nd_region *nd_region_create(struct nvdimm_bus *nvdimm_bus,
 
 		if (test_bit(NDD_NOBLK, &nvdimm->flags) &&
 		    dev_type == &nd_blk_device_type) {
-			dev_err(&nvdimm_bus->dev, "%s: %s mapping%d is not BLK capable\n",
-				caller, dev_name(&nvdimm->dev), i);
+			dev_err(&nvdimm_bus->dev,
+				"%s: %s mapping%d is not BLK capable\n", caller,
+				dev_name(&nvdimm->dev), i);
 			return NULL;
 		}
 	}
@@ -1020,8 +1024,8 @@ static struct nd_region *nd_region_create(struct nvdimm_bus *nvdimm_bus,
 		struct nd_blk_region *ndbr;
 
 		ndbr_desc = to_blk_region_desc(ndr_desc);
-		ndbr = kzalloc(sizeof(*ndbr) + sizeof(struct nd_mapping)
-			       * ndr_desc->num_mappings,
+		ndbr = kzalloc(sizeof(*ndbr) + sizeof(struct nd_mapping) *
+						       ndr_desc->num_mappings,
 			       GFP_KERNEL);
 		if (ndbr) {
 			nd_region = &ndbr->nd_region;
@@ -1136,16 +1140,15 @@ int nvdimm_flush(struct nd_region *nd_region, struct bio *bio)
 {
 	int rc = 0;
 
-	if (!nd_region->flush) {
+	if (!nd_region->flush)
 		rc = generic_nvdimm_flush(nd_region);
-	} else {
+	else {
 		if (nd_region->flush(nd_region, bio))
 			rc = -EIO;
 	}
 
 	return rc;
 }
-
 /**
  * nvdimm_flush - flush any posted write queues between the cpu and pmem media
  * @nd_region: blk or interleaved pmem region
@@ -1216,14 +1219,14 @@ EXPORT_SYMBOL_GPL(nvdimm_has_flush);
 int nvdimm_has_cache(struct nd_region *nd_region)
 {
 	return is_nd_pmem(&nd_region->dev) &&
-		!test_bit(ND_REGION_PERSIST_CACHE, &nd_region->flags);
+	       !test_bit(ND_REGION_PERSIST_CACHE, &nd_region->flags);
 }
 EXPORT_SYMBOL_GPL(nvdimm_has_cache);
 
 bool is_nvdimm_sync(struct nd_region *nd_region)
 {
 	return is_nd_pmem(&nd_region->dev) &&
-		!test_bit(ND_REGION_ASYNC, &nd_region->flags);
+	       !test_bit(ND_REGION_ASYNC, &nd_region->flags);
 }
 EXPORT_SYMBOL_GPL(is_nvdimm_sync);
 
diff --git a/drivers/nvdimm/security.c b/drivers/nvdimm/security.c
index cb14c05f127e..4e600b190272 100644
--- a/drivers/nvdimm/security.c
+++ b/drivers/nvdimm/security.c
@@ -15,8 +15,8 @@
 #include "nd-core.h"
 #include "nd.h"
 
-#define NVDIMM_BASE_KEY		0
-#define NVDIMM_NEW_KEY		1
+#define NVDIMM_BASE_KEY 0
+#define NVDIMM_NEW_KEY 1
 
 static bool key_revalidate = true;
 module_param(key_revalidate, bool, 0444);
@@ -173,9 +173,7 @@ static int __nvdimm_security_unlock(struct nvdimm *nvdimm)
 	/* The bus lock should be held at the top level of the call stack */
 	lockdep_assert_held(&nvdimm_bus->reconfig_mutex);
 
-	if (!nvdimm->sec.ops ||
-	    !nvdimm->sec.ops->unlock ||
-	    !nvdimm->sec.flags)
+	if (!nvdimm->sec.ops || !nvdimm->sec.ops->unlock || !nvdimm->sec.flags)
 		return -EIO;
 
 	if (test_bit(NDD_SECURITY_OVERWRITE, &nvdimm->flags)) {
@@ -195,9 +193,8 @@ static int __nvdimm_security_unlock(struct nvdimm *nvdimm)
 			return 0;
 
 		return nvdimm_key_revalidate(nvdimm);
-	}
-
-	data = nvdimm_get_key_payload(nvdimm, &key);
+	} else
+		data = nvdimm_get_key_payload(nvdimm, &key);
 
 	rc = nvdimm->sec.ops->unlock(nvdimm, data);
 	dev_dbg(dev, "key: %d unlock: %s\n", key_serial(key),
@@ -230,7 +227,7 @@ static int check_security_state(struct nvdimm *nvdimm)
 	}
 
 	if (test_bit(NDD_SECURITY_OVERWRITE, &nvdimm->flags)) {
-		dev_dbg(dev, "Security operation in progress\n");
+		dev_dbg(dev, "Security operation in progress.\n");
 		return -EBUSY;
 	}
 
@@ -248,23 +245,21 @@ static int security_disable(struct nvdimm *nvdimm, unsigned int keyid)
 	/* The bus lock should be held at the top level of the call stack */
 	lockdep_assert_held(&nvdimm_bus->reconfig_mutex);
 
-	if (!nvdimm->sec.ops ||
-	    !nvdimm->sec.ops->disable ||
-	    !nvdimm->sec.flags)
+	if (!nvdimm->sec.ops || !nvdimm->sec.ops->disable || !nvdimm->sec.flags)
 		return -EOPNOTSUPP;
 
 	rc = check_security_state(nvdimm);
 	if (rc)
 		return rc;
 
-	data = nvdimm_get_user_key_payload(nvdimm, keyid,
-					   NVDIMM_BASE_KEY, &key);
+	data = nvdimm_get_user_key_payload(nvdimm, keyid, NVDIMM_BASE_KEY,
+					   &key);
 	if (!data)
 		return -ENOKEY;
 
 	rc = nvdimm->sec.ops->disable(nvdimm, data);
-	dev_dbg(dev, "key: %d disable: %s\n",
-		key_serial(key), rc == 0 ? "success" : "fail");
+	dev_dbg(dev, "key: %d disable: %s\n", key_serial(key),
+		rc == 0 ? "success" : "fail");
 
 	nvdimm_put_key(key);
 	nvdimm->sec.flags = nvdimm_security_flags(nvdimm, NVDIMM_USER);
@@ -284,8 +279,7 @@ static int security_update(struct nvdimm *nvdimm, unsigned int keyid,
 	/* The bus lock should be held at the top level of the call stack */
 	lockdep_assert_held(&nvdimm_bus->reconfig_mutex);
 
-	if (!nvdimm->sec.ops ||
-	    !nvdimm->sec.ops->change_key ||
+	if (!nvdimm->sec.ops || !nvdimm->sec.ops->change_key ||
 	    !nvdimm->sec.flags)
 		return -EOPNOTSUPP;
 
@@ -293,29 +287,29 @@ static int security_update(struct nvdimm *nvdimm, unsigned int keyid,
 	if (rc)
 		return rc;
 
-	data = nvdimm_get_user_key_payload(nvdimm, keyid,
-					   NVDIMM_BASE_KEY, &key);
+	data = nvdimm_get_user_key_payload(nvdimm, keyid, NVDIMM_BASE_KEY,
+					   &key);
 	if (!data)
 		return -ENOKEY;
 
-	newdata = nvdimm_get_user_key_payload(nvdimm, new_keyid,
-					      NVDIMM_NEW_KEY, &newkey);
+	newdata = nvdimm_get_user_key_payload(nvdimm, new_keyid, NVDIMM_NEW_KEY,
+					      &newkey);
 	if (!newdata) {
 		nvdimm_put_key(key);
 		return -ENOKEY;
 	}
 
 	rc = nvdimm->sec.ops->change_key(nvdimm, data, newdata, pass_type);
-	dev_dbg(dev, "key: %d %d update%s: %s\n",
-		key_serial(key), key_serial(newkey),
+	dev_dbg(dev, "key: %d %d update%s: %s\n", key_serial(key),
+		key_serial(newkey),
 		pass_type == NVDIMM_MASTER ? "(master)" : "(user)",
 		rc == 0 ? "success" : "fail");
 
 	nvdimm_put_key(newkey);
 	nvdimm_put_key(key);
 	if (pass_type == NVDIMM_MASTER)
-		nvdimm->sec.ext_flags = nvdimm_security_flags(nvdimm,
-							      NVDIMM_MASTER);
+		nvdimm->sec.ext_flags =
+			nvdimm_security_flags(nvdimm, NVDIMM_MASTER);
 	else
 		nvdimm->sec.flags = nvdimm_security_flags(nvdimm, NVDIMM_USER);
 	return rc;
@@ -333,9 +327,7 @@ static int security_erase(struct nvdimm *nvdimm, unsigned int keyid,
 	/* The bus lock should be held at the top level of the call stack */
 	lockdep_assert_held(&nvdimm_bus->reconfig_mutex);
 
-	if (!nvdimm->sec.ops ||
-	    !nvdimm->sec.ops->erase ||
-	    !nvdimm->sec.flags)
+	if (!nvdimm->sec.ops || !nvdimm->sec.ops->erase || !nvdimm->sec.flags)
 		return -EOPNOTSUPP;
 
 	rc = check_security_state(nvdimm);
@@ -344,18 +336,18 @@ static int security_erase(struct nvdimm *nvdimm, unsigned int keyid,
 
 	if (!test_bit(NVDIMM_SECURITY_UNLOCKED, &nvdimm->sec.ext_flags) &&
 	    pass_type == NVDIMM_MASTER) {
-		dev_dbg(dev, "Attempt to secure erase in wrong master state\n");
+		dev_dbg(dev,
+			"Attempt to secure erase in wrong master state.\n");
 		return -EOPNOTSUPP;
 	}
 
-	data = nvdimm_get_user_key_payload(nvdimm, keyid,
-					   NVDIMM_BASE_KEY, &key);
+	data = nvdimm_get_user_key_payload(nvdimm, keyid, NVDIMM_BASE_KEY,
+					   &key);
 	if (!data)
 		return -ENOKEY;
 
 	rc = nvdimm->sec.ops->erase(nvdimm, data, pass_type);
-	dev_dbg(dev, "key: %d erase%s: %s\n",
-		key_serial(key),
+	dev_dbg(dev, "key: %d erase%s: %s\n", key_serial(key),
 		pass_type == NVDIMM_MASTER ? "(master)" : "(user)",
 		rc == 0 ? "success" : "fail");
 
@@ -375,13 +367,12 @@ static int security_overwrite(struct nvdimm *nvdimm, unsigned int keyid)
 	/* The bus lock should be held at the top level of the call stack */
 	lockdep_assert_held(&nvdimm_bus->reconfig_mutex);
 
-	if (!nvdimm->sec.ops ||
-	    !nvdimm->sec.ops->overwrite ||
+	if (!nvdimm->sec.ops || !nvdimm->sec.ops->overwrite ||
 	    !nvdimm->sec.flags)
 		return -EOPNOTSUPP;
 
 	if (dev->driver == NULL) {
-		dev_dbg(dev, "Unable to overwrite while DIMM active\n");
+		dev_dbg(dev, "Unable to overwrite while DIMM active.\n");
 		return -EINVAL;
 	}
 
@@ -389,14 +380,14 @@ static int security_overwrite(struct nvdimm *nvdimm, unsigned int keyid)
 	if (rc)
 		return rc;
 
-	data = nvdimm_get_user_key_payload(nvdimm, keyid,
-					   NVDIMM_BASE_KEY, &key);
+	data = nvdimm_get_user_key_payload(nvdimm, keyid, NVDIMM_BASE_KEY,
+					   &key);
 	if (!data)
 		return -ENOKEY;
 
 	rc = nvdimm->sec.ops->overwrite(nvdimm, data);
-	dev_dbg(dev, "key: %d overwrite submission: %s\n",
-		key_serial(key), rc == 0 ? "success" : "fail");
+	dev_dbg(dev, "key: %d overwrite submission: %s\n", key_serial(key),
+		rc == 0 ? "success" : "fail");
 
 	nvdimm_put_key(key);
 	if (rc == 0) {
@@ -432,8 +423,7 @@ void __nvdimm_security_overwrite_query(struct nvdimm *nvdimm)
 
 	tmo = nvdimm->sec.overwrite_tmo;
 
-	if (!nvdimm->sec.ops ||
-	    !nvdimm->sec.ops->query_overwrite ||
+	if (!nvdimm->sec.ops || !nvdimm->sec.ops->query_overwrite ||
 	    !nvdimm->sec.flags)
 		return;
 
@@ -463,27 +453,27 @@ void __nvdimm_security_overwrite_query(struct nvdimm *nvdimm)
 
 void nvdimm_security_overwrite_query(struct work_struct *work)
 {
-	struct nvdimm *nvdimm =
-		container_of(work, typeof(*nvdimm), dwork.work);
+	struct nvdimm *nvdimm = container_of(work, typeof(*nvdimm), dwork.work);
 
 	nvdimm_bus_lock(&nvdimm->dev);
 	__nvdimm_security_overwrite_query(nvdimm);
 	nvdimm_bus_unlock(&nvdimm->dev);
 }
 
-#define OPS								\
-	C(OP_FREEZE,		"freeze",		1),		\
-	C(OP_DISABLE,		"disable",		2),		\
-	C(OP_UPDATE,		"update",		3),		\
-	C(OP_ERASE,		"erase",		2),		\
-	C(OP_OVERWRITE,		"overwrite",		2),		\
-	C(OP_MASTER_UPDATE,	"master_update",	3),		\
-	C(OP_MASTER_ERASE,	"master_erase",		2)
+#define OPS                                                                    \
+	C(OP_FREEZE, "freeze", 1), C(OP_DISABLE, "disable", 2),                \
+		C(OP_UPDATE, "update", 3), C(OP_ERASE, "erase", 2),            \
+		C(OP_OVERWRITE, "overwrite", 2),                               \
+		C(OP_MASTER_UPDATE, "master_update", 3),                       \
+		C(OP_MASTER_ERASE, "master_erase", 2)
 #undef C
 #define C(a, b, c) a
 enum nvdimmsec_op_ids { OPS };
 #undef C
-#define C(a, b, c) { b, c }
+#define C(a, b, c)                                                             \
+	{                                                                      \
+		b, c                                                           \
+	}
 static struct {
 	const char *name;
 	int args;
@@ -502,10 +492,15 @@ ssize_t nvdimm_security_store(struct device *dev, const char *buf, size_t len)
 	unsigned int key, newkey;
 	int i;
 
-	rc = sscanf(buf, "%"__stringify(SEC_CMD_SIZE)"s"
-		    " %"__stringify(KEY_ID_SIZE)"s"
-		    " %"__stringify(KEY_ID_SIZE)"s",
-		    cmd, keystr, nkeystr);
+	rc = sscanf(
+		buf,
+		"%" __stringify(
+			SEC_CMD_SIZE) "s"
+				      " %" __stringify(
+					      KEY_ID_SIZE) "s"
+							   " %" __stringify(
+								   KEY_ID_SIZE) "s",
+		cmd, keystr, nkeystr);
 	if (rc < 1)
 		return -EINVAL;
 	for (i = 0; i < ARRAY_SIZE(ops); i++)
@@ -528,26 +523,29 @@ ssize_t nvdimm_security_store(struct device *dev, const char *buf, size_t len)
 		rc = security_disable(nvdimm, key);
 	} else if (i == OP_UPDATE || i == OP_MASTER_UPDATE) {
 		dev_dbg(dev, "%s %u %u\n", ops[i].name, key, newkey);
-		rc = security_update(nvdimm, key, newkey, i == OP_UPDATE
-				     ? NVDIMM_USER : NVDIMM_MASTER);
+		rc = security_update(nvdimm, key, newkey,
+				     i == OP_UPDATE ? NVDIMM_USER :
+						      NVDIMM_MASTER);
 	} else if (i == OP_ERASE || i == OP_MASTER_ERASE) {
 		dev_dbg(dev, "%s %u\n", ops[i].name, key);
 		if (atomic_read(&nvdimm->busy)) {
-			dev_dbg(dev, "Unable to secure erase while DIMM active\n");
+			dev_dbg(dev,
+				"Unable to secure erase while DIMM active.\n");
 			return -EBUSY;
 		}
-		rc = security_erase(nvdimm, key, i == OP_ERASE
-				    ? NVDIMM_USER : NVDIMM_MASTER);
+		rc = security_erase(nvdimm, key,
+				    i == OP_ERASE ? NVDIMM_USER :
+						    NVDIMM_MASTER);
 	} else if (i == OP_OVERWRITE) {
 		dev_dbg(dev, "overwrite %u\n", key);
 		if (atomic_read(&nvdimm->busy)) {
-			dev_dbg(dev, "Unable to overwrite while DIMM active\n");
+			dev_dbg(dev,
+				"Unable to overwrite while DIMM active.\n");
 			return -EBUSY;
 		}
 		rc = security_overwrite(nvdimm, key);
-	} else {
+	} else
 		return -EINVAL;
-	}
 
 	if (rc == 0)
 		rc = len;
diff --git a/drivers/nvdimm/virtio_pmem.c b/drivers/nvdimm/virtio_pmem.c
index 087753ac81a0..3d0443d24eee 100644
--- a/drivers/nvdimm/virtio_pmem.c
+++ b/drivers/nvdimm/virtio_pmem.c
@@ -18,8 +18,7 @@ static struct virtio_device_id id_table[] = {
 static int init_vq(struct virtio_pmem *vpmem)
 {
 	/* single vq */
-	vpmem->req_vq = virtio_find_single_vq(vpmem->vdev,
-					      virtio_pmem_host_ack,
+	vpmem->req_vq = virtio_find_single_vq(vpmem->vdev, virtio_pmem_host_ack,
 					      "flush_queue");
 	if (IS_ERR(vpmem->req_vq))
 		return PTR_ERR(vpmem->req_vq);
@@ -59,20 +58,20 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
 		goto out_err;
 	}
 
-	virtio_cread(vpmem->vdev, struct virtio_pmem_config,
-		     start, &vpmem->start);
-	virtio_cread(vpmem->vdev, struct virtio_pmem_config,
-		     size, &vpmem->size);
+	virtio_cread(vpmem->vdev, struct virtio_pmem_config, start,
+		     &vpmem->start);
+	virtio_cread(vpmem->vdev, struct virtio_pmem_config, size,
+		     &vpmem->size);
 
 	res.start = vpmem->start;
-	res.end   = vpmem->start + vpmem->size - 1;
+	res.end = vpmem->start + vpmem->size - 1;
 	vpmem->nd_desc.provider_name = "virtio-pmem";
 	vpmem->nd_desc.module = THIS_MODULE;
 
-	vpmem->nvdimm_bus = nvdimm_bus_register(&vdev->dev,
-						&vpmem->nd_desc);
+	vpmem->nvdimm_bus = nvdimm_bus_register(&vdev->dev, &vpmem->nd_desc);
 	if (!vpmem->nvdimm_bus) {
-		dev_err(&vdev->dev, "failed to register device with nvdimm_bus\n");
+		dev_err(&vdev->dev,
+			"failed to register device with nvdimm_bus\n");
 		err = -ENXIO;
 		goto out_vq;
 	}
@@ -92,7 +91,6 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
 	}
 	nd_region->provider_data = dev_to_virtio(nd_region->dev.parent->parent);
 	return 0;
-
 out_nd:
 	nvdimm_bus_unregister(vpmem->nvdimm_bus);
 out_vq:
@@ -111,11 +109,11 @@ static void virtio_pmem_remove(struct virtio_device *vdev)
 }
 
 static struct virtio_driver virtio_pmem_driver = {
-	.driver.name		= KBUILD_MODNAME,
-	.driver.owner		= THIS_MODULE,
-	.id_table		= id_table,
-	.probe			= virtio_pmem_probe,
-	.remove			= virtio_pmem_remove,
+	.driver.name = KBUILD_MODNAME,
+	.driver.owner = THIS_MODULE,
+	.id_table = id_table,
+	.probe = virtio_pmem_probe,
+	.remove = virtio_pmem_remove,
 };
 
 module_virtio_driver(virtio_pmem_driver);

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply related	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-11 15:48 [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
                   ` (3 preceding siblings ...)
  2019-09-11 16:40 ` [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen
@ 2019-09-12 13:10 ` Bart Van Assche
  4 siblings, 0 replies; 53+ messages in thread
From: Bart Van Assche @ 2019-09-12 13:10 UTC (permalink / raw)
  To: Dan Williams, linux-kernel
  Cc: ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, Dmitry Vyukov,
	Mauro Carvalho Chehab, Steve French, Tobin C. Harding

On 9/11/19 4:48 PM, Dan Williams wrote:
> At last years Plumbers Conference I proposed the Maintainer Entry
> Profile as a document that a maintainer can provide to set contributor
> expectations and provide fodder for a discussion between maintainers
> about the merits of different maintainer policies.
> 
> For those that did not attend, the goal of the Maintainer Entry Profile,
> and the Maintainer Handbook more generally, is to provide a desk
> reference for maintainers both new and experienced. The session
> introduction was:
> 
>     The first rule of kernel maintenance is that there are no hard and
>     fast rules. That state of affairs is both a blessing and a curse. It
>     has served the community well to be adaptable to the different
>     people and different problem spaces that inhabit the kernel
>     community. However, that variability also leads to inconsistent
>     experiences for contributors, little to no guidance for new
>     contributors, and unnecessary stress on current maintainers. There
>     are quite a few of people who have been around long enough to make
>     enough mistakes that they have gained some hard earned proficiency.
>     However if the kernel community expects to keep growing it needs to
>     be able both scale the maintainers it has and ramp new ones without
>     necessarily let them make a decades worth of mistakes to learn the
>     ropes. 
> 
> To be clear, the proposed document does not impose or suggest new
> rules. Instead it provides an outlet to document the unwritten rules
> and policies in effect for each subsystem, and that each subsystem
> might decide differently for whatever reason.

Any maintainer who reads this might interpret this as an encouragement
to establish custom policies. I think one of the conclusions of the
Linux Plumbers 2019 edition is that too much diversity is bad and that
we need more uniformity across kernel subsystems with regard what is
expected from patch contributors. I would appreciate if a summary of
https://linuxplumbersconf.org/event/4/contributions/554/attachments/353/584/Reflections__Kernel_Summit_2019.pdf
would be integrated in the maintainer handbook.

Thanks,

Bart.

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-11 16:40 ` [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen
@ 2019-09-12 13:31   ` Bart Van Assche
  2019-09-12 15:34     ` Joe Perches
  2019-09-13 22:03     ` Martin K. Petersen
  0 siblings, 2 replies; 53+ messages in thread
From: Bart Van Assche @ 2019-09-12 13:31 UTC (permalink / raw)
  To: Martin K. Petersen, Dan Williams
  Cc: ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel,
	Dmitry Vyukov, Mauro Carvalho Chehab, Steve French,
	Tobin C. Harding

On 9/11/19 5:40 PM, Martin K. Petersen wrote:
> * Do not use custom To: and Cc: for individual patches. We want to see the
>   whole series, even patches that potentially need to go through a different
>   subsystem tree.

Hi Martin,

Thanks for having written this summary. This is very helpful. For the
above paragraph, should it be clarified whether that requirement applies
to mailing list e-mail addresses only or also to individual e-mail
addresses? When using git send-email it is easy to end up with different
cc-lists per patch.

> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__")
>   and does not incur any zeroday test robot complaints.

How about adding W=1 to that make command?

How about existing drivers that trigger tons of endianness warnings,
e.g. qla2xxx? How about requiring that no new warnings are introduced?

> * The patch must have a commit message that describes, comprehensively and in
>   plain English, what the patch does.

How about making this requirement more detailed and requiring that not
only what has been changed is document but also why that change has been
made?

> * Patches which have been obsoleted by a later version will be set to
>   "Superceded" status.

Did you perhaps mean "Superseded"?

Thanks,

Bart.

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-12 11:02             ` Joe Perches
@ 2019-09-12 14:17               ` Dan Williams
  2019-09-12 14:51                 ` Joe Perches
  0 siblings, 1 reply; 53+ messages in thread
From: Dan Williams @ 2019-09-12 14:17 UTC (permalink / raw)
  To: Joe Perches
  Cc: Miguel Ojeda, Linux Kernel Mailing List, Dan Carpenter, linux-nvdimm

On Thu, Sep 12, 2019 at 4:02 AM Joe Perches <joe@perches.com> wrote:
>
> (cut down the cc-list)
>
> On Thu, 2019-09-12 at 03:18 -0700, Joe Perches wrote:
> > On Thu, 2019-09-12 at 10:24 +0200, Miguel Ojeda wrote:
> > > On Thu, Sep 12, 2019 at 9:43 AM Dan Williams <dan.j.williams@intel.com> wrote:
> > > > Now I come to find that CodingStyle has settled on clang-format (in
> > > > the last 15 months) as the new standard which is a much better answer
> > > > to me than a manually specified style open to interpretation. I'll
> > > > take a look at getting libnvdimm converted over.
> > >
> > > Note that clang-format cannot do everything as we want within the
> > > kernel just yet, but it is a close enough approximation -- it is near
> > > the point where we could simply agree to use it and stop worrying
> > > about styling issues. However, that would mean everyone needs to have
> > > a recent clang-format available, which I think is the biggest obstacle
> > > at the moment.
> >
> > I don't think that's close to true yet for clang-format.
> >
> > For instance: clang-format does not do anything with
> > missing braces, or coalescing multi-part strings,
> > or any number of other nominal coding style defects
> > like all the for_each macros, aligning or not aligning
> > columnar contents appropriately, etc...
> >
> > clang-format as yet has no taste.

Ok, good to confirm that we do not yet have an objective standard for
coding style. This means it's not yet something process documentation
can better standardize for contributors and will be subject to ongoing
taste debates. Lets reclaim the time to talk about objective items
that *can* clarified across maintainers.

> >
> > I believe it'll take a lot of work to improve it to a point
> > where its formatting is acceptable and appropriate.
> .
>
> Just fyi:
>
> Here's the difference that clang-format produces from the current
> nvdimm sources to the patch series I posted.
>
> clang-format does some OK, some not OK, some really bad.
> (e.g.: __stringify)
>
> My git branch for my patches is 20190911_nvdimm, and
> using Stephen Rothwell's git tree for -next:
>
> $ git checkout next-20190904
> $ clang-format -i drivers/nvdimm/*.[ch]
> $ git diff --stat -p 20190911_nvdimm -- drivers/nvdimm/ > nvdimm.clang-diff
> ---
[..]
>  25 files changed, 895 insertions(+), 936 deletions(-)

So, I'm lamenting the damage either of these mass conversions is going
to do git blame flows. To be honest I regret broaching Coding Style
standardization because it's taking the air out of the room for the
wider discussion of the maintainer/contributor topics we might be able
to agree.

As for libnvdimm at this point I'd rather start with objective
checkpatch error cleanups and defer the personal taste items.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-12 10:18           ` Joe Perches
  2019-09-12 11:02             ` Joe Perches
@ 2019-09-12 14:42             ` Miguel Ojeda
  1 sibling, 0 replies; 53+ messages in thread
From: Miguel Ojeda @ 2019-09-12 14:42 UTC (permalink / raw)
  To: Joe Perches
  Cc: Jens Axboe, ksummit, linux-nvdimm, Linux Kernel Mailing List,
	bpf, Dan Carpenter

On Thu, Sep 12, 2019 at 12:18 PM Joe Perches <joe@perches.com> wrote:
>
> I don't think that's close to true yet for clang-format.

I don't expect clang-format to match perfectly our current code style.

However, if core maintainers agree that it is "close enough now"
(specially with newer LLVMs, like 9), then there is a great benefit on
moving to automatically-styled code. The "con" is having to change a
bit our style wherever clang-format does not support exactly our
current style.

> For instance: clang-format does not do anything with
> missing braces, or coalescing multi-part strings,
> or any number of other nominal coding style defects
> like all the for_each macros, aligning or not aligning
> columnar contents appropriately, etc...

Some of these may or may not be fixable tweaking the options. Note
that there are conflicting styles within the kernel at the moment,
e.g. how to indent arguments to function calls. Therefore, some of the
differences do not apply as soon as we decide on a given style.

Furthermore, with automatic formatting we have also the chance to
review some options that we couldn't easily change before.

> clang-format as yet has no taste.
>
> I believe it'll take a lot of work to improve it to a point
> where its formatting is acceptable and appropriate.
>
> An AI rather than a table based system like clang-format is
> more likely to be a real solution, but training that AI
> isn't a thing that I want to do.

I don't think we need taste (or AI-like solutions), because
consistency has a lot of value too. Not just for our brains, but for
patches as well.

Note that clang-format is a tool used by major projects successfully,
it is not like we are experimenting too much here :-)

Cheers,
Miguel
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-12 14:17               ` Dan Williams
@ 2019-09-12 14:51                 ` Joe Perches
  0 siblings, 0 replies; 53+ messages in thread
From: Joe Perches @ 2019-09-12 14:51 UTC (permalink / raw)
  To: Dan Williams
  Cc: Miguel Ojeda, Linux Kernel Mailing List, Dan Carpenter, linux-nvdimm

On Thu, 2019-09-12 at 07:17 -0700, Dan Williams wrote:

> Ok, good to confirm that we do not yet have an objective standard for
> coding style. This means it's not yet something process documentation
> can better standardize for contributors and will be subject to ongoing
> taste debates. Lets reclaim the time to talk about objective items
> that *can* clarified across maintainers.

No, let's not and just clarify whether or not whitespace
style patches are acceptable patch submissions.

Coding style fragmentation is not otherwise acceptable to me.

nvdimm mandating 2 tab indentation when nvdimm itself is not
at all consistent in that regard is also whitespace noise.

> As for libnvdimm at this point I'd rather start with objective
> checkpatch error cleanups and defer the personal taste items.

Fine by me.

I do want to avoid documenting per-subsystem coding styles.

How about adding something to MAINTAINERS like:

A:	Accepting patches by newbies or CodingStyle strict

and checkpatch could be changed turn off a bunch of
whitespace rules on a subsystem basis when run with
-f for files or without -f for a patch.

Most of this comes down to whitespace like

	a = b + c

where it hardly matters if the CodingStyle mandated
space around + is used or

	foo = bar(baz,
			qux)

where qux position is not really important.


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-12 13:31   ` [Ksummit-discuss] " Bart Van Assche
@ 2019-09-12 15:34     ` Joe Perches
  2019-09-12 20:01       ` Bart Van Assche
  2019-09-13 22:03     ` Martin K. Petersen
  1 sibling, 1 reply; 53+ messages in thread
From: Joe Perches @ 2019-09-12 15:34 UTC (permalink / raw)
  To: Bart Van Assche, Martin K. Petersen, Dan Williams
  Cc: ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel,
	Steve French, Mauro Carvalho Chehab, Dmitry Vyukov,
	Tobin C. Harding

On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:
> On 9/11/19 5:40 PM, Martin K. Petersen wrote:
> > * Do not use custom To: and Cc: for individual patches. We want to see the
> >   whole series, even patches that potentially need to go through a different
> >   subsystem tree.

That's not currently feasible when cc'ing any vger.kernel.org list
as those lists have a maximum email header size and patches that
span multiple subsystems can have very long to: and cc: lists.

> > * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__")
> >   and does not incur any zeroday test robot complaints.
> 
> How about adding W=1 to that make command?

That's rather too compiler version dependent and new
warnings frequently get introduced by new compiler versions.

> How about existing drivers that trigger tons of endianness warnings,
> e.g. qla2xxx? How about requiring that no new warnings are introduced?

Adding a sparse clean C=2 requirement might be useful.

> > * The patch must have a commit message that describes, comprehensively and in
> >   plain English, what the patch does.
> 
> How about making this requirement more detailed and requiring that not
> only what has been changed is document but also why that change has been
> made?

I believe the "why" is rather more important than the "how"
and should be the primary thing described in the commit message.


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-12 15:34     ` Joe Perches
@ 2019-09-12 20:01       ` Bart Van Assche
  2019-09-12 20:34         ` Joe Perches
  2019-09-13 12:56         ` Matthew Wilcox
  0 siblings, 2 replies; 53+ messages in thread
From: Bart Van Assche @ 2019-09-12 20:01 UTC (permalink / raw)
  To: Joe Perches, Martin K. Petersen, Dan Williams
  Cc: ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel,
	Steve French, Mauro Carvalho Chehab, Dmitry Vyukov,
	Tobin C. Harding

On 9/12/19 8:34 AM, Joe Perches wrote:
> On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:
>> On 9/11/19 5:40 PM, Martin K. Petersen wrote:
>>> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__")
>>>   and does not incur any zeroday test robot complaints.
>>
>> How about adding W=1 to that make command?
> 
> That's rather too compiler version dependent and new
> warnings frequently get introduced by new compiler versions.

I've never observed this myself. If a new compiler warning is added to
gcc and if it produces warnings that are not useful for kernel code
usually Linus or someone else is quick to suppress that warning.

Another argument in favor of W=1 is that the formatting of kernel-doc
headers is checked only if W=1 is passed to make.

Bart.

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-12 20:01       ` Bart Van Assche
@ 2019-09-12 20:34         ` Joe Perches
  2019-09-13 14:26           ` Rob Herring
  2019-09-13 12:56         ` Matthew Wilcox
  1 sibling, 1 reply; 53+ messages in thread
From: Joe Perches @ 2019-09-12 20:34 UTC (permalink / raw)
  To: Bart Van Assche, Martin K. Petersen, Dan Williams
  Cc: ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel,
	Steve French, Mauro Carvalho Chehab, Dmitry Vyukov,
	Tobin C. Harding

On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote:

> Another argument in favor of W=1 is that the formatting of kernel-doc
> headers is checked only if W=1 is passed to make.

Actually, but for the fact there are far too many
to generally enable that warning right now,
(an x86-64 defconfig has more than 1000)
that sounds pretty reasonable to me.



_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 18:43   ` [Ksummit-discuss] " Dan Carpenter
  2019-09-11 22:11     ` Jens Axboe
@ 2019-09-13  2:11     ` Aneesh Kumar K.V
  2019-09-13  5:00       ` Greg KH
  1 sibling, 1 reply; 53+ messages in thread
From: Aneesh Kumar K.V @ 2019-09-13  2:11 UTC (permalink / raw)
  To: Dan Carpenter, Dan Williams; +Cc: bpf, linux-kernel, linux-nvdimm

On 9/12/19 12:13 AM, Dan Carpenter wrote:
> On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
>> +Coding Style Addendum
>> +---------------------
>> +libnvdimm expects multi-line statements to be double indented. I.e.
>> +
>> +        if (x...
>> +                        && ...y) {
> 
> That looks horrible and it causes a checkpatch warning.  :(  Why not
> do it the same way that everyone else does it.
> 
> 	if (blah_blah_x && <-- && has to be on the first line for checkpatch
> 	    blah_blah_y) { <-- [tab][space][space][space][space]blah
> 
> Now all the conditions are aligned visually which makes it readable.
> They aren't aligned with the indent block so it's easy to tell the
> inside from the if condition.


I came across this while sending patches to libnvdimm subsystem. W.r.t 
coding Style can we have consistent styles across the kernel? Otherwise, 
one would have to change the editor settings as they work across 
different subsystems in the kernel. In this specific case both 
clang-format and emacs customization tip in the kernel documentation 
directory suggest the later style.

-aneesh


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13  2:11     ` Aneesh Kumar K.V
@ 2019-09-13  5:00       ` Greg KH
  0 siblings, 0 replies; 53+ messages in thread
From: Greg KH @ 2019-09-13  5:00 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: linux-nvdimm, linux-kernel, bpf, Dan Carpenter

On Fri, Sep 13, 2019 at 07:41:55AM +0530, Aneesh Kumar K.V wrote:
> On 9/12/19 12:13 AM, Dan Carpenter wrote:
> > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
> > > +Coding Style Addendum
> > > +---------------------
> > > +libnvdimm expects multi-line statements to be double indented. I.e.
> > > +
> > > +        if (x...
> > > +                        && ...y) {
> > 
> > That looks horrible and it causes a checkpatch warning.  :(  Why not
> > do it the same way that everyone else does it.
> > 
> > 	if (blah_blah_x && <-- && has to be on the first line for checkpatch
> > 	    blah_blah_y) { <-- [tab][space][space][space][space]blah
> > 
> > Now all the conditions are aligned visually which makes it readable.
> > They aren't aligned with the indent block so it's easy to tell the
> > inside from the if condition.
> 
> 
> I came across this while sending patches to libnvdimm subsystem. W.r.t
> coding Style can we have consistent styles across the kernel? Otherwise, one
> would have to change the editor settings as they work across different
> subsystems in the kernel. In this specific case both clang-format and emacs
> customization tip in the kernel documentation directory suggest the later
> style.

We _should_ have a consistent coding style across the whole kernel,
that's the whole reason for having a coding style in the first place!

The problem is, we all have agreed on the "basics" a long time ago, but
are now down in the tiny nits as to what some minor things should, or
should not, look like.

It might be time to just bite the bullet and do something like
"clang-format" to stop arguing about stuff like this for new
submissions, if for no other reason to keep us from wasting mental
energy on trivial things like this.

thanks,

greg k-h
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 22:11     ` Jens Axboe
  2019-09-12  7:41       ` Dan Williams
@ 2019-09-13  7:09       ` Jonathan Corbet
  2019-09-13 11:48         ` Dan Carpenter
  2019-09-13 21:44       ` Martin K. Petersen
  2 siblings, 1 reply; 53+ messages in thread
From: Jonathan Corbet @ 2019-09-13  7:09 UTC (permalink / raw)
  To: Jens Axboe
  Cc: ksummit-discuss, linux-nvdimm, linux-kernel, bpf, Dan Carpenter

On Wed, 11 Sep 2019 16:11:29 -0600
Jens Axboe <axboe@kernel.dk> wrote:

> On 9/11/19 12:43 PM, Dan Carpenter wrote:
> > 
> > I kind of hate all this extra documentation because now everyone thinks
> > they can invent new hoops to jump through.  
> 
> FWIW, I completely agree with Dan (Carpenter) here. I absolutely
> dislike having these kinds of files, and with subsystems imposing weird
> restrictions on style (like the quoted example, yuck).
> 
> Additionally, it would seem saner to standardize rules around when
> code is expected to hit the maintainers hands for kernel releases. Both
> yours and Martins deals with that, there really shouldn't be the need
> to have this specified in detail per sub-system.

This sort of objection came up at the maintainers summit yesterday; the
consensus was that, while we might not like subsystem-specific rules, they
do currently exist and we're just documenting reality.  To paraphrase
Phillip K. Dick, reality is that which, when you refuse to document it,
doesn't go away.

So I'm expecting to take this kind of stuff into Documentation/.  My own
personal hope is that it can maybe serve to shame some of these "local
quirks" out of existence.  The evidence from this brief discussion suggests
that this might indeed happen.

Thanks,

jon
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13  7:09       ` Jonathan Corbet
@ 2019-09-13 11:48         ` Dan Carpenter
  2019-09-13 12:18           ` Dan Williams
                             ` (3 more replies)
  0 siblings, 4 replies; 53+ messages in thread
From: Dan Carpenter @ 2019-09-13 11:48 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Jens Axboe, ksummit-discuss, linux-nvdimm, linux-kernel, bpf

On Fri, Sep 13, 2019 at 01:09:37AM -0600, Jonathan Corbet wrote:
> On Wed, 11 Sep 2019 16:11:29 -0600
> Jens Axboe <axboe@kernel.dk> wrote:
> 
> > On 9/11/19 12:43 PM, Dan Carpenter wrote:
> > > 
> > > I kind of hate all this extra documentation because now everyone thinks
> > > they can invent new hoops to jump through.
> > 
> > FWIW, I completely agree with Dan (Carpenter) here. I absolutely
> > dislike having these kinds of files, and with subsystems imposing weird
> > restrictions on style (like the quoted example, yuck).
> > 
> > Additionally, it would seem saner to standardize rules around when
> > code is expected to hit the maintainers hands for kernel releases. Both
> > yours and Martins deals with that, there really shouldn't be the need
> > to have this specified in detail per sub-system.
> 
> This sort of objection came up at the maintainers summit yesterday; the
> consensus was that, while we might not like subsystem-specific rules, they
> do currently exist and we're just documenting reality.  To paraphrase
> Phillip K. Dick, reality is that which, when you refuse to document it,
> doesn't go away.

There aren't that many subsystem rules.  The big exception is
networking, with the comment style and reverse Chrismas tree
declarations.  Also you have to label which git tree the patch applies
to like [net] or [net-next].

It used to be that infiniband used "sizeof foo" instead of sizeof(foo)
but now there is a new maintainer.

There is one subsystem which where the maintainer will capitalize your
patch prefix and complain.  There are others where they will silently
change it to lower case.  (Maybe that has changed in recent years).

There is one subsystem where the maintainer is super strict rules that
you can't use "I" or "we" in the commit message.  So you can't say "I
noticed a bug while reviewing", you have to say "The code has a bug".

Some maintainers have rules about what you can put in the declaration
block.  No kmalloc() in the declarations is a common rule.
"struct foo *p = kmalloc();".

Some people (I do) have strict rules for error handling, but most won't
complain unless the error handling has bugs.

The bpf people want you to put [bpf] or [bpf-next] in the subject.
Everyone just guesses, and uneducated guesses are worse than leaving it
blank, but that's just my opinion.

> So I'm expecting to take this kind of stuff into Documentation/.  My own
> personal hope is that it can maybe serve to shame some of these "local
> quirks" out of existence.  The evidence from this brief discussion suggests
> that this might indeed happen.

I don't think it's shaming, I think it's validating.  Everyone just
insists that since it's written in the Book of Rules then it's our fault
for not reading it.  It's like those EULA things where there is more
text than anyone can physically read in a life time.

And the documentation doesn't help.  For example, I knew people's rules
about capitalizing the subject but I'd just forget.  I say that if you
can't be bothered to add it to checkpatch then it means you don't really
care that strongly.

regards,
dan carpenter
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13 11:48         ` Dan Carpenter
@ 2019-09-13 12:18           ` Dan Williams
  2019-09-13 15:00           ` Randy Dunlap
                             ` (2 subsequent siblings)
  3 siblings, 0 replies; 53+ messages in thread
From: Dan Williams @ 2019-09-13 12:18 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Jens Axboe, ksummit, linux-nvdimm, Jonathan Corbet,
	Linux Kernel Mailing List, bpf

On Fri, Sep 13, 2019 at 4:49 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Fri, Sep 13, 2019 at 01:09:37AM -0600, Jonathan Corbet wrote:
> > On Wed, 11 Sep 2019 16:11:29 -0600
> > Jens Axboe <axboe@kernel.dk> wrote:
> >
> > > On 9/11/19 12:43 PM, Dan Carpenter wrote:
> > > >
> > > > I kind of hate all this extra documentation because now everyone thinks
> > > > they can invent new hoops to jump through.
> > >
> > > FWIW, I completely agree with Dan (Carpenter) here. I absolutely
> > > dislike having these kinds of files, and with subsystems imposing weird
> > > restrictions on style (like the quoted example, yuck).
> > >
> > > Additionally, it would seem saner to standardize rules around when
> > > code is expected to hit the maintainers hands for kernel releases. Both
> > > yours and Martins deals with that, there really shouldn't be the need
> > > to have this specified in detail per sub-system.
> >
> > This sort of objection came up at the maintainers summit yesterday; the
> > consensus was that, while we might not like subsystem-specific rules, they
> > do currently exist and we're just documenting reality.  To paraphrase
> > Phillip K. Dick, reality is that which, when you refuse to document it,
> > doesn't go away.
>
> There aren't that many subsystem rules.  The big exception is
> networking, with the comment style and reverse Chrismas tree
> declarations.  Also you have to label which git tree the patch applies
> to like [net] or [net-next].
>
> It used to be that infiniband used "sizeof foo" instead of sizeof(foo)
> but now there is a new maintainer.
>
> There is one subsystem which where the maintainer will capitalize your
> patch prefix and complain.  There are others where they will silently
> change it to lower case.  (Maybe that has changed in recent years).
>
> There is one subsystem where the maintainer is super strict rules that
> you can't use "I" or "we" in the commit message.  So you can't say "I
> noticed a bug while reviewing", you have to say "The code has a bug".
>
> Some maintainers have rules about what you can put in the declaration
> block.  No kmalloc() in the declarations is a common rule.
> "struct foo *p = kmalloc();".
>
> Some people (I do) have strict rules for error handling, but most won't
> complain unless the error handling has bugs.
>
> The bpf people want you to put [bpf] or [bpf-next] in the subject.
> Everyone just guesses, and uneducated guesses are worse than leaving it
> blank, but that's just my opinion.
>
> > So I'm expecting to take this kind of stuff into Documentation/.  My own
> > personal hope is that it can maybe serve to shame some of these "local
> > quirks" out of existence.  The evidence from this brief discussion suggests
> > that this might indeed happen.
>
> I don't think it's shaming, I think it's validating.  Everyone just
> insists that since it's written in the Book of Rules then it's our fault
> for not reading it.  It's like those EULA things where there is more
> text than anyone can physically read in a life time.
>
> And the documentation doesn't help.  For example, I knew people's rules
> about capitalizing the subject but I'd just forget.  I say that if you
> can't be bothered to add it to checkpatch then it means you don't really
> care that strongly.

True, can someone with better perl skills than me take a shot at a
rule for checkpatch to catch the capitalization preference based on
the subsystem being touched, or otherwise agree that if a maintainer
has a changelog capitalization preference they just silently fix it up
at application time and not waste time pointing out something so
trivial? For example, I notice Linus likes "-" instead of "*" for
bullet lists in changelogs he just fixes it up silently if I forget.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-12 20:01       ` Bart Van Assche
  2019-09-12 20:34         ` Joe Perches
@ 2019-09-13 12:56         ` Matthew Wilcox
  2019-09-13 13:54           ` Mauro Carvalho Chehab
  1 sibling, 1 reply; 53+ messages in thread
From: Matthew Wilcox @ 2019-09-13 12:56 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel,
	Dmitry Vyukov, Joe Perches, Mauro Carvalho Chehab, Steve French,
	Tobin C. Harding

It's easy enough to move the kernel-doc warnings out from under W=1. I only
out them there to avoid overwhelming us with new warnings. If they're
mostly fixed now, let's make checking them the default.

On Thu., Sep. 12, 2019, 16:01 Bart Van Assche, <bvanassche@acm.org> wrote:

> On 9/12/19 8:34 AM, Joe Perches wrote:
> > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:
> >> On 9/11/19 5:40 PM, Martin K. Petersen wrote:
> >>> * The patch must compile without warnings (make C=1
> CF="-D__CHECK_ENDIAN__")
> >>>   and does not incur any zeroday test robot complaints.
> >>
> >> How about adding W=1 to that make command?
> >
> > That's rather too compiler version dependent and new
> > warnings frequently get introduced by new compiler versions.
>
> I've never observed this myself. If a new compiler warning is added to
> gcc and if it produces warnings that are not useful for kernel code
> usually Linus or someone else is quick to suppress that warning.
>
> Another argument in favor of W=1 is that the formatting of kernel-doc
> headers is checked only if W=1 is passed to make.
>
> Bart.
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-13 12:56         ` Matthew Wilcox
@ 2019-09-13 13:54           ` Mauro Carvalho Chehab
  2019-09-13 14:59             ` Guenter Roeck
  0 siblings, 1 reply; 53+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 13:54 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Bart Van Assche, ksummit-discuss, linux-nvdimm,
	Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov, Joe Perches,
	Steve French, Tobin C. Harding

Em Fri, 13 Sep 2019 08:56:30 -0400
Matthew Wilcox <willy6545@gmail.com> escreveu:

> It's easy enough to move the kernel-doc warnings out from under W=1. I only
> out them there to avoid overwhelming us with new warnings. If they're
> mostly fixed now, let's make checking them the default.

Didn't try doing it kernelwide, but for media we do use W=1 by default,
on our CI instance.

There's a few warnings at EDAC, but they all seem easy enough to be
fixed.

So, from my side, I'm all to make W=1 default.

Regards,
Mauro

> 
> On Thu., Sep. 12, 2019, 16:01 Bart Van Assche, <bvanassche@acm.org> wrote:
> 
> > On 9/12/19 8:34 AM, Joe Perches wrote:  
> > > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:  
> > >> On 9/11/19 5:40 PM, Martin K. Petersen wrote:  
> > >>> * The patch must compile without warnings (make C=1  
> > CF="-D__CHECK_ENDIAN__")  
> > >>>   and does not incur any zeroday test robot complaints.  
> > >>
> > >> How about adding W=1 to that make command?  
> > >
> > > That's rather too compiler version dependent and new
> > > warnings frequently get introduced by new compiler versions.  
> >
> > I've never observed this myself. If a new compiler warning is added to
> > gcc and if it produces warnings that are not useful for kernel code
> > usually Linus or someone else is quick to suppress that warning.
> >
> > Another argument in favor of W=1 is that the formatting of kernel-doc
> > headers is checked only if W=1 is passed to make.
> >
> > Bart.
> >
> > _______________________________________________
> > Ksummit-discuss mailing list
> > Ksummit-discuss@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> >  



Thanks,
Mauro
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-12 20:34         ` Joe Perches
@ 2019-09-13 14:26           ` Rob Herring
  2019-09-13 18:42             ` Joe Perches
  0 siblings, 1 reply; 53+ messages in thread
From: Rob Herring @ 2019-09-13 14:26 UTC (permalink / raw)
  To: Joe Perches
  Cc: Bart Van Assche, ksummit, linux-nvdimm, Greg Kroah-Hartman,
	linux-kernel, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French,
	Tobin C. Harding

On Fri, Sep 13, 2019 at 3:12 PM Joe Perches <joe@perches.com> wrote:
>
> On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote:
>
> > Another argument in favor of W=1 is that the formatting of kernel-doc
> > headers is checked only if W=1 is passed to make.
>
> Actually, but for the fact there are far too many
> to generally enable that warning right now,
> (an x86-64 defconfig has more than 1000)
> that sounds pretty reasonable to me.

It's in the 1000s on arm because W=1 turns on more checks in building
.dts files. There are lots of duplicates as most of the dts content is
as an include file (e.g. board dts includes soc dts).

We could shift the dts checks to W=2 (and what's enabled by W=2 now to
3) I guess.

Why not just promote what doesn't give false or still noisy warnings
out of W=1 to be the default?

Rob
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-13 13:54           ` Mauro Carvalho Chehab
@ 2019-09-13 14:59             ` Guenter Roeck
  0 siblings, 0 replies; 53+ messages in thread
From: Guenter Roeck @ 2019-09-13 14:59 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Bart Van Assche, ksummit-discuss, linux-nvdimm,
	Greg Kroah-Hartman, Matthew Wilcox, linux-kernel, Steve French,
	Dmitry Vyukov, Tobin C. Harding

On Fri, Sep 13, 2019 at 10:54:46AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 13 Sep 2019 08:56:30 -0400
> Matthew Wilcox <willy6545@gmail.com> escreveu:
> 
> > It's easy enough to move the kernel-doc warnings out from under W=1. I only
> > out them there to avoid overwhelming us with new warnings. If they're
> > mostly fixed now, let's make checking them the default.
> 
> Didn't try doing it kernelwide, but for media we do use W=1 by default,
> on our CI instance.
> 

I used to do that as well, but gave up on it since it resulted in lots
of warnings from generic kernel include files. I have not tried recently,
so maybe that is no longer the case.

> There's a few warnings at EDAC, but they all seem easy enough to be
> fixed.
> 

Acceptance depends on the maintainer, really. I had patches rejected
when trying to fix W=1 warnings, so I no longer do it.

> So, from my side, I'm all to make W=1 default.
> 
Seems to me that would require a common agreement that maintainers
are expected to accept fixes for problems reported with W=1.

Guenter

> Regards,
> Mauro
> 
> > 
> > On Thu., Sep. 12, 2019, 16:01 Bart Van Assche, <bvanassche@acm.org> wrote:
> > 
> > > On 9/12/19 8:34 AM, Joe Perches wrote:  
> > > > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:  
> > > >> On 9/11/19 5:40 PM, Martin K. Petersen wrote:  
> > > >>> * The patch must compile without warnings (make C=1  
> > > CF="-D__CHECK_ENDIAN__")  
> > > >>>   and does not incur any zeroday test robot complaints.  
> > > >>
> > > >> How about adding W=1 to that make command?  
> > > >
> > > > That's rather too compiler version dependent and new
> > > > warnings frequently get introduced by new compiler versions.  
> > >
> > > I've never observed this myself. If a new compiler warning is added to
> > > gcc and if it produces warnings that are not useful for kernel code
> > > usually Linus or someone else is quick to suppress that warning.
> > >
> > > Another argument in favor of W=1 is that the formatting of kernel-doc
> > > headers is checked only if W=1 is passed to make.
> > >
> > > Bart.
> > >
> > > _______________________________________________
> > > Ksummit-discuss mailing list
> > > Ksummit-discuss@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> > >  
> 
> 
> 
> Thanks,
> Mauro
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13 11:48         ` Dan Carpenter
  2019-09-13 12:18           ` Dan Williams
@ 2019-09-13 15:00           ` Randy Dunlap
  2019-09-13 15:46             ` Rob Herring
  2019-09-13 17:57             ` Geert Uytterhoeven
  2019-09-16 12:42           ` Jani Nikula
       [not found]           ` <20190917161608.GA12866@ziepe.ca>
  3 siblings, 2 replies; 53+ messages in thread
From: Randy Dunlap @ 2019-09-13 15:00 UTC (permalink / raw)
  To: Dan Carpenter, Jonathan Corbet
  Cc: ksummit-discuss, linux-nvdimm, linux-kernel, bpf

On 9/13/19 4:48 AM, Dan Carpenter wrote:

>> So I'm expecting to take this kind of stuff into Documentation/.  My own
>> personal hope is that it can maybe serve to shame some of these "local
>> quirks" out of existence.  The evidence from this brief discussion suggests
>> that this might indeed happen.
> 
> I don't think it's shaming, I think it's validating.  Everyone just
> insists that since it's written in the Book of Rules then it's our fault
> for not reading it.  It's like those EULA things where there is more
> text than anyone can physically read in a life time.

Yes, agreed.

> And the documentation doesn't help.  For example, I knew people's rules
> about capitalizing the subject but I'd just forget.  I say that if you
> can't be bothered to add it to checkpatch then it means you don't really
> care that strongly.

If a subsystem requires a certain spelling/capitalization in patch email
subjects, it should be added to MAINTAINERS IMO.  E.g.,
E:	NuBus

-- 
~Randy
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
  2019-09-11 15:48 ` [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams
@ 2019-09-13 15:37   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 53+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 15:37 UTC (permalink / raw)
  To: Dan Williams; +Cc: linux-kernel, ksummit-discuss, linux-nvdimm

Em Wed, 11 Sep 2019 08:48:48 -0700
Dan Williams <dan.j.williams@intel.com> escreveu:

> Fixup some P: entries to be M: and delete the others that do not include an
> email address. The P: tag will be used to indicate the location of a
> Profile for a given MAINTAINERS entry.
> 
> Cc: Joe Perches <joe@perches.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  MAINTAINERS |   12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 

...

>  MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
>  M:	Mauro Carvalho Chehab <mchehab@kernel.org>
> -P:	LinuxTV.org Project
>  L:	linux-media@vger.kernel.org
>  W:	https://linuxtv.org
>  Q:	http://patchwork.kernel.org/project/linux-media/list/
> @@ -13452,7 +13450,6 @@ S:	Maintained
>  F:	arch/mips/ralink

Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

Thanks,
Mauro
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13 15:00           ` Randy Dunlap
@ 2019-09-13 15:46             ` Rob Herring
  2019-09-13 16:42               ` Joe Perches
  2019-09-13 17:57             ` Geert Uytterhoeven
  1 sibling, 1 reply; 53+ messages in thread
From: Rob Herring @ 2019-09-13 15:46 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: ksummit, linux-nvdimm, Jonathan Corbet, linux-kernel, bpf, Dan Carpenter

On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 9/13/19 4:48 AM, Dan Carpenter wrote:
>
> >> So I'm expecting to take this kind of stuff into Documentation/.  My own
> >> personal hope is that it can maybe serve to shame some of these "local
> >> quirks" out of existence.  The evidence from this brief discussion suggests
> >> that this might indeed happen.
> >
> > I don't think it's shaming, I think it's validating.  Everyone just
> > insists that since it's written in the Book of Rules then it's our fault
> > for not reading it.  It's like those EULA things where there is more
> > text than anyone can physically read in a life time.
>
> Yes, agreed.
>
> > And the documentation doesn't help.  For example, I knew people's rules
> > about capitalizing the subject but I'd just forget.  I say that if you
> > can't be bothered to add it to checkpatch then it means you don't really
> > care that strongly.
>
> If a subsystem requires a certain spelling/capitalization in patch email
> subjects, it should be added to MAINTAINERS IMO.  E.g.,
> E:      NuBus

+1

Better make this a regex to deal with (net|net-next).

We could probably script populating MAINTAINERS with this using how it
is done manually: git log --oneline <dir>

Rob
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13 15:46             ` Rob Herring
@ 2019-09-13 16:42               ` Joe Perches
  2019-09-13 19:32                 ` Rob Herring
  0 siblings, 1 reply; 53+ messages in thread
From: Joe Perches @ 2019-09-13 16:42 UTC (permalink / raw)
  To: Rob Herring, Randy Dunlap
  Cc: ksummit, linux-nvdimm, linux-kernel, bpf, Dan Carpenter

On Fri, 2019-09-13 at 16:46 +0100, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> > On 9/13/19 4:48 AM, Dan Carpenter wrote:
> > 
> > > > So I'm expecting to take this kind of stuff into Documentation/.  My own
> > > > personal hope is that it can maybe serve to shame some of these "local
> > > > quirks" out of existence.  The evidence from this brief discussion suggests
> > > > that this might indeed happen.
> > > 
> > > I don't think it's shaming, I think it's validating.  Everyone just
> > > insists that since it's written in the Book of Rules then it's our fault
> > > for not reading it.  It's like those EULA things where there is more
> > > text than anyone can physically read in a life time.
> > 
> > Yes, agreed.
> > 
> > > And the documentation doesn't help.  For example, I knew people's rules
> > > about capitalizing the subject but I'd just forget.  I say that if you
> > > can't be bothered to add it to checkpatch then it means you don't really
> > > care that strongly.
> > 
> > If a subsystem requires a certain spelling/capitalization in patch email
> > subjects, it should be added to MAINTAINERS IMO.  E.g.,
> > E:      NuBus
> 
> +1
> 
> Better make this a regex to deal with (net|net-next).
> 
> We could probably script populating MAINTAINERS with this using how it
> is done manually: git log --oneline <dir>

I made a similar proposal nearly a decade ago to add a grammar
to MAINTAINERS sections for patch subject prefixes.

https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13 15:00           ` Randy Dunlap
  2019-09-13 15:46             ` Rob Herring
@ 2019-09-13 17:57             ` Geert Uytterhoeven
  1 sibling, 0 replies; 53+ messages in thread
From: Geert Uytterhoeven @ 2019-09-13 17:57 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: ksummit, linux-nvdimm, Jonathan Corbet,
	Linux Kernel Mailing List, bpf, Dan Carpenter

Hi Randy,

On Fri, Sep 13, 2019 at 5:00 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> On 9/13/19 4:48 AM, Dan Carpenter wrote:
> >> So I'm expecting to take this kind of stuff into Documentation/.  My own
> >> personal hope is that it can maybe serve to shame some of these "local
> >> quirks" out of existence.  The evidence from this brief discussion suggests
> >> that this might indeed happen.
> >
> > I don't think it's shaming, I think it's validating.  Everyone just
> > insists that since it's written in the Book of Rules then it's our fault
> > for not reading it.  It's like those EULA things where there is more
> > text than anyone can physically read in a life time.
>
> Yes, agreed.
>
> > And the documentation doesn't help.  For example, I knew people's rules
> > about capitalizing the subject but I'd just forget.  I say that if you
> > can't be bothered to add it to checkpatch then it means you don't really
> > care that strongly.
>
> If a subsystem requires a certain spelling/capitalization in patch email
> subjects, it should be added to MAINTAINERS IMO.  E.g.,
> E:      NuBus

Oh, I understood the question differently.  I thought it was about
"sub: system: Fix foo" vs. "sub: system: fix foo".

For simple and trivial things, I tend to make changes while applying, as that's
usually less work than complaining, and verifying that it's been fixed in the
next (if any) version n days/weeks/months later.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-13 14:26           ` Rob Herring
@ 2019-09-13 18:42             ` Joe Perches
  2019-09-13 19:17               ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 53+ messages in thread
From: Joe Perches @ 2019-09-13 18:42 UTC (permalink / raw)
  To: Rob Herring
  Cc: Bart Van Assche, ksummit, linux-nvdimm, Greg Kroah-Hartman,
	linux-kernel, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French,
	Tobin C. Harding

On Fri, 2019-09-13 at 15:26 +0100, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 3:12 PM Joe Perches <joe@perches.com> wrote:
> > On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote:
> > 
> > > Another argument in favor of W=1 is that the formatting of kernel-doc
> > > headers is checked only if W=1 is passed to make.
> > 
> > Actually, but for the fact there are far too many
> > to generally enable that warning right now,
> > (an x86-64 defconfig has more than 1000)
> > that sounds pretty reasonable to me.

> It's in the 1000s on arm because W=1 turns on more checks in building
> .dts files. There are lots of duplicates as most of the dts content is
> as an include file (e.g. board dts includes soc dts).

Yeah, dts[i] files in arm compilations are very noisy at W=1
so moving those message types to W=2 seems sensible.

$ { opt="ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnueabi-" ; make $opt clean ; make $opt defconfig ; make $opt W=1 -j4 ; } > arm_make.log 2>&1

$ grep -i -P 'dtsi?:.*warning' arm_make.log | wc -l
69164

Just fyi:  for an x86-64 defconfig with gcc 8.3

$ { make clean ; make defconfig ; make -j4 W=1 ; } > make.log 2>&1

There are ~300 W=1 for non kernel-doc -W<foo> warnings.

$ grep -i -P -oh '\[\-W[\w\-]+\]' make.log |sort | uniq -c | sort -rn
    163 [-Wmissing-prototypes]
     69 [-Wunused-but-set-variable]
     16 [-Wempty-body]
     10 [-Wtype-limits]
      6 [-Woverride-init]
      2 [-Wstringop-truncation]
      2 [-Wcast-function-type]
      1 [-Wunused-but-set-parameter]

And there are ~1000 kernel-doc only messages in various files

$ grep -i 'function parameter' make.log | cut -f1 -d: | sort | uniq -c
      6 arch/x86/events/intel/pt.c
      2 arch/x86/kernel/apic/apic.c
     10 arch/x86/kernel/cpu/mtrr/generic.c
      5 arch/x86/kernel/crash_dump_64.c
      1 arch/x86/kernel/i8259.c
      3 arch/x86/kernel/smpboot.c
      3 arch/x86/kernel/tsc.c
      2 arch/x86/kernel/uprobes.c
      1 arch/x86/lib/cmdline.c
      1 arch/x86/lib/insn.c
      2 arch/x86/lib/insn-eval.c
      4 arch/x86/lib/msr.c
      2 arch/x86/lib/usercopy_64.c
      1 arch/x86/mm/pat.c
     13 arch/x86/mm/pgtable.c
      1 arch/x86/pci/i386.c
      2 arch/x86/power/cpu.c
      2 arch/x86/power/hibernate.c
      8 certs/system_keyring.c
      4 crypto/asymmetric_keys/asymmetric_type.c
      3 crypto/asymmetric_keys/pkcs7_trust.c
     16 crypto/jitterentropy.c
      3 drivers/acpi/acpi_apd.c
      3 drivers/acpi/bus.c
      2 drivers/acpi/cppc_acpi.c
      5 drivers/acpi/device_sysfs.c
      2 drivers/acpi/dock.c
      2 drivers/acpi/nvs.c
      1 drivers/acpi/pci_root.c
      5 drivers/acpi/property.c
      4 drivers/acpi/sleep.c
      7 drivers/acpi/utils.c
      1 drivers/ata/libata-acpi.c
      2 drivers/ata/libata-pmp.c
      6 drivers/ata/libata-transport.c
      4 drivers/ata/pata_amd.c
      4 drivers/base/attribute_container.c
      1 drivers/base/devcon.c
      3 drivers/base/platform-msi.c
      3 drivers/base/power/runtime.c
      5 drivers/base/power/wakeup.c
      2 drivers/char/agp/backend.c
      3 drivers/char/agp/generic.c
      2 drivers/clk/clk.c
      1 drivers/clk/clk-fixed-factor.c
      1 drivers/clk/clk-fixed-rate.c
      3 drivers/connector/cn_proc.c
     31 drivers/cpufreq/cpufreq.c
      3 drivers/cpufreq/cpufreq_governor.c
      7 drivers/cpufreq/freq_table.c
      1 drivers/cpufreq/intel_pstate.c
      6 drivers/cpuidle/sysfs.c
      1 drivers/dma-buf/dma-buf.c
      1 drivers/dma-buf/dma-fence-chain.c
      6 drivers/dma/dmaengine.c
      7 drivers/firewire/init_ohci1394_dma.c
      2 drivers/firmware/efi/memmap.c
      1 drivers/firmware/efi/vars.c
     20 drivers/gpu/drm/drm_agpsupport.c
      8 drivers/hid/hid-core.c
      3 drivers/hid/hid-quirks.c
      5 drivers/hid/usbhid/hid-pidff.c
      3 drivers/input/mouse/synaptics.c
      2 drivers/iommu/amd_iommu_init.c
      2 drivers/iommu/dmar.c
      1 drivers/iommu/intel-pasid.c
      1 drivers/iommu/iommu.c
      2 drivers/leds/led-class.c
      2 drivers/mailbox/pcc.c
      6 drivers/net/ethernet/intel/e1000/e1000_hw.c
     21 drivers/net/ethernet/intel/e1000/e1000_main.c
      1 drivers/net/ethernet/intel/e1000e/80003es2lan.c
      6 drivers/net/ethernet/intel/e1000e/ich8lan.c
     42 drivers/net/ethernet/intel/e1000e/netdev.c
      3 drivers/net/ethernet/intel/e1000e/phy.c
      2 drivers/net/ethernet/intel/e1000e/ptp.c
      1 drivers/net/netconsole.c
      3 drivers/net/phy/mdio-boardinfo.c
      2 drivers/net/phy/mdio_device.c
      2 drivers/pci/ats.c
      3 drivers/pci/hotplug/acpi_pcihp.c
      4 drivers/pci/pcie/aer.c
      2 drivers/pci/pcie/pme.c
      1 drivers/pci/setup-bus.c
      1 drivers/pci/vc.c
     22 drivers/pcmcia/cistpl.c
     13 drivers/pcmcia/pcmcia_cis.c
     13 drivers/pcmcia/pcmcia_resource.c
     11 drivers/pcmcia/rsrc_nonstatic.c
      1 drivers/pnp/system.c
     11 drivers/rtc/interface.c
      3 drivers/rtc/sysfs.c
      2 drivers/thermal/step_wise.c
      2 drivers/thermal/user_space.c
      6 drivers/tty/n_tty.c
      4 drivers/tty/pty.c
      7 drivers/tty/tty_audit.c
      7 drivers/tty/tty_baudrate.c
     13 drivers/tty/tty_buffer.c
     25 drivers/tty/tty_io.c
      5 drivers/tty/tty_jobctrl.c
      6 drivers/tty/tty_ldisc.c
      6 drivers/tty/tty_port.c
      5 drivers/tty/vt/consolemap.c
      4 drivers/tty/vt/vt.c
      3 drivers/tty/vt/vt_ioctl.c
     12 drivers/usb/common/debug.c
      1 drivers/usb/host/pci-quirks.c
      1 drivers/usb/host/xhci.c
      6 drivers/usb/host/xhci-mem.c
      2 drivers/video/backlight/backlight.c
      1 drivers/video/fbdev/core/fbmon.c
      2 drivers/video/fbdev/core/fb_notify.c
      7 fs/devpts/inode.c
      4 fs/direct-io.c
      3 fs/eventpoll.c
      6 fs/fat/dir.c
      3 fs/fat/misc.c
      6 fs/fat/nfs.c
      4 fs/fs_context.c
      1 fs/fs_parser.c
      2 fs/fs-writeback.c
      5 fs/ioctl.c
      1 fs/libfs.c
      3 fs/namespace.c
      2 fs/nfs_common/grace.c
      2 fs/open.c
      3 fs/posix_acl.c
      1 fs/proc/proc_net.c
      2 fs/proc/vmcore.c
      2 fs/read_write.c
      1 fs/super.c
      5 fs/xattr.c
      2 kernel/cgroup/cpuset.c
      1 kernel/cpu.c
      4 kernel/events/core.c
      2 kernel/events/hw_breakpoint.c
      5 kernel/fork.c
     27 kernel/irq/irqdomain.c
      3 kernel/irq/matrix.c
      1 kernel/kprobes.c
      5 kernel/locking/rtmutex.c
      1 kernel/notifier.c
      3 kernel/power/main.c
      2 kernel/power/qos.c
     51 kernel/power/snapshot.c
      2 kernel/power/suspend.c
     14 kernel/power/swap.c
      1 kernel/reboot.c
      4 kernel/seccomp.c
      2 kernel/stacktrace.c
      4 kernel/time/alarmtimer.c
      1 kernel/time/clockevents.c
      4 kernel/time/posix-cpu-timers.c
      1 kernel/time/tick-broadcast.c
      6 kernel/time/tick-oneshot.c
      3 kernel/time/tick-sched.c
      3 kernel/time/timeconv.c
     23 kernel/time/timekeeping.c
      9 kernel/trace/ring_buffer.c
      8 kernel/trace/trace_events_filter.c
      2 kernel/trace/trace_events_trigger.c
      1 kernel/trace/trace_seq.c
      1 lib/argv_split.c
      1 lib/cpumask.c
      5 lib/genalloc.c
      4 lib/iov_iter.c
      2 lib/nlattr.c
      3 lib/percpu_counter.c
      6 lib/radix-tree.c
      2 lib/scatterlist.c
      3 lib/win_minmax.c
      1 mm/compaction.c
      2 mm/oom_kill.c
      1 mm/page_vma_mapped.c
      2 mm/swap_state.c
      1 mm/vmalloc.c
      1 mm/vmscan.c
      8 net/ipv4/cipso_ipv4.c
      3 net/ipv4/ipmr.c
      1 net/ipv4/tcp_input.c
      5 net/ipv4/tcp_output.c
      2 net/ipv4/tcp_timer.c
      3 net/ipv4/udp.c
      4 net/ipv6/calipso.c
      1 net/ipv6/exthdrs.c
      1 net/ipv6/ip6_output.c
      3 net/ipv6/udp.c
      1 net/mac80211/tx.c
      5 net/netlabel/netlabel_calipso.c
      2 net/netlabel/netlabel_domainhash.c
      3 net/sched/ematch.c
      1 net/socket.c
      1 net/wireless/radiotap.c
      4 net/wireless/reg.c
      6 security/commoncap.c
      1 security/lsm_audit.c
     12 security/selinux/avc.c
      7 security/selinux/netlabel.c
      2 security/selinux/netport.c
      4 security/selinux/ss/mls.c
     34 security/selinux/ss/services.c
      3 sound/hda/hdac_bus.c
      1 sound/hda/hdac_component.c
      2 sound/hda/hdac_controller.c
     10 sound/hda/hdac_device.c
      2 sound/hda/hdac_stream.c
      1 sound/pci/hda/hda_codec.c


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-13 18:42             ` Joe Perches
@ 2019-09-13 19:17               ` Mauro Carvalho Chehab
  2019-09-13 20:33                 ` Joe Perches
  0 siblings, 1 reply; 53+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 19:17 UTC (permalink / raw)
  To: Joe Perches
  Cc: Bart Van Assche, ksummit, linux-nvdimm, Greg Kroah-Hartman,
	linux-kernel, Rob Herring, Dmitry Vyukov, Steve French,
	Tobin C. Harding

Em Fri, 13 Sep 2019 11:42:38 -0700
Joe Perches <joe@perches.com> escreveu:

> On Fri, 2019-09-13 at 15:26 +0100, Rob Herring wrote:
> > On Fri, Sep 13, 2019 at 3:12 PM Joe Perches <joe@perches.com> wrote:  
> > > On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote:
> > >   
> > > > Another argument in favor of W=1 is that the formatting of kernel-doc
> > > > headers is checked only if W=1 is passed to make.  
> > > 
> > > Actually, but for the fact there are far too many
> > > to generally enable that warning right now,
> > > (an x86-64 defconfig has more than 1000)
> > > that sounds pretty reasonable to me.  
> 
> > It's in the 1000s on arm because W=1 turns on more checks in building
> > .dts files. There are lots of duplicates as most of the dts content is
> > as an include file (e.g. board dts includes soc dts).  
> 
> Yeah, dts[i] files in arm compilations are very noisy at W=1
> so moving those message types to W=2 seems sensible.
> 
> $ { opt="ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnueabi-" ; make $opt clean ; make $opt defconfig ; make $opt W=1 -j4 ; } > arm_make.log 2>&1
> 
> $ grep -i -P 'dtsi?:.*warning' arm_make.log | wc -l
> 69164

Yeah, makes sense moving them to W=2, or to make them somehow produce
less noise.

> Just fyi:  for an x86-64 defconfig with gcc 8.3
> 
> $ { make clean ; make defconfig ; make -j4 W=1 ; } > make.log 2>&1
> 
> There are ~300 W=1 for non kernel-doc -W<foo> warnings.
> 
> $ grep -i -P -oh '\[\-W[\w\-]+\]' make.log |sort | uniq -c | sort -rn
>     163 [-Wmissing-prototypes]
>      69 [-Wunused-but-set-variable]
>      16 [-Wempty-body]
>      10 [-Wtype-limits]
>       6 [-Woverride-init]
>       2 [-Wstringop-truncation]
>       2 [-Wcast-function-type]
>       1 [-Wunused-but-set-parameter]

On my eyes, it doesn't sound too much. I suspect that, 
with gcc-9, it should produce more warnings, though.

Perhaps we could "promote" most of those to W=0.

> 
> And there are ~1000 kernel-doc only messages in various files

A significant amount of those warnings appear with "make htmldocs".

Not having the kernel-doc warning as part of W=0 helps to make
very hard to have them cleared.

IMHO, those should be enabled by default with W=0, at least for the
files that are included on some kernel-doc tag.

I mean, perhaps, when W=0, Kernel build could run:

	$ ./scripts/kernel-doc -none $(git grep kernel-doc:: Documentation/|cut -d: -f4-|sort|uniq|grep -vE "\bsource\b")

That produces 165 warnings (against v5.3-rc4 + media -next patches).

Thanks,
Mauro
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13 16:42               ` Joe Perches
@ 2019-09-13 19:32                 ` Rob Herring
  0 siblings, 0 replies; 53+ messages in thread
From: Rob Herring @ 2019-09-13 19:32 UTC (permalink / raw)
  To: Joe Perches
  Cc: ksummit, linux-nvdimm, Randy Dunlap, linux-kernel, bpf, Dan Carpenter

On Fri, Sep 13, 2019 at 11:42 AM Joe Perches <joe@perches.com> wrote:
>
> On Fri, 2019-09-13 at 16:46 +0100, Rob Herring wrote:
> > On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> > > On 9/13/19 4:48 AM, Dan Carpenter wrote:
> > >
> > > > > So I'm expecting to take this kind of stuff into Documentation/.  My own
> > > > > personal hope is that it can maybe serve to shame some of these "local
> > > > > quirks" out of existence.  The evidence from this brief discussion suggests
> > > > > that this might indeed happen.
> > > >
> > > > I don't think it's shaming, I think it's validating.  Everyone just
> > > > insists that since it's written in the Book of Rules then it's our fault
> > > > for not reading it.  It's like those EULA things where there is more
> > > > text than anyone can physically read in a life time.
> > >
> > > Yes, agreed.
> > >
> > > > And the documentation doesn't help.  For example, I knew people's rules
> > > > about capitalizing the subject but I'd just forget.  I say that if you
> > > > can't be bothered to add it to checkpatch then it means you don't really
> > > > care that strongly.
> > >
> > > If a subsystem requires a certain spelling/capitalization in patch email
> > > subjects, it should be added to MAINTAINERS IMO.  E.g.,
> > > E:      NuBus
> >
> > +1
> >
> > Better make this a regex to deal with (net|net-next).
> >
> > We could probably script populating MAINTAINERS with this using how it
> > is done manually: git log --oneline <dir>
>
> I made a similar proposal nearly a decade ago to add a grammar
> to MAINTAINERS sections for patch subject prefixes.
>
> https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/

Perhaps there's more support for it now. I didn't get through all the
thread, but the positions seemed to range from "who cares, subjects
are easy to edit" to "seems like a good idea and doesn't hurt". I
probably would have implemented something, but perl (tacking on to
checkpatch and having you tell me everything wrong is about all I can
do :)).

Rob
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-13 19:17               ` Mauro Carvalho Chehab
@ 2019-09-13 20:33                 ` Joe Perches
  0 siblings, 0 replies; 53+ messages in thread
From: Joe Perches @ 2019-09-13 20:33 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Bart Van Assche, ksummit, linux-nvdimm, Greg Kroah-Hartman,
	linux-kernel, Rob Herring, Dmitry Vyukov, Steve French,
	Tobin C. Harding

On Fri, 2019-09-13 at 16:17 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 13 Sep 2019 11:42:38 -0700
> Joe Perches <joe@perches.com> escreveu:
[]
> > Just fyi:  for an x86-64 defconfig with gcc 8.3
> > 
> > $ { make clean ; make defconfig ; make -j4 W=1 ; } > make.log 2>&1
> > 
> > There are ~300 W=1 for non kernel-doc -W<foo> warnings.
> > 
> > $ grep -i -P -oh '\[\-W[\w\-]+\]' make.log |sort | uniq -c | sort -rn
> >     163 [-Wmissing-prototypes]
> >      69 [-Wunused-but-set-variable]
> >      16 [-Wempty-body]
> >      10 [-Wtype-limits]
> >       6 [-Woverride-init]
> >       2 [-Wstringop-truncation]
> >       2 [-Wcast-function-type]
> >       1 [-Wunused-but-set-parameter]
> 
> On my eyes, it doesn't sound too much.

In general, I agree and most of these are pretty
trivial to remove.  It'd just take some time to
remove most of the missing-prototypes and
unused-but-set warnings before being able to
enable the warnings at the default W=0.

> I suspect that, 
> with gcc-9, it should produce more warnings, though.

It doesn't though.
At least not so far as I can tell.
gcc-9.1 produces the same output.

$ { make clean ; make defconfig ; make CC=/usr/bin/gcc-9 -j4 W=1 V=1 ; } > make_gcc9.log 2>&1
$  grep -i -P -oh '\[\-W[\w\-]+\]' make_gcc9.log | sort | uniq -c | sort -rn
    163 [-Wmissing-prototypes]
     69 [-Wunused-but-set-variable]
     16 [-Wempty-body]
     10 [-Wtype-limits]
      6 [-Woverride-init]
      2 [-Wstringop-truncation]
      2 [-Wcast-function-type]
      1 [-Wunused-but-set-parameter]


_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-11 22:11     ` Jens Axboe
  2019-09-12  7:41       ` Dan Williams
  2019-09-13  7:09       ` Jonathan Corbet
@ 2019-09-13 21:44       ` Martin K. Petersen
  2019-09-16  7:01         ` Dan Carpenter
  2 siblings, 1 reply; 53+ messages in thread
From: Martin K. Petersen @ 2019-09-13 21:44 UTC (permalink / raw)
  To: Jens Axboe
  Cc: ksummit-discuss, linux-nvdimm, linux-kernel, bpf, Dan Carpenter


Jens,

> Additionally, it would seem saner to standardize rules around when
> code is expected to hit the maintainers hands for kernel
> releases. Both yours and Martins deals with that, there really
> shouldn't be the need to have this specified in detail per sub-system.

Yeah. There is basically nothing specific about SCSI in my write-up
outside of the branch naming.

I deliberately didn't mention coding style preferences. We have so much
20+ year old cruft in SCSI that's impossible to even entertain. But I do
request new code to follow coding-style.rst. BYOXT.

Also note that the original target audience for my document. It was
aimed at onboarding new driver contributors from hardware companies. So
people that don't live and breathe Linux development and who are not
intimately familiar with the kernel development process. It's possible
that we have this information in Documentation/ these days; I'll go
look. But it didn't exist when this doc was written. And in my
experience nobody coming to Linux development from the outside
understands what the "merge window" is. And when the appropriate time is
to submit patches and features. I think this would be a great area to
have a common set of guidelines and documentation. I'd prefer for this
to be global and then let maintainers apply their own wiggle room
instead of documenting particular rules for a given subsystem.

One pet peeve I have is that people are pretty bad at indicating the
intended target tree. I often ask for it in private mail but the
practice doesn't seem to stick. I spend a ton of time guessing whether a
patch is a fix for a new feature in the x+1 queue or a fix for the
current release. It is not always obvious.

-- 
Martin K. Petersen	Oracle Linux Engineering
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-12 13:31   ` [Ksummit-discuss] " Bart Van Assche
  2019-09-12 15:34     ` Joe Perches
@ 2019-09-13 22:03     ` Martin K. Petersen
  2020-04-29 13:55       ` Roman Bolshakov
  1 sibling, 1 reply; 53+ messages in thread
From: Martin K. Petersen @ 2019-09-13 22:03 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman, linux-kernel,
	Dmitry Vyukov, Mauro Carvalho Chehab, Steve French,
	Tobin C. Harding


Hi Bart,

> On 9/11/19 5:40 PM, Martin K. Petersen wrote:
>> * Do not use custom To: and Cc: for individual patches. We want to see the
>>   whole series, even patches that potentially need to go through a different
>>   subsystem tree.
>
> Thanks for having written this summary. This is very helpful. For the
> above paragraph, should it be clarified whether that requirement
> applies to mailing list e-mail addresses only or also to individual
> e-mail addresses? When using git send-email it is easy to end up with
> different cc-lists per patch.

I prefer to have the entire series sent to linux-scsi or
target-devel. It wouldn't be so bad if discussions about the merits of a
tree-wide change consistently happened in responses to the cover
letter. But more often than not discussion happens in response to a
patch touching a different subsystem and therefore in a mail exchange
that doesn't end up on linux-scsi.

>> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__")
>>   and does not incur any zeroday test robot complaints.
>
> How about adding W=1 to that make command?
>
> How about existing drivers that trigger tons of endianness warnings,
> e.g. qla2xxx? How about requiring that no new warnings are introduced?

This was in response to a driver submission (for a different driver)
around the time this doc was written. The problem is that it's sometimes
hard to distinguish new warnings from old ones. I'm all for requiring
that no new warnings are introduced.

>> * The patch must have a commit message that describes,
>> comprehensively and in plain English, what the patch does.
>
> How about making this requirement more detailed and requiring that not
> only what has been changed is document but also why that change has
> been made?

I'd really like all this patch submission guideline material to live in
Documentation/process. But yes.

-- 
Martin K. Petersen	Oracle Linux Engineering
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13 21:44       ` Martin K. Petersen
@ 2019-09-16  7:01         ` Dan Carpenter
  2019-09-16 17:08           ` Martin K. Petersen
  0 siblings, 1 reply; 53+ messages in thread
From: Dan Carpenter @ 2019-09-16  7:01 UTC (permalink / raw)
  To: Martin K. Petersen
  Cc: Jens Axboe, bpf, linux-kernel, ksummit-discuss, linux-nvdimm

On Fri, Sep 13, 2019 at 05:44:39PM -0400, Martin K. Petersen wrote:
> One pet peeve I have is that people are pretty bad at indicating the
> intended target tree. I often ask for it in private mail but the
> practice doesn't seem to stick. I spend a ton of time guessing whether a
> patch is a fix for a new feature in the x+1 queue or a fix for the
> current release. It is not always obvious.

The Fixes tag doesn't help?

Of course, you've never asked me or anyone on kernel-newbies that
question.  We don't normally know the answer either.  I do always try to
figure it out for networking, but it's kind of a pain in the butt and I
mess up surpisingly often for how much effort I put into getting it
right.

regards,
dan carpenter
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
  2019-09-11 15:48 ` [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
  2019-09-11 17:34   ` [Ksummit-discuss] " Verma, Vishal L
@ 2019-09-16 12:35   ` Jani Nikula
  2019-10-01 13:55   ` Jonathan Corbet
  2 siblings, 0 replies; 53+ messages in thread
From: Jani Nikula @ 2019-09-16 12:35 UTC (permalink / raw)
  To: Dan Williams, linux-kernel
  Cc: ksummit-discuss, linux-nvdimm, Jonathan Corbet, Steve French,
	Greg Kroah-Hartman, Mauro Carvalho Chehab, Dmitry Vyukov,
	Tobin C. Harding

On Wed, 11 Sep 2019, Dan Williams <dan.j.williams@intel.com> wrote:
> As presented at the 2018 Linux Plumbers conference [1], the Maintainer
> Entry Profile (formerly Subsystem Profile) is proposed as a way to reduce
> friction between committers and maintainers and encourage conversations
> amongst maintainers about common best practices. While coding-style,
> submit-checklist, and submitting-drivers lay out some common expectations
> there remain local customs and maintainer preferences that vary by
> subsystem.
>
> The profile contains short answers to some of the common policy questions a
> contributor might have that are local to the subsystem / device-driver, or
> otherwise not covered by the top-level process documents.
>
> Overview: General introduction to how the subsystem operates
> Submit Checklist Addendum: Mechanical items that gate submission staging
> Key Cycle Dates:
>  - Last -rc for new feature submissions: Expected lead time for submissions
>  - Last -rc to merge features: Deadline for merge decisions
> Coding Style Addendum: Clarifications of local style preferences
> Resubmit Cadence: When to ping the maintainer
> Checkpatch / Style Cleanups: Policy on pure cleanup patches
>
> See Documentation/maintainer/maintainer-entry-profile.rst for more details,
> and a follow-on example profile for the libnvdimm subsystem.
>
> [1]: https://linuxplumbersconf.org/event/2/contributions/59/
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Steve French <stfrench@microsoft.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Tobin C. Harding <me@tobin.cc>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Martin K. Petersen <martin.petersen@oracle.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Joe Perches <joe@perches.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/maintainer/index.rst                 |    1 
>  .../maintainer/maintainer-entry-profile.rst        |   99 ++++++++++++++++++++
>  MAINTAINERS                                        |    4 +
>  3 files changed, 104 insertions(+)
>  create mode 100644 Documentation/maintainer/maintainer-entry-profile.rst
>
> diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst
> index 56e2c09dfa39..d904e74e1159 100644
> --- a/Documentation/maintainer/index.rst
> +++ b/Documentation/maintainer/index.rst
> @@ -12,4 +12,5 @@ additions to this manual.
>     configure-git
>     rebasing-and-merging
>     pull-requests
> +   maintainer-entry-profile
>  
> diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst
> new file mode 100644
> index 000000000000..aaedf4d6dbf7
> --- /dev/null
> +++ b/Documentation/maintainer/maintainer-entry-profile.rst
> @@ -0,0 +1,99 @@
> +.. _maintainerentryprofile:
> +
> +Maintainer Entry Profile
> +========================
> +
> +The Maintainer Entry Profile supplements the top-level process documents
> +(coding-style, submitting-patches...) with subsystem/device-driver-local
> +customs as well as details about the patch submission lifecycle. A
> +contributor uses this document to level set their expectations and avoid
> +common mistakes, maintainers may use these profiles to look across
> +subsystems for opportunities to converge on common practices.

In general I think we're already pretty good at adding and accumulating
documentation, but not so much cleaning up existing and outright
throwing out obsolete documentation.

'wc -l Documentation/process/*' says we already have 11k lines of
generic process documentation.

I would much rather see a streamlined and friendly guide to contributing
to the kernel than more rules, and driver/subsystem specific rules at
that. I would much rather get the feeling from submissions that the long
tail of contributors have actually read and understood the most relevant
parts of Documentation/process.

I'm pretty sure *I* haven't read all of Documentation/process.

My fear is that the entry profiles will only be helpful to the
contributors that already "get it". It may be helpful to the maintainers
in the sense that they can reply to patches with a pointer to the
relevant hoops to jump through.

---

Even so, if this gets merged, I'll probably add something helpful for
drm and/or i915 contributors. But what's the buy-in across the kernel?
If my grep serves me right, there are something like 2000+ entries in
MAINTAINERS. If 10% of them adds a profile, that's a fairly serious
amount of documentation. But can you actually expect more than a handful
of subsystems/drivers to add a profile? Then what's the coverage?

For reference, I've added or promoted adding the B: and C: entries to
MAINTAINERS. Various subsystems and drivers are really picky about where
and how they want bugs reported; in particular some folks only accept
email. Yet networking is the only one to indicate the email preference
in MAINTAINERS. And adding that is a one line change. (There are 19 B:
entries and 7 C: entries in total.)


BR,
Jani.


> +
> +
> +Overview
> +--------
> +Provide an introduction to how the subsystem operates. While MAINTAINERS
> +tells the contributor where to send patches for which files, it does not
> +convey other subsystem-local infrastructure and mechanisms that aid
> +development.
> +Example questions to consider:
> +- Are there notifications when patches are applied to the local tree, or
> +  merged upstream?
> +- Does the subsystem have a patchwork instance?
> +- Any bots or CI infrastructure that watches the list?
> +- Git branches that are pulled into -next?
> +- What branch should contributors submit against?
> +- Links to any other Maintainer Entry Profiles? For example a
> +  device-driver may point to an entry for its parent subsystem. This makes
> +  the contributor aware of obligations a maintainer may have have for
> +  other maintainers in the submission chain.
> +
> +
> +Submit Checklist Addendum
> +-------------------------
> +List mandatory and advisory criteria, beyond the common "submit-checklist",
> +for a patch to be considered healthy enough for maintainer attention.
> +For example: "pass checkpatch.pl with no errors, or warning. Pass the
> +unit test detailed at $URI".
> +
> +
> +Key Cycle Dates
> +---------------
> +One of the common misunderstandings of submitters is that patches can be
> +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
> +wait for the next -rc. At a minimum:
> +- Last -rc for new feature submissions:
> +  New feature submissions targeting the next merge window should have
> +  their first posting for consideration before this point. Patches that
> +  are submitted after this point should be clear that they are targeting
> +  the NEXT+1 merge window, or should come with sufficient justification
> +  why they should be considered on an expedited schedule. A general
> +  guideline is to set expectation with contributors that new feature
> +  submissions should appear before -rc5.
> +
> +- 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
> +  resubmit for the following merge window.
> +
> +Optional:
> +- First -rc at which the development baseline branch, listed in the
> +  overview section, should be considered ready for new submissions.
> +
> +
> +Coding Style Addendum
> +---------------------
> +While the top-level "coding-style" document covers most style
> +considerations there are still discrepancies and local preferences
> +across subsystems. If a submitter should be aware of incremental / local
> +style guidelines like x-mas tree variable declarations, indentation
> +for multi line statements, function definition style, etc., list them
> +here.
> +
> +
> +Review Cadence
> +--------------
> +One of the largest sources of contributor angst is how soon to ping
> +after a patchset has been posted without receiving any feedback. In
> +addition to specifying how long to wait before a resubmission this
> +section can also indicate a preferred style of update like, resend the
> +full series, or privately send a reminder email. This section might also
> +list how review works for this code area and methods to get feedback
> +that are not directly from the maintainer.
> +
> +
> +Style Cleanup Patches
> +---------------------
> +For subsystems with long standing code bases it is reasonable to decline
> +to accept pure coding-style fixup patches. This is where you can let
> +contributors know "Standalone style-cleanups are welcome",
> +"Style-cleanups to existing code only welcome with other feature
> +changes", or “Standalone style-cleanups to existing code are not
> +welcome".
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3f171339df53..e5d111a86e61 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -98,6 +98,10 @@ Descriptions of section entries:
>  	   Obsolete:	Old code. Something tagged obsolete generally means
>  			it has been replaced by a better system and you
>  			should be using that.
> +	P: Subsystem Profile document for more details submitting
> +	   patches to the given subsystem. This is either an in-tree file,
> +	   or a URI. See Documentation/maintainer/maintainer-entry-profile.rst
> +	   for details.
>  	F: Files and directories with wildcard patterns.
>  	   A trailing slash includes all files and subdirectory files.
>  	   F:	drivers/net/	all files in and below drivers/net
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-13 11:48         ` Dan Carpenter
  2019-09-13 12:18           ` Dan Williams
  2019-09-13 15:00           ` Randy Dunlap
@ 2019-09-16 12:42           ` Jani Nikula
       [not found]           ` <20190917161608.GA12866@ziepe.ca>
  3 siblings, 0 replies; 53+ messages in thread
From: Jani Nikula @ 2019-09-16 12:42 UTC (permalink / raw)
  To: Dan Carpenter, Jonathan Corbet
  Cc: ksummit-discuss, linux-nvdimm, linux-kernel, bpf

On Fri, 13 Sep 2019, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> And the documentation doesn't help.  For example, I knew people's rules
> about capitalizing the subject but I'd just forget.  I say that if you
> can't be bothered to add it to checkpatch then it means you don't really
> care that strongly.

It would be entirely possible to add the subsystem/driver specific
checkpatch rules to MAINTAINERS entries or directory specific config
files. As checkpatch options directly. For example

--strict --max-line-length=100 --ignore=BIT_MACRO,SPLIT_STRING,LONG_LINE_STRING,BOOL_MEMBER

or whatever.

SMOP. ;)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
  2019-09-16  7:01         ` Dan Carpenter
@ 2019-09-16 17:08           ` Martin K. Petersen
  0 siblings, 0 replies; 53+ messages in thread
From: Martin K. Petersen @ 2019-09-16 17:08 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Jens Axboe, ksummit-discuss, linux-nvdimm, linux-kernel, bpf


Dan,

>> One pet peeve I have is that people are pretty bad at indicating the
>> intended target tree. I often ask for it in private mail but the
>> practice doesn't seem to stick. I spend a ton of time guessing whether a
>> patch is a fix for a new feature in the x+1 queue or a fix for the
>> current release. It is not always obvious.
>
> The Fixes tag doesn't help?

Always.

> Of course, you've never asked me or anyone on kernel-newbies that
> question.  We don't normally know the answer either.  I do always try
> to figure it out for networking, but it's kind of a pain in the butt
> and I mess up surpisingly often for how much effort I put into getting
> it right.

It's not a big issue for your patches. These are inevitably fixes and
I'll pick an appropriate tree depending on where we are in the cycle,
how likely one is to hit the issue, whether the driver is widely used,
etc.

Vendor driver submissions, however, are generally huge. Sometimes 50+
patches per submission window. And during this window I often get on the
order of 10 to 20 patches for the same driver in the fixes tree. It is
not always easy to determine whether a bug fix series is for one tree or
the other.

-- 
Martin K. Petersen	Oracle Linux Engineering
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
       [not found]           ` <20190917161608.GA12866@ziepe.ca>
@ 2019-09-17 21:59             ` Dan Williams
  0 siblings, 0 replies; 53+ messages in thread
From: Dan Williams @ 2019-09-17 21:59 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Jens Axboe, ksummit, linux-nvdimm, Jonathan Corbet,
	Linux Kernel Mailing List, bpf, Dan Carpenter

On Tue, Sep 17, 2019 at 9:16 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Fri, Sep 13, 2019 at 02:48:50PM +0300, Dan Carpenter wrote:
>
> > It used to be that infiniband used "sizeof foo" instead of sizeof(foo)
> > but now there is a new maintainer.
>
> These days I run everything through checkpatch and generally don't
> want to see much deviation from the 'normal' style, a few minor
> clang-format quibbles and other check patch positives excluded.
>
> This means when people touch lines they have to adjust minor things
> like the odd 'sizeof foo' to make it conforming.
>
> Like others there is a big historical mismatch and the best I hope for
> is that new stuff follow the cannonical style. Trying to guess what
> some appropriate mongral style is for each patch is just a waste of my
> time.
>
> I also hold drivers/infiniband as an example of why the column
> alignment style is harmful. That has not aged well and is the cause of
> a lot of ugly things.
>
> > There is one subsystem where the maintainer is super strict rules that
> > you can't use "I" or "we" in the commit message.  So you can't say "I
> > noticed a bug while reviewing", you have to say "The code has a bug".
>
> Ah, the imperative mood nitpick. This one is very exciting to explain
> to non-native speakers. With many regular submitters I'm still at the
> "I wish you would use proper grammer and sentence structure" phase..
>
> These days I just end up copy editing most of the commit messages :(
>
> > I don't think it's shaming, I think it's validating.  Everyone just
> > insists that since it's written in the Book of Rules then it's our fault
> > for not reading it.  It's like those EULA things where there is more
> > text than anyone can physically read in a life time.
>
> Yeah, I tend to agree.
>
> The big special cases with high patch volumes (net being the classic
> example) should remain special.
>
> But everyone else is not special, and shouldn't act the same.
>
> The work people like DanC do with static analysis is valuable, and we
> should not be insisting that those contributors have to jump through a
> thousand special hoops.
>
> I have simply viewed it as the job of the maintainer to run the
> process and deal with minor nit picks on the fly.
>
> Maybe that is what we should be documenting?

In theory, yes, in practice, as long as there is an exception to the
rule, it comes down to a question of "is this case special like net or
not?". I'd rather not waste time debating that on a per-subsystem
basis vs just getting it all documented for contributors.

I do think it is worth clarifying in the guidelines of writing a
profile to make an effort to not be special, and that odd looking
rules will be questioned (like libnvdimm statement continuation), but
lets not fight the new standards fight until it becomes apparent where
the outliers lie.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
  2019-09-11 15:48 ` [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
  2019-09-11 17:34   ` [Ksummit-discuss] " Verma, Vishal L
  2019-09-16 12:35   ` Jani Nikula
@ 2019-10-01 13:55   ` Jonathan Corbet
  2019-10-01 18:17     ` Martin K. Petersen
  2019-11-07 20:13     ` Jonathan Corbet
  2 siblings, 2 replies; 53+ messages in thread
From: Jonathan Corbet @ 2019-10-01 13:55 UTC (permalink / raw)
  To: Dan Williams
  Cc: linux-kernel, Thomas Gleixner, Mauro Carvalho Chehab,
	Steve French, Greg Kroah-Hartman, Linus Torvalds,
	Tobin C. Harding, Olof Johansson, Daniel Vetter, Joe Perches,
	Dmitry Vyukov, Alexandre Belloni, linux-nvdimm, ksummit-discuss

On Wed, 11 Sep 2019 08:48:54 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> As presented at the 2018 Linux Plumbers conference [1], the Maintainer
> Entry Profile (formerly Subsystem Profile) is proposed as a way to reduce
> friction between committers and maintainers and encourage conversations
> amongst maintainers about common best practices. While coding-style,
> submit-checklist, and submitting-drivers lay out some common expectations
> there remain local customs and maintainer preferences that vary by
> subsystem.
> 
> The profile contains short answers to some of the common policy questions a
> contributor might have that are local to the subsystem / device-driver, or
> otherwise not covered by the top-level process documents.
> 
> Overview: General introduction to how the subsystem operates
> Submit Checklist Addendum: Mechanical items that gate submission staging
> Key Cycle Dates:
>  - Last -rc for new feature submissions: Expected lead time for submissions
>  - Last -rc to merge features: Deadline for merge decisions
> Coding Style Addendum: Clarifications of local style preferences
> Resubmit Cadence: When to ping the maintainer
> Checkpatch / Style Cleanups: Policy on pure cleanup patches

So I'm finally back home after my European tour, and I have it on good
authority that my bag might even get here eventually too.  That means I'm
digging through a pile of docs stuff I've been neglecting badly...

My intention is to apply these patches.  But as I was reading through
them, one little nagging thing came to mind...

> See Documentation/maintainer/maintainer-entry-profile.rst for more details,
> and a follow-on example profile for the libnvdimm subsystem.

Thus far, the maintainer guide is focused on how to *be* a maintainer.
This document, instead, is more about how to deal with specific
maintainers.  So I suspect that Documentation/maintainer might be the
wrong place for it.

Should we maybe place it instead under Documentation/process, or even
create a new top-level "book" for this information?

Thanks,

jon
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
  2019-10-01 13:55   ` Jonathan Corbet
@ 2019-10-01 18:17     ` Martin K. Petersen
  2019-11-07 20:13     ` Jonathan Corbet
  1 sibling, 0 replies; 53+ messages in thread
From: Martin K. Petersen @ 2019-10-01 18:17 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: linux-kernel, Thomas Gleixner, Mauro Carvalho Chehab,
	Steve French, Greg Kroah-Hartman, Linus Torvalds,
	Tobin C. Harding, Olof Johansson, Daniel Vetter, Joe Perches,
	Dmitry Vyukov, Alexandre Belloni, linux-nvdimm, ksummit-discuss


Jonathan,

> Thus far, the maintainer guide is focused on how to *be* a maintainer.
> This document, instead, is more about how to deal with specific
> maintainers.  So I suspect that Documentation/maintainer might be the
> wrong place for it.
>
> Should we maybe place it instead under Documentation/process, or even
> create a new top-level "book" for this information?

I think Documentation/process is the right place for all the common
practices and guidelines for code submission. Documentation is already
pretty big. And based on the discussions in this thread, I think we're
better off enhancing the existing process documents instead of
introducing more places for people to look.

-- 
Martin K. Petersen	Oracle Linux Engineering
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
  2019-10-01 13:55   ` Jonathan Corbet
  2019-10-01 18:17     ` Martin K. Petersen
@ 2019-11-07 20:13     ` Jonathan Corbet
  2019-11-08  2:41       ` Dan Williams
  1 sibling, 1 reply; 53+ messages in thread
From: Jonathan Corbet @ 2019-11-07 20:13 UTC (permalink / raw)
  To: Dan Williams
  Cc: linux-kernel, Thomas Gleixner, Mauro Carvalho Chehab,
	Steve French, Greg Kroah-Hartman, Linus Torvalds,
	Tobin C. Harding, Olof Johansson, Daniel Vetter, Joe Perches,
	Dmitry Vyukov, Alexandre Belloni, linux-nvdimm, ksummit-discuss

Hi, Dan,

A month or so ago I wrote...

> > See Documentation/maintainer/maintainer-entry-profile.rst for more details,
> > and a follow-on example profile for the libnvdimm subsystem.  
> 
> Thus far, the maintainer guide is focused on how to *be* a maintainer.
> This document, instead, is more about how to deal with specific
> maintainers.  So I suspect that Documentation/maintainer might be the
> wrong place for it.
> 
> Should we maybe place it instead under Documentation/process, or even
> create a new top-level "book" for this information?

Unless I missed it, I've not heard back from you on this.  I'd like to get
this stuff pulled in for 5.5 if possible...  would you object if I were to
apply your patches, then tack on a move over to the process guide?

Thanks,

jon
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
  2019-11-07 20:13     ` Jonathan Corbet
@ 2019-11-08  2:41       ` Dan Williams
  0 siblings, 0 replies; 53+ messages in thread
From: Dan Williams @ 2019-11-08  2:41 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Linux Kernel Mailing List, Thomas Gleixner,
	Mauro Carvalho Chehab, Steve French, Greg Kroah-Hartman,
	Linus Torvalds, Tobin C. Harding, Olof Johansson, Daniel Vetter,
	Joe Perches, Dmitry Vyukov, Alexandre Belloni, linux-nvdimm,
	ksummit

On Thu, Nov 7, 2019 at 12:13 PM Jonathan Corbet <corbet@lwn.net> wrote:
>
> Hi, Dan,
>
> A month or so ago I wrote...
>
> > > See Documentation/maintainer/maintainer-entry-profile.rst for more details,
> > > and a follow-on example profile for the libnvdimm subsystem.
> >
> > Thus far, the maintainer guide is focused on how to *be* a maintainer.
> > This document, instead, is more about how to deal with specific
> > maintainers.  So I suspect that Documentation/maintainer might be the
> > wrong place for it.
> >
> > Should we maybe place it instead under Documentation/process, or even
> > create a new top-level "book" for this information?
>
> Unless I missed it, I've not heard back from you on this.  I'd like to get
> this stuff pulled in for 5.5 if possible...  would you object if I were to
> apply your patches, then tack on a move over to the process guide?

Sorry for the delay.

Yes, the process book is a better location now that this information
is focused on being supplemental guidelines for submitters rather than
a "how to maintain X subsystem" guide.

I do want to respin this without the Coding Style addendum to address
the specific feedback there, but other than that I'm happy to see this
move forward.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
  2019-09-13 22:03     ` Martin K. Petersen
@ 2020-04-29 13:55       ` Roman Bolshakov
  0 siblings, 0 replies; 53+ messages in thread
From: Roman Bolshakov @ 2020-04-29 13:55 UTC (permalink / raw)
  To: martin.petersen
  Cc: bvanassche, dvyukov, gregkh, ksummit-discuss, linux-kernel,
	linux-nvdimm, mchehab, me, stfrench, Roman Bolshakov

On 9/11/19 5:40 PM, Martin K. Petersen wrote:
> After the Plumbers session last year I wrote this for SCSI based on a
> prior version by Christoph. It's gone a bit stale but I'll update it to
> match your template.
> 

Hi Martin,

The Maintainer profile is very helpful. Are you planning to send another
version and address Bart's comments?

Thanks,
Roman
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

^ permalink raw reply	[flat|nested] 53+ messages in thread

end of thread, other threads:[~2020-04-29 14:01 UTC | newest]

Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-11 15:48 [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
2019-09-11 15:48 ` [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams
2019-09-13 15:37   ` [Ksummit-discuss] " Mauro Carvalho Chehab
2019-09-11 15:48 ` [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
2019-09-11 17:34   ` [Ksummit-discuss] " Verma, Vishal L
2019-09-16 12:35   ` Jani Nikula
2019-10-01 13:55   ` Jonathan Corbet
2019-10-01 18:17     ` Martin K. Petersen
2019-11-07 20:13     ` Jonathan Corbet
2019-11-08  2:41       ` Dan Williams
2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
2019-09-11 17:42   ` [Ksummit-discuss] " Vishal Verma
2019-09-11 17:45   ` Dave Jiang
2019-09-11 18:43   ` [Ksummit-discuss] " Dan Carpenter
2019-09-11 22:11     ` Jens Axboe
2019-09-12  7:41       ` Dan Williams
2019-09-12  8:24         ` Miguel Ojeda
2019-09-12 10:18           ` Joe Perches
2019-09-12 11:02             ` Joe Perches
2019-09-12 14:17               ` Dan Williams
2019-09-12 14:51                 ` Joe Perches
2019-09-12 14:42             ` Miguel Ojeda
2019-09-13  7:09       ` Jonathan Corbet
2019-09-13 11:48         ` Dan Carpenter
2019-09-13 12:18           ` Dan Williams
2019-09-13 15:00           ` Randy Dunlap
2019-09-13 15:46             ` Rob Herring
2019-09-13 16:42               ` Joe Perches
2019-09-13 19:32                 ` Rob Herring
2019-09-13 17:57             ` Geert Uytterhoeven
2019-09-16 12:42           ` Jani Nikula
     [not found]           ` <20190917161608.GA12866@ziepe.ca>
2019-09-17 21:59             ` Dan Williams
2019-09-13 21:44       ` Martin K. Petersen
2019-09-16  7:01         ` Dan Carpenter
2019-09-16 17:08           ` Martin K. Petersen
2019-09-13  2:11     ` Aneesh Kumar K.V
2019-09-13  5:00       ` Greg KH
2019-09-11 20:30   ` Joe Perches
2019-09-11 16:40 ` [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen
2019-09-12 13:31   ` [Ksummit-discuss] " Bart Van Assche
2019-09-12 15:34     ` Joe Perches
2019-09-12 20:01       ` Bart Van Assche
2019-09-12 20:34         ` Joe Perches
2019-09-13 14:26           ` Rob Herring
2019-09-13 18:42             ` Joe Perches
2019-09-13 19:17               ` Mauro Carvalho Chehab
2019-09-13 20:33                 ` Joe Perches
2019-09-13 12:56         ` Matthew Wilcox
2019-09-13 13:54           ` Mauro Carvalho Chehab
2019-09-13 14:59             ` Guenter Roeck
2019-09-13 22:03     ` Martin K. Petersen
2020-04-29 13:55       ` Roman Bolshakov
2019-09-12 13:10 ` Bart Van Assche

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).