* [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
To: linux-kernel
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
Steve French, Vishal Verma, Mauro Carvalho Chehab, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
To: linux-kernel
Cc: Mauro Carvalho Chehab, Dave Jiang, Daniel Vetter, Linus Torvalds,
Dmitry Vyukov, Vishal Verma, Jonathan Corbet, Thomas Gleixner,
Joe Perches, Tobin C. Harding, Alexandre Belloni,
Martin K. Petersen, Greg Kroah-Hartman, Steve French,
Olof Johansson, linux-nvdimm, ksummit-discuss
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-11 15:48 ` Dan Williams
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
To: linux-kernel; +Cc: vishal.l.verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
To: linux-kernel; +Cc: Joe Perches, vishal.l.verma, linux-nvdimm, ksummit-discuss
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
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-11 15:48 ` Dan Williams
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
To: linux-kernel
Cc: vishal.l.verma, ksummit-discuss, Greg Kroah-Hartman,
linux-nvdimm, Dmitry Vyukov, Mauro Carvalho Chehab, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
To: linux-kernel
Cc: Jonathan Corbet, Thomas Gleixner, Mauro Carvalho Chehab,
Steve French, Greg Kroah-Hartman, Linus Torvalds,
Tobin C. Harding, Olof Johansson, Martin K. Petersen,
Daniel Vetter, Joe Perches, Dmitry Vyukov, Alexandre Belloni,
vishal.l.verma, linux-nvdimm, ksummit-discuss
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
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-11 15:48 ` Dan Williams
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
To: linux-kernel; +Cc: Vishal Verma, Dave Jiang, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 15:48 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-11 15:48 UTC (permalink / raw)
To: linux-kernel; +Cc: Vishal Verma, Dave Jiang, linux-nvdimm, ksummit-discuss
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
^ permalink raw reply related [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-11 16:40 ` Martin K. Petersen
-1 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-09-11 16:40 UTC (permalink / raw)
To: Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, linux-kernel,
Greg Kroah-Hartman, Steve French, Vishal Verma,
Mauro Carvalho Chehab, 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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-11 16:40 ` Martin K. Petersen
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-11 16:40 ` Martin K. Petersen
0 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-09-11 16:40 UTC (permalink / raw)
To: Dan Williams
Cc: linux-kernel, Mauro Carvalho Chehab, Dave Jiang, Daniel Vetter,
Linus Torvalds, Dmitry Vyukov, Vishal Verma, Jonathan Corbet,
Thomas Gleixner, Joe Perches, Tobin C. Harding,
Alexandre Belloni, Martin K. Petersen, Greg Kroah-Hartman,
Steve French, Olof Johansson, linux-nvdimm, ksummit-discuss
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.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
@ 2019-09-11 17:34 ` Verma, Vishal L
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-09-11 17:34 ` Verma, Vishal L
0 siblings, 0 replies; 227+ messages in thread
From: Verma, Vishal L @ 2019-09-11 17:34 UTC (permalink / raw)
To: Williams, Dan J, linux-kernel
Cc: me, stfrench, ksummit-discuss, linux-nvdimm, gregkh, mchehab, dvyukov
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/ ?
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-11 17:42 ` Vishal Verma
-1 siblings, 0 replies; 227+ messages in thread
From: Vishal Verma @ 2019-09-11 17:42 UTC (permalink / raw)
To: Dan Williams, linux-kernel; +Cc: Dave Jiang, 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>
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 17:42 ` Vishal Verma
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 17:42 ` Vishal Verma
0 siblings, 0 replies; 227+ messages in thread
From: Vishal Verma @ 2019-09-11 17:42 UTC (permalink / raw)
To: Dan Williams, linux-kernel; +Cc: Dave Jiang, 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>
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
@ 2019-09-11 17:45 ` Dave Jiang
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 17:45 ` Dave Jiang
0 siblings, 0 replies; 227+ messages in thread
From: Dave Jiang @ 2019-09-11 17:45 UTC (permalink / raw)
To: Dan Williams, linux-kernel; +Cc: Vishal Verma, linux-nvdimm, ksummit-discuss
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
>
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-11 18:43 ` Dan Carpenter
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-11 18:43 UTC (permalink / raw)
To: Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 18:43 ` Dan Carpenter
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 18:43 ` Dan Carpenter
0 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-11 18:43 UTC (permalink / raw)
To: Dan Williams
Cc: linux-kernel, Vishal Verma, Dave Jiang, ksummit-discuss,
linux-nvdimm, 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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-11 20:30 ` Joe Perches
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-11 20:30 UTC (permalink / raw)
To: Dan Williams, linux-kernel
Cc: Vishal Verma, Dave Jiang, 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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 20:30 ` Joe Perches
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 20:30 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-11 20:30 UTC (permalink / raw)
To: Dan Williams, linux-kernel
Cc: Vishal Verma, Dave Jiang, 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.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 18:43 ` Dan Carpenter
(?)
@ 2019-09-11 22:11 ` Jens Axboe
-1 siblings, 0 replies; 227+ messages in thread
From: Jens Axboe @ 2019-09-11 22:11 UTC (permalink / raw)
To: Dan Carpenter, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 22:11 ` Jens Axboe
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-11 22:11 ` Jens Axboe
0 siblings, 0 replies; 227+ messages in thread
From: Jens Axboe @ 2019-09-11 22:11 UTC (permalink / raw)
To: Dan Carpenter, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-12 7:41 UTC (permalink / raw)
To: Jens Axboe
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma,
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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 7:41 ` Dan Williams
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 7:41 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-12 7:41 UTC (permalink / raw)
To: Jens Axboe
Cc: Dan Carpenter, Dave Jiang, ksummit, linux-nvdimm, Vishal Verma,
Linux Kernel Mailing List, bpf
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.
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 8:24 ` Miguel Ojeda
0 siblings, 0 replies; 227+ messages in thread
From: Miguel Ojeda @ 2019-09-12 8:24 UTC (permalink / raw)
To: Dan Williams
Cc: Jens Axboe, Dan Carpenter, Dave Jiang, ksummit, linux-nvdimm,
Vishal Verma, Linux Kernel Mailing List, bpf
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-12 10:18 UTC (permalink / raw)
To: Miguel Ojeda, Dan Williams
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma,
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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 10:18 ` Joe Perches
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 10:18 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-12 10:18 UTC (permalink / raw)
To: Miguel Ojeda, Dan Williams
Cc: Jens Axboe, Dan Carpenter, Dave Jiang, ksummit, linux-nvdimm,
Vishal Verma, Linux Kernel Mailing List, bpf
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.
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 11:02 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-12 11:02 UTC (permalink / raw)
To: Miguel Ojeda, Dan Williams
Cc: Dan Carpenter, linux-nvdimm, Vishal Verma, Linux Kernel Mailing List
(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);
^ permalink raw reply related [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-12 13:10 ` Bart Van Assche
-1 siblings, 0 replies; 227+ messages in thread
From: Bart Van Assche @ 2019-09-12 13:10 UTC (permalink / raw)
To: Dan Williams, linux-kernel
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
Dmitry Vyukov, Vishal Verma, 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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 13:10 ` Bart Van Assche
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 13:10 ` Bart Van Assche
0 siblings, 0 replies; 227+ messages in thread
From: Bart Van Assche @ 2019-09-12 13:10 UTC (permalink / raw)
To: Dan Williams, linux-kernel
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
Steve French, Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov,
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.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
2019-09-11 16:40 ` Martin K. Petersen
(?)
@ 2019-09-12 13:31 ` Bart Van Assche
-1 siblings, 0 replies; 227+ messages in thread
From: Bart Van Assche @ 2019-09-12 13:31 UTC (permalink / raw)
To: Martin K. Petersen, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Dmitry Vyukov, Vishal Verma, 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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 13:31 ` Bart Van Assche
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 13:31 ` Bart Van Assche
0 siblings, 0 replies; 227+ messages in thread
From: Bart Van Assche @ 2019-09-12 13:31 UTC (permalink / raw)
To: Martin K. Petersen, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, linux-kernel,
Greg Kroah-Hartman, Steve French, Vishal Verma,
Mauro Carvalho Chehab, Dmitry Vyukov, 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.
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 14:17 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-12 14:17 UTC (permalink / raw)
To: Joe Perches
Cc: Miguel Ojeda, Dan Carpenter, linux-nvdimm, Vishal Verma,
Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 227+ 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 14:42 ` Miguel Ojeda
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 14:42 ` Miguel Ojeda
0 siblings, 0 replies; 227+ messages in thread
From: Miguel Ojeda @ 2019-09-12 14:42 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Williams, Jens Axboe, Dan Carpenter, Dave Jiang, ksummit,
linux-nvdimm, Vishal Verma, Linux Kernel Mailing List, bpf
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-12 14:51 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-12 14:51 UTC (permalink / raw)
To: Dan Williams
Cc: Miguel Ojeda, Dan Carpenter, linux-nvdimm, Vishal Verma,
Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
2019-09-12 13:31 ` Bart Van Assche
(?)
@ 2019-09-12 15:34 ` Joe Perches
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-12 15:34 UTC (permalink / raw)
To: Bart Van Assche, Martin K. Petersen, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Steve French, Vishal Verma, 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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 15:34 ` Joe Perches
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 15:34 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-12 15:34 UTC (permalink / raw)
To: Bart Van Assche, Martin K. Petersen, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Dmitry Vyukov, Vishal Verma, Mauro Carvalho Chehab,
Steve French, 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.
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Bart Van Assche @ 2019-09-12 20:01 UTC (permalink / raw)
To: Joe Perches, Martin K. Petersen, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Steve French, Vishal Verma, 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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 20:01 ` Bart Van Assche
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 20:01 ` Bart Van Assche
0 siblings, 0 replies; 227+ messages in thread
From: Bart Van Assche @ 2019-09-12 20:01 UTC (permalink / raw)
To: Joe Perches, Martin K. Petersen, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Dmitry Vyukov, Vishal Verma, Mauro Carvalho Chehab,
Steve French, 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.
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-12 20:34 UTC (permalink / raw)
To: Bart Van Assche, Martin K. Petersen, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Steve French, Vishal Verma, 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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 20:34 ` Joe Perches
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-12 20:34 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-12 20:34 UTC (permalink / raw)
To: Bart Van Assche, Martin K. Petersen, Dan Williams
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Dmitry Vyukov, Vishal Verma, Mauro Carvalho Chehab,
Steve French, 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.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 18:43 ` Dan Carpenter
@ 2019-09-13 2:11 ` Aneesh Kumar K.V
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 2:11 ` Aneesh Kumar K.V
0 siblings, 0 replies; 227+ messages in thread
From: Aneesh Kumar K.V @ 2019-09-13 2:11 UTC (permalink / raw)
To: Dan Carpenter, Dan Williams
Cc: Dave Jiang, linux-nvdimm, Vishal Verma, linux-kernel, bpf
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 5:00 ` Greg KH
0 siblings, 0 replies; 227+ messages in thread
From: Greg KH @ 2019-09-13 5:00 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Dan Carpenter, Dan Williams, Dave Jiang, linux-nvdimm,
Vishal Verma, linux-kernel, bpf
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 22:11 ` Jens Axboe
(?)
@ 2019-09-13 7:09 ` Jonathan Corbet
-1 siblings, 0 replies; 227+ messages in thread
From: Jonathan Corbet @ 2019-09-13 7:09 UTC (permalink / raw)
To: Jens Axboe
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 7:09 ` Jonathan Corbet
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 7:09 ` Jonathan Corbet
0 siblings, 0 replies; 227+ messages in thread
From: Jonathan Corbet @ 2019-09-13 7:09 UTC (permalink / raw)
To: Jens Axboe
Cc: Dan Carpenter, Dan Williams, Dave Jiang, ksummit-discuss,
linux-nvdimm, Vishal Verma, linux-kernel, bpf
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-13 11:48 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 11:48 ` Dan Carpenter
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 11:48 ` Dan Carpenter
0 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-13 11:48 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Jens Axboe, Dan Williams, Dave Jiang, ksummit-discuss,
linux-nvdimm, Vishal Verma, 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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-13 12:18 UTC (permalink / raw)
To: Dan Carpenter
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma,
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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 12:18 ` Dan Williams
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 12:18 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-13 12:18 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jonathan Corbet, Jens Axboe, Dave Jiang, ksummit, linux-nvdimm,
Vishal Verma, 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.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
2019-09-12 20:01 ` Bart Van Assche
@ 2019-09-13 12:56 ` Matthew Wilcox
-1 siblings, 0 replies; 227+ messages in thread
From: Matthew Wilcox @ 2019-09-13 12:56 UTC (permalink / raw)
To: Bart Van Assche
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Dmitry Vyukov, Vishal Verma, Mauro Carvalho Chehab,
Steve French, Tobin C. Harding
[-- Attachment #1.1: Type: text/plain, Size: 1305 bytes --]
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
>
[-- Attachment #1.2: Type: text/html, Size: 1939 bytes --]
[-- Attachment #2: Type: text/plain, Size: 186 bytes --]
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 12:56 ` Matthew Wilcox
0 siblings, 0 replies; 227+ 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] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 13:54 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Dave Jiang, Bart Van Assche, ksummit-discuss, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, Dmitry Vyukov,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 13:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 13:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 13:54 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Bart Van Assche, Joe Perches, Martin K . Petersen, Dan Williams,
Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Steve French, Vishal Verma, Dmitry Vyukov,
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Rob Herring @ 2019-09-13 14:26 UTC (permalink / raw)
To: Joe Perches
Cc: Dave Jiang, Bart Van Assche, ksummit, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 14:26 ` Rob Herring
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 14:26 ` Rob Herring
0 siblings, 0 replies; 227+ messages in thread
From: Rob Herring @ 2019-09-13 14:26 UTC (permalink / raw)
To: Joe Perches
Cc: Bart Van Assche, Martin K. Petersen, Dan Williams, Dave Jiang,
ksummit, linux-nvdimm, Greg Kroah-Hartman, linux-kernel,
Steve French, Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov,
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Guenter Roeck @ 2019-09-13 14:59 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Dave Jiang, Bart Van Assche, ksummit-discuss, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Steve French, Vishal Verma,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 14:59 ` Guenter Roeck
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 14:59 ` Guenter Roeck
0 siblings, 0 replies; 227+ messages in thread
From: Guenter Roeck @ 2019-09-13 14:59 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Matthew Wilcox, Dave Jiang, Bart Van Assche, ksummit-discuss,
linux-nvdimm, Greg Kroah-Hartman, linux-kernel, Vishal Verma,
Dmitry Vyukov, Steve French, 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
^ permalink raw reply [flat|nested] 227+ 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 15:00 ` Randy Dunlap
-1 siblings, 0 replies; 227+ messages in thread
From: Randy Dunlap @ 2019-09-13 15:00 UTC (permalink / raw)
To: Dan Carpenter, Jonathan Corbet
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 15:00 ` Randy Dunlap
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 15:00 ` Randy Dunlap
0 siblings, 0 replies; 227+ messages in thread
From: Randy Dunlap @ 2019-09-13 15:00 UTC (permalink / raw)
To: Dan Carpenter, Jonathan Corbet
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-13 15:37 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 15:37 UTC (permalink / raw)
To: Dan Williams; +Cc: vishal.l.verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
@ 2019-09-13 15:37 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
@ 2019-09-13 15:37 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 15:37 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-kernel, vishal.l.verma, 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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Rob Herring @ 2019-09-13 15:46 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 15:46 ` Rob Herring
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 15:46 ` Rob Herring
0 siblings, 0 replies; 227+ messages in thread
From: Rob Herring @ 2019-09-13 15:46 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dan Carpenter, Jonathan Corbet, Dave Jiang, ksummit,
linux-nvdimm, Vishal Verma, linux-kernel, bpf
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-13 16:19 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 16:19 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab, ksummit-discuss
Document the basic policies of the media subsystem profile.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
That's basically a modified version of:
https://patchwork.linuxtv.org/patch/52999/
Applied to the new template
Documentation/media/index.rst | 1 +
.../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 142 insertions(+)
create mode 100644 Documentation/media/maintainer-entry-profile.rst
diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index 0301c25ff887..ac94685b822a 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
.. toctree::
:maxdepth: 2
+ maintainer-entry-profile
media_uapi
media_kapi
dvb-drivers/index
diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
new file mode 100644
index 000000000000..81d3b0f9c36a
--- /dev/null
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -0,0 +1,140 @@
+Media Subsystem Profile
+=======================
+
+Overview
+--------
+
+The media subsystem cover support for a variety of devices: stream
+capture, analog and digital TV, cameras, remote controllers, HDMI CEC
+and media pipeline control.
+
+It covers, mainly, the contents of those directories:
+
+ - drivers/media
+ - drivers/staging/media
+ - Documentation/media
+ - include/media
+
+Both media userspace and Kernel APIs are documented and should be kept in
+sync with the API changes. It means that all patches that add new
+features to the subsystem should also bring changes to the corresponding
+API files.
+
+Also, patches for device drivers that changes the Open Firmware/Device
+Tree bindings should be reviewed by the Device Tree maintainers.
+
+Due to the size and wide scope of the media subsystem, media's
+maintainership model is to have sub-maintainers that have a broad
+knowledge of an specific aspect of the subsystem. It is a
+sub-maintainers task to review the patches, providing feedback to users
+if the patches are following the subsystem rules and are properly using
+the media internal and external APIs.
+
+Patches for the media subsystem should be sent to the media mailing list
+at linux-media@vger.kernel.org as plain text only e-mail. Emails with
+HTML will be automatically rejected by the mail server. There's no need
+to copy the maintainer or sub-maintainer(s).
+
+Media's workflow is heavily based on Patchwork, meaning that, once a patch
+is submitted, it should appear at:
+
+ - https://patchwork.linuxtv.org/project/linux-media/list/
+
+If it doesn't automatically appear there after a few minutes, then
+probably something got wrong on your submission. Please check if the
+email is in plain text only and if your emailer is not mangling with
+whitespaces before complaining or submit it again.
+
+Sub-maintainers
++++++++++++++++
+
+At the media subsystem, we have a group of senior developers that are
+responsible for doing the code reviews at the drivers (called
+sub-maintainers), and another senior developer responsible for the
+subsystem as a hole. For core changes, whenever possible, multiple
+media (sub-)maintainers do the review.
+
+The sub-maintainers work on specific areas of the subsystem, as
+described below:
+
+Digital TV:
+ Sean Young <sean@mess.org>
+
+HDMI CEC:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Media controller drivers:
+ Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+Remote Controllers:
+ Sean Young <sean@mess.org>
+
+Sensor drivers:
+ Sakari Ailus <sakari.ailus@linux.intel.com>
+
+V4L2 drivers:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Submit Checklist Addendum
+-------------------------
+
+There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
+that should be used in order to check if the drivers are properly
+implementing the media APIs.
+
+Those tests need to be passed before the patches go upstream.
+
+Also, please notice that we build the Kernel with::
+
+ make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
+
+Where the check script is::
+
+ #!/bin/bash
+ /devel/smatch/smatch -p=kernel $@ >&2
+ /devel/sparse/sparse $@ >&2
+
+Be sure to not introduce new warnings on your patches.
+
+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 -rc5, and ideally stabilized
+in the linux-media branch by -rc6.
+
+Coding Style Addendum
+---------------------
+
+Media development uses checkpatch on strict mode to verify the code style, e. g.::
+
+ $ ./script/checkpatch.pl --strict
+
+Review Cadence
+--------------
+
+Provided that your patch is at https://patchwork.linuxtv.org, it should
+be sooner or later handled, so you don't need to re-submit a patch.
+
+Except for bug fixes, we don't usually add new patches to the development
+tree between -rc6 and the next -rc1.
+
+Please notice that the media subsystem is a high traffic one, so it
+could take a while for us to be able to review your patches. Feel free
+to ping if you don't get a feedback on a couple of weeks or to ask
+other developers to publicly add Reviewed-by and, more importantly,
+Tested-by tags.
+
+Please notice that we expect a detailed description for Tested-by,
+identifying what boards were used at the test and what it was tested.
+
+Style Cleanup Patches
+---------------------
+
+Style-cleanups are welcome when they come together with other changes
+at the files where the style changes will affect.
+
+We may accept pure standalone style-cleanups, but they should be grouped
+per directory. So, for example, if you're doing a cleanup at drivers
+under drivers/media, please send a single patch for all drivers under
+drivers/media/pci, another one for drivers/media/usb and so on.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c62b45201d7..e7f44ec05a42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10077,6 +10077,7 @@ W: https://linuxtv.org
Q: http://patchwork.kernel.org/project/linux-media/list/
T: git git://linuxtv.org/media_tree.git
S: Maintained
+P: Documentation/media/maintainer-entry-profile.rst
F: Documentation/devicetree/bindings/media/
F: Documentation/media/
F: drivers/media/
--
2.21.0
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-13 16:19 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 16:19 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab, ksummit-discuss
Document the basic policies of the media subsystem profile.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
That's basically a modified version of:
https://patchwork.linuxtv.org/patch/52999/
Applied to the new template
Documentation/media/index.rst | 1 +
.../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 142 insertions(+)
create mode 100644 Documentation/media/maintainer-entry-profile.rst
diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index 0301c25ff887..ac94685b822a 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
.. toctree::
:maxdepth: 2
+ maintainer-entry-profile
media_uapi
media_kapi
dvb-drivers/index
diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
new file mode 100644
index 000000000000..81d3b0f9c36a
--- /dev/null
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -0,0 +1,140 @@
+Media Subsystem Profile
+=======================
+
+Overview
+--------
+
+The media subsystem cover support for a variety of devices: stream
+capture, analog and digital TV, cameras, remote controllers, HDMI CEC
+and media pipeline control.
+
+It covers, mainly, the contents of those directories:
+
+ - drivers/media
+ - drivers/staging/media
+ - Documentation/media
+ - include/media
+
+Both media userspace and Kernel APIs are documented and should be kept in
+sync with the API changes. It means that all patches that add new
+features to the subsystem should also bring changes to the corresponding
+API files.
+
+Also, patches for device drivers that changes the Open Firmware/Device
+Tree bindings should be reviewed by the Device Tree maintainers.
+
+Due to the size and wide scope of the media subsystem, media's
+maintainership model is to have sub-maintainers that have a broad
+knowledge of an specific aspect of the subsystem. It is a
+sub-maintainers task to review the patches, providing feedback to users
+if the patches are following the subsystem rules and are properly using
+the media internal and external APIs.
+
+Patches for the media subsystem should be sent to the media mailing list
+at linux-media@vger.kernel.org as plain text only e-mail. Emails with
+HTML will be automatically rejected by the mail server. There's no need
+to copy the maintainer or sub-maintainer(s).
+
+Media's workflow is heavily based on Patchwork, meaning that, once a patch
+is submitted, it should appear at:
+
+ - https://patchwork.linuxtv.org/project/linux-media/list/
+
+If it doesn't automatically appear there after a few minutes, then
+probably something got wrong on your submission. Please check if the
+email is in plain text only and if your emailer is not mangling with
+whitespaces before complaining or submit it again.
+
+Sub-maintainers
++++++++++++++++
+
+At the media subsystem, we have a group of senior developers that are
+responsible for doing the code reviews at the drivers (called
+sub-maintainers), and another senior developer responsible for the
+subsystem as a hole. For core changes, whenever possible, multiple
+media (sub-)maintainers do the review.
+
+The sub-maintainers work on specific areas of the subsystem, as
+described below:
+
+Digital TV:
+ Sean Young <sean@mess.org>
+
+HDMI CEC:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Media controller drivers:
+ Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+Remote Controllers:
+ Sean Young <sean@mess.org>
+
+Sensor drivers:
+ Sakari Ailus <sakari.ailus@linux.intel.com>
+
+V4L2 drivers:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Submit Checklist Addendum
+-------------------------
+
+There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
+that should be used in order to check if the drivers are properly
+implementing the media APIs.
+
+Those tests need to be passed before the patches go upstream.
+
+Also, please notice that we build the Kernel with::
+
+ make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
+
+Where the check script is::
+
+ #!/bin/bash
+ /devel/smatch/smatch -p=kernel $@ >&2
+ /devel/sparse/sparse $@ >&2
+
+Be sure to not introduce new warnings on your patches.
+
+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 -rc5, and ideally stabilized
+in the linux-media branch by -rc6.
+
+Coding Style Addendum
+---------------------
+
+Media development uses checkpatch on strict mode to verify the code style, e. g.::
+
+ $ ./script/checkpatch.pl --strict
+
+Review Cadence
+--------------
+
+Provided that your patch is at https://patchwork.linuxtv.org, it should
+be sooner or later handled, so you don't need to re-submit a patch.
+
+Except for bug fixes, we don't usually add new patches to the development
+tree between -rc6 and the next -rc1.
+
+Please notice that the media subsystem is a high traffic one, so it
+could take a while for us to be able to review your patches. Feel free
+to ping if you don't get a feedback on a couple of weeks or to ask
+other developers to publicly add Reviewed-by and, more importantly,
+Tested-by tags.
+
+Please notice that we expect a detailed description for Tested-by,
+identifying what boards were used at the test and what it was tested.
+
+Style Cleanup Patches
+---------------------
+
+Style-cleanups are welcome when they come together with other changes
+at the files where the style changes will affect.
+
+We may accept pure standalone style-cleanups, but they should be grouped
+per directory. So, for example, if you're doing a cleanup at drivers
+under drivers/media, please send a single patch for all drivers under
+drivers/media/pci, another one for drivers/media/usb and so on.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c62b45201d7..e7f44ec05a42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10077,6 +10077,7 @@ W: https://linuxtv.org
Q: http://patchwork.kernel.org/project/linux-media/list/
T: git git://linuxtv.org/media_tree.git
S: Maintained
+P: Documentation/media/maintainer-entry-profile.rst
F: Documentation/devicetree/bindings/media/
F: Documentation/media/
F: drivers/media/
--
2.21.0
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [PATCH] media: add a subsystem profile documentation
@ 2019-09-13 16:19 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 16:19 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Dan Williams,
ksummit-discuss
Document the basic policies of the media subsystem profile.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
That's basically a modified version of:
https://patchwork.linuxtv.org/patch/52999/
Applied to the new template
Documentation/media/index.rst | 1 +
.../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 142 insertions(+)
create mode 100644 Documentation/media/maintainer-entry-profile.rst
diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index 0301c25ff887..ac94685b822a 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
.. toctree::
:maxdepth: 2
+ maintainer-entry-profile
media_uapi
media_kapi
dvb-drivers/index
diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
new file mode 100644
index 000000000000..81d3b0f9c36a
--- /dev/null
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -0,0 +1,140 @@
+Media Subsystem Profile
+=======================
+
+Overview
+--------
+
+The media subsystem cover support for a variety of devices: stream
+capture, analog and digital TV, cameras, remote controllers, HDMI CEC
+and media pipeline control.
+
+It covers, mainly, the contents of those directories:
+
+ - drivers/media
+ - drivers/staging/media
+ - Documentation/media
+ - include/media
+
+Both media userspace and Kernel APIs are documented and should be kept in
+sync with the API changes. It means that all patches that add new
+features to the subsystem should also bring changes to the corresponding
+API files.
+
+Also, patches for device drivers that changes the Open Firmware/Device
+Tree bindings should be reviewed by the Device Tree maintainers.
+
+Due to the size and wide scope of the media subsystem, media's
+maintainership model is to have sub-maintainers that have a broad
+knowledge of an specific aspect of the subsystem. It is a
+sub-maintainers task to review the patches, providing feedback to users
+if the patches are following the subsystem rules and are properly using
+the media internal and external APIs.
+
+Patches for the media subsystem should be sent to the media mailing list
+at linux-media@vger.kernel.org as plain text only e-mail. Emails with
+HTML will be automatically rejected by the mail server. There's no need
+to copy the maintainer or sub-maintainer(s).
+
+Media's workflow is heavily based on Patchwork, meaning that, once a patch
+is submitted, it should appear at:
+
+ - https://patchwork.linuxtv.org/project/linux-media/list/
+
+If it doesn't automatically appear there after a few minutes, then
+probably something got wrong on your submission. Please check if the
+email is in plain text only and if your emailer is not mangling with
+whitespaces before complaining or submit it again.
+
+Sub-maintainers
++++++++++++++++
+
+At the media subsystem, we have a group of senior developers that are
+responsible for doing the code reviews at the drivers (called
+sub-maintainers), and another senior developer responsible for the
+subsystem as a hole. For core changes, whenever possible, multiple
+media (sub-)maintainers do the review.
+
+The sub-maintainers work on specific areas of the subsystem, as
+described below:
+
+Digital TV:
+ Sean Young <sean@mess.org>
+
+HDMI CEC:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Media controller drivers:
+ Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+Remote Controllers:
+ Sean Young <sean@mess.org>
+
+Sensor drivers:
+ Sakari Ailus <sakari.ailus@linux.intel.com>
+
+V4L2 drivers:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Submit Checklist Addendum
+-------------------------
+
+There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
+that should be used in order to check if the drivers are properly
+implementing the media APIs.
+
+Those tests need to be passed before the patches go upstream.
+
+Also, please notice that we build the Kernel with::
+
+ make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
+
+Where the check script is::
+
+ #!/bin/bash
+ /devel/smatch/smatch -p=kernel $@ >&2
+ /devel/sparse/sparse $@ >&2
+
+Be sure to not introduce new warnings on your patches.
+
+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 -rc5, and ideally stabilized
+in the linux-media branch by -rc6.
+
+Coding Style Addendum
+---------------------
+
+Media development uses checkpatch on strict mode to verify the code style, e. g.::
+
+ $ ./script/checkpatch.pl --strict
+
+Review Cadence
+--------------
+
+Provided that your patch is at https://patchwork.linuxtv.org, it should
+be sooner or later handled, so you don't need to re-submit a patch.
+
+Except for bug fixes, we don't usually add new patches to the development
+tree between -rc6 and the next -rc1.
+
+Please notice that the media subsystem is a high traffic one, so it
+could take a while for us to be able to review your patches. Feel free
+to ping if you don't get a feedback on a couple of weeks or to ask
+other developers to publicly add Reviewed-by and, more importantly,
+Tested-by tags.
+
+Please notice that we expect a detailed description for Tested-by,
+identifying what boards were used at the test and what it was tested.
+
+Style Cleanup Patches
+---------------------
+
+Style-cleanups are welcome when they come together with other changes
+at the files where the style changes will affect.
+
+We may accept pure standalone style-cleanups, but they should be grouped
+per directory. So, for example, if you're doing a cleanup at drivers
+under drivers/media, please send a single patch for all drivers under
+drivers/media/pci, another one for drivers/media/usb and so on.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c62b45201d7..e7f44ec05a42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10077,6 +10077,7 @@ W: https://linuxtv.org
Q: http://patchwork.kernel.org/project/linux-media/list/
T: git git://linuxtv.org/media_tree.git
S: Maintained
+P: Documentation/media/maintainer-entry-profile.rst
F: Documentation/devicetree/bindings/media/
F: Documentation/media/
F: drivers/media/
--
2.21.0
^ permalink raw reply related [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-13 16:42 UTC (permalink / raw)
To: Rob Herring, Randy Dunlap
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, 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/
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 16:42 ` Joe Perches
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 16:42 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-13 16:42 UTC (permalink / raw)
To: Rob Herring, Randy Dunlap
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, 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/
^ permalink raw reply [flat|nested] 227+ 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 17:57 ` Geert Uytterhoeven
-1 siblings, 0 replies; 227+ messages in thread
From: Geert Uytterhoeven @ 2019-09-13 17:57 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 17:57 ` Geert Uytterhoeven
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 17:57 ` Geert Uytterhoeven
0 siblings, 0 replies; 227+ messages in thread
From: Geert Uytterhoeven @ 2019-09-13 17:57 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dan Carpenter, Jonathan Corbet, Dave Jiang, ksummit,
linux-nvdimm, Vishal Verma, Linux Kernel Mailing List, bpf
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-13 18:42 UTC (permalink / raw)
To: Rob Herring
Cc: Dave Jiang, Bart Van Assche, ksummit, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 18:42 ` Joe Perches
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 18:42 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-13 18:42 UTC (permalink / raw)
To: Rob Herring
Cc: Bart Van Assche, Martin K. Petersen, Dan Williams, Dave Jiang,
ksummit, linux-nvdimm, Greg Kroah-Hartman, linux-kernel,
Steve French, Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov,
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 19:17 UTC (permalink / raw)
To: Joe Perches
Cc: Dave Jiang, Bart Van Assche, ksummit, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 19:17 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 19:17 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-13 19:17 UTC (permalink / raw)
To: Joe Perches
Cc: Rob Herring, Bart Van Assche, Martin K. Petersen, Dan Williams,
Dave Jiang, ksummit, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Steve French, Vishal Verma, Dmitry Vyukov,
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Rob Herring @ 2019-09-13 19:32 UTC (permalink / raw)
To: Joe Perches
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 19:32 ` Rob Herring
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 19:32 ` Rob Herring
0 siblings, 0 replies; 227+ messages in thread
From: Rob Herring @ 2019-09-13 19:32 UTC (permalink / raw)
To: Joe Perches
Cc: Randy Dunlap, Dave Jiang, ksummit, linux-nvdimm, Vishal Verma,
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-13 20:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Dave Jiang, Bart Van Assche, ksummit, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, 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]
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 20:33 ` Joe Perches
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 20:33 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-13 20:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Rob Herring, Bart Van Assche, Martin K. Petersen, Dan Williams,
Dave Jiang, ksummit, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Steve French, Vishal Verma, Dmitry Vyukov,
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]
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-11 22:11 ` Jens Axboe
(?)
@ 2019-09-13 21:44 ` Martin K. Petersen
-1 siblings, 0 replies; 227+ 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 21:44 ` Martin K. Petersen
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-13 21:44 ` Martin K. Petersen
0 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-09-13 21:44 UTC (permalink / raw)
To: Jens Axboe
Cc: Dan Carpenter, Dan Williams, ksummit-discuss, linux-nvdimm,
linux-kernel, bpf
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
2019-09-12 13:31 ` Bart Van Assche
(?)
@ 2019-09-13 22:03 ` Martin K. Petersen
-1 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-09-13 22:03 UTC (permalink / raw)
To: Bart Van Assche
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Greg Kroah-Hartman,
linux-kernel, Dmitry Vyukov, Vishal Verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 22:03 ` Martin K. Petersen
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2019-09-13 22:03 ` Martin K. Petersen
0 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-09-13 22:03 UTC (permalink / raw)
To: Bart Van Assche
Cc: Martin K. Petersen, Dan Williams, Dave Jiang, ksummit-discuss,
linux-nvdimm, linux-kernel, Greg Kroah-Hartman, Steve French,
Vishal Verma, Mauro Carvalho Chehab, Dmitry Vyukov,
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-16 7:01 UTC (permalink / raw)
To: Martin K. Petersen; +Cc: 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-16 7:01 ` Dan Carpenter
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-16 7:01 ` Dan Carpenter
0 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-16 7:01 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Jens Axboe, ksummit-discuss, linux-nvdimm, linux-kernel, bpf
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-09-16 12:35 ` Jani Nikula
-1 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-16 12:35 UTC (permalink / raw)
To: Dan Williams, linux-kernel
Cc: ksummit-discuss, linux-nvdimm, vishal.l.verma, 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-09-16 12:35 ` Jani Nikula
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-09-16 12:35 ` Jani Nikula
0 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-16 12:35 UTC (permalink / raw)
To: Dan Williams, linux-kernel
Cc: vishal.l.verma, ksummit-discuss, Greg Kroah-Hartman,
linux-nvdimm, Dmitry Vyukov, Mauro Carvalho Chehab, Steve French,
Tobin C. Harding, Jonathan Corbet
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-13 11:48 ` Dan Carpenter
(?)
@ 2019-09-16 12:42 ` Jani Nikula
-1 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-16 12:42 UTC (permalink / raw)
To: Dan Carpenter, Jonathan Corbet
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-16 12:42 ` Jani Nikula
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-16 12:42 ` Jani Nikula
0 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-16 12:42 UTC (permalink / raw)
To: Dan Carpenter, Jonathan Corbet
Cc: Dave Jiang, ksummit-discuss, linux-nvdimm, Vishal Verma,
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
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-09-16 17:08 UTC (permalink / raw)
To: Dan Carpenter; +Cc: 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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-16 17:08 ` Martin K. Petersen
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-16 17:08 ` Martin K. Petersen
0 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-09-16 17:08 UTC (permalink / raw)
To: Dan Carpenter
Cc: Martin K. Petersen, 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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-16 17:08 ` Martin K. Petersen
@ 2019-09-16 17:15 ` Mark Brown
-1 siblings, 0 replies; 227+ messages in thread
From: Mark Brown @ 2019-09-16 17:15 UTC (permalink / raw)
To: Martin K. Petersen
Cc: linux-kernel, bpf, ksummit-discuss, Dan Carpenter, linux-nvdimm
[-- Attachment #1.1: Type: text/plain, Size: 801 bytes --]
On Mon, Sep 16, 2019 at 01:08:45PM -0400, Martin K. Petersen wrote:
> 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.
I get the impression that a lot of vendors just don't distinguish and
only really care about getting things upstream, especially in the
embedded world many of them realistically expect to be shipping a pile
of out of tree patches to anyone using anything other than mainline
anyway so it's not super clear to them that it's worthwhile. This goes
back to the converstations about stable and how vendors interact with
that.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 186 bytes --]
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-16 17:15 ` Mark Brown
0 siblings, 0 replies; 227+ messages in thread
From: Mark Brown @ 2019-09-16 17:15 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Dan Carpenter, ksummit-discuss, linux-nvdimm, linux-kernel, bpf
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
On Mon, Sep 16, 2019 at 01:08:45PM -0400, Martin K. Petersen wrote:
> 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.
I get the impression that a lot of vendors just don't distinguish and
only really care about getting things upstream, especially in the
embedded world many of them realistically expect to be shipping a pile
of out of tree patches to anyone using anything other than mainline
anyway so it's not super clear to them that it's worthwhile. This goes
back to the converstations about stable and how vendors interact with
that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 227+ messages in thread
* [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-13 16:19 ` [Ksummit-discuss] " Mauro Carvalho Chehab
@ 2019-09-17 3:35 ` Kees Cook
-1 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-17 3:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List
On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> Document the basic policies of the media subsystem profile.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> That's basically a modified version of:
> https://patchwork.linuxtv.org/patch/52999/
>
> Applied to the new template
>
> Documentation/media/index.rst | 1 +
> .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
One idea I proposed to Dan at the Maintainer's Summit was to collect all
the profiles is a single directory in Documentation/, since there are
two ways someone would want to read profiles:
1) a single profile, based on a MAINTAINERS entry which includes the path
2) all of them, to study for various reasons
The #2 case is helped by having them all in one directory with a single
index.rst, etc. Then similar profiles are able to merge, etc.
--
Kees Cook
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* single maintainer profile directory (was Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation)
@ 2019-09-17 3:35 ` Kees Cook
0 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-17 3:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, ksummit-discuss, Dan Williams
On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> Document the basic policies of the media subsystem profile.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> That's basically a modified version of:
> https://patchwork.linuxtv.org/patch/52999/
>
> Applied to the new template
>
> Documentation/media/index.rst | 1 +
> .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
One idea I proposed to Dan at the Maintainer's Summit was to collect all
the profiles is a single directory in Documentation/, since there are
two ways someone would want to read profiles:
1) a single profile, based on a MAINTAINERS entry which includes the path
2) all of them, to study for various reasons
The #2 case is helped by having them all in one directory with a single
index.rst, etc. Then similar profiles are able to merge, etc.
--
Kees Cook
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-17 3:35 ` single maintainer profile directory (was Re: [Ksummit-discuss] " Kees Cook
@ 2019-09-17 13:28 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-17 13:28 UTC (permalink / raw)
To: Kees Cook; +Cc: ksummit-discuss, Linux Media Mailing List
Hi Kees,
Em Mon, 16 Sep 2019 20:35:45 -0700
Kees Cook <keescook@chromium.org> escreveu:
> On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> >
> > That's basically a modified version of:
> > https://patchwork.linuxtv.org/patch/52999/
> >
> > Applied to the new template
> >
> > Documentation/media/index.rst | 1 +
> > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
>
> One idea I proposed to Dan at the Maintainer's Summit was to collect all
> the profiles is a single directory in Documentation/,
No matter where the profiles will physically be stored, its contents belong
to subsystem-specific documentation, and should be visible at the same index
file as the kAPI docs is located, as anyone interested on submitting patches
for a subsystem should be aware about the subsystem specific policies and
details.
So, my vote is to store them at Documentation/*/<subsystem> (together
with the kAPI book).
> since there are
> two ways someone would want to read profiles:
>
> 1) a single profile, based on a MAINTAINERS entry which includes the path
That is the common case. The problem is that the MAINTAINERS file
currently doesn't generate html output. This is not a problem for
"old school" devs, but a newbie wanting to collaborate to a single
specific subsystem may not notice - or understand - the importance
of the MAINTAINERS file[1].
[1] btw, that's why I submitted a RFC, several years ago, a patch
converting it to ReST - and later - another patch that would be parsing
its contents and producing a ReST output.
That's, by far, the most relevant usecase for the profiles, as the
audience is the ~4k Kernel developers.
> 2) all of them, to study for various reasons
I suspect that only core people will have interest on study them.
Those people are more skilled, and can easily find all those files with
a simple grep:
$ grep "^P:\s" MAINTAINERS|cut -d':' -f2-
or
$ git grep "^P:\s" MAINTAINERS|cut -d: -f3-
If, for whatever reason, he would prefer an HTML output [1], he could even
create an index file with all of those with something like:
$ for i in $(grep "^P:\s" MAINTAINERS|cut -d':' -f2-); do j=${i/rst/html}; echo "<a href=\"$j\">$j</a><br/>"; done >Documentation/output/index_profiles.html
We might, instead, teach the Documentation/Makefile to create something
like the above, but, IMHO, that would just add more complexity to the
build without a good reason.
[1] I doubt that core devs would prefer seeing this in html form, but some
variant of the above could be used, for example, to create symlinks for
all profile docs into a "study" directory.
> The #2 case is helped by having them all in one directory with a single
> index.rst, etc. Then similar profiles are able to merge, etc.
Thanks,
Mauro
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: single maintainer profile directory (was Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation)
@ 2019-09-17 13:28 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-17 13:28 UTC (permalink / raw)
To: Kees Cook; +Cc: Linux Media Mailing List, ksummit-discuss, Dan Williams
Hi Kees,
Em Mon, 16 Sep 2019 20:35:45 -0700
Kees Cook <keescook@chromium.org> escreveu:
> On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> >
> > That's basically a modified version of:
> > https://patchwork.linuxtv.org/patch/52999/
> >
> > Applied to the new template
> >
> > Documentation/media/index.rst | 1 +
> > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
>
> One idea I proposed to Dan at the Maintainer's Summit was to collect all
> the profiles is a single directory in Documentation/,
No matter where the profiles will physically be stored, its contents belong
to subsystem-specific documentation, and should be visible at the same index
file as the kAPI docs is located, as anyone interested on submitting patches
for a subsystem should be aware about the subsystem specific policies and
details.
So, my vote is to store them at Documentation/*/<subsystem> (together
with the kAPI book).
> since there are
> two ways someone would want to read profiles:
>
> 1) a single profile, based on a MAINTAINERS entry which includes the path
That is the common case. The problem is that the MAINTAINERS file
currently doesn't generate html output. This is not a problem for
"old school" devs, but a newbie wanting to collaborate to a single
specific subsystem may not notice - or understand - the importance
of the MAINTAINERS file[1].
[1] btw, that's why I submitted a RFC, several years ago, a patch
converting it to ReST - and later - another patch that would be parsing
its contents and producing a ReST output.
That's, by far, the most relevant usecase for the profiles, as the
audience is the ~4k Kernel developers.
> 2) all of them, to study for various reasons
I suspect that only core people will have interest on study them.
Those people are more skilled, and can easily find all those files with
a simple grep:
$ grep "^P:\s" MAINTAINERS|cut -d':' -f2-
or
$ git grep "^P:\s" MAINTAINERS|cut -d: -f3-
If, for whatever reason, he would prefer an HTML output [1], he could even
create an index file with all of those with something like:
$ for i in $(grep "^P:\s" MAINTAINERS|cut -d':' -f2-); do j=${i/rst/html}; echo "<a href=\"$j\">$j</a><br/>"; done >Documentation/output/index_profiles.html
We might, instead, teach the Documentation/Makefile to create something
like the above, but, IMHO, that would just add more complexity to the
build without a good reason.
[1] I doubt that core devs would prefer seeing this in html form, but some
variant of the above could be used, for example, to create symlinks for
all profile docs into a "study" directory.
> The #2 case is helped by having them all in one directory with a single
> index.rst, etc. Then similar profiles are able to merge, etc.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-13 11:48 ` Dan Carpenter
` (4 preceding siblings ...)
(?)
@ 2019-09-17 16:16 ` Jason Gunthorpe
2019-09-17 21:59 ` Dan Williams
-1 siblings, 1 reply; 227+ messages in thread
From: Jason Gunthorpe @ 2019-09-17 16:16 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jonathan Corbet, Jens Axboe, Dan Williams, Dave Jiang,
ksummit-discuss, linux-nvdimm, Vishal Verma, linux-kernel, bpf
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?
Jason
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-17 13:28 ` single maintainer profile directory (was Re: [Ksummit-discuss] " Mauro Carvalho Chehab
@ 2019-09-17 16:33 ` Kees Cook
-1 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-17 16:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List
On Tue, Sep 17, 2019 at 10:28:17AM -0300, Mauro Carvalho Chehab wrote:
> No matter where the profiles will physically be stored, its contents belong
> to subsystem-specific documentation, and should be visible at the same index
> file as the kAPI docs is located, as anyone interested on submitting patches
> for a subsystem should be aware about the subsystem specific policies and
> details.
That's a good point. I think your other suggestions below address my
"find them all" case...
> So, my vote is to store them at Documentation/*/<subsystem> (together
> with the kAPI book).
>
> > since there are
> > two ways someone would want to read profiles:
> >
> > 1) a single profile, based on a MAINTAINERS entry which includes the path
>
> That is the common case. The problem is that the MAINTAINERS file
> currently doesn't generate html output. This is not a problem for
> "old school" devs, but a newbie wanting to collaborate to a single
> specific subsystem may not notice - or understand - the importance
> of the MAINTAINERS file[1].
>
> [1] btw, that's why I submitted a RFC, several years ago, a patch
> converting it to ReST - and later - another patch that would be parsing
> its contents and producing a ReST output.
>
> That's, by far, the most relevant usecase for the profiles, as the
> audience is the ~4k Kernel developers.
Oh yes, having a .rst of the MAINTAINERS file would be pretty great.
Seems like it could just be a build target (and then dependency) for the
sphinx targets?
> > 2) all of them, to study for various reasons
>
> I suspect that only core people will have interest on study them.
>
> Those people are more skilled, and can easily find all those files with
> a simple grep:
>
> $ grep "^P:\s" MAINTAINERS|cut -d':' -f2-
>
> or
>
> $ git grep "^P:\s" MAINTAINERS|cut -d: -f3-
>
> If, for whatever reason, he would prefer an HTML output [1], he could even
> create an index file with all of those with something like:
>
> $ for i in $(grep "^P:\s" MAINTAINERS|cut -d':' -f2-); do j=${i/rst/html}; echo "<a href=\"$j\">$j</a><br/>"; done >Documentation/output/index_profiles.html
>
> We might, instead, teach the Documentation/Makefile to create something
> like the above, but, IMHO, that would just add more complexity to the
> build without a good reason.
>
> [1] I doubt that core devs would prefer seeing this in html form, but some
> variant of the above could be used, for example, to create symlinks for
> all profile docs into a "study" directory.
>
> > The #2 case is helped by having them all in one directory with a single
> > index.rst, etc. Then similar profiles are able to merge, etc.
Whatever the case, please don't let me distract from the actual content
of these profiles: I think it's awesome to capture these details and
makes my life so much easier. :)
--
Kees Cook
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: single maintainer profile directory (was Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation)
@ 2019-09-17 16:33 ` Kees Cook
0 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-17 16:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, ksummit-discuss, Dan Williams
On Tue, Sep 17, 2019 at 10:28:17AM -0300, Mauro Carvalho Chehab wrote:
> No matter where the profiles will physically be stored, its contents belong
> to subsystem-specific documentation, and should be visible at the same index
> file as the kAPI docs is located, as anyone interested on submitting patches
> for a subsystem should be aware about the subsystem specific policies and
> details.
That's a good point. I think your other suggestions below address my
"find them all" case...
> So, my vote is to store them at Documentation/*/<subsystem> (together
> with the kAPI book).
>
> > since there are
> > two ways someone would want to read profiles:
> >
> > 1) a single profile, based on a MAINTAINERS entry which includes the path
>
> That is the common case. The problem is that the MAINTAINERS file
> currently doesn't generate html output. This is not a problem for
> "old school" devs, but a newbie wanting to collaborate to a single
> specific subsystem may not notice - or understand - the importance
> of the MAINTAINERS file[1].
>
> [1] btw, that's why I submitted a RFC, several years ago, a patch
> converting it to ReST - and later - another patch that would be parsing
> its contents and producing a ReST output.
>
> That's, by far, the most relevant usecase for the profiles, as the
> audience is the ~4k Kernel developers.
Oh yes, having a .rst of the MAINTAINERS file would be pretty great.
Seems like it could just be a build target (and then dependency) for the
sphinx targets?
> > 2) all of them, to study for various reasons
>
> I suspect that only core people will have interest on study them.
>
> Those people are more skilled, and can easily find all those files with
> a simple grep:
>
> $ grep "^P:\s" MAINTAINERS|cut -d':' -f2-
>
> or
>
> $ git grep "^P:\s" MAINTAINERS|cut -d: -f3-
>
> If, for whatever reason, he would prefer an HTML output [1], he could even
> create an index file with all of those with something like:
>
> $ for i in $(grep "^P:\s" MAINTAINERS|cut -d':' -f2-); do j=${i/rst/html}; echo "<a href=\"$j\">$j</a><br/>"; done >Documentation/output/index_profiles.html
>
> We might, instead, teach the Documentation/Makefile to create something
> like the above, but, IMHO, that would just add more complexity to the
> build without a good reason.
>
> [1] I doubt that core devs would prefer seeing this in html form, but some
> variant of the above could be used, for example, to create symlinks for
> all profile docs into a "study" directory.
>
> > The #2 case is helped by having them all in one directory with a single
> > index.rst, etc. Then similar profiles are able to merge, etc.
Whatever the case, please don't let me distract from the actual content
of these profiles: I think it's awesome to capture these details and
makes my life so much easier. :)
--
Kees Cook
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
2019-09-17 16:16 ` Jason Gunthorpe
2019-09-17 21:59 ` Dan Williams
@ 2019-09-17 21:59 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-17 21:59 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Dave Jiang, ksummit, linux-nvdimm, Vishal Verma,
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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-17 21:59 ` Dan Williams
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
@ 2019-09-17 21:59 ` Dan Williams
0 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-09-17 21:59 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Dan Carpenter, Jonathan Corbet, Jens Axboe, Dave Jiang, ksummit,
linux-nvdimm, Vishal Verma, Linux Kernel Mailing List, bpf
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.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-17 16:33 ` single maintainer profile directory (was Re: [Ksummit-discuss] " Kees Cook
@ 2019-09-18 11:23 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 11:23 UTC (permalink / raw)
To: Kees Cook; +Cc: ksummit-discuss, Linux Media Mailing List
Em Tue, 17 Sep 2019 09:33:11 -0700
Kees Cook <keescook@chromium.org> escreveu:
> On Tue, Sep 17, 2019 at 10:28:17AM -0300, Mauro Carvalho Chehab wrote:
> > No matter where the profiles will physically be stored, its contents belong
> > to subsystem-specific documentation, and should be visible at the same index
> > file as the kAPI docs is located, as anyone interested on submitting patches
> > for a subsystem should be aware about the subsystem specific policies and
> > details.
>
> That's a good point. I think your other suggestions below address my
> "find them all" case...
>
> > So, my vote is to store them at Documentation/*/<subsystem> (together
> > with the kAPI book).
> >
> > > since there are
> > > two ways someone would want to read profiles:
> > >
> > > 1) a single profile, based on a MAINTAINERS entry which includes the path
> >
> > That is the common case. The problem is that the MAINTAINERS file
> > currently doesn't generate html output. This is not a problem for
> > "old school" devs, but a newbie wanting to collaborate to a single
> > specific subsystem may not notice - or understand - the importance
> > of the MAINTAINERS file[1].
> >
> > [1] btw, that's why I submitted a RFC, several years ago, a patch
> > converting it to ReST - and later - another patch that would be parsing
> > its contents and producing a ReST output.
> >
> > That's, by far, the most relevant usecase for the profiles, as the
> > audience is the ~4k Kernel developers.
>
> Oh yes, having a .rst of the MAINTAINERS file would be pretty great.
> Seems like it could just be a build target (and then dependency) for the
> sphinx targets?
You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,
as:
- The instructions at the top will be badly parsed;
- It will also parse wrong the entries.
On the patches I wrote several years ago, I fixed the instructions
to make them to produce something that would produce a good output.
That's the easiest part.
For the entries contents, the simplest solution would be something like:
diff --git a/MAINTAINERS b/MAINTAINERS
index 6b4bc320e6ab..ae2afb14ae01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -147,4 +147,4 @@ F: drivers/net/ethernet/3com/3c59x.c
-M: David Dillow <dave@thedillows.org>
-L: netdev@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/3com/typhoon*
+:M: David Dillow <dave@thedillows.org>
+:L: netdev@vger.kernel.org
+:S: Maintained
+:F: drivers/net/ethernet/3com/typhoon*
A trivial change for a normal file, but doing this at MAINTAINERS
will be really painful, as it will cause lots of conflicts.
So, IMO, the best way to do it is to have a script (or to teach
get_maintainers.pl) to produce a ReST output that would do the
above.
The latest RFC about that with I sent was this one:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html
I would probably address this on a different way those days.
A simple/lazy solution would be to apply the enclosed patch - or a
variant of it that would place the contents of MAINTAINERS outside
process/index.html, and add instructions about how to use
get_maintainers.pl.
Jon,
Please let me know if you're willing to accept something like that.
Thanks,
Mauro
[PATCH RFC] docs: process: add MAINTAINERS file contents
Anyone working with the Kernel need to consider the contents of the
MAINTAINERS file. So, add it to the ReST output.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index e2c9ffc682c5..22e5b42b8470 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -59,6 +59,9 @@ lack of a better place.
volatile-considered-harmful
clang-format
+.. include:: ../../MAINTAINERS
+ :literal:
+
.. only:: subproject and html
Indices
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
@ 2019-09-18 11:23 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 11:23 UTC (permalink / raw)
To: Kees Cook; +Cc: ksummit-discuss, Linux Media Mailing List, Jonathan Corbet
Em Tue, 17 Sep 2019 09:33:11 -0700
Kees Cook <keescook@chromium.org> escreveu:
> On Tue, Sep 17, 2019 at 10:28:17AM -0300, Mauro Carvalho Chehab wrote:
> > No matter where the profiles will physically be stored, its contents belong
> > to subsystem-specific documentation, and should be visible at the same index
> > file as the kAPI docs is located, as anyone interested on submitting patches
> > for a subsystem should be aware about the subsystem specific policies and
> > details.
>
> That's a good point. I think your other suggestions below address my
> "find them all" case...
>
> > So, my vote is to store them at Documentation/*/<subsystem> (together
> > with the kAPI book).
> >
> > > since there are
> > > two ways someone would want to read profiles:
> > >
> > > 1) a single profile, based on a MAINTAINERS entry which includes the path
> >
> > That is the common case. The problem is that the MAINTAINERS file
> > currently doesn't generate html output. This is not a problem for
> > "old school" devs, but a newbie wanting to collaborate to a single
> > specific subsystem may not notice - or understand - the importance
> > of the MAINTAINERS file[1].
> >
> > [1] btw, that's why I submitted a RFC, several years ago, a patch
> > converting it to ReST - and later - another patch that would be parsing
> > its contents and producing a ReST output.
> >
> > That's, by far, the most relevant usecase for the profiles, as the
> > audience is the ~4k Kernel developers.
>
> Oh yes, having a .rst of the MAINTAINERS file would be pretty great.
> Seems like it could just be a build target (and then dependency) for the
> sphinx targets?
You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,
as:
- The instructions at the top will be badly parsed;
- It will also parse wrong the entries.
On the patches I wrote several years ago, I fixed the instructions
to make them to produce something that would produce a good output.
That's the easiest part.
For the entries contents, the simplest solution would be something like:
diff --git a/MAINTAINERS b/MAINTAINERS
index 6b4bc320e6ab..ae2afb14ae01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -147,4 +147,4 @@ F: drivers/net/ethernet/3com/3c59x.c
-M: David Dillow <dave@thedillows.org>
-L: netdev@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/3com/typhoon*
+:M: David Dillow <dave@thedillows.org>
+:L: netdev@vger.kernel.org
+:S: Maintained
+:F: drivers/net/ethernet/3com/typhoon*
A trivial change for a normal file, but doing this at MAINTAINERS
will be really painful, as it will cause lots of conflicts.
So, IMO, the best way to do it is to have a script (or to teach
get_maintainers.pl) to produce a ReST output that would do the
above.
The latest RFC about that with I sent was this one:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html
I would probably address this on a different way those days.
A simple/lazy solution would be to apply the enclosed patch - or a
variant of it that would place the contents of MAINTAINERS outside
process/index.html, and add instructions about how to use
get_maintainers.pl.
Jon,
Please let me know if you're willing to accept something like that.
Thanks,
Mauro
[PATCH RFC] docs: process: add MAINTAINERS file contents
Anyone working with the Kernel need to consider the contents of the
MAINTAINERS file. So, add it to the ReST output.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index e2c9ffc682c5..22e5b42b8470 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -59,6 +59,9 @@ lack of a better place.
volatile-considered-harmful
clang-format
+.. include:: ../../MAINTAINERS
+ :literal:
+
.. only:: subproject and html
Indices
^ permalink raw reply related [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-13 16:19 ` [Ksummit-discuss] " Mauro Carvalho Chehab
@ 2019-09-18 12:36 ` Laurent Pinchart
-1 siblings, 0 replies; 227+ messages in thread
From: Laurent Pinchart @ 2019-09-18 12:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List
Hi Mauro,
On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> Document the basic policies of the media subsystem profile.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> That's basically a modified version of:
> https://patchwork.linuxtv.org/patch/52999/
>
> Applied to the new template
>
> Documentation/media/index.rst | 1 +
> .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 142 insertions(+)
> create mode 100644 Documentation/media/maintainer-entry-profile.rst
>
> diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> index 0301c25ff887..ac94685b822a 100644
> --- a/Documentation/media/index.rst
> +++ b/Documentation/media/index.rst
> @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> .. toctree::
> :maxdepth: 2
>
> + maintainer-entry-profile
> media_uapi
> media_kapi
> dvb-drivers/index
> diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> new file mode 100644
> index 000000000000..81d3b0f9c36a
> --- /dev/null
> +++ b/Documentation/media/maintainer-entry-profile.rst
> @@ -0,0 +1,140 @@
> +Media Subsystem Profile
> +=======================
> +
> +Overview
> +--------
> +
> +The media subsystem cover support for a variety of devices: stream
s/cover/covers/
> +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> +and media pipeline control.
> +
> +It covers, mainly, the contents of those directories:
> +
> + - drivers/media
> + - drivers/staging/media
> + - Documentation/media
> + - include/media
> +
> +Both media userspace and Kernel APIs are documented and should be kept in
> +sync with the API changes. It means that all patches that add new
> +features to the subsystem should also bring changes to the corresponding
> +API files.
> +
> +Also, patches for device drivers that changes the Open Firmware/Device
> +Tree bindings should be reviewed by the Device Tree maintainers.
You may want to make it clear that this covers bindings only, not driver
code that parses the DT. I would just remove "for device drivers", as
the rule should also apply to DT bindings documentation that is not
driver-specific.
> +Due to the size and wide scope of the media subsystem, media's
> +maintainership model is to have sub-maintainers that have a broad
> +knowledge of an specific aspect of the subsystem. It is a
> +sub-maintainers task to review the patches, providing feedback to users
s/sub-maintainers/sub-maintainer's/
> +if the patches are following the subsystem rules and are properly using
> +the media internal and external APIs.
> +
> +Patches for the media subsystem should be sent to the media mailing list
> +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> +HTML will be automatically rejected by the mail server. There's no need
> +to copy the maintainer or sub-maintainer(s).
There's too much traffic on mailing lists for me to follow everything, I
much prefer being CC'ed on patches.
> +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> +is submitted, it should appear at:
> +
> + - https://patchwork.linuxtv.org/project/linux-media/list/
> +
> +If it doesn't automatically appear there after a few minutes, then
> +probably something got wrong on your submission. Please check if the
> +email is in plain text only and if your emailer is not mangling with
> +whitespaces before complaining or submit it again.
> +
> +Sub-maintainers
> ++++++++++++++++
> +
> +At the media subsystem, we have a group of senior developers that are
How about "experienced" instead of "senior" ? Quality doesn't always
come with age, neither for people nor wine :-)
> +responsible for doing the code reviews at the drivers (called
> +sub-maintainers), and another senior developer responsible for the
> +subsystem as a hole. For core changes, whenever possible, multiple
> +media (sub-)maintainers do the review.
> +
> +The sub-maintainers work on specific areas of the subsystem, as
> +described below:
> +
> +Digital TV:
> + Sean Young <sean@mess.org>
> +
> +HDMI CEC:
> + Hans Verkuil <hverkuil@xs4all.nl>
> +
> +Media controller drivers:
> + Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +Remote Controllers:
> + Sean Young <sean@mess.org>
> +
> +Sensor drivers:
> + Sakari Ailus <sakari.ailus@linux.intel.com>
> +
> +V4L2 drivers:
> + Hans Verkuil <hverkuil@xs4all.nl>
> +
> +Submit Checklist Addendum
> +-------------------------
> +
> +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> +that should be used in order to check if the drivers are properly
> +implementing the media APIs.
> +
> +Those tests need to be passed before the patches go upstream.
s/need to be passed/need to pass/
> +
> +Also, please notice that we build the Kernel with::
> +
> + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> +
> +Where the check script is::
> +
> + #!/bin/bash
> + /devel/smatch/smatch -p=kernel $@ >&2
> + /devel/sparse/sparse $@ >&2
> +
> +Be sure to not introduce new warnings on your patches.
While static analysers deliver value, I fear this is a high barrier to
entry for new contributors.
> +
> +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 -rc5, and ideally stabilized
> +in the linux-media branch by -rc6.
> +
> +Coding Style Addendum
> +---------------------
> +
> +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> +
> + $ ./script/checkpatch.pl --strict
But we still accept some warnings. I think this should be documented.
> +
> +Review Cadence
> +--------------
> +
> +Provided that your patch is at https://patchwork.linuxtv.org, it should
> +be sooner or later handled, so you don't need to re-submit a patch.
> +
> +Except for bug fixes, we don't usually add new patches to the development
> +tree between -rc6 and the next -rc1.
> +
> +Please notice that the media subsystem is a high traffic one, so it
> +could take a while for us to be able to review your patches. Feel free
> +to ping if you don't get a feedback on a couple of weeks or to ask
s/on a/in a/
> +other developers to publicly add Reviewed-by and, more importantly,
> +Tested-by tags.
> +
> +Please notice that we expect a detailed description for Tested-by,
s/notice/note/
> +identifying what boards were used at the test and what it was tested.
> +
> +Style Cleanup Patches
> +---------------------
> +
> +Style-cleanups are welcome when they come together with other changes
> +at the files where the style changes will affect.
> +
> +We may accept pure standalone style-cleanups, but they should be grouped
> +per directory. So, for example, if you're doing a cleanup at drivers
> +under drivers/media, please send a single patch for all drivers under
> +drivers/media/pci, another one for drivers/media/usb and so on.
How about also stating that if the cleanup is low volume, a single patch
for the whole subsystem is preferred ? I think that should actually be
the rule, with a split to ease review only when the patch would be too
big.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7c62b45201d7..e7f44ec05a42 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10077,6 +10077,7 @@ W: https://linuxtv.org
> Q: http://patchwork.kernel.org/project/linux-media/list/
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> +P: Documentation/media/maintainer-entry-profile.rst
> F: Documentation/devicetree/bindings/media/
> F: Documentation/media/
> F: drivers/media/
--
Regards,
Laurent Pinchart
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-18 12:36 ` Laurent Pinchart
0 siblings, 0 replies; 227+ messages in thread
From: Laurent Pinchart @ 2019-09-18 12:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, ksummit-discuss
Hi Mauro,
On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> Document the basic policies of the media subsystem profile.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> That's basically a modified version of:
> https://patchwork.linuxtv.org/patch/52999/
>
> Applied to the new template
>
> Documentation/media/index.rst | 1 +
> .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 142 insertions(+)
> create mode 100644 Documentation/media/maintainer-entry-profile.rst
>
> diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> index 0301c25ff887..ac94685b822a 100644
> --- a/Documentation/media/index.rst
> +++ b/Documentation/media/index.rst
> @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> .. toctree::
> :maxdepth: 2
>
> + maintainer-entry-profile
> media_uapi
> media_kapi
> dvb-drivers/index
> diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> new file mode 100644
> index 000000000000..81d3b0f9c36a
> --- /dev/null
> +++ b/Documentation/media/maintainer-entry-profile.rst
> @@ -0,0 +1,140 @@
> +Media Subsystem Profile
> +=======================
> +
> +Overview
> +--------
> +
> +The media subsystem cover support for a variety of devices: stream
s/cover/covers/
> +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> +and media pipeline control.
> +
> +It covers, mainly, the contents of those directories:
> +
> + - drivers/media
> + - drivers/staging/media
> + - Documentation/media
> + - include/media
> +
> +Both media userspace and Kernel APIs are documented and should be kept in
> +sync with the API changes. It means that all patches that add new
> +features to the subsystem should also bring changes to the corresponding
> +API files.
> +
> +Also, patches for device drivers that changes the Open Firmware/Device
> +Tree bindings should be reviewed by the Device Tree maintainers.
You may want to make it clear that this covers bindings only, not driver
code that parses the DT. I would just remove "for device drivers", as
the rule should also apply to DT bindings documentation that is not
driver-specific.
> +Due to the size and wide scope of the media subsystem, media's
> +maintainership model is to have sub-maintainers that have a broad
> +knowledge of an specific aspect of the subsystem. It is a
> +sub-maintainers task to review the patches, providing feedback to users
s/sub-maintainers/sub-maintainer's/
> +if the patches are following the subsystem rules and are properly using
> +the media internal and external APIs.
> +
> +Patches for the media subsystem should be sent to the media mailing list
> +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> +HTML will be automatically rejected by the mail server. There's no need
> +to copy the maintainer or sub-maintainer(s).
There's too much traffic on mailing lists for me to follow everything, I
much prefer being CC'ed on patches.
> +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> +is submitted, it should appear at:
> +
> + - https://patchwork.linuxtv.org/project/linux-media/list/
> +
> +If it doesn't automatically appear there after a few minutes, then
> +probably something got wrong on your submission. Please check if the
> +email is in plain text only and if your emailer is not mangling with
> +whitespaces before complaining or submit it again.
> +
> +Sub-maintainers
> ++++++++++++++++
> +
> +At the media subsystem, we have a group of senior developers that are
How about "experienced" instead of "senior" ? Quality doesn't always
come with age, neither for people nor wine :-)
> +responsible for doing the code reviews at the drivers (called
> +sub-maintainers), and another senior developer responsible for the
> +subsystem as a hole. For core changes, whenever possible, multiple
> +media (sub-)maintainers do the review.
> +
> +The sub-maintainers work on specific areas of the subsystem, as
> +described below:
> +
> +Digital TV:
> + Sean Young <sean@mess.org>
> +
> +HDMI CEC:
> + Hans Verkuil <hverkuil@xs4all.nl>
> +
> +Media controller drivers:
> + Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +Remote Controllers:
> + Sean Young <sean@mess.org>
> +
> +Sensor drivers:
> + Sakari Ailus <sakari.ailus@linux.intel.com>
> +
> +V4L2 drivers:
> + Hans Verkuil <hverkuil@xs4all.nl>
> +
> +Submit Checklist Addendum
> +-------------------------
> +
> +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> +that should be used in order to check if the drivers are properly
> +implementing the media APIs.
> +
> +Those tests need to be passed before the patches go upstream.
s/need to be passed/need to pass/
> +
> +Also, please notice that we build the Kernel with::
> +
> + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> +
> +Where the check script is::
> +
> + #!/bin/bash
> + /devel/smatch/smatch -p=kernel $@ >&2
> + /devel/sparse/sparse $@ >&2
> +
> +Be sure to not introduce new warnings on your patches.
While static analysers deliver value, I fear this is a high barrier to
entry for new contributors.
> +
> +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 -rc5, and ideally stabilized
> +in the linux-media branch by -rc6.
> +
> +Coding Style Addendum
> +---------------------
> +
> +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> +
> + $ ./script/checkpatch.pl --strict
But we still accept some warnings. I think this should be documented.
> +
> +Review Cadence
> +--------------
> +
> +Provided that your patch is at https://patchwork.linuxtv.org, it should
> +be sooner or later handled, so you don't need to re-submit a patch.
> +
> +Except for bug fixes, we don't usually add new patches to the development
> +tree between -rc6 and the next -rc1.
> +
> +Please notice that the media subsystem is a high traffic one, so it
> +could take a while for us to be able to review your patches. Feel free
> +to ping if you don't get a feedback on a couple of weeks or to ask
s/on a/in a/
> +other developers to publicly add Reviewed-by and, more importantly,
> +Tested-by tags.
> +
> +Please notice that we expect a detailed description for Tested-by,
s/notice/note/
> +identifying what boards were used at the test and what it was tested.
> +
> +Style Cleanup Patches
> +---------------------
> +
> +Style-cleanups are welcome when they come together with other changes
> +at the files where the style changes will affect.
> +
> +We may accept pure standalone style-cleanups, but they should be grouped
> +per directory. So, for example, if you're doing a cleanup at drivers
> +under drivers/media, please send a single patch for all drivers under
> +drivers/media/pci, another one for drivers/media/usb and so on.
How about also stating that if the cleanup is low volume, a single patch
for the whole subsystem is preferred ? I think that should actually be
the rule, with a split to ease review only when the patch would be too
big.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7c62b45201d7..e7f44ec05a42 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10077,6 +10077,7 @@ W: https://linuxtv.org
> Q: http://patchwork.kernel.org/project/linux-media/list/
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> +P: Documentation/media/maintainer-entry-profile.rst
> F: Documentation/devicetree/bindings/media/
> F: Documentation/media/
> F: drivers/media/
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-18 12:36 ` Laurent Pinchart
@ 2019-09-18 13:57 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 13:57 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ksummit-discuss, Linux Media Mailing List
Em Wed, 18 Sep 2019 15:36:20 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Mauro,
>
> On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> >
> > That's basically a modified version of:
> > https://patchwork.linuxtv.org/patch/52999/
> >
> > Applied to the new template
> >
> > Documentation/media/index.rst | 1 +
> > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
> > MAINTAINERS | 1 +
> > 3 files changed, 142 insertions(+)
> > create mode 100644 Documentation/media/maintainer-entry-profile.rst
> >
> > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > index 0301c25ff887..ac94685b822a 100644
> > --- a/Documentation/media/index.rst
> > +++ b/Documentation/media/index.rst
> > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> > .. toctree::
> > :maxdepth: 2
> >
> > + maintainer-entry-profile
> > media_uapi
> > media_kapi
> > dvb-drivers/index
> > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> > new file mode 100644
> > index 000000000000..81d3b0f9c36a
> > --- /dev/null
> > +++ b/Documentation/media/maintainer-entry-profile.rst
> > @@ -0,0 +1,140 @@
> > +Media Subsystem Profile
> > +=======================
> > +
> > +Overview
> > +--------
> > +
> > +The media subsystem cover support for a variety of devices: stream
>
> s/cover/covers/
>
> > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> > +and media pipeline control.
> > +
> > +It covers, mainly, the contents of those directories:
> > +
> > + - drivers/media
> > + - drivers/staging/media
> > + - Documentation/media
> > + - include/media
> > +
> > +Both media userspace and Kernel APIs are documented and should be kept in
> > +sync with the API changes. It means that all patches that add new
> > +features to the subsystem should also bring changes to the corresponding
> > +API files.
> > +
> > +Also, patches for device drivers that changes the Open Firmware/Device
> > +Tree bindings should be reviewed by the Device Tree maintainers.
>
> You may want to make it clear that this covers bindings only, not driver
> code that parses the DT. I would just remove "for device drivers", as
> the rule should also apply to DT bindings documentation that is not
> driver-specific.
>
> > +Due to the size and wide scope of the media subsystem, media's
> > +maintainership model is to have sub-maintainers that have a broad
> > +knowledge of an specific aspect of the subsystem. It is a
> > +sub-maintainers task to review the patches, providing feedback to users
>
> s/sub-maintainers/sub-maintainer's/
>
> > +if the patches are following the subsystem rules and are properly using
> > +the media internal and external APIs.
> > +
> > +Patches for the media subsystem should be sent to the media mailing list
> > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > +HTML will be automatically rejected by the mail server. There's no need
> > +to copy the maintainer or sub-maintainer(s).
>
> There's too much traffic on mailing lists for me to follow everything, I
> much prefer being CC'ed on patches.
Well, by using patchwork, the best is to take a look on it at least for
the patches that you're interested. You could script something using
pwclient in order to make it easier.
Anyway, not sure if the other sub-maintainers see the same way. From my side,
I prefer not to be c/c, as this is just more noise, as I just rely on
patchwork for media patches. What about changing this to:
Patches for the media subsystem should be sent to the media mailing list
at linux-media@vger.kernel.org as plain text only e-mail. Emails with
HTML will be automatically rejected by the mail server. It could be wise
to also copy the sub-maintainer(s).
>
> > +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> > +is submitted, it should appear at:
> > +
> > + - https://patchwork.linuxtv.org/project/linux-media/list/
> > +
> > +If it doesn't automatically appear there after a few minutes, then
> > +probably something got wrong on your submission. Please check if the
> > +email is in plain text only and if your emailer is not mangling with
> > +whitespaces before complaining or submit it again.
> > +
> > +Sub-maintainers
> > ++++++++++++++++
> > +
> > +At the media subsystem, we have a group of senior developers that are
>
> How about "experienced" instead of "senior" ? Quality doesn't always
> come with age, neither for people nor wine :-)
>
> > +responsible for doing the code reviews at the drivers (called
> > +sub-maintainers), and another senior developer responsible for the
> > +subsystem as a hole. For core changes, whenever possible, multiple
> > +media (sub-)maintainers do the review.
> > +
> > +The sub-maintainers work on specific areas of the subsystem, as
> > +described below:
> > +
> > +Digital TV:
> > + Sean Young <sean@mess.org>
> > +
> > +HDMI CEC:
> > + Hans Verkuil <hverkuil@xs4all.nl>
> > +
> > +Media controller drivers:
> > + Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > +
> > +Remote Controllers:
> > + Sean Young <sean@mess.org>
> > +
> > +Sensor drivers:
> > + Sakari Ailus <sakari.ailus@linux.intel.com>
> > +
> > +V4L2 drivers:
> > + Hans Verkuil <hverkuil@xs4all.nl>
> > +
> > +Submit Checklist Addendum
> > +-------------------------
> > +
> > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> > +that should be used in order to check if the drivers are properly
> > +implementing the media APIs.
> > +
> > +Those tests need to be passed before the patches go upstream.
>
> s/need to be passed/need to pass/
>
> > +
> > +Also, please notice that we build the Kernel with::
> > +
> > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> > +
> > +Where the check script is::
> > +
> > + #!/bin/bash
> > + /devel/smatch/smatch -p=kernel $@ >&2
> > + /devel/sparse/sparse $@ >&2
> > +
> > +Be sure to not introduce new warnings on your patches.
>
> While static analysers deliver value, I fear this is a high barrier to
> entry for new contributors.
Will change this to:
Be sure to not introduce new warnings on your patches without a
very good reason.
Especially for new contributors, I really expect patches to not introduce
new warnings, as it is usually a lot more painful to fix them later than
to ask devs to do things right at the first place.
>
> > +
> > +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 -rc5, and ideally stabilized
> > +in the linux-media branch by -rc6.
> > +
> > +Coding Style Addendum
> > +---------------------
> > +
> > +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> > +
> > + $ ./script/checkpatch.pl --strict
>
> But we still accept some warnings. I think this should be documented.
True, but not sure if we should enter into too specific details here.
What about adding something like:
Please notice that the goal here is to improve code readability. On a few
cases, checkpatch may actually point to something that would look worse.
So, you should use good send sense here, being prepared to justify any
coding style decision.
Please also notice that, on some cases, when you fix one issue, you may
receive warnings about lines longer than 80 columns. It is fine to have
longer lines if this means that other warnings will be fixed by that.
Yet, if you're having more than 80 columns on a line, please consider
simplifying the code - if too idented - or to use shorter names for
variables.
>
> > +
> > +Review Cadence
> > +--------------
> > +
> > +Provided that your patch is at https://patchwork.linuxtv.org, it should
> > +be sooner or later handled, so you don't need to re-submit a patch.
> > +
> > +Except for bug fixes, we don't usually add new patches to the development
> > +tree between -rc6 and the next -rc1.
> > +
> > +Please notice that the media subsystem is a high traffic one, so it
> > +could take a while for us to be able to review your patches. Feel free
> > +to ping if you don't get a feedback on a couple of weeks or to ask
>
> s/on a/in a/
>
> > +other developers to publicly add Reviewed-by and, more importantly,
> > +Tested-by tags.
> > +
> > +Please notice that we expect a detailed description for Tested-by,
>
> s/notice/note/
>
> > +identifying what boards were used at the test and what it was tested.
> > +
> > +Style Cleanup Patches
> > +---------------------
> > +
> > +Style-cleanups are welcome when they come together with other changes
> > +at the files where the style changes will affect.
> > +
> > +We may accept pure standalone style-cleanups, but they should be grouped
> > +per directory. So, for example, if you're doing a cleanup at drivers
> > +under drivers/media, please send a single patch for all drivers under
> > +drivers/media/pci, another one for drivers/media/usb and so on.
>
> How about also stating that if the cleanup is low volume, a single patch
> for the whole subsystem is preferred ? I think that should actually be
> the rule, with a split to ease review only when the patch would be too
> big.
>
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 7c62b45201d7..e7f44ec05a42 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10077,6 +10077,7 @@ W: https://linuxtv.org
> > Q: http://patchwork.kernel.org/project/linux-media/list/
> > T: git git://linuxtv.org/media_tree.git
> > S: Maintained
> > +P: Documentation/media/maintainer-entry-profile.rst
> > F: Documentation/devicetree/bindings/media/
> > F: Documentation/media/
> > F: drivers/media/
>
I'm enclosing the diff against the past version. I'll send a final version
once the profiles patchset arrives upstream.
Thanks,
Mauro
diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
index 81d3b0f9c36a..68d642abe2c1 100644
--- a/Documentation/media/maintainer-entry-profile.rst
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -4,7 +4,7 @@ Media Subsystem Profile
Overview
--------
-The media subsystem cover support for a variety of devices: stream
+The media subsystem covers support for a variety of devices: stream
capture, analog and digital TV, cameras, remote controllers, HDMI CEC
and media pipeline control.
@@ -20,20 +20,20 @@ sync with the API changes. It means that all patches that add new
features to the subsystem should also bring changes to the corresponding
API files.
-Also, patches for device drivers that changes the Open Firmware/Device
-Tree bindings should be reviewed by the Device Tree maintainers.
+Also, patches that changes the Open Firmware/Device Tree bindings should
+also be reviewed by the Device Tree maintainers.
Due to the size and wide scope of the media subsystem, media's
maintainership model is to have sub-maintainers that have a broad
knowledge of an specific aspect of the subsystem. It is a
-sub-maintainers task to review the patches, providing feedback to users
+sub-maintainer's task to review the patches, providing feedback to users
if the patches are following the subsystem rules and are properly using
the media internal and external APIs.
Patches for the media subsystem should be sent to the media mailing list
at linux-media@vger.kernel.org as plain text only e-mail. Emails with
-HTML will be automatically rejected by the mail server. There's no need
-to copy the maintainer or sub-maintainer(s).
+HTML will be automatically rejected by the mail server. It could be wise
+to also copy the sub-maintainer(s).
Media's workflow is heavily based on Patchwork, meaning that, once a patch
is submitted, it should appear at:
@@ -48,8 +48,8 @@ whitespaces before complaining or submit it again.
Sub-maintainers
+++++++++++++++
-At the media subsystem, we have a group of senior developers that are
-responsible for doing the code reviews at the drivers (called
+At the media subsystem, we have a group of experienced developers that
+are responsible for doing the code reviews at the drivers (called
sub-maintainers), and another senior developer responsible for the
subsystem as a hole. For core changes, whenever possible, multiple
media (sub-)maintainers do the review.
@@ -82,7 +82,7 @@ There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
that should be used in order to check if the drivers are properly
implementing the media APIs.
-Those tests need to be passed before the patches go upstream.
+Those tests need to pass before the patches go upstream.
Also, please notice that we build the Kernel with::
@@ -94,7 +94,8 @@ Where the check script is::
/devel/smatch/smatch -p=kernel $@ >&2
/devel/sparse/sparse $@ >&2
-Be sure to not introduce new warnings on your patches.
+Be sure to not introduce new warnings on your patches without a
+very good reason.
Key Cycle Dates
---------------
@@ -110,6 +111,20 @@ Media development uses checkpatch on strict mode to verify the code style, e. g.
$ ./script/checkpatch.pl --strict
+Please notice that the goal here is to improve code readability. On a few
+cases, checkpatch may actually point to something that would look worse.
+
+So, you should use good send sense here, being prepared to justify any
+coding style decision.
+
+Please also notice that, on some cases, when you fix one issue, you may
+receive warnings about lines longer than 80 columns. It is fine to have
+longer lines if this means that other warnings will be fixed by that.
+
+Yet, if you're having more than 80 columns on a line, please consider
+simplifying the code - if too idented - or to use shorter names for
+variables.
+
Review Cadence
--------------
@@ -121,11 +136,11 @@ tree between -rc6 and the next -rc1.
Please notice that the media subsystem is a high traffic one, so it
could take a while for us to be able to review your patches. Feel free
-to ping if you don't get a feedback on a couple of weeks or to ask
+to ping if you don't get a feedback in a couple of weeks or to ask
other developers to publicly add Reviewed-by and, more importantly,
Tested-by tags.
-Please notice that we expect a detailed description for Tested-by,
+Please note that we expect a detailed description for Tested-by,
identifying what boards were used at the test and what it was tested.
Style Cleanup Patches
@@ -134,7 +149,9 @@ Style Cleanup Patches
Style-cleanups are welcome when they come together with other changes
at the files where the style changes will affect.
-We may accept pure standalone style-cleanups, but they should be grouped
-per directory. So, for example, if you're doing a cleanup at drivers
-under drivers/media, please send a single patch for all drivers under
-drivers/media/pci, another one for drivers/media/usb and so on.
+We may accept pure standalone style-cleanups, but they should ideally
+be one patch for the hole subsystem (if the cleanup is low volume),
+or at least be grouped per directory. So, for example, if you're doing
+big cleanup changes at drivers under drivers/media, please send a single
+patch for all drivers under drivers/media/pci, another one for
+drivers/media/usb and so on.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-18 13:57 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 13:57 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Linux Media Mailing List, ksummit-discuss
Em Wed, 18 Sep 2019 15:36:20 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Mauro,
>
> On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> >
> > That's basically a modified version of:
> > https://patchwork.linuxtv.org/patch/52999/
> >
> > Applied to the new template
> >
> > Documentation/media/index.rst | 1 +
> > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
> > MAINTAINERS | 1 +
> > 3 files changed, 142 insertions(+)
> > create mode 100644 Documentation/media/maintainer-entry-profile.rst
> >
> > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > index 0301c25ff887..ac94685b822a 100644
> > --- a/Documentation/media/index.rst
> > +++ b/Documentation/media/index.rst
> > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> > .. toctree::
> > :maxdepth: 2
> >
> > + maintainer-entry-profile
> > media_uapi
> > media_kapi
> > dvb-drivers/index
> > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> > new file mode 100644
> > index 000000000000..81d3b0f9c36a
> > --- /dev/null
> > +++ b/Documentation/media/maintainer-entry-profile.rst
> > @@ -0,0 +1,140 @@
> > +Media Subsystem Profile
> > +=======================
> > +
> > +Overview
> > +--------
> > +
> > +The media subsystem cover support for a variety of devices: stream
>
> s/cover/covers/
>
> > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> > +and media pipeline control.
> > +
> > +It covers, mainly, the contents of those directories:
> > +
> > + - drivers/media
> > + - drivers/staging/media
> > + - Documentation/media
> > + - include/media
> > +
> > +Both media userspace and Kernel APIs are documented and should be kept in
> > +sync with the API changes. It means that all patches that add new
> > +features to the subsystem should also bring changes to the corresponding
> > +API files.
> > +
> > +Also, patches for device drivers that changes the Open Firmware/Device
> > +Tree bindings should be reviewed by the Device Tree maintainers.
>
> You may want to make it clear that this covers bindings only, not driver
> code that parses the DT. I would just remove "for device drivers", as
> the rule should also apply to DT bindings documentation that is not
> driver-specific.
>
> > +Due to the size and wide scope of the media subsystem, media's
> > +maintainership model is to have sub-maintainers that have a broad
> > +knowledge of an specific aspect of the subsystem. It is a
> > +sub-maintainers task to review the patches, providing feedback to users
>
> s/sub-maintainers/sub-maintainer's/
>
> > +if the patches are following the subsystem rules and are properly using
> > +the media internal and external APIs.
> > +
> > +Patches for the media subsystem should be sent to the media mailing list
> > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > +HTML will be automatically rejected by the mail server. There's no need
> > +to copy the maintainer or sub-maintainer(s).
>
> There's too much traffic on mailing lists for me to follow everything, I
> much prefer being CC'ed on patches.
Well, by using patchwork, the best is to take a look on it at least for
the patches that you're interested. You could script something using
pwclient in order to make it easier.
Anyway, not sure if the other sub-maintainers see the same way. From my side,
I prefer not to be c/c, as this is just more noise, as I just rely on
patchwork for media patches. What about changing this to:
Patches for the media subsystem should be sent to the media mailing list
at linux-media@vger.kernel.org as plain text only e-mail. Emails with
HTML will be automatically rejected by the mail server. It could be wise
to also copy the sub-maintainer(s).
>
> > +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> > +is submitted, it should appear at:
> > +
> > + - https://patchwork.linuxtv.org/project/linux-media/list/
> > +
> > +If it doesn't automatically appear there after a few minutes, then
> > +probably something got wrong on your submission. Please check if the
> > +email is in plain text only and if your emailer is not mangling with
> > +whitespaces before complaining or submit it again.
> > +
> > +Sub-maintainers
> > ++++++++++++++++
> > +
> > +At the media subsystem, we have a group of senior developers that are
>
> How about "experienced" instead of "senior" ? Quality doesn't always
> come with age, neither for people nor wine :-)
>
> > +responsible for doing the code reviews at the drivers (called
> > +sub-maintainers), and another senior developer responsible for the
> > +subsystem as a hole. For core changes, whenever possible, multiple
> > +media (sub-)maintainers do the review.
> > +
> > +The sub-maintainers work on specific areas of the subsystem, as
> > +described below:
> > +
> > +Digital TV:
> > + Sean Young <sean@mess.org>
> > +
> > +HDMI CEC:
> > + Hans Verkuil <hverkuil@xs4all.nl>
> > +
> > +Media controller drivers:
> > + Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > +
> > +Remote Controllers:
> > + Sean Young <sean@mess.org>
> > +
> > +Sensor drivers:
> > + Sakari Ailus <sakari.ailus@linux.intel.com>
> > +
> > +V4L2 drivers:
> > + Hans Verkuil <hverkuil@xs4all.nl>
> > +
> > +Submit Checklist Addendum
> > +-------------------------
> > +
> > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> > +that should be used in order to check if the drivers are properly
> > +implementing the media APIs.
> > +
> > +Those tests need to be passed before the patches go upstream.
>
> s/need to be passed/need to pass/
>
> > +
> > +Also, please notice that we build the Kernel with::
> > +
> > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> > +
> > +Where the check script is::
> > +
> > + #!/bin/bash
> > + /devel/smatch/smatch -p=kernel $@ >&2
> > + /devel/sparse/sparse $@ >&2
> > +
> > +Be sure to not introduce new warnings on your patches.
>
> While static analysers deliver value, I fear this is a high barrier to
> entry for new contributors.
Will change this to:
Be sure to not introduce new warnings on your patches without a
very good reason.
Especially for new contributors, I really expect patches to not introduce
new warnings, as it is usually a lot more painful to fix them later than
to ask devs to do things right at the first place.
>
> > +
> > +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 -rc5, and ideally stabilized
> > +in the linux-media branch by -rc6.
> > +
> > +Coding Style Addendum
> > +---------------------
> > +
> > +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> > +
> > + $ ./script/checkpatch.pl --strict
>
> But we still accept some warnings. I think this should be documented.
True, but not sure if we should enter into too specific details here.
What about adding something like:
Please notice that the goal here is to improve code readability. On a few
cases, checkpatch may actually point to something that would look worse.
So, you should use good send sense here, being prepared to justify any
coding style decision.
Please also notice that, on some cases, when you fix one issue, you may
receive warnings about lines longer than 80 columns. It is fine to have
longer lines if this means that other warnings will be fixed by that.
Yet, if you're having more than 80 columns on a line, please consider
simplifying the code - if too idented - or to use shorter names for
variables.
>
> > +
> > +Review Cadence
> > +--------------
> > +
> > +Provided that your patch is at https://patchwork.linuxtv.org, it should
> > +be sooner or later handled, so you don't need to re-submit a patch.
> > +
> > +Except for bug fixes, we don't usually add new patches to the development
> > +tree between -rc6 and the next -rc1.
> > +
> > +Please notice that the media subsystem is a high traffic one, so it
> > +could take a while for us to be able to review your patches. Feel free
> > +to ping if you don't get a feedback on a couple of weeks or to ask
>
> s/on a/in a/
>
> > +other developers to publicly add Reviewed-by and, more importantly,
> > +Tested-by tags.
> > +
> > +Please notice that we expect a detailed description for Tested-by,
>
> s/notice/note/
>
> > +identifying what boards were used at the test and what it was tested.
> > +
> > +Style Cleanup Patches
> > +---------------------
> > +
> > +Style-cleanups are welcome when they come together with other changes
> > +at the files where the style changes will affect.
> > +
> > +We may accept pure standalone style-cleanups, but they should be grouped
> > +per directory. So, for example, if you're doing a cleanup at drivers
> > +under drivers/media, please send a single patch for all drivers under
> > +drivers/media/pci, another one for drivers/media/usb and so on.
>
> How about also stating that if the cleanup is low volume, a single patch
> for the whole subsystem is preferred ? I think that should actually be
> the rule, with a split to ease review only when the patch would be too
> big.
>
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 7c62b45201d7..e7f44ec05a42 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10077,6 +10077,7 @@ W: https://linuxtv.org
> > Q: http://patchwork.kernel.org/project/linux-media/list/
> > T: git git://linuxtv.org/media_tree.git
> > S: Maintained
> > +P: Documentation/media/maintainer-entry-profile.rst
> > F: Documentation/devicetree/bindings/media/
> > F: Documentation/media/
> > F: drivers/media/
>
I'm enclosing the diff against the past version. I'll send a final version
once the profiles patchset arrives upstream.
Thanks,
Mauro
diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
index 81d3b0f9c36a..68d642abe2c1 100644
--- a/Documentation/media/maintainer-entry-profile.rst
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -4,7 +4,7 @@ Media Subsystem Profile
Overview
--------
-The media subsystem cover support for a variety of devices: stream
+The media subsystem covers support for a variety of devices: stream
capture, analog and digital TV, cameras, remote controllers, HDMI CEC
and media pipeline control.
@@ -20,20 +20,20 @@ sync with the API changes. It means that all patches that add new
features to the subsystem should also bring changes to the corresponding
API files.
-Also, patches for device drivers that changes the Open Firmware/Device
-Tree bindings should be reviewed by the Device Tree maintainers.
+Also, patches that changes the Open Firmware/Device Tree bindings should
+also be reviewed by the Device Tree maintainers.
Due to the size and wide scope of the media subsystem, media's
maintainership model is to have sub-maintainers that have a broad
knowledge of an specific aspect of the subsystem. It is a
-sub-maintainers task to review the patches, providing feedback to users
+sub-maintainer's task to review the patches, providing feedback to users
if the patches are following the subsystem rules and are properly using
the media internal and external APIs.
Patches for the media subsystem should be sent to the media mailing list
at linux-media@vger.kernel.org as plain text only e-mail. Emails with
-HTML will be automatically rejected by the mail server. There's no need
-to copy the maintainer or sub-maintainer(s).
+HTML will be automatically rejected by the mail server. It could be wise
+to also copy the sub-maintainer(s).
Media's workflow is heavily based on Patchwork, meaning that, once a patch
is submitted, it should appear at:
@@ -48,8 +48,8 @@ whitespaces before complaining or submit it again.
Sub-maintainers
+++++++++++++++
-At the media subsystem, we have a group of senior developers that are
-responsible for doing the code reviews at the drivers (called
+At the media subsystem, we have a group of experienced developers that
+are responsible for doing the code reviews at the drivers (called
sub-maintainers), and another senior developer responsible for the
subsystem as a hole. For core changes, whenever possible, multiple
media (sub-)maintainers do the review.
@@ -82,7 +82,7 @@ There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
that should be used in order to check if the drivers are properly
implementing the media APIs.
-Those tests need to be passed before the patches go upstream.
+Those tests need to pass before the patches go upstream.
Also, please notice that we build the Kernel with::
@@ -94,7 +94,8 @@ Where the check script is::
/devel/smatch/smatch -p=kernel $@ >&2
/devel/sparse/sparse $@ >&2
-Be sure to not introduce new warnings on your patches.
+Be sure to not introduce new warnings on your patches without a
+very good reason.
Key Cycle Dates
---------------
@@ -110,6 +111,20 @@ Media development uses checkpatch on strict mode to verify the code style, e. g.
$ ./script/checkpatch.pl --strict
+Please notice that the goal here is to improve code readability. On a few
+cases, checkpatch may actually point to something that would look worse.
+
+So, you should use good send sense here, being prepared to justify any
+coding style decision.
+
+Please also notice that, on some cases, when you fix one issue, you may
+receive warnings about lines longer than 80 columns. It is fine to have
+longer lines if this means that other warnings will be fixed by that.
+
+Yet, if you're having more than 80 columns on a line, please consider
+simplifying the code - if too idented - or to use shorter names for
+variables.
+
Review Cadence
--------------
@@ -121,11 +136,11 @@ tree between -rc6 and the next -rc1.
Please notice that the media subsystem is a high traffic one, so it
could take a while for us to be able to review your patches. Feel free
-to ping if you don't get a feedback on a couple of weeks or to ask
+to ping if you don't get a feedback in a couple of weeks or to ask
other developers to publicly add Reviewed-by and, more importantly,
Tested-by tags.
-Please notice that we expect a detailed description for Tested-by,
+Please note that we expect a detailed description for Tested-by,
identifying what boards were used at the test and what it was tested.
Style Cleanup Patches
@@ -134,7 +149,9 @@ Style Cleanup Patches
Style-cleanups are welcome when they come together with other changes
at the files where the style changes will affect.
-We may accept pure standalone style-cleanups, but they should be grouped
-per directory. So, for example, if you're doing a cleanup at drivers
-under drivers/media, please send a single patch for all drivers under
-drivers/media/pci, another one for drivers/media/usb and so on.
+We may accept pure standalone style-cleanups, but they should ideally
+be one patch for the hole subsystem (if the cleanup is low volume),
+or at least be grouped per directory. So, for example, if you're doing
+big cleanup changes at drivers under drivers/media, please send a single
+patch for all drivers under drivers/media/pci, another one for
+drivers/media/usb and so on.
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [Ksummit-discuss] [PATCH v2] media: add a subsystem profile documentation
2019-09-18 12:36 ` Laurent Pinchart
@ 2019-09-18 13:59 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 13:59 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab, ksummit-discuss
Document the basic policies of the media subsystem profile.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/media/index.rst | 1 +
.../media/maintainer-entry-profile.rst | 157 ++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 159 insertions(+)
create mode 100644 Documentation/media/maintainer-entry-profile.rst
diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index 0301c25ff887..ac94685b822a 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
.. toctree::
:maxdepth: 2
+ maintainer-entry-profile
media_uapi
media_kapi
dvb-drivers/index
diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
new file mode 100644
index 000000000000..68d642abe2c1
--- /dev/null
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -0,0 +1,157 @@
+Media Subsystem Profile
+=======================
+
+Overview
+--------
+
+The media subsystem covers support for a variety of devices: stream
+capture, analog and digital TV, cameras, remote controllers, HDMI CEC
+and media pipeline control.
+
+It covers, mainly, the contents of those directories:
+
+ - drivers/media
+ - drivers/staging/media
+ - Documentation/media
+ - include/media
+
+Both media userspace and Kernel APIs are documented and should be kept in
+sync with the API changes. It means that all patches that add new
+features to the subsystem should also bring changes to the corresponding
+API files.
+
+Also, patches that changes the Open Firmware/Device Tree bindings should
+also be reviewed by the Device Tree maintainers.
+
+Due to the size and wide scope of the media subsystem, media's
+maintainership model is to have sub-maintainers that have a broad
+knowledge of an specific aspect of the subsystem. It is a
+sub-maintainer's task to review the patches, providing feedback to users
+if the patches are following the subsystem rules and are properly using
+the media internal and external APIs.
+
+Patches for the media subsystem should be sent to the media mailing list
+at linux-media@vger.kernel.org as plain text only e-mail. Emails with
+HTML will be automatically rejected by the mail server. It could be wise
+to also copy the sub-maintainer(s).
+
+Media's workflow is heavily based on Patchwork, meaning that, once a patch
+is submitted, it should appear at:
+
+ - https://patchwork.linuxtv.org/project/linux-media/list/
+
+If it doesn't automatically appear there after a few minutes, then
+probably something got wrong on your submission. Please check if the
+email is in plain text only and if your emailer is not mangling with
+whitespaces before complaining or submit it again.
+
+Sub-maintainers
++++++++++++++++
+
+At the media subsystem, we have a group of experienced developers that
+are responsible for doing the code reviews at the drivers (called
+sub-maintainers), and another senior developer responsible for the
+subsystem as a hole. For core changes, whenever possible, multiple
+media (sub-)maintainers do the review.
+
+The sub-maintainers work on specific areas of the subsystem, as
+described below:
+
+Digital TV:
+ Sean Young <sean@mess.org>
+
+HDMI CEC:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Media controller drivers:
+ Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+Remote Controllers:
+ Sean Young <sean@mess.org>
+
+Sensor drivers:
+ Sakari Ailus <sakari.ailus@linux.intel.com>
+
+V4L2 drivers:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Submit Checklist Addendum
+-------------------------
+
+There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
+that should be used in order to check if the drivers are properly
+implementing the media APIs.
+
+Those tests need to pass before the patches go upstream.
+
+Also, please notice that we build the Kernel with::
+
+ make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
+
+Where the check script is::
+
+ #!/bin/bash
+ /devel/smatch/smatch -p=kernel $@ >&2
+ /devel/sparse/sparse $@ >&2
+
+Be sure to not introduce new warnings on your patches without a
+very good reason.
+
+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 -rc5, and ideally stabilized
+in the linux-media branch by -rc6.
+
+Coding Style Addendum
+---------------------
+
+Media development uses checkpatch on strict mode to verify the code style, e. g.::
+
+ $ ./script/checkpatch.pl --strict
+
+Please notice that the goal here is to improve code readability. On a few
+cases, checkpatch may actually point to something that would look worse.
+
+So, you should use good send sense here, being prepared to justify any
+coding style decision.
+
+Please also notice that, on some cases, when you fix one issue, you may
+receive warnings about lines longer than 80 columns. It is fine to have
+longer lines if this means that other warnings will be fixed by that.
+
+Yet, if you're having more than 80 columns on a line, please consider
+simplifying the code - if too idented - or to use shorter names for
+variables.
+
+Review Cadence
+--------------
+
+Provided that your patch is at https://patchwork.linuxtv.org, it should
+be sooner or later handled, so you don't need to re-submit a patch.
+
+Except for bug fixes, we don't usually add new patches to the development
+tree between -rc6 and the next -rc1.
+
+Please notice that the media subsystem is a high traffic one, so it
+could take a while for us to be able to review your patches. Feel free
+to ping if you don't get a feedback in a couple of weeks or to ask
+other developers to publicly add Reviewed-by and, more importantly,
+Tested-by tags.
+
+Please note that we expect a detailed description for Tested-by,
+identifying what boards were used at the test and what it was tested.
+
+Style Cleanup Patches
+---------------------
+
+Style-cleanups are welcome when they come together with other changes
+at the files where the style changes will affect.
+
+We may accept pure standalone style-cleanups, but they should ideally
+be one patch for the hole subsystem (if the cleanup is low volume),
+or at least be grouped per directory. So, for example, if you're doing
+big cleanup changes at drivers under drivers/media, please send a single
+patch for all drivers under drivers/media/pci, another one for
+drivers/media/usb and so on.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c62b45201d7..e7f44ec05a42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10077,6 +10077,7 @@ W: https://linuxtv.org
Q: http://patchwork.kernel.org/project/linux-media/list/
T: git git://linuxtv.org/media_tree.git
S: Maintained
+P: Documentation/media/maintainer-entry-profile.rst
F: Documentation/devicetree/bindings/media/
F: Documentation/media/
F: drivers/media/
--
2.21.0
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* [PATCH v2] media: add a subsystem profile documentation
@ 2019-09-18 13:59 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 13:59 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, ksummit-discuss,
laurent.pinchart
Document the basic policies of the media subsystem profile.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/media/index.rst | 1 +
.../media/maintainer-entry-profile.rst | 157 ++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 159 insertions(+)
create mode 100644 Documentation/media/maintainer-entry-profile.rst
diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index 0301c25ff887..ac94685b822a 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
.. toctree::
:maxdepth: 2
+ maintainer-entry-profile
media_uapi
media_kapi
dvb-drivers/index
diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
new file mode 100644
index 000000000000..68d642abe2c1
--- /dev/null
+++ b/Documentation/media/maintainer-entry-profile.rst
@@ -0,0 +1,157 @@
+Media Subsystem Profile
+=======================
+
+Overview
+--------
+
+The media subsystem covers support for a variety of devices: stream
+capture, analog and digital TV, cameras, remote controllers, HDMI CEC
+and media pipeline control.
+
+It covers, mainly, the contents of those directories:
+
+ - drivers/media
+ - drivers/staging/media
+ - Documentation/media
+ - include/media
+
+Both media userspace and Kernel APIs are documented and should be kept in
+sync with the API changes. It means that all patches that add new
+features to the subsystem should also bring changes to the corresponding
+API files.
+
+Also, patches that changes the Open Firmware/Device Tree bindings should
+also be reviewed by the Device Tree maintainers.
+
+Due to the size and wide scope of the media subsystem, media's
+maintainership model is to have sub-maintainers that have a broad
+knowledge of an specific aspect of the subsystem. It is a
+sub-maintainer's task to review the patches, providing feedback to users
+if the patches are following the subsystem rules and are properly using
+the media internal and external APIs.
+
+Patches for the media subsystem should be sent to the media mailing list
+at linux-media@vger.kernel.org as plain text only e-mail. Emails with
+HTML will be automatically rejected by the mail server. It could be wise
+to also copy the sub-maintainer(s).
+
+Media's workflow is heavily based on Patchwork, meaning that, once a patch
+is submitted, it should appear at:
+
+ - https://patchwork.linuxtv.org/project/linux-media/list/
+
+If it doesn't automatically appear there after a few minutes, then
+probably something got wrong on your submission. Please check if the
+email is in plain text only and if your emailer is not mangling with
+whitespaces before complaining or submit it again.
+
+Sub-maintainers
++++++++++++++++
+
+At the media subsystem, we have a group of experienced developers that
+are responsible for doing the code reviews at the drivers (called
+sub-maintainers), and another senior developer responsible for the
+subsystem as a hole. For core changes, whenever possible, multiple
+media (sub-)maintainers do the review.
+
+The sub-maintainers work on specific areas of the subsystem, as
+described below:
+
+Digital TV:
+ Sean Young <sean@mess.org>
+
+HDMI CEC:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Media controller drivers:
+ Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+Remote Controllers:
+ Sean Young <sean@mess.org>
+
+Sensor drivers:
+ Sakari Ailus <sakari.ailus@linux.intel.com>
+
+V4L2 drivers:
+ Hans Verkuil <hverkuil@xs4all.nl>
+
+Submit Checklist Addendum
+-------------------------
+
+There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
+that should be used in order to check if the drivers are properly
+implementing the media APIs.
+
+Those tests need to pass before the patches go upstream.
+
+Also, please notice that we build the Kernel with::
+
+ make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
+
+Where the check script is::
+
+ #!/bin/bash
+ /devel/smatch/smatch -p=kernel $@ >&2
+ /devel/sparse/sparse $@ >&2
+
+Be sure to not introduce new warnings on your patches without a
+very good reason.
+
+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 -rc5, and ideally stabilized
+in the linux-media branch by -rc6.
+
+Coding Style Addendum
+---------------------
+
+Media development uses checkpatch on strict mode to verify the code style, e. g.::
+
+ $ ./script/checkpatch.pl --strict
+
+Please notice that the goal here is to improve code readability. On a few
+cases, checkpatch may actually point to something that would look worse.
+
+So, you should use good send sense here, being prepared to justify any
+coding style decision.
+
+Please also notice that, on some cases, when you fix one issue, you may
+receive warnings about lines longer than 80 columns. It is fine to have
+longer lines if this means that other warnings will be fixed by that.
+
+Yet, if you're having more than 80 columns on a line, please consider
+simplifying the code - if too idented - or to use shorter names for
+variables.
+
+Review Cadence
+--------------
+
+Provided that your patch is at https://patchwork.linuxtv.org, it should
+be sooner or later handled, so you don't need to re-submit a patch.
+
+Except for bug fixes, we don't usually add new patches to the development
+tree between -rc6 and the next -rc1.
+
+Please notice that the media subsystem is a high traffic one, so it
+could take a while for us to be able to review your patches. Feel free
+to ping if you don't get a feedback in a couple of weeks or to ask
+other developers to publicly add Reviewed-by and, more importantly,
+Tested-by tags.
+
+Please note that we expect a detailed description for Tested-by,
+identifying what boards were used at the test and what it was tested.
+
+Style Cleanup Patches
+---------------------
+
+Style-cleanups are welcome when they come together with other changes
+at the files where the style changes will affect.
+
+We may accept pure standalone style-cleanups, but they should ideally
+be one patch for the hole subsystem (if the cleanup is low volume),
+or at least be grouped per directory. So, for example, if you're doing
+big cleanup changes at drivers under drivers/media, please send a single
+patch for all drivers under drivers/media/pci, another one for
+drivers/media/usb and so on.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c62b45201d7..e7f44ec05a42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10077,6 +10077,7 @@ W: https://linuxtv.org
Q: http://patchwork.kernel.org/project/linux-media/list/
T: git git://linuxtv.org/media_tree.git
S: Maintained
+P: Documentation/media/maintainer-entry-profile.rst
F: Documentation/devicetree/bindings/media/
F: Documentation/media/
F: drivers/media/
--
2.21.0
^ permalink raw reply related [flat|nested] 227+ messages in thread
* Re: [PATCH v2] media: add a subsystem profile documentation
2019-09-18 13:59 ` Mauro Carvalho Chehab
(?)
@ 2019-09-18 14:07 ` André Almeida
2019-09-18 14:11 ` Mauro Carvalho Chehab
-1 siblings, 1 reply; 227+ messages in thread
From: André Almeida @ 2019-09-18 14:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Media Mailing List
Cc: Mauro Carvalho Chehab, ksummit-discuss, laurent.pinchart
Hello Mauro,
On 9/18/19 10:59 AM, Mauro Carvalho Chehab wrote:
> Document the basic policies of the media subsystem profile.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/media/index.rst | 1 +
> .../media/maintainer-entry-profile.rst | 157 ++++++++++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 159 insertions(+)
> create mode 100644 Documentation/media/maintainer-entry-profile.rst
>
> diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> index 0301c25ff887..ac94685b822a 100644
> --- a/Documentation/media/index.rst
> +++ b/Documentation/media/index.rst
> @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> .. toctree::
> :maxdepth: 2
>
> + maintainer-entry-profile
> media_uapi
> media_kapi
> dvb-drivers/index
> diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> new file mode 100644
> index 000000000000..68d642abe2c1
> --- /dev/null
> +++ b/Documentation/media/maintainer-entry-profile.rst
> @@ -0,0 +1,157 @@
> +Media Subsystem Profile
> +=======================
> +
> +Overview
> +--------
> +
> +The media subsystem covers support for a variety of devices: stream
> +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> +and media pipeline control.
> +
> +It covers, mainly, the contents of those directories:
> +
> + - drivers/media
> + - drivers/staging/media
> + - Documentation/media
> + - include/media
> +
> +Both media userspace and Kernel APIs are documented and should be kept in
> +sync with the API changes. It means that all patches that add new
> +features to the subsystem should also bring changes to the corresponding
> +API files.
> +
> +Also, patches that changes the Open Firmware/Device Tree bindings should
> +also be reviewed by the Device Tree maintainers.
> +
> +Due to the size and wide scope of the media subsystem, media's
> +maintainership model is to have sub-maintainers that have a broad
> +knowledge of an specific aspect of the subsystem. It is a
> +sub-maintainer's task to review the patches, providing feedback to users
> +if the patches are following the subsystem rules and are properly using
> +the media internal and external APIs.
> +
> +Patches for the media subsystem should be sent to the media mailing list
> +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> +HTML will be automatically rejected by the mail server. It could be wise
> +to also copy the sub-maintainer(s).
> +
> +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> +is submitted, it should appear at:
> +
> + - https://patchwork.linuxtv.org/project/linux-media/list/
> +
> +If it doesn't automatically appear there after a few minutes, then
> +probably something got wrong on your submission. Please check if the
> +email is in plain text only and if your emailer is not mangling with
> +whitespaces before complaining or submit it again.
> +
> +Sub-maintainers
> ++++++++++++++++
What is the motivation for using "+++" instead of "---"?
> +
> +At the media subsystem, we have a group of experienced developers that
> +are responsible for doing the code reviews at the drivers (called
> +sub-maintainers), and another senior developer responsible for the
> +subsystem as a hole. For core changes, whenever possible, multiple
> +media (sub-)maintainers do the review.
> +
> +The sub-maintainers work on specific areas of the subsystem, as
> +described below:
> +
> +Digital TV:
> + Sean Young <sean@mess.org>
> +
> +HDMI CEC:
> + Hans Verkuil <hverkuil@xs4all.nl>
> +
> +Media controller drivers:
> + Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +Remote Controllers:
> + Sean Young <sean@mess.org>
> +
> +Sensor drivers:
> + Sakari Ailus <sakari.ailus@linux.intel.com>
> +
> +V4L2 drivers:
> + Hans Verkuil <hverkuil@xs4all.nl>
> +
> +Submit Checklist Addendum
> +-------------------------
> +
> +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> +that should be used in order to check if the drivers are properly
> +implementing the media APIs.
> +
> +Those tests need to pass before the patches go upstream.
> +
> +Also, please notice that we build the Kernel with::
> +
> + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> +
> +Where the check script is::
> +
> + #!/bin/bash
> + /devel/smatch/smatch -p=kernel $@ >&2
> + /devel/sparse/sparse $@ >&2
> +
> +Be sure to not introduce new warnings on your patches without a
> +very good reason.
> +
> +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 -rc5, and ideally stabilized
> +in the linux-media branch by -rc6.
> +
> +Coding Style Addendum
> +---------------------
> +
> +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> +
> + $ ./script/checkpatch.pl --strict
> +
> +Please notice that the goal here is to improve code readability. On a few
> +cases, checkpatch may actually point to something that would look worse.
> +
> +So, you should use good send sense here, being prepared to justify any
> +coding style decision.
> +
> +Please also notice that, on some cases, when you fix one issue, you may
> +receive warnings about lines longer than 80 columns. It is fine to have
> +longer lines if this means that other warnings will be fixed by that.
> +
> +Yet, if you're having more than 80 columns on a line, please consider
> +simplifying the code - if too idented - or to use shorter names for
> +variables.
> +
> +Review Cadence
> +--------------
> +
> +Provided that your patch is at https://patchwork.linuxtv.org, it should
> +be sooner or later handled, so you don't need to re-submit a patch.
> +
> +Except for bug fixes, we don't usually add new patches to the development
> +tree between -rc6 and the next -rc1.
> +
> +Please notice that the media subsystem is a high traffic one, so it
> +could take a while for us to be able to review your patches. Feel free
> +to ping if you don't get a feedback in a couple of weeks or to ask
> +other developers to publicly add Reviewed-by and, more importantly,
> +Tested-by tags.
> +
> +Please note that we expect a detailed description for Tested-by,
> +identifying what boards were used at the test and what it was tested.
> +
> +Style Cleanup Patches
> +---------------------
> +
> +Style-cleanups are welcome when they come together with other changes
> +at the files where the style changes will affect.
> +
> +We may accept pure standalone style-cleanups, but they should ideally
> +be one patch for the hole subsystem (if the cleanup is low volume),
> +or at least be grouped per directory. So, for example, if you're doing
> +big cleanup changes at drivers under drivers/media, please send a single
> +patch for all drivers under drivers/media/pci, another one for
> +drivers/media/usb and so on.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7c62b45201d7..e7f44ec05a42 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10077,6 +10077,7 @@ W: https://linuxtv.org
> Q: http://patchwork.kernel.org/project/linux-media/list/
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> +P: Documentation/media/maintainer-entry-profile.rst
> F: Documentation/devicetree/bindings/media/
> F: Documentation/media/
> F: drivers/media/
>
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2] media: add a subsystem profile documentation
2019-09-18 14:07 ` André Almeida
@ 2019-09-18 14:11 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 14:11 UTC (permalink / raw)
To: André Almeida; +Cc: ksummit-discuss, Linux Media Mailing List
Em Wed, 18 Sep 2019 11:07:16 -0300
André Almeida <andrealmeid@collabora.com> escreveu:
> Hello Mauro,
>
> On 9/18/19 10:59 AM, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/media/index.rst | 1 +
> > .../media/maintainer-entry-profile.rst | 157 ++++++++++++++++++
> > MAINTAINERS | 1 +
> > 3 files changed, 159 insertions(+)
> > create mode 100644 Documentation/media/maintainer-entry-profile.rst
> >
> > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > index 0301c25ff887..ac94685b822a 100644
> > --- a/Documentation/media/index.rst
> > +++ b/Documentation/media/index.rst
> > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> > .. toctree::
> > :maxdepth: 2
> >
> > + maintainer-entry-profile
> > media_uapi
> > media_kapi
> > dvb-drivers/index
> > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> > new file mode 100644
> > index 000000000000..68d642abe2c1
> > --- /dev/null
> > +++ b/Documentation/media/maintainer-entry-profile.rst
> > @@ -0,0 +1,157 @@
> > +Media Subsystem Profile
> > +=======================
> > +
> > +Overview
> > +--------
> > +
> > +The media subsystem covers support for a variety of devices: stream
> > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> > +and media pipeline control.
> > +
> > +It covers, mainly, the contents of those directories:
> > +
> > + - drivers/media
> > + - drivers/staging/media
> > + - Documentation/media
> > + - include/media
> > +
> > +Both media userspace and Kernel APIs are documented and should be kept in
> > +sync with the API changes. It means that all patches that add new
> > +features to the subsystem should also bring changes to the corresponding
> > +API files.
> > +
> > +Also, patches that changes the Open Firmware/Device Tree bindings should
> > +also be reviewed by the Device Tree maintainers.
> > +
> > +Due to the size and wide scope of the media subsystem, media's
> > +maintainership model is to have sub-maintainers that have a broad
> > +knowledge of an specific aspect of the subsystem. It is a
> > +sub-maintainer's task to review the patches, providing feedback to users
> > +if the patches are following the subsystem rules and are properly using
> > +the media internal and external APIs.
> > +
> > +Patches for the media subsystem should be sent to the media mailing list
> > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > +HTML will be automatically rejected by the mail server. It could be wise
> > +to also copy the sub-maintainer(s).
> > +
> > +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> > +is submitted, it should appear at:
> > +
> > + - https://patchwork.linuxtv.org/project/linux-media/list/
> > +
> > +If it doesn't automatically appear there after a few minutes, then
> > +probably something got wrong on your submission. Please check if the
> > +email is in plain text only and if your emailer is not mangling with
> > +whitespaces before complaining or submit it again.
> > +
> > +Sub-maintainers
> > ++++++++++++++++
>
> What is the motivation for using "+++" instead of "---"?
Just cosmetics.
This chapter doesn't exist at the original profile, as sub-maintainers,
co-maintainers, etc. are used only on a few subsystems.
So, I'm adding it as a sub-chapter.
Thanks,
Mauro
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [PATCH v2] media: add a subsystem profile documentation
@ 2019-09-18 14:11 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 14:11 UTC (permalink / raw)
To: André Almeida
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, ksummit-discuss,
laurent.pinchart
Em Wed, 18 Sep 2019 11:07:16 -0300
André Almeida <andrealmeid@collabora.com> escreveu:
> Hello Mauro,
>
> On 9/18/19 10:59 AM, Mauro Carvalho Chehab wrote:
> > Document the basic policies of the media subsystem profile.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/media/index.rst | 1 +
> > .../media/maintainer-entry-profile.rst | 157 ++++++++++++++++++
> > MAINTAINERS | 1 +
> > 3 files changed, 159 insertions(+)
> > create mode 100644 Documentation/media/maintainer-entry-profile.rst
> >
> > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > index 0301c25ff887..ac94685b822a 100644
> > --- a/Documentation/media/index.rst
> > +++ b/Documentation/media/index.rst
> > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> > .. toctree::
> > :maxdepth: 2
> >
> > + maintainer-entry-profile
> > media_uapi
> > media_kapi
> > dvb-drivers/index
> > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> > new file mode 100644
> > index 000000000000..68d642abe2c1
> > --- /dev/null
> > +++ b/Documentation/media/maintainer-entry-profile.rst
> > @@ -0,0 +1,157 @@
> > +Media Subsystem Profile
> > +=======================
> > +
> > +Overview
> > +--------
> > +
> > +The media subsystem covers support for a variety of devices: stream
> > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> > +and media pipeline control.
> > +
> > +It covers, mainly, the contents of those directories:
> > +
> > + - drivers/media
> > + - drivers/staging/media
> > + - Documentation/media
> > + - include/media
> > +
> > +Both media userspace and Kernel APIs are documented and should be kept in
> > +sync with the API changes. It means that all patches that add new
> > +features to the subsystem should also bring changes to the corresponding
> > +API files.
> > +
> > +Also, patches that changes the Open Firmware/Device Tree bindings should
> > +also be reviewed by the Device Tree maintainers.
> > +
> > +Due to the size and wide scope of the media subsystem, media's
> > +maintainership model is to have sub-maintainers that have a broad
> > +knowledge of an specific aspect of the subsystem. It is a
> > +sub-maintainer's task to review the patches, providing feedback to users
> > +if the patches are following the subsystem rules and are properly using
> > +the media internal and external APIs.
> > +
> > +Patches for the media subsystem should be sent to the media mailing list
> > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > +HTML will be automatically rejected by the mail server. It could be wise
> > +to also copy the sub-maintainer(s).
> > +
> > +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> > +is submitted, it should appear at:
> > +
> > + - https://patchwork.linuxtv.org/project/linux-media/list/
> > +
> > +If it doesn't automatically appear there after a few minutes, then
> > +probably something got wrong on your submission. Please check if the
> > +email is in plain text only and if your emailer is not mangling with
> > +whitespaces before complaining or submit it again.
> > +
> > +Sub-maintainers
> > ++++++++++++++++
>
> What is the motivation for using "+++" instead of "---"?
Just cosmetics.
This chapter doesn't exist at the original profile, as sub-maintainers,
co-maintainers, etc. are used only on a few subsystems.
So, I'm adding it as a sub-chapter.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-18 13:57 ` Mauro Carvalho Chehab
@ 2019-09-18 17:27 ` Laurent Pinchart
-1 siblings, 0 replies; 227+ messages in thread
From: Laurent Pinchart @ 2019-09-18 17:27 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List
Hi Mauro,
On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 18 Sep 2019 15:36:20 +0300 Laurent Pinchart escreveu:
> > On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> > > Document the basic policies of the media subsystem profile.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > ---
> > >
> > > That's basically a modified version of:
> > > https://patchwork.linuxtv.org/patch/52999/
> > >
> > > Applied to the new template
> > >
> > > Documentation/media/index.rst | 1 +
> > > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
> > > MAINTAINERS | 1 +
> > > 3 files changed, 142 insertions(+)
> > > create mode 100644 Documentation/media/maintainer-entry-profile.rst
> > >
> > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > > index 0301c25ff887..ac94685b822a 100644
> > > --- a/Documentation/media/index.rst
> > > +++ b/Documentation/media/index.rst
> > > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> > > .. toctree::
> > > :maxdepth: 2
> > >
> > > + maintainer-entry-profile
> > > media_uapi
> > > media_kapi
> > > dvb-drivers/index
> > > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> > > new file mode 100644
> > > index 000000000000..81d3b0f9c36a
> > > --- /dev/null
> > > +++ b/Documentation/media/maintainer-entry-profile.rst
> > > @@ -0,0 +1,140 @@
> > > +Media Subsystem Profile
> > > +=======================
> > > +
> > > +Overview
> > > +--------
> > > +
> > > +The media subsystem cover support for a variety of devices: stream
> >
> > s/cover/covers/
> >
> > > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> > > +and media pipeline control.
> > > +
> > > +It covers, mainly, the contents of those directories:
> > > +
> > > + - drivers/media
> > > + - drivers/staging/media
> > > + - Documentation/media
> > > + - include/media
> > > +
> > > +Both media userspace and Kernel APIs are documented and should be kept in
> > > +sync with the API changes. It means that all patches that add new
> > > +features to the subsystem should also bring changes to the corresponding
> > > +API files.
> > > +
> > > +Also, patches for device drivers that changes the Open Firmware/Device
> > > +Tree bindings should be reviewed by the Device Tree maintainers.
> >
> > You may want to make it clear that this covers bindings only, not driver
> > code that parses the DT. I would just remove "for device drivers", as
> > the rule should also apply to DT bindings documentation that is not
> > driver-specific.
> >
> > > +Due to the size and wide scope of the media subsystem, media's
> > > +maintainership model is to have sub-maintainers that have a broad
> > > +knowledge of an specific aspect of the subsystem. It is a
> > > +sub-maintainers task to review the patches, providing feedback to users
> >
> > s/sub-maintainers/sub-maintainer's/
> >
> > > +if the patches are following the subsystem rules and are properly using
> > > +the media internal and external APIs.
> > > +
> > > +Patches for the media subsystem should be sent to the media mailing list
> > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > +HTML will be automatically rejected by the mail server. There's no need
> > > +to copy the maintainer or sub-maintainer(s).
> >
> > There's too much traffic on mailing lists for me to follow everything, I
> > much prefer being CC'ed on patches.
>
> Well, by using patchwork, the best is to take a look on it at least for
> the patches that you're interested. You could script something using
> pwclient in order to make it easier.
>
> Anyway, not sure if the other sub-maintainers see the same way. From my side,
> I prefer not to be c/c, as this is just more noise, as I just rely on
> patchwork for media patches. What about changing this to:
>
> Patches for the media subsystem should be sent to the media mailing list
> at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> HTML will be automatically rejected by the mail server. It could be wise
> to also copy the sub-maintainer(s).
That works for me. As this is really a personal preference, is there a
way it could be encoded in MAINTAINERS in a per-person fashion ?
Something that would allow you to opt-out from CC from linux-media (but
possibly opt-in for other parts of the kernel), and allow me to opt-in
for the drivers I maintain ?
> > > +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> > > +is submitted, it should appear at:
> > > +
> > > + - https://patchwork.linuxtv.org/project/linux-media/list/
> > > +
> > > +If it doesn't automatically appear there after a few minutes, then
> > > +probably something got wrong on your submission. Please check if the
> > > +email is in plain text only and if your emailer is not mangling with
> > > +whitespaces before complaining or submit it again.
> > > +
> > > +Sub-maintainers
> > > ++++++++++++++++
> > > +
> > > +At the media subsystem, we have a group of senior developers that are
> >
> > How about "experienced" instead of "senior" ? Quality doesn't always
> > come with age, neither for people nor wine :-)
> >
> > > +responsible for doing the code reviews at the drivers (called
> > > +sub-maintainers), and another senior developer responsible for the
> > > +subsystem as a hole. For core changes, whenever possible, multiple
> > > +media (sub-)maintainers do the review.
> > > +
> > > +The sub-maintainers work on specific areas of the subsystem, as
> > > +described below:
> > > +
> > > +Digital TV:
> > > + Sean Young <sean@mess.org>
> > > +
> > > +HDMI CEC:
> > > + Hans Verkuil <hverkuil@xs4all.nl>
> > > +
> > > +Media controller drivers:
> > > + Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > +
> > > +Remote Controllers:
> > > + Sean Young <sean@mess.org>
> > > +
> > > +Sensor drivers:
> > > + Sakari Ailus <sakari.ailus@linux.intel.com>
> > > +
> > > +V4L2 drivers:
> > > + Hans Verkuil <hverkuil@xs4all.nl>
> > > +
> > > +Submit Checklist Addendum
> > > +-------------------------
> > > +
> > > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> > > +that should be used in order to check if the drivers are properly
> > > +implementing the media APIs.
> > > +
> > > +Those tests need to be passed before the patches go upstream.
> >
> > s/need to be passed/need to pass/
> >
> > > +
> > > +Also, please notice that we build the Kernel with::
> > > +
> > > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> > > +
> > > +Where the check script is::
> > > +
> > > + #!/bin/bash
> > > + /devel/smatch/smatch -p=kernel $@ >&2
> > > + /devel/sparse/sparse $@ >&2
> > > +
> > > +Be sure to not introduce new warnings on your patches.
> >
> > While static analysers deliver value, I fear this is a high barrier to
> > entry for new contributors.
>
> Will change this to:
>
> Be sure to not introduce new warnings on your patches without a
> very good reason.
>
> Especially for new contributors, I really expect patches to not introduce
> new warnings, as it is usually a lot more painful to fix them later than
> to ask devs to do things right at the first place.
I fully agree with the goal, but asking a drive-by contributor, who
usually has to go through issues with sending patches through e-mail
already, to install smatch and sparse and use them, is setting the bar
high. I think automating those checks is the way to go.
> > > +
> > > +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 -rc5, and ideally stabilized
> > > +in the linux-media branch by -rc6.
> > > +
> > > +Coding Style Addendum
> > > +---------------------
> > > +
> > > +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> > > +
> > > + $ ./script/checkpatch.pl --strict
> >
> > But we still accept some warnings. I think this should be documented.
>
> True, but not sure if we should enter into too specific details here.
>
> What about adding something like:
>
> Please notice that the goal here is to improve code readability. On a few
> cases, checkpatch may actually point to something that would look worse.
>
> So, you should use good send sense here, being prepared to justify any
s/send sense/sense/
> coding style decision.
"being prepared to justify" sounds a bit harsh :-) But the general
message is good.
>
> Please also notice that, on some cases, when you fix one issue, you may
> receive warnings about lines longer than 80 columns. It is fine to have
> longer lines if this means that other warnings will be fixed by that.
>
> Yet, if you're having more than 80 columns on a line, please consider
> simplifying the code - if too idented - or to use shorter names for
> variables.
That's already quite specific for my taste. We can keep it as-is if you
think it's fine, but we clearly shouldn't go into more details.
> > > +
> > > +Review Cadence
> > > +--------------
> > > +
> > > +Provided that your patch is at https://patchwork.linuxtv.org, it should
> > > +be sooner or later handled, so you don't need to re-submit a patch.
> > > +
> > > +Except for bug fixes, we don't usually add new patches to the development
> > > +tree between -rc6 and the next -rc1.
> > > +
> > > +Please notice that the media subsystem is a high traffic one, so it
> > > +could take a while for us to be able to review your patches. Feel free
> > > +to ping if you don't get a feedback on a couple of weeks or to ask
> >
> > s/on a/in a/
> >
> > > +other developers to publicly add Reviewed-by and, more importantly,
> > > +Tested-by tags.
> > > +
> > > +Please notice that we expect a detailed description for Tested-by,
> >
> > s/notice/note/
> >
> > > +identifying what boards were used at the test and what it was tested.
> > > +
> > > +Style Cleanup Patches
> > > +---------------------
> > > +
> > > +Style-cleanups are welcome when they come together with other changes
> > > +at the files where the style changes will affect.
> > > +
> > > +We may accept pure standalone style-cleanups, but they should be grouped
> > > +per directory. So, for example, if you're doing a cleanup at drivers
> > > +under drivers/media, please send a single patch for all drivers under
> > > +drivers/media/pci, another one for drivers/media/usb and so on.
> >
> > How about also stating that if the cleanup is low volume, a single patch
> > for the whole subsystem is preferred ? I think that should actually be
> > the rule, with a split to ease review only when the patch would be too
> > big.
> >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 7c62b45201d7..e7f44ec05a42 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -10077,6 +10077,7 @@ W: https://linuxtv.org
> > > Q: http://patchwork.kernel.org/project/linux-media/list/
> > > T: git git://linuxtv.org/media_tree.git
> > > S: Maintained
> > > +P: Documentation/media/maintainer-entry-profile.rst
> > > F: Documentation/devicetree/bindings/media/
> > > F: Documentation/media/
> > > F: drivers/media/
> >
>
> I'm enclosing the diff against the past version. I'll send a final version
> once the profiles patchset arrives upstream.
>
> diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> index 81d3b0f9c36a..68d642abe2c1 100644
> --- a/Documentation/media/maintainer-entry-profile.rst
> +++ b/Documentation/media/maintainer-entry-profile.rst
> @@ -4,7 +4,7 @@ Media Subsystem Profile
> Overview
> --------
>
> -The media subsystem cover support for a variety of devices: stream
> +The media subsystem covers support for a variety of devices: stream
> capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> and media pipeline control.
>
> @@ -20,20 +20,20 @@ sync with the API changes. It means that all patches that add new
> features to the subsystem should also bring changes to the corresponding
> API files.
>
> -Also, patches for device drivers that changes the Open Firmware/Device
> -Tree bindings should be reviewed by the Device Tree maintainers.
> +Also, patches that changes the Open Firmware/Device Tree bindings should
> +also be reviewed by the Device Tree maintainers.
>
> Due to the size and wide scope of the media subsystem, media's
> maintainership model is to have sub-maintainers that have a broad
> knowledge of an specific aspect of the subsystem. It is a
> -sub-maintainers task to review the patches, providing feedback to users
> +sub-maintainer's task to review the patches, providing feedback to users
> if the patches are following the subsystem rules and are properly using
> the media internal and external APIs.
>
> Patches for the media subsystem should be sent to the media mailing list
> at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> -HTML will be automatically rejected by the mail server. There's no need
> -to copy the maintainer or sub-maintainer(s).
> +HTML will be automatically rejected by the mail server. It could be wise
> +to also copy the sub-maintainer(s).
>
> Media's workflow is heavily based on Patchwork, meaning that, once a patch
> is submitted, it should appear at:
> @@ -48,8 +48,8 @@ whitespaces before complaining or submit it again.
> Sub-maintainers
> +++++++++++++++
>
> -At the media subsystem, we have a group of senior developers that are
> -responsible for doing the code reviews at the drivers (called
> +At the media subsystem, we have a group of experienced developers that
> +are responsible for doing the code reviews at the drivers (called
> sub-maintainers), and another senior developer responsible for the
> subsystem as a hole. For core changes, whenever possible, multiple
> media (sub-)maintainers do the review.
> @@ -82,7 +82,7 @@ There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> that should be used in order to check if the drivers are properly
> implementing the media APIs.
>
> -Those tests need to be passed before the patches go upstream.
> +Those tests need to pass before the patches go upstream.
>
> Also, please notice that we build the Kernel with::
>
> @@ -94,7 +94,8 @@ Where the check script is::
> /devel/smatch/smatch -p=kernel $@ >&2
> /devel/sparse/sparse $@ >&2
>
> -Be sure to not introduce new warnings on your patches.
> +Be sure to not introduce new warnings on your patches without a
> +very good reason.
>
> Key Cycle Dates
> ---------------
> @@ -110,6 +111,20 @@ Media development uses checkpatch on strict mode to verify the code style, e. g.
>
> $ ./script/checkpatch.pl --strict
>
> +Please notice that the goal here is to improve code readability. On a few
> +cases, checkpatch may actually point to something that would look worse.
> +
> +So, you should use good send sense here, being prepared to justify any
> +coding style decision.
> +
> +Please also notice that, on some cases, when you fix one issue, you may
> +receive warnings about lines longer than 80 columns. It is fine to have
> +longer lines if this means that other warnings will be fixed by that.
> +
> +Yet, if you're having more than 80 columns on a line, please consider
> +simplifying the code - if too idented - or to use shorter names for
> +variables.
> +
> Review Cadence
> --------------
>
> @@ -121,11 +136,11 @@ tree between -rc6 and the next -rc1.
>
> Please notice that the media subsystem is a high traffic one, so it
> could take a while for us to be able to review your patches. Feel free
> -to ping if you don't get a feedback on a couple of weeks or to ask
> +to ping if you don't get a feedback in a couple of weeks or to ask
> other developers to publicly add Reviewed-by and, more importantly,
> Tested-by tags.
>
> -Please notice that we expect a detailed description for Tested-by,
> +Please note that we expect a detailed description for Tested-by,
> identifying what boards were used at the test and what it was tested.
>
> Style Cleanup Patches
> @@ -134,7 +149,9 @@ Style Cleanup Patches
> Style-cleanups are welcome when they come together with other changes
> at the files where the style changes will affect.
>
> -We may accept pure standalone style-cleanups, but they should be grouped
> -per directory. So, for example, if you're doing a cleanup at drivers
> -under drivers/media, please send a single patch for all drivers under
> -drivers/media/pci, another one for drivers/media/usb and so on.
> +We may accept pure standalone style-cleanups, but they should ideally
> +be one patch for the hole subsystem (if the cleanup is low volume),
s/hole/whole/
> +or at least be grouped per directory. So, for example, if you're doing
> +big cleanup changes at drivers under drivers/media, please send a single
> +patch for all drivers under drivers/media/pci, another one for
> +drivers/media/usb and so on.
--
Regards,
Laurent Pinchart
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-18 17:27 ` Laurent Pinchart
0 siblings, 0 replies; 227+ messages in thread
From: Laurent Pinchart @ 2019-09-18 17:27 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, ksummit-discuss
Hi Mauro,
On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 18 Sep 2019 15:36:20 +0300 Laurent Pinchart escreveu:
> > On Fri, Sep 13, 2019 at 01:19:21PM -0300, Mauro Carvalho Chehab wrote:
> > > Document the basic policies of the media subsystem profile.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > ---
> > >
> > > That's basically a modified version of:
> > > https://patchwork.linuxtv.org/patch/52999/
> > >
> > > Applied to the new template
> > >
> > > Documentation/media/index.rst | 1 +
> > > .../media/maintainer-entry-profile.rst | 140 ++++++++++++++++++
> > > MAINTAINERS | 1 +
> > > 3 files changed, 142 insertions(+)
> > > create mode 100644 Documentation/media/maintainer-entry-profile.rst
> > >
> > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > > index 0301c25ff887..ac94685b822a 100644
> > > --- a/Documentation/media/index.rst
> > > +++ b/Documentation/media/index.rst
> > > @@ -12,6 +12,7 @@ Linux Media Subsystem Documentation
> > > .. toctree::
> > > :maxdepth: 2
> > >
> > > + maintainer-entry-profile
> > > media_uapi
> > > media_kapi
> > > dvb-drivers/index
> > > diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> > > new file mode 100644
> > > index 000000000000..81d3b0f9c36a
> > > --- /dev/null
> > > +++ b/Documentation/media/maintainer-entry-profile.rst
> > > @@ -0,0 +1,140 @@
> > > +Media Subsystem Profile
> > > +=======================
> > > +
> > > +Overview
> > > +--------
> > > +
> > > +The media subsystem cover support for a variety of devices: stream
> >
> > s/cover/covers/
> >
> > > +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> > > +and media pipeline control.
> > > +
> > > +It covers, mainly, the contents of those directories:
> > > +
> > > + - drivers/media
> > > + - drivers/staging/media
> > > + - Documentation/media
> > > + - include/media
> > > +
> > > +Both media userspace and Kernel APIs are documented and should be kept in
> > > +sync with the API changes. It means that all patches that add new
> > > +features to the subsystem should also bring changes to the corresponding
> > > +API files.
> > > +
> > > +Also, patches for device drivers that changes the Open Firmware/Device
> > > +Tree bindings should be reviewed by the Device Tree maintainers.
> >
> > You may want to make it clear that this covers bindings only, not driver
> > code that parses the DT. I would just remove "for device drivers", as
> > the rule should also apply to DT bindings documentation that is not
> > driver-specific.
> >
> > > +Due to the size and wide scope of the media subsystem, media's
> > > +maintainership model is to have sub-maintainers that have a broad
> > > +knowledge of an specific aspect of the subsystem. It is a
> > > +sub-maintainers task to review the patches, providing feedback to users
> >
> > s/sub-maintainers/sub-maintainer's/
> >
> > > +if the patches are following the subsystem rules and are properly using
> > > +the media internal and external APIs.
> > > +
> > > +Patches for the media subsystem should be sent to the media mailing list
> > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > +HTML will be automatically rejected by the mail server. There's no need
> > > +to copy the maintainer or sub-maintainer(s).
> >
> > There's too much traffic on mailing lists for me to follow everything, I
> > much prefer being CC'ed on patches.
>
> Well, by using patchwork, the best is to take a look on it at least for
> the patches that you're interested. You could script something using
> pwclient in order to make it easier.
>
> Anyway, not sure if the other sub-maintainers see the same way. From my side,
> I prefer not to be c/c, as this is just more noise, as I just rely on
> patchwork for media patches. What about changing this to:
>
> Patches for the media subsystem should be sent to the media mailing list
> at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> HTML will be automatically rejected by the mail server. It could be wise
> to also copy the sub-maintainer(s).
That works for me. As this is really a personal preference, is there a
way it could be encoded in MAINTAINERS in a per-person fashion ?
Something that would allow you to opt-out from CC from linux-media (but
possibly opt-in for other parts of the kernel), and allow me to opt-in
for the drivers I maintain ?
> > > +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> > > +is submitted, it should appear at:
> > > +
> > > + - https://patchwork.linuxtv.org/project/linux-media/list/
> > > +
> > > +If it doesn't automatically appear there after a few minutes, then
> > > +probably something got wrong on your submission. Please check if the
> > > +email is in plain text only and if your emailer is not mangling with
> > > +whitespaces before complaining or submit it again.
> > > +
> > > +Sub-maintainers
> > > ++++++++++++++++
> > > +
> > > +At the media subsystem, we have a group of senior developers that are
> >
> > How about "experienced" instead of "senior" ? Quality doesn't always
> > come with age, neither for people nor wine :-)
> >
> > > +responsible for doing the code reviews at the drivers (called
> > > +sub-maintainers), and another senior developer responsible for the
> > > +subsystem as a hole. For core changes, whenever possible, multiple
> > > +media (sub-)maintainers do the review.
> > > +
> > > +The sub-maintainers work on specific areas of the subsystem, as
> > > +described below:
> > > +
> > > +Digital TV:
> > > + Sean Young <sean@mess.org>
> > > +
> > > +HDMI CEC:
> > > + Hans Verkuil <hverkuil@xs4all.nl>
> > > +
> > > +Media controller drivers:
> > > + Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > +
> > > +Remote Controllers:
> > > + Sean Young <sean@mess.org>
> > > +
> > > +Sensor drivers:
> > > + Sakari Ailus <sakari.ailus@linux.intel.com>
> > > +
> > > +V4L2 drivers:
> > > + Hans Verkuil <hverkuil@xs4all.nl>
> > > +
> > > +Submit Checklist Addendum
> > > +-------------------------
> > > +
> > > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> > > +that should be used in order to check if the drivers are properly
> > > +implementing the media APIs.
> > > +
> > > +Those tests need to be passed before the patches go upstream.
> >
> > s/need to be passed/need to pass/
> >
> > > +
> > > +Also, please notice that we build the Kernel with::
> > > +
> > > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> > > +
> > > +Where the check script is::
> > > +
> > > + #!/bin/bash
> > > + /devel/smatch/smatch -p=kernel $@ >&2
> > > + /devel/sparse/sparse $@ >&2
> > > +
> > > +Be sure to not introduce new warnings on your patches.
> >
> > While static analysers deliver value, I fear this is a high barrier to
> > entry for new contributors.
>
> Will change this to:
>
> Be sure to not introduce new warnings on your patches without a
> very good reason.
>
> Especially for new contributors, I really expect patches to not introduce
> new warnings, as it is usually a lot more painful to fix them later than
> to ask devs to do things right at the first place.
I fully agree with the goal, but asking a drive-by contributor, who
usually has to go through issues with sending patches through e-mail
already, to install smatch and sparse and use them, is setting the bar
high. I think automating those checks is the way to go.
> > > +
> > > +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 -rc5, and ideally stabilized
> > > +in the linux-media branch by -rc6.
> > > +
> > > +Coding Style Addendum
> > > +---------------------
> > > +
> > > +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> > > +
> > > + $ ./script/checkpatch.pl --strict
> >
> > But we still accept some warnings. I think this should be documented.
>
> True, but not sure if we should enter into too specific details here.
>
> What about adding something like:
>
> Please notice that the goal here is to improve code readability. On a few
> cases, checkpatch may actually point to something that would look worse.
>
> So, you should use good send sense here, being prepared to justify any
s/send sense/sense/
> coding style decision.
"being prepared to justify" sounds a bit harsh :-) But the general
message is good.
>
> Please also notice that, on some cases, when you fix one issue, you may
> receive warnings about lines longer than 80 columns. It is fine to have
> longer lines if this means that other warnings will be fixed by that.
>
> Yet, if you're having more than 80 columns on a line, please consider
> simplifying the code - if too idented - or to use shorter names for
> variables.
That's already quite specific for my taste. We can keep it as-is if you
think it's fine, but we clearly shouldn't go into more details.
> > > +
> > > +Review Cadence
> > > +--------------
> > > +
> > > +Provided that your patch is at https://patchwork.linuxtv.org, it should
> > > +be sooner or later handled, so you don't need to re-submit a patch.
> > > +
> > > +Except for bug fixes, we don't usually add new patches to the development
> > > +tree between -rc6 and the next -rc1.
> > > +
> > > +Please notice that the media subsystem is a high traffic one, so it
> > > +could take a while for us to be able to review your patches. Feel free
> > > +to ping if you don't get a feedback on a couple of weeks or to ask
> >
> > s/on a/in a/
> >
> > > +other developers to publicly add Reviewed-by and, more importantly,
> > > +Tested-by tags.
> > > +
> > > +Please notice that we expect a detailed description for Tested-by,
> >
> > s/notice/note/
> >
> > > +identifying what boards were used at the test and what it was tested.
> > > +
> > > +Style Cleanup Patches
> > > +---------------------
> > > +
> > > +Style-cleanups are welcome when they come together with other changes
> > > +at the files where the style changes will affect.
> > > +
> > > +We may accept pure standalone style-cleanups, but they should be grouped
> > > +per directory. So, for example, if you're doing a cleanup at drivers
> > > +under drivers/media, please send a single patch for all drivers under
> > > +drivers/media/pci, another one for drivers/media/usb and so on.
> >
> > How about also stating that if the cleanup is low volume, a single patch
> > for the whole subsystem is preferred ? I think that should actually be
> > the rule, with a split to ease review only when the patch would be too
> > big.
> >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 7c62b45201d7..e7f44ec05a42 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -10077,6 +10077,7 @@ W: https://linuxtv.org
> > > Q: http://patchwork.kernel.org/project/linux-media/list/
> > > T: git git://linuxtv.org/media_tree.git
> > > S: Maintained
> > > +P: Documentation/media/maintainer-entry-profile.rst
> > > F: Documentation/devicetree/bindings/media/
> > > F: Documentation/media/
> > > F: drivers/media/
> >
>
> I'm enclosing the diff against the past version. I'll send a final version
> once the profiles patchset arrives upstream.
>
> diff --git a/Documentation/media/maintainer-entry-profile.rst b/Documentation/media/maintainer-entry-profile.rst
> index 81d3b0f9c36a..68d642abe2c1 100644
> --- a/Documentation/media/maintainer-entry-profile.rst
> +++ b/Documentation/media/maintainer-entry-profile.rst
> @@ -4,7 +4,7 @@ Media Subsystem Profile
> Overview
> --------
>
> -The media subsystem cover support for a variety of devices: stream
> +The media subsystem covers support for a variety of devices: stream
> capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> and media pipeline control.
>
> @@ -20,20 +20,20 @@ sync with the API changes. It means that all patches that add new
> features to the subsystem should also bring changes to the corresponding
> API files.
>
> -Also, patches for device drivers that changes the Open Firmware/Device
> -Tree bindings should be reviewed by the Device Tree maintainers.
> +Also, patches that changes the Open Firmware/Device Tree bindings should
> +also be reviewed by the Device Tree maintainers.
>
> Due to the size and wide scope of the media subsystem, media's
> maintainership model is to have sub-maintainers that have a broad
> knowledge of an specific aspect of the subsystem. It is a
> -sub-maintainers task to review the patches, providing feedback to users
> +sub-maintainer's task to review the patches, providing feedback to users
> if the patches are following the subsystem rules and are properly using
> the media internal and external APIs.
>
> Patches for the media subsystem should be sent to the media mailing list
> at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> -HTML will be automatically rejected by the mail server. There's no need
> -to copy the maintainer or sub-maintainer(s).
> +HTML will be automatically rejected by the mail server. It could be wise
> +to also copy the sub-maintainer(s).
>
> Media's workflow is heavily based on Patchwork, meaning that, once a patch
> is submitted, it should appear at:
> @@ -48,8 +48,8 @@ whitespaces before complaining or submit it again.
> Sub-maintainers
> +++++++++++++++
>
> -At the media subsystem, we have a group of senior developers that are
> -responsible for doing the code reviews at the drivers (called
> +At the media subsystem, we have a group of experienced developers that
> +are responsible for doing the code reviews at the drivers (called
> sub-maintainers), and another senior developer responsible for the
> subsystem as a hole. For core changes, whenever possible, multiple
> media (sub-)maintainers do the review.
> @@ -82,7 +82,7 @@ There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> that should be used in order to check if the drivers are properly
> implementing the media APIs.
>
> -Those tests need to be passed before the patches go upstream.
> +Those tests need to pass before the patches go upstream.
>
> Also, please notice that we build the Kernel with::
>
> @@ -94,7 +94,8 @@ Where the check script is::
> /devel/smatch/smatch -p=kernel $@ >&2
> /devel/sparse/sparse $@ >&2
>
> -Be sure to not introduce new warnings on your patches.
> +Be sure to not introduce new warnings on your patches without a
> +very good reason.
>
> Key Cycle Dates
> ---------------
> @@ -110,6 +111,20 @@ Media development uses checkpatch on strict mode to verify the code style, e. g.
>
> $ ./script/checkpatch.pl --strict
>
> +Please notice that the goal here is to improve code readability. On a few
> +cases, checkpatch may actually point to something that would look worse.
> +
> +So, you should use good send sense here, being prepared to justify any
> +coding style decision.
> +
> +Please also notice that, on some cases, when you fix one issue, you may
> +receive warnings about lines longer than 80 columns. It is fine to have
> +longer lines if this means that other warnings will be fixed by that.
> +
> +Yet, if you're having more than 80 columns on a line, please consider
> +simplifying the code - if too idented - or to use shorter names for
> +variables.
> +
> Review Cadence
> --------------
>
> @@ -121,11 +136,11 @@ tree between -rc6 and the next -rc1.
>
> Please notice that the media subsystem is a high traffic one, so it
> could take a while for us to be able to review your patches. Feel free
> -to ping if you don't get a feedback on a couple of weeks or to ask
> +to ping if you don't get a feedback in a couple of weeks or to ask
> other developers to publicly add Reviewed-by and, more importantly,
> Tested-by tags.
>
> -Please notice that we expect a detailed description for Tested-by,
> +Please note that we expect a detailed description for Tested-by,
> identifying what boards were used at the test and what it was tested.
>
> Style Cleanup Patches
> @@ -134,7 +149,9 @@ Style Cleanup Patches
> Style-cleanups are welcome when they come together with other changes
> at the files where the style changes will affect.
>
> -We may accept pure standalone style-cleanups, but they should be grouped
> -per directory. So, for example, if you're doing a cleanup at drivers
> -under drivers/media, please send a single patch for all drivers under
> -drivers/media/pci, another one for drivers/media/usb and so on.
> +We may accept pure standalone style-cleanups, but they should ideally
> +be one patch for the hole subsystem (if the cleanup is low volume),
s/hole/whole/
> +or at least be grouped per directory. So, for example, if you're doing
> +big cleanup changes at drivers under drivers/media, please send a single
> +patch for all drivers under drivers/media/pci, another one for
> +drivers/media/usb and so on.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-18 11:23 ` Mauro Carvalho Chehab
@ 2019-09-18 17:39 ` Kees Cook
-1 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-18 17:39 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List
On Wed, Sep 18, 2019 at 08:23:26AM -0300, Mauro Carvalho Chehab wrote:
> You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,
Right! Sorry, I meant what you'd suggested earlier: having a script
convert it at doc-build-time.
> The latest RFC about that with I sent was this one:
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html
Cool, I've found it on Lore now too:
https://lore.kernel.org/lkml/20160923120733.546a4b7a@vento.lan/
I think having a script generate the entire thing might be better
(instead of having duplicated instructions at the top of both files),
which I see is what Joe suggested too.
> +.. include:: ../../MAINTAINERS
> + :literal:
Nah, let's do a full make target as you'd suggested back in that thread.
I'll give it a shot if you don't beat me to it. :)
--
Kees Cook
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
@ 2019-09-18 17:39 ` Kees Cook
0 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-18 17:39 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: ksummit-discuss, Linux Media Mailing List, Jonathan Corbet
On Wed, Sep 18, 2019 at 08:23:26AM -0300, Mauro Carvalho Chehab wrote:
> You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,
Right! Sorry, I meant what you'd suggested earlier: having a script
convert it at doc-build-time.
> The latest RFC about that with I sent was this one:
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html
Cool, I've found it on Lore now too:
https://lore.kernel.org/lkml/20160923120733.546a4b7a@vento.lan/
I think having a script generate the entire thing might be better
(instead of having duplicated instructions at the top of both files),
which I see is what Joe suggested too.
> +.. include:: ../../MAINTAINERS
> + :literal:
Nah, let's do a full make target as you'd suggested back in that thread.
I'll give it a shot if you don't beat me to it. :)
--
Kees Cook
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-18 17:39 ` Kees Cook
@ 2019-09-18 18:35 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 18:35 UTC (permalink / raw)
To: Kees Cook; +Cc: ksummit-discuss, Linux Media Mailing List
Em Wed, 18 Sep 2019 10:39:32 -0700
Kees Cook <keescook@chromium.org> escreveu:
> On Wed, Sep 18, 2019 at 08:23:26AM -0300, Mauro Carvalho Chehab wrote:
> > You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,
>
> Right! Sorry, I meant what you'd suggested earlier: having a script
> convert it at doc-build-time.
>
> > The latest RFC about that with I sent was this one:
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html
>
> Cool, I've found it on Lore now too:
> https://lore.kernel.org/lkml/20160923120733.546a4b7a@vento.lan/
>
> I think having a script generate the entire thing might be better
> (instead of having duplicated instructions at the top of both files),
> which I see is what Joe suggested too.
Yes, I agree that having the instructions duplicated was not the best
idea :-)
I guess I did it, on that time, just to experiment with the approach,
but my plan were to avoid the duplication on some future patch.
The big issue, on that point, was the usage of the programoutput
extension. Some devs didn't like using it.
>
> > +.. include:: ../../MAINTAINERS
> > + :literal:
>
> Nah, let's do a full make target as you'd suggested back in that thread.
>
> I'll give it a shot if you don't beat me to it. :)
Yeah, please give it a shot. Feel free to reuse anything from my past
approaches if needed.
I suspect that, if we convert the first part of MAINTAINERS to ReST
syntax, we could add something similar to this to Documentation/Makefile:
$(BUILDDIR)/maintainers.rst:
awk '{if (match($0,"----------")) exit; print}' MAINTAINERS >$(BUILDDIR)/maintainers.rst
awk '/----------/{y=1;next}y' MAINTAINERS|sed -E 's,^(\w:),:\1,' >>$(BUILDDIR)/maintainers.rst
Thanks,
Mauro
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
@ 2019-09-18 18:35 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 18:35 UTC (permalink / raw)
To: Kees Cook; +Cc: ksummit-discuss, Linux Media Mailing List, Jonathan Corbet
Em Wed, 18 Sep 2019 10:39:32 -0700
Kees Cook <keescook@chromium.org> escreveu:
> On Wed, Sep 18, 2019 at 08:23:26AM -0300, Mauro Carvalho Chehab wrote:
> > You can't simply rename MAINTAINERS to .rst and let Sphinx handle it,
>
> Right! Sorry, I meant what you'd suggested earlier: having a script
> convert it at doc-build-time.
>
> > The latest RFC about that with I sent was this one:
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1238576.html
>
> Cool, I've found it on Lore now too:
> https://lore.kernel.org/lkml/20160923120733.546a4b7a@vento.lan/
>
> I think having a script generate the entire thing might be better
> (instead of having duplicated instructions at the top of both files),
> which I see is what Joe suggested too.
Yes, I agree that having the instructions duplicated was not the best
idea :-)
I guess I did it, on that time, just to experiment with the approach,
but my plan were to avoid the duplication on some future patch.
The big issue, on that point, was the usage of the programoutput
extension. Some devs didn't like using it.
>
> > +.. include:: ../../MAINTAINERS
> > + :literal:
>
> Nah, let's do a full make target as you'd suggested back in that thread.
>
> I'll give it a shot if you don't beat me to it. :)
Yeah, please give it a shot. Feel free to reuse anything from my past
approaches if needed.
I suspect that, if we convert the first part of MAINTAINERS to ReST
syntax, we could add something similar to this to Documentation/Makefile:
$(BUILDDIR)/maintainers.rst:
awk '{if (match($0,"----------")) exit; print}' MAINTAINERS >$(BUILDDIR)/maintainers.rst
awk '/----------/{y=1;next}y' MAINTAINERS|sed -E 's,^(\w:),:\1,' >>$(BUILDDIR)/maintainers.rst
Thanks,
Mauro
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-18 17:27 ` Laurent Pinchart
@ 2019-09-18 18:48 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 18:48 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ksummit-discuss, Linux Media Mailing List
Em Wed, 18 Sep 2019 20:27:05 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > I prefer not to be c/c, as this is just more noise, as I just rely on
> > patchwork for media patches. What about changing this to:
> >
> > Patches for the media subsystem should be sent to the media mailing list
> > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > HTML will be automatically rejected by the mail server. It could be wise
> > to also copy the sub-maintainer(s).
>
> That works for me. As this is really a personal preference, is there a
> way it could be encoded in MAINTAINERS in a per-person fashion ?
> Something that would allow you to opt-out from CC from linux-media (but
> possibly opt-in for other parts of the kernel), and allow me to opt-in
> for the drivers I maintain ?
I don't think so. Perhaps we could add, instead, something like that at the
sub-maintainers section of the profile.
> > > > +Submit Checklist Addendum
> > > > +-------------------------
> > > > +
> > > > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> > > > +that should be used in order to check if the drivers are properly
> > > > +implementing the media APIs.
> > > > +
> > > > +Those tests need to be passed before the patches go upstream.
> > >
> > > s/need to be passed/need to pass/
> > >
> > > > +
> > > > +Also, please notice that we build the Kernel with::
> > > > +
> > > > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> > > > +
> > > > +Where the check script is::
> > > > +
> > > > + #!/bin/bash
> > > > + /devel/smatch/smatch -p=kernel $@ >&2
> > > > + /devel/sparse/sparse $@ >&2
> > > > +
> > > > +Be sure to not introduce new warnings on your patches.
> > >
> > > While static analysers deliver value, I fear this is a high barrier to
> > > entry for new contributors.
> >
> > Will change this to:
> >
> > Be sure to not introduce new warnings on your patches without a
> > very good reason.
> >
> > Especially for new contributors, I really expect patches to not introduce
> > new warnings, as it is usually a lot more painful to fix them later than
> > to ask devs to do things right at the first place.
>
> I fully agree with the goal, but asking a drive-by contributor, who
> usually has to go through issues with sending patches through e-mail
> already, to install smatch and sparse and use them, is setting the bar
> high. I think automating those checks is the way to go.
Yeah, I have plans to automate it, the same way we did for pull
requests. I'm planning to do that later, after upgrading patchwork
to the current upstream version (with requires upgrading some libraries
too at the server).
In any case, having this at the profile is a reminder for whomever is
submitting a patch that it should be clean for static analyzers too.
> > > > +Coding Style Addendum
> > > > +---------------------
> > > > +
> > > > +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> > > > +
> > > > + $ ./script/checkpatch.pl --strict
> > >
> > > But we still accept some warnings. I think this should be documented.
> >
> > True, but not sure if we should enter into too specific details here.
> >
> > What about adding something like:
> >
> > Please notice that the goal here is to improve code readability. On a few
> > cases, checkpatch may actually point to something that would look worse.
> >
> > So, you should use good send sense here, being prepared to justify any
>
> s/send sense/sense/
Gah... where this "send" came from??? :-p
>
> > coding style decision.
>
> "being prepared to justify" sounds a bit harsh :-) But the general
> message is good.
Any suggestions for a lighter text with similar meaning? :-)
> > Please also notice that, on some cases, when you fix one issue, you may
> > receive warnings about lines longer than 80 columns. It is fine to have
> > longer lines if this means that other warnings will be fixed by that.
> >
> > Yet, if you're having more than 80 columns on a line, please consider
> > simplifying the code - if too idented - or to use shorter names for
> > variables.
>
> That's already quite specific for my taste. We can keep it as-is if you
> think it's fine, but we clearly shouldn't go into more details.
Yeah, I see. Yet, IMHO, we should either not add anything about checkpatch
warnings that might not be relevant or add something similar like the above.
Thanks,
Mauro
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-18 18:48 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-18 18:48 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Linux Media Mailing List, ksummit-discuss
Em Wed, 18 Sep 2019 20:27:05 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > I prefer not to be c/c, as this is just more noise, as I just rely on
> > patchwork for media patches. What about changing this to:
> >
> > Patches for the media subsystem should be sent to the media mailing list
> > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > HTML will be automatically rejected by the mail server. It could be wise
> > to also copy the sub-maintainer(s).
>
> That works for me. As this is really a personal preference, is there a
> way it could be encoded in MAINTAINERS in a per-person fashion ?
> Something that would allow you to opt-out from CC from linux-media (but
> possibly opt-in for other parts of the kernel), and allow me to opt-in
> for the drivers I maintain ?
I don't think so. Perhaps we could add, instead, something like that at the
sub-maintainers section of the profile.
> > > > +Submit Checklist Addendum
> > > > +-------------------------
> > > > +
> > > > +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> > > > +that should be used in order to check if the drivers are properly
> > > > +implementing the media APIs.
> > > > +
> > > > +Those tests need to be passed before the patches go upstream.
> > >
> > > s/need to be passed/need to pass/
> > >
> > > > +
> > > > +Also, please notice that we build the Kernel with::
> > > > +
> > > > + make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
> > > > +
> > > > +Where the check script is::
> > > > +
> > > > + #!/bin/bash
> > > > + /devel/smatch/smatch -p=kernel $@ >&2
> > > > + /devel/sparse/sparse $@ >&2
> > > > +
> > > > +Be sure to not introduce new warnings on your patches.
> > >
> > > While static analysers deliver value, I fear this is a high barrier to
> > > entry for new contributors.
> >
> > Will change this to:
> >
> > Be sure to not introduce new warnings on your patches without a
> > very good reason.
> >
> > Especially for new contributors, I really expect patches to not introduce
> > new warnings, as it is usually a lot more painful to fix them later than
> > to ask devs to do things right at the first place.
>
> I fully agree with the goal, but asking a drive-by contributor, who
> usually has to go through issues with sending patches through e-mail
> already, to install smatch and sparse and use them, is setting the bar
> high. I think automating those checks is the way to go.
Yeah, I have plans to automate it, the same way we did for pull
requests. I'm planning to do that later, after upgrading patchwork
to the current upstream version (with requires upgrading some libraries
too at the server).
In any case, having this at the profile is a reminder for whomever is
submitting a patch that it should be clean for static analyzers too.
> > > > +Coding Style Addendum
> > > > +---------------------
> > > > +
> > > > +Media development uses checkpatch on strict mode to verify the code style, e. g.::
> > > > +
> > > > + $ ./script/checkpatch.pl --strict
> > >
> > > But we still accept some warnings. I think this should be documented.
> >
> > True, but not sure if we should enter into too specific details here.
> >
> > What about adding something like:
> >
> > Please notice that the goal here is to improve code readability. On a few
> > cases, checkpatch may actually point to something that would look worse.
> >
> > So, you should use good send sense here, being prepared to justify any
>
> s/send sense/sense/
Gah... where this "send" came from??? :-p
>
> > coding style decision.
>
> "being prepared to justify" sounds a bit harsh :-) But the general
> message is good.
Any suggestions for a lighter text with similar meaning? :-)
> > Please also notice that, on some cases, when you fix one issue, you may
> > receive warnings about lines longer than 80 columns. It is fine to have
> > longer lines if this means that other warnings will be fixed by that.
> >
> > Yet, if you're having more than 80 columns on a line, please consider
> > simplifying the code - if too idented - or to use shorter names for
> > variables.
>
> That's already quite specific for my taste. We can keep it as-is if you
> think it's fine, but we clearly shouldn't go into more details.
Yeah, I see. Yet, IMHO, we should either not add anything about checkpatch
warnings that might not be relevant or add something similar like the above.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-18 13:57 ` Mauro Carvalho Chehab
@ 2019-09-19 6:56 ` Dan Carpenter
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-19 6:56 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List
On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > +Patches for the media subsystem should be sent to the media mailing list
> > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > +HTML will be automatically rejected by the mail server. There's no need
> > > +to copy the maintainer or sub-maintainer(s).
> >
> > There's too much traffic on mailing lists for me to follow everything, I
> > much prefer being CC'ed on patches.
>
> Well, by using patchwork, the best is to take a look on it at least for
> the patches that you're interested. You could script something using
> pwclient in order to make it easier.
>
> Anyway, not sure if the other sub-maintainers see the same way. From my side,
> I prefer not to be c/c, as this is just more noise, as I just rely on
> patchwork for media patches. What about changing this to:
>
> Patches for the media subsystem should be sent to the media mailing list
> at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> HTML will be automatically rejected by the mail server. It could be wise
> to also copy the sub-maintainer(s).
The documentation should say "Use get_maintainer.pl" and do what it
says. Everything else is too complicated.
Occasionally staging maintainers will complain that they aren't CC'd
even though the staging/driver/README says to CC them and I am tell them
"No, the responsibility is for you to add yourself to MAINTAINERS. It
doesn't matter what the documentation says, you messed up so you need to
stop getting annoyed with newbies for not reading the documentation when
it's your fault you weren't CC'd."
When I sent a patch, I use get_maintainer.pl then I add whoever the
wrote the commit from the Fixes tag. Then I remove Colin King and Kees
Cook from the CC list because they worked all over the tree and I know
them. I also normally remove LKML if there is another mailing list but
at least one subsystem uses LKML for patchwork so this isn't safe.
So the safest instructions are "Use get_matainer.pl and add the person
who wrote the commit in the Fixes tag".
regards,
dan carpenter
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-19 6:56 ` Dan Carpenter
0 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-19 6:56 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, ksummit-discuss, Linux Media Mailing List
On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > +Patches for the media subsystem should be sent to the media mailing list
> > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > +HTML will be automatically rejected by the mail server. There's no need
> > > +to copy the maintainer or sub-maintainer(s).
> >
> > There's too much traffic on mailing lists for me to follow everything, I
> > much prefer being CC'ed on patches.
>
> Well, by using patchwork, the best is to take a look on it at least for
> the patches that you're interested. You could script something using
> pwclient in order to make it easier.
>
> Anyway, not sure if the other sub-maintainers see the same way. From my side,
> I prefer not to be c/c, as this is just more noise, as I just rely on
> patchwork for media patches. What about changing this to:
>
> Patches for the media subsystem should be sent to the media mailing list
> at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> HTML will be automatically rejected by the mail server. It could be wise
> to also copy the sub-maintainer(s).
The documentation should say "Use get_maintainer.pl" and do what it
says. Everything else is too complicated.
Occasionally staging maintainers will complain that they aren't CC'd
even though the staging/driver/README says to CC them and I am tell them
"No, the responsibility is for you to add yourself to MAINTAINERS. It
doesn't matter what the documentation says, you messed up so you need to
stop getting annoyed with newbies for not reading the documentation when
it's your fault you weren't CC'd."
When I sent a patch, I use get_maintainer.pl then I add whoever the
wrote the commit from the Fixes tag. Then I remove Colin King and Kees
Cook from the CC list because they worked all over the tree and I know
them. I also normally remove LKML if there is another mailing list but
at least one subsystem uses LKML for patchwork so this isn't safe.
So the safest instructions are "Use get_matainer.pl and add the person
who wrote the commit in the Fixes tag".
regards,
dan carpenter
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-18 18:48 ` Mauro Carvalho Chehab
@ 2019-09-19 7:08 ` Dan Carpenter
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-19 7:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List
On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 18 Sep 2019 20:27:05 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
>
> > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > patchwork for media patches. What about changing this to:
> > >
> > > Patches for the media subsystem should be sent to the media mailing list
> > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > HTML will be automatically rejected by the mail server. It could be wise
> > > to also copy the sub-maintainer(s).
> >
> > That works for me. As this is really a personal preference, is there a
> > way it could be encoded in MAINTAINERS in a per-person fashion ?
> > Something that would allow you to opt-out from CC from linux-media (but
> > possibly opt-in for other parts of the kernel), and allow me to opt-in
> > for the drivers I maintain ?
>
> I don't think so. Perhaps we could add, instead, something like that at the
> sub-maintainers section of the profile.
Of course there is a way to add yourself as a maintainer for a specific
.c file... Maybe people feel like MAINTAINERS is too crowded?
We could update get_maintainer.pl to grep the .c files for a specific
tag instead of putting everything in a centralized MAINTAINERS file.
But it doesn't make sense to try store that information MY BRAIN! I
can't remember anything from one minute to the next so I have no idea
who maintains media submodules...
regards,
dan carpenter
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-19 7:08 ` Dan Carpenter
0 siblings, 0 replies; 227+ messages in thread
From: Dan Carpenter @ 2019-09-19 7:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Laurent Pinchart, ksummit-discuss, Linux Media Mailing List
On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 18 Sep 2019 20:27:05 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
>
> > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > patchwork for media patches. What about changing this to:
> > >
> > > Patches for the media subsystem should be sent to the media mailing list
> > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > HTML will be automatically rejected by the mail server. It could be wise
> > > to also copy the sub-maintainer(s).
> >
> > That works for me. As this is really a personal preference, is there a
> > way it could be encoded in MAINTAINERS in a per-person fashion ?
> > Something that would allow you to opt-out from CC from linux-media (but
> > possibly opt-in for other parts of the kernel), and allow me to opt-in
> > for the drivers I maintain ?
>
> I don't think so. Perhaps we could add, instead, something like that at the
> sub-maintainers section of the profile.
Of course there is a way to add yourself as a maintainer for a specific
.c file... Maybe people feel like MAINTAINERS is too crowded?
We could update get_maintainer.pl to grep the .c files for a specific
tag instead of putting everything in a centralized MAINTAINERS file.
But it doesn't make sense to try store that information MY BRAIN! I
can't remember anything from one minute to the next so I have no idea
who maintains media submodules...
regards,
dan carpenter
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-19 6:56 ` Dan Carpenter
@ 2019-09-19 7:22 ` Geert Uytterhoeven
-1 siblings, 0 replies; 227+ messages in thread
From: Geert Uytterhoeven @ 2019-09-19 7:22 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Mauro Carvalho Chehab, ksummit, Linux Media Mailing List
On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > +to copy the maintainer or sub-maintainer(s).
> > >
> > > There's too much traffic on mailing lists for me to follow everything, I
> > > much prefer being CC'ed on patches.
> >
> > Well, by using patchwork, the best is to take a look on it at least for
> > the patches that you're interested. You could script something using
> > pwclient in order to make it easier.
> >
> > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > I prefer not to be c/c, as this is just more noise, as I just rely on
> > patchwork for media patches. What about changing this to:
> >
> > Patches for the media subsystem should be sent to the media mailing list
> > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > HTML will be automatically rejected by the mail server. It could be wise
> > to also copy the sub-maintainer(s).
>
> The documentation should say "Use get_maintainer.pl" and do what it
> says. Everything else is too complicated.
+1
> When I sent a patch, I use get_maintainer.pl then I add whoever the
> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> Cook from the CC list because they worked all over the tree and I know
> them. I also normally remove LKML if there is another mailing list but
> at least one subsystem uses LKML for patchwork so this isn't safe.
>
> So the safest instructions are "Use get_matainer.pl and add the person
> who wrote the commit in the Fixes tag".
Better: perhaps get_maintainer.pl can be taught to add the author of the
commit pointed to by the Fixes tag, if present?
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-19 7:22 ` Geert Uytterhoeven
0 siblings, 0 replies; 227+ messages in thread
From: Geert Uytterhoeven @ 2019-09-19 7:22 UTC (permalink / raw)
To: Dan Carpenter
Cc: Mauro Carvalho Chehab, ksummit, Linux Media Mailing List, Joe Perches
On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > +to copy the maintainer or sub-maintainer(s).
> > >
> > > There's too much traffic on mailing lists for me to follow everything, I
> > > much prefer being CC'ed on patches.
> >
> > Well, by using patchwork, the best is to take a look on it at least for
> > the patches that you're interested. You could script something using
> > pwclient in order to make it easier.
> >
> > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > I prefer not to be c/c, as this is just more noise, as I just rely on
> > patchwork for media patches. What about changing this to:
> >
> > Patches for the media subsystem should be sent to the media mailing list
> > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > HTML will be automatically rejected by the mail server. It could be wise
> > to also copy the sub-maintainer(s).
>
> The documentation should say "Use get_maintainer.pl" and do what it
> says. Everything else is too complicated.
+1
> When I sent a patch, I use get_maintainer.pl then I add whoever the
> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> Cook from the CC list because they worked all over the tree and I know
> them. I also normally remove LKML if there is another mailing list but
> at least one subsystem uses LKML for patchwork so this isn't safe.
>
> So the safest instructions are "Use get_matainer.pl and add the person
> who wrote the commit in the Fixes tag".
Better: perhaps get_maintainer.pl can be taught to add the author of the
commit pointed to by the Fixes tag, if present?
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-19 7:22 ` Geert Uytterhoeven
@ 2019-09-19 8:49 ` Jani Nikula
-1 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-19 8:49 UTC (permalink / raw)
To: Geert Uytterhoeven, Dan Carpenter
Cc: Mauro Carvalho Chehab, ksummit, Linux Media Mailing List
On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
>> When I sent a patch, I use get_maintainer.pl then I add whoever the
>> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
>> Cook from the CC list because they worked all over the tree and I know
>> them. I also normally remove LKML if there is another mailing list but
>> at least one subsystem uses LKML for patchwork so this isn't safe.
>>
>> So the safest instructions are "Use get_matainer.pl and add the person
>> who wrote the commit in the Fixes tag".
>
> Better: perhaps get_maintainer.pl can be taught to add the author of the
> commit pointed to by the Fixes tag, if present?
The drm maintainer tools [1] have that, with Cc's and reviewers picked
up, and appropriate Cc: stable added. On a random commit from v5.3:
$ dim fixes 61f7f7c8f978b1c0d80e43c83b7d110ca0496eb4
Fixes: 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com>
Cc: Ian W MORRISON <ianwmorrison@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: <stable@vger.kernel.org> # v5.3+
I'm sure it could be massively improved, but it does give you the
initial list that's easy to trim.
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/maintainer-tools/blob/master/dim#L2398
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-19 8:49 ` Jani Nikula
0 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-19 8:49 UTC (permalink / raw)
To: Geert Uytterhoeven, Dan Carpenter
Cc: Mauro Carvalho Chehab, ksummit, Linux Media Mailing List
On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
>> When I sent a patch, I use get_maintainer.pl then I add whoever the
>> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
>> Cook from the CC list because they worked all over the tree and I know
>> them. I also normally remove LKML if there is another mailing list but
>> at least one subsystem uses LKML for patchwork so this isn't safe.
>>
>> So the safest instructions are "Use get_matainer.pl and add the person
>> who wrote the commit in the Fixes tag".
>
> Better: perhaps get_maintainer.pl can be taught to add the author of the
> commit pointed to by the Fixes tag, if present?
The drm maintainer tools [1] have that, with Cc's and reviewers picked
up, and appropriate Cc: stable added. On a random commit from v5.3:
$ dim fixes 61f7f7c8f978b1c0d80e43c83b7d110ca0496eb4
Fixes: 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com>
Cc: Ian W MORRISON <ianwmorrison@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: <stable@vger.kernel.org> # v5.3+
I'm sure it could be massively improved, but it does give you the
initial list that's easy to trim.
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/maintainer-tools/blob/master/dim#L2398
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-19 8:49 ` Jani Nikula
@ 2019-09-19 8:58 ` Geert Uytterhoeven
-1 siblings, 0 replies; 227+ messages in thread
From: Geert Uytterhoeven @ 2019-09-19 8:58 UTC (permalink / raw)
To: Jani Nikula
Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List
Hi Jani,
On Thu, Sep 19, 2019 at 10:49 AM Jani Nikula <jani.nikula@intel.com> wrote:
> On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> >> When I sent a patch, I use get_maintainer.pl then I add whoever the
> >> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> >> Cook from the CC list because they worked all over the tree and I know
> >> them. I also normally remove LKML if there is another mailing list but
> >> at least one subsystem uses LKML for patchwork so this isn't safe.
> >>
> >> So the safest instructions are "Use get_matainer.pl and add the person
> >> who wrote the commit in the Fixes tag".
> >
> > Better: perhaps get_maintainer.pl can be taught to add the author of the
> > commit pointed to by the Fixes tag, if present?
>
> The drm maintainer tools [1] have that, with Cc's and reviewers picked
> up, and appropriate Cc: stable added. On a random commit from v5.3:
Thanks, but that's not scripts/get_maintainer.pl, and restricted to one out
of N subsystems. Not so dissimilar from what Dan was complaining about.
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-19 8:58 ` Geert Uytterhoeven
0 siblings, 0 replies; 227+ messages in thread
From: Geert Uytterhoeven @ 2019-09-19 8:58 UTC (permalink / raw)
To: Jani Nikula
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit, Linux Media Mailing List
Hi Jani,
On Thu, Sep 19, 2019 at 10:49 AM Jani Nikula <jani.nikula@intel.com> wrote:
> On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> >> When I sent a patch, I use get_maintainer.pl then I add whoever the
> >> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> >> Cook from the CC list because they worked all over the tree and I know
> >> them. I also normally remove LKML if there is another mailing list but
> >> at least one subsystem uses LKML for patchwork so this isn't safe.
> >>
> >> So the safest instructions are "Use get_matainer.pl and add the person
> >> who wrote the commit in the Fixes tag".
> >
> > Better: perhaps get_maintainer.pl can be taught to add the author of the
> > commit pointed to by the Fixes tag, if present?
>
> The drm maintainer tools [1] have that, with Cc's and reviewers picked
> up, and appropriate Cc: stable added. On a random commit from v5.3:
Thanks, but that's not scripts/get_maintainer.pl, and restricted to one out
of N subsystems. Not so dissimilar from what Dan was complaining about.
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-19 6:56 ` Dan Carpenter
@ 2019-09-19 9:52 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-19 9:52 UTC (permalink / raw)
To: Dan Carpenter; +Cc: ksummit-discuss, Linux Media Mailing List
Em Thu, 19 Sep 2019 09:56:44 +0300
Dan Carpenter <dan.carpenter@oracle.com> escreveu:
> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > +to copy the maintainer or sub-maintainer(s).
> > >
> > > There's too much traffic on mailing lists for me to follow everything, I
> > > much prefer being CC'ed on patches.
> >
> > Well, by using patchwork, the best is to take a look on it at least for
> > the patches that you're interested. You could script something using
> > pwclient in order to make it easier.
> >
> > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > I prefer not to be c/c, as this is just more noise, as I just rely on
> > patchwork for media patches. What about changing this to:
> >
> > Patches for the media subsystem should be sent to the media mailing list
> > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > HTML will be automatically rejected by the mail server. It could be wise
> > to also copy the sub-maintainer(s).
>
> The documentation should say "Use get_maintainer.pl" and do what it
> says. Everything else is too complicated.
Works for me.
> Occasionally staging maintainers will complain that they aren't CC'd
> even though the staging/driver/README says to CC them and I am tell them
> "No, the responsibility is for you to add yourself to MAINTAINERS. It
> doesn't matter what the documentation says, you messed up so you need to
> stop getting annoyed with newbies for not reading the documentation when
> it's your fault you weren't CC'd."
>
> When I sent a patch, I use get_maintainer.pl then I add whoever the
> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> Cook from the CC list because they worked all over the tree and I know
> them. I also normally remove LKML if there is another mailing list but
> at least one subsystem uses LKML for patchwork so this isn't safe.
I use get_maintainer.pl myself, but when submitting some patches
(like documentation ones), I need to manually clean the list, as
it is not uncommon to have a really long c/c list.
>
> So the safest instructions are "Use get_matainer.pl and add the person
> who wrote the commit in the Fixes tag".
>
> regards,
> dan carpenter
>
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-19 9:52 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-19 9:52 UTC (permalink / raw)
To: Dan Carpenter; +Cc: ksummit-discuss, Linux Media Mailing List
Em Thu, 19 Sep 2019 09:56:44 +0300
Dan Carpenter <dan.carpenter@oracle.com> escreveu:
> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > +to copy the maintainer or sub-maintainer(s).
> > >
> > > There's too much traffic on mailing lists for me to follow everything, I
> > > much prefer being CC'ed on patches.
> >
> > Well, by using patchwork, the best is to take a look on it at least for
> > the patches that you're interested. You could script something using
> > pwclient in order to make it easier.
> >
> > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > I prefer not to be c/c, as this is just more noise, as I just rely on
> > patchwork for media patches. What about changing this to:
> >
> > Patches for the media subsystem should be sent to the media mailing list
> > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > HTML will be automatically rejected by the mail server. It could be wise
> > to also copy the sub-maintainer(s).
>
> The documentation should say "Use get_maintainer.pl" and do what it
> says. Everything else is too complicated.
Works for me.
> Occasionally staging maintainers will complain that they aren't CC'd
> even though the staging/driver/README says to CC them and I am tell them
> "No, the responsibility is for you to add yourself to MAINTAINERS. It
> doesn't matter what the documentation says, you messed up so you need to
> stop getting annoyed with newbies for not reading the documentation when
> it's your fault you weren't CC'd."
>
> When I sent a patch, I use get_maintainer.pl then I add whoever the
> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> Cook from the CC list because they worked all over the tree and I know
> them. I also normally remove LKML if there is another mailing list but
> at least one subsystem uses LKML for patchwork so this isn't safe.
I use get_maintainer.pl myself, but when submitting some patches
(like documentation ones), I need to manually clean the list, as
it is not uncommon to have a really long c/c list.
>
> So the safest instructions are "Use get_matainer.pl and add the person
> who wrote the commit in the Fixes tag".
>
> regards,
> dan carpenter
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
Thanks,
Mauro
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-19 8:58 ` Geert Uytterhoeven
@ 2019-09-19 9:52 ` Jani Nikula
-1 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-19 9:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List
On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Jani,
>
> On Thu, Sep 19, 2019 at 10:49 AM Jani Nikula <jani.nikula@intel.com> wrote:
>> On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> >> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
>> >> When I sent a patch, I use get_maintainer.pl then I add whoever the
>> >> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
>> >> Cook from the CC list because they worked all over the tree and I know
>> >> them. I also normally remove LKML if there is another mailing list but
>> >> at least one subsystem uses LKML for patchwork so this isn't safe.
>> >>
>> >> So the safest instructions are "Use get_matainer.pl and add the person
>> >> who wrote the commit in the Fixes tag".
>> >
>> > Better: perhaps get_maintainer.pl can be taught to add the author of the
>> > commit pointed to by the Fixes tag, if present?
>>
>> The drm maintainer tools [1] have that, with Cc's and reviewers picked
>> up, and appropriate Cc: stable added. On a random commit from v5.3:
>
> Thanks, but that's not scripts/get_maintainer.pl, and restricted to one out
> of N subsystems. Not so dissimilar from what Dan was complaining about.
The point was, perhaps poorly conveyed, to provide it as a reference,
and something to steal from. You can think of it as a wrapper around
get_maintainer.pl, it's really not subsystem specific, though part of
our scripts, and it'll take you all of five minutes to make it generic
from the source (MIT):
function dim_cite
{
local sha1
sha1=${1:?$usage}
git --git-dir="$DIM_PREFIX/$DIM_REPO/.git" log -1 $sha1 \
"--pretty=format:%H (\"%s\")%n" | \
sed -e 's/\([0-f]\{12\}\)[0-f]*/\1/'
}
function dim_fixes
{
local sha1 tag
sha1=${1:?$usage}
cd $DIM_PREFIX/$DIM_REPO
echo "Fixes: $(dim_cite $sha1)"
(
git show --no-patch $sha1 | \
sed -e 's/\(Reviewed\|Acked\|Reported\|Signed\)[a-zA-Z-]*-by:/Cc:/' | \
sed -e 's/^ C[Cc]: */Cc: /' | grep '^Cc: '
git show $sha1 | scripts/get_maintainer.pl --email --norolestats --pattern-depth 1 | sed -e "s/^/Cc: /"
) | awk '!x[$0]++'
tag=$(git tag --contains $sha1 | grep ^v | sort -V | head -n 1)
if [[ -n "$tag" ]]; then
if ! echo "$tag" | grep -q -e "-rc"; then
echo "Cc: <stable@vger.kernel.org> # ${tag}+"
fi
fi
}
HTH,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-19 9:52 ` Jani Nikula
0 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-19 9:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit, Linux Media Mailing List
On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Jani,
>
> On Thu, Sep 19, 2019 at 10:49 AM Jani Nikula <jani.nikula@intel.com> wrote:
>> On Thu, 19 Sep 2019, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> >> On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
>> >> When I sent a patch, I use get_maintainer.pl then I add whoever the
>> >> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
>> >> Cook from the CC list because they worked all over the tree and I know
>> >> them. I also normally remove LKML if there is another mailing list but
>> >> at least one subsystem uses LKML for patchwork so this isn't safe.
>> >>
>> >> So the safest instructions are "Use get_matainer.pl and add the person
>> >> who wrote the commit in the Fixes tag".
>> >
>> > Better: perhaps get_maintainer.pl can be taught to add the author of the
>> > commit pointed to by the Fixes tag, if present?
>>
>> The drm maintainer tools [1] have that, with Cc's and reviewers picked
>> up, and appropriate Cc: stable added. On a random commit from v5.3:
>
> Thanks, but that's not scripts/get_maintainer.pl, and restricted to one out
> of N subsystems. Not so dissimilar from what Dan was complaining about.
The point was, perhaps poorly conveyed, to provide it as a reference,
and something to steal from. You can think of it as a wrapper around
get_maintainer.pl, it's really not subsystem specific, though part of
our scripts, and it'll take you all of five minutes to make it generic
from the source (MIT):
function dim_cite
{
local sha1
sha1=${1:?$usage}
git --git-dir="$DIM_PREFIX/$DIM_REPO/.git" log -1 $sha1 \
"--pretty=format:%H (\"%s\")%n" | \
sed -e 's/\([0-f]\{12\}\)[0-f]*/\1/'
}
function dim_fixes
{
local sha1 tag
sha1=${1:?$usage}
cd $DIM_PREFIX/$DIM_REPO
echo "Fixes: $(dim_cite $sha1)"
(
git show --no-patch $sha1 | \
sed -e 's/\(Reviewed\|Acked\|Reported\|Signed\)[a-zA-Z-]*-by:/Cc:/' | \
sed -e 's/^ C[Cc]: */Cc: /' | grep '^Cc: '
git show $sha1 | scripts/get_maintainer.pl --email --norolestats --pattern-depth 1 | sed -e "s/^/Cc: /"
) | awk '!x[$0]++'
tag=$(git tag --contains $sha1 | grep ^v | sort -V | head -n 1)
if [[ -n "$tag" ]]; then
if ! echo "$tag" | grep -q -e "-rc"; then
echo "Cc: <stable@vger.kernel.org> # ${tag}+"
fi
fi
}
HTH,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-19 7:08 ` Dan Carpenter
@ 2019-09-20 5:29 ` Joe Perches
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-20 5:29 UTC (permalink / raw)
To: Dan Carpenter, Mauro Carvalho Chehab
Cc: ksummit-discuss, Linux Media Mailing List
On Thu, 2019-09-19 at 10:08 +0300, Dan Carpenter wrote:
> On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 18 Sep 2019 20:27:05 +0300
> > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> >
> > > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > > patchwork for media patches. What about changing this to:
> > > >
> > > > Patches for the media subsystem should be sent to the media mailing list
> > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > HTML will be automatically rejected by the mail server. It could be wise
> > > > to also copy the sub-maintainer(s).
> > >
> > > That works for me. As this is really a personal preference, is there a
> > > way it could be encoded in MAINTAINERS in a per-person fashion ?
> > > Something that would allow you to opt-out from CC from linux-media (but
> > > possibly opt-in for other parts of the kernel), and allow me to opt-in
> > > for the drivers I maintain ?
> >
> > I don't think so. Perhaps we could add, instead, something like that at the
> > sub-maintainers section of the profile.
>
> Of course there is a way to add yourself as a maintainer for a specific
> .c file... Maybe people feel like MAINTAINERS is too crowded?
>
> We could update get_maintainer.pl to grep the .c files for a specific
> tag instead of putting everything in a centralized MAINTAINERS file.
Another option is to split the MAINTAINERS file into multiple
distributed files. get_maintainer.pl already supports that.
https://lwn.net/Articles/730509/
https://lore.kernel.org/lkml/1501350403.5368.65.camel@perches.com/
> But it doesn't make sense to try store that information MY BRAIN! I
> can't remember anything from one minute to the next so I have no idea
> who maintains media submodules...
Nor I. Nor should I have to.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-20 5:29 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-20 5:29 UTC (permalink / raw)
To: Dan Carpenter, Mauro Carvalho Chehab
Cc: ksummit-discuss, Linux Media Mailing List
On Thu, 2019-09-19 at 10:08 +0300, Dan Carpenter wrote:
> On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 18 Sep 2019 20:27:05 +0300
> > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> >
> > > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > > patchwork for media patches. What about changing this to:
> > > >
> > > > Patches for the media subsystem should be sent to the media mailing list
> > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > HTML will be automatically rejected by the mail server. It could be wise
> > > > to also copy the sub-maintainer(s).
> > >
> > > That works for me. As this is really a personal preference, is there a
> > > way it could be encoded in MAINTAINERS in a per-person fashion ?
> > > Something that would allow you to opt-out from CC from linux-media (but
> > > possibly opt-in for other parts of the kernel), and allow me to opt-in
> > > for the drivers I maintain ?
> >
> > I don't think so. Perhaps we could add, instead, something like that at the
> > sub-maintainers section of the profile.
>
> Of course there is a way to add yourself as a maintainer for a specific
> .c file... Maybe people feel like MAINTAINERS is too crowded?
>
> We could update get_maintainer.pl to grep the .c files for a specific
> tag instead of putting everything in a centralized MAINTAINERS file.
Another option is to split the MAINTAINERS file into multiple
distributed files. get_maintainer.pl already supports that.
https://lwn.net/Articles/730509/
https://lore.kernel.org/lkml/1501350403.5368.65.camel@perches.com/
> But it doesn't make sense to try store that information MY BRAIN! I
> can't remember anything from one minute to the next so I have no idea
> who maintains media submodules...
Nor I. Nor should I have to.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-20 5:29 ` Joe Perches
@ 2019-09-20 14:09 ` Daniel Vetter
-1 siblings, 0 replies; 227+ messages in thread
From: Daniel Vetter @ 2019-09-20 14:09 UTC (permalink / raw)
To: Joe Perches
Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List
On Fri, Sep 20, 2019 at 1:27 PM Joe Perches <joe@perches.com> wrote:
>
> On Thu, 2019-09-19 at 10:08 +0300, Dan Carpenter wrote:
> > On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Wed, 18 Sep 2019 20:27:05 +0300
> > > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > >
> > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > > > patchwork for media patches. What about changing this to:
> > > > >
> > > > > Patches for the media subsystem should be sent to the media mailing list
> > > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > > HTML will be automatically rejected by the mail server. It could be wise
> > > > > to also copy the sub-maintainer(s).
> > > >
> > > > That works for me. As this is really a personal preference, is there a
> > > > way it could be encoded in MAINTAINERS in a per-person fashion ?
> > > > Something that would allow you to opt-out from CC from linux-media (but
> > > > possibly opt-in for other parts of the kernel), and allow me to opt-in
> > > > for the drivers I maintain ?
> > >
> > > I don't think so. Perhaps we could add, instead, something like that at the
> > > sub-maintainers section of the profile.
> >
> > Of course there is a way to add yourself as a maintainer for a specific
> > .c file... Maybe people feel like MAINTAINERS is too crowded?
> >
> > We could update get_maintainer.pl to grep the .c files for a specific
> > tag instead of putting everything in a centralized MAINTAINERS file.
>
> Another option is to split the MAINTAINERS file into multiple
> distributed files. get_maintainer.pl already supports that.
>
> https://lwn.net/Articles/730509/
> https://lore.kernel.org/lkml/1501350403.5368.65.camel@perches.com/
Oh I missed that entirely. Can we roll this out now in subsystems? I'd
really like to move all the gpu related MAINTAINERS entries into
drivers/gpu. The one file in the root is unmangeable big and git blame
takes forever. Ofc splitting it isn't an immediate fix, but long term
should be easier. I thought Linus planned to just do that split (at
least the first level or so) after an -rc1?
-Daniel
> > But it doesn't make sense to try store that information MY BRAIN! I
> > can't remember anything from one minute to the next so I have no idea
> > who maintains media submodules...
>
> Nor I. Nor should I have to.
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-20 14:09 ` Daniel Vetter
0 siblings, 0 replies; 227+ messages in thread
From: Daniel Vetter @ 2019-09-20 14:09 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit, Linux Media Mailing List
On Fri, Sep 20, 2019 at 1:27 PM Joe Perches <joe@perches.com> wrote:
>
> On Thu, 2019-09-19 at 10:08 +0300, Dan Carpenter wrote:
> > On Wed, Sep 18, 2019 at 03:48:31PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Wed, 18 Sep 2019 20:27:05 +0300
> > > Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> > >
> > > > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > > > patchwork for media patches. What about changing this to:
> > > > >
> > > > > Patches for the media subsystem should be sent to the media mailing list
> > > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > > HTML will be automatically rejected by the mail server. It could be wise
> > > > > to also copy the sub-maintainer(s).
> > > >
> > > > That works for me. As this is really a personal preference, is there a
> > > > way it could be encoded in MAINTAINERS in a per-person fashion ?
> > > > Something that would allow you to opt-out from CC from linux-media (but
> > > > possibly opt-in for other parts of the kernel), and allow me to opt-in
> > > > for the drivers I maintain ?
> > >
> > > I don't think so. Perhaps we could add, instead, something like that at the
> > > sub-maintainers section of the profile.
> >
> > Of course there is a way to add yourself as a maintainer for a specific
> > .c file... Maybe people feel like MAINTAINERS is too crowded?
> >
> > We could update get_maintainer.pl to grep the .c files for a specific
> > tag instead of putting everything in a centralized MAINTAINERS file.
>
> Another option is to split the MAINTAINERS file into multiple
> distributed files. get_maintainer.pl already supports that.
>
> https://lwn.net/Articles/730509/
> https://lore.kernel.org/lkml/1501350403.5368.65.camel@perches.com/
Oh I missed that entirely. Can we roll this out now in subsystems? I'd
really like to move all the gpu related MAINTAINERS entries into
drivers/gpu. The one file in the root is unmangeable big and git blame
takes forever. Ofc splitting it isn't an immediate fix, but long term
should be easier. I thought Linus planned to just do that split (at
least the first level or so) after an -rc1?
-Daniel
> > But it doesn't make sense to try store that information MY BRAIN! I
> > can't remember anything from one minute to the next so I have no idea
> > who maintains media submodules...
>
> Nor I. Nor should I have to.
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-19 7:22 ` Geert Uytterhoeven
@ 2019-09-20 14:53 ` Laurent Pinchart
-1 siblings, 0 replies; 227+ messages in thread
From: Laurent Pinchart @ 2019-09-20 14:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List
On Thu, Sep 19, 2019 at 09:22:45AM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > > +to copy the maintainer or sub-maintainer(s).
> > > >
> > > > There's too much traffic on mailing lists for me to follow everything, I
> > > > much prefer being CC'ed on patches.
> > >
> > > Well, by using patchwork, the best is to take a look on it at least for
> > > the patches that you're interested. You could script something using
> > > pwclient in order to make it easier.
> > >
> > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > patchwork for media patches. What about changing this to:
> > >
> > > Patches for the media subsystem should be sent to the media mailing list
> > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > HTML will be automatically rejected by the mail server. It could be wise
> > > to also copy the sub-maintainer(s).
> >
> > The documentation should say "Use get_maintainer.pl" and do what it
> > says. Everything else is too complicated.
>
> +1
>
> > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > Cook from the CC list because they worked all over the tree and I know
> > them. I also normally remove LKML if there is another mailing list but
> > at least one subsystem uses LKML for patchwork so this isn't safe.
> >
> > So the safest instructions are "Use get_matainer.pl and add the person
> > who wrote the commit in the Fixes tag".
>
> Better: perhaps get_maintainer.pl can be taught to add the author of the
> commit pointed to by the Fixes tag, if present?
And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up
get_maintainer.pl a bit is a good idea. I'm for instance not sure adding
LKML automatically is a good idea if other mailing lists are already
CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it
when no other mailing list is appropriate certainly makes sense).
--
Regards,
Laurent Pinchart
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-20 14:53 ` Laurent Pinchart
0 siblings, 0 replies; 227+ messages in thread
From: Laurent Pinchart @ 2019-09-20 14:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit, Linux Media Mailing List
On Thu, Sep 19, 2019 at 09:22:45AM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > > +to copy the maintainer or sub-maintainer(s).
> > > >
> > > > There's too much traffic on mailing lists for me to follow everything, I
> > > > much prefer being CC'ed on patches.
> > >
> > > Well, by using patchwork, the best is to take a look on it at least for
> > > the patches that you're interested. You could script something using
> > > pwclient in order to make it easier.
> > >
> > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > patchwork for media patches. What about changing this to:
> > >
> > > Patches for the media subsystem should be sent to the media mailing list
> > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > HTML will be automatically rejected by the mail server. It could be wise
> > > to also copy the sub-maintainer(s).
> >
> > The documentation should say "Use get_maintainer.pl" and do what it
> > says. Everything else is too complicated.
>
> +1
>
> > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > Cook from the CC list because they worked all over the tree and I know
> > them. I also normally remove LKML if there is another mailing list but
> > at least one subsystem uses LKML for patchwork so this isn't safe.
> >
> > So the safest instructions are "Use get_matainer.pl and add the person
> > who wrote the commit in the Fixes tag".
>
> Better: perhaps get_maintainer.pl can be taught to add the author of the
> commit pointed to by the Fixes tag, if present?
And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up
get_maintainer.pl a bit is a good idea. I'm for instance not sure adding
LKML automatically is a good idea if other mailing lists are already
CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it
when no other mailing list is appropriate certainly makes sense).
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-20 14:53 ` Laurent Pinchart
@ 2019-09-20 14:59 ` Doug Anderson
-1 siblings, 0 replies; 227+ messages in thread
From: Doug Anderson @ 2019-09-20 14:59 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Dan Carpenter, ksummit, Linux Media Mailing List
Hi,
On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Thu, Sep 19, 2019 at 09:22:45AM +0200, Geert Uytterhoeven wrote:
> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > > > +to copy the maintainer or sub-maintainer(s).
> > > > >
> > > > > There's too much traffic on mailing lists for me to follow everything, I
> > > > > much prefer being CC'ed on patches.
> > > >
> > > > Well, by using patchwork, the best is to take a look on it at least for
> > > > the patches that you're interested. You could script something using
> > > > pwclient in order to make it easier.
> > > >
> > > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > > patchwork for media patches. What about changing this to:
> > > >
> > > > Patches for the media subsystem should be sent to the media mailing list
> > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > HTML will be automatically rejected by the mail server. It could be wise
> > > > to also copy the sub-maintainer(s).
> > >
> > > The documentation should say "Use get_maintainer.pl" and do what it
> > > says. Everything else is too complicated.
> >
> > +1
> >
> > > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > > Cook from the CC list because they worked all over the tree and I know
> > > them. I also normally remove LKML if there is another mailing list but
> > > at least one subsystem uses LKML for patchwork so this isn't safe.
> > >
> > > So the safest instructions are "Use get_matainer.pl and add the person
> > > who wrote the commit in the Fixes tag".
> >
> > Better: perhaps get_maintainer.pl can be taught to add the author of the
> > commit pointed to by the Fixes tag, if present?
>
> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up
> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding
> LKML automatically is a good idea if other mailing lists are already
> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it
> when no other mailing list is appropriate certainly makes sense).
Please don't do this, as it means the patch won't be findable on the
"LKML" patchwork instance at:
https://lore.kernel.org/patchwork/project/lkml/list/
Having LKML copied on all patches is also nice because it makes it
easier to respond to a patch that was posted to a list you didn't
subscribe to. I subscribe to LKML and have it redirected to a folder
that I never look at. Then if I want to find an email thread I can
search that folder and easily respond from within my normal email
client.
Is there any downside to CCing LKML?
-Doug
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-20 14:59 ` Doug Anderson
0 siblings, 0 replies; 227+ messages in thread
From: Doug Anderson @ 2019-09-20 14:59 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Geert Uytterhoeven, Mauro Carvalho Chehab, ksummit,
Dan Carpenter, Linux Media Mailing List
Hi,
On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Thu, Sep 19, 2019 at 09:22:45AM +0200, Geert Uytterhoeven wrote:
> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > > On Wed, Sep 18, 2019 at 10:57:28AM -0300, Mauro Carvalho Chehab wrote:
> > > > > > +Patches for the media subsystem should be sent to the media mailing list
> > > > > > +at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > > > +HTML will be automatically rejected by the mail server. There's no need
> > > > > > +to copy the maintainer or sub-maintainer(s).
> > > > >
> > > > > There's too much traffic on mailing lists for me to follow everything, I
> > > > > much prefer being CC'ed on patches.
> > > >
> > > > Well, by using patchwork, the best is to take a look on it at least for
> > > > the patches that you're interested. You could script something using
> > > > pwclient in order to make it easier.
> > > >
> > > > Anyway, not sure if the other sub-maintainers see the same way. From my side,
> > > > I prefer not to be c/c, as this is just more noise, as I just rely on
> > > > patchwork for media patches. What about changing this to:
> > > >
> > > > Patches for the media subsystem should be sent to the media mailing list
> > > > at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> > > > HTML will be automatically rejected by the mail server. It could be wise
> > > > to also copy the sub-maintainer(s).
> > >
> > > The documentation should say "Use get_maintainer.pl" and do what it
> > > says. Everything else is too complicated.
> >
> > +1
> >
> > > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > > Cook from the CC list because they worked all over the tree and I know
> > > them. I also normally remove LKML if there is another mailing list but
> > > at least one subsystem uses LKML for patchwork so this isn't safe.
> > >
> > > So the safest instructions are "Use get_matainer.pl and add the person
> > > who wrote the commit in the Fixes tag".
> >
> > Better: perhaps get_maintainer.pl can be taught to add the author of the
> > commit pointed to by the Fixes tag, if present?
>
> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up
> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding
> LKML automatically is a good idea if other mailing lists are already
> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it
> when no other mailing list is appropriate certainly makes sense).
Please don't do this, as it means the patch won't be findable on the
"LKML" patchwork instance at:
https://lore.kernel.org/patchwork/project/lkml/list/
Having LKML copied on all patches is also nice because it makes it
easier to respond to a patch that was posted to a list you didn't
subscribe to. I subscribe to LKML and have it redirected to a folder
that I never look at. Then if I want to find an email thread I can
search that folder and easily respond from within my normal email
client.
Is there any downside to CCing LKML?
-Doug
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-20 14:59 ` Doug Anderson
@ 2019-09-21 8:56 ` Jani Nikula
-1 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-21 8:56 UTC (permalink / raw)
To: Doug Anderson, Laurent Pinchart
Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List
On Fri, 20 Sep 2019, Doug Anderson <dianders@chromium.org> wrote:
> On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up
>> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding
>> LKML automatically is a good idea if other mailing lists are already
>> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it
>> when no other mailing list is appropriate certainly makes sense).
>
> Please don't do this, as it means the patch won't be findable on the
> "LKML" patchwork instance at:
>
> https://lore.kernel.org/patchwork/project/lkml/list/
>
> Having LKML copied on all patches is also nice because it makes it
> easier to respond to a patch that was posted to a list you didn't
> subscribe to. I subscribe to LKML and have it redirected to a folder
> that I never look at. Then if I want to find an email thread I can
> search that folder and easily respond from within my normal email
> client.
>
> Is there any downside to CCing LKML?
I think the question becomes, do we want *everything* posted to LKML?
For example, based on the last 30 days, the kernel the monthly addition
to LKML traffic from my corner of the kernel would be in this ballpark:
$ notmuch count date:30d.. to:intel-gfx@lists.freedesktop.org or to:dri-devel@lists.freedesktop.org and not to linux-kernel@vger.kernel.org and subject:PATCH
96904
OTOH LKML is already a firehose that's impossible to drink from, so not
much difference there...
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-21 8:56 ` Jani Nikula
0 siblings, 0 replies; 227+ messages in thread
From: Jani Nikula @ 2019-09-21 8:56 UTC (permalink / raw)
To: Doug Anderson, Laurent Pinchart
Cc: Mauro Carvalho Chehab, Dan Carpenter, ksummit, Linux Media Mailing List
On Fri, 20 Sep 2019, Doug Anderson <dianders@chromium.org> wrote:
> On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up
>> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding
>> LKML automatically is a good idea if other mailing lists are already
>> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it
>> when no other mailing list is appropriate certainly makes sense).
>
> Please don't do this, as it means the patch won't be findable on the
> "LKML" patchwork instance at:
>
> https://lore.kernel.org/patchwork/project/lkml/list/
>
> Having LKML copied on all patches is also nice because it makes it
> easier to respond to a patch that was posted to a list you didn't
> subscribe to. I subscribe to LKML and have it redirected to a folder
> that I never look at. Then if I want to find an email thread I can
> search that folder and easily respond from within my normal email
> client.
>
> Is there any downside to CCing LKML?
I think the question becomes, do we want *everything* posted to LKML?
For example, based on the last 30 days, the kernel the monthly addition
to LKML traffic from my corner of the kernel would be in this ballpark:
$ notmuch count date:30d.. to:intel-gfx@lists.freedesktop.org or to:dri-devel@lists.freedesktop.org and not to linux-kernel@vger.kernel.org and subject:PATCH
96904
OTOH LKML is already a firehose that's impossible to drink from, so not
much difference there...
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-18 11:23 ` Mauro Carvalho Chehab
@ 2019-09-21 19:13 ` Jonathan Corbet
-1 siblings, 0 replies; 227+ messages in thread
From: Jonathan Corbet @ 2019-09-21 19:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: ksummit-discuss, Linux Media Mailing List
On Wed, 18 Sep 2019 08:23:26 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> A simple/lazy solution would be to apply the enclosed patch - or a
> variant of it that would place the contents of MAINTAINERS outside
> process/index.html, and add instructions about how to use
> get_maintainers.pl.
>
> Jon,
>
> Please let me know if you're willing to accept something like that.
[Sorry for the slowness, I'm kind of tuned out this week]
I guess we could do that as a short-term thing.
In truth, though, this thing is a database; printing it out linearly is
perhaps not the best thing we could do. There should be better ways we
could provide access to it.
Also, that file is nearly 18K lines long. If some unsuspecting person
generates a PDF and prints it, they're going to get something along the
lines of 300 pages of MAINTAINERS, which may not quite be what they had
in mind. It costs (almost) nothing to put that into HTML output, but
other formats could be painful.
So I dunno, we need to think this through a bit...
jon
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
@ 2019-09-21 19:13 ` Jonathan Corbet
0 siblings, 0 replies; 227+ messages in thread
From: Jonathan Corbet @ 2019-09-21 19:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Kees Cook, ksummit-discuss, Linux Media Mailing List
On Wed, 18 Sep 2019 08:23:26 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> A simple/lazy solution would be to apply the enclosed patch - or a
> variant of it that would place the contents of MAINTAINERS outside
> process/index.html, and add instructions about how to use
> get_maintainers.pl.
>
> Jon,
>
> Please let me know if you're willing to accept something like that.
[Sorry for the slowness, I'm kind of tuned out this week]
I guess we could do that as a short-term thing.
In truth, though, this thing is a database; printing it out linearly is
perhaps not the best thing we could do. There should be better ways we
could provide access to it.
Also, that file is nearly 18K lines long. If some unsuspecting person
generates a PDF and prints it, they're going to get something along the
lines of 300 pages of MAINTAINERS, which may not quite be what they had
in mind. It costs (almost) nothing to put that into HTML output, but
other formats could be painful.
So I dunno, we need to think this through a bit...
jon
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-21 19:13 ` Jonathan Corbet
@ 2019-09-21 19:45 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-21 19:45 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: ksummit-discuss, Linux Media Mailing List
Em Sat, 21 Sep 2019 13:13:07 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 18 Sep 2019 08:23:26 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > A simple/lazy solution would be to apply the enclosed patch - or a
> > variant of it that would place the contents of MAINTAINERS outside
> > process/index.html, and add instructions about how to use
> > get_maintainers.pl.
> >
> > Jon,
> >
> > Please let me know if you're willing to accept something like that.
>
> [Sorry for the slowness, I'm kind of tuned out this week]
>
> I guess we could do that as a short-term thing.
>
> In truth, though, this thing is a database; printing it out linearly is
> perhaps not the best thing we could do. There should be better ways we
> could provide access to it.
Yeah, as this is a database, instead of just outputting it on a
formatted way, it is possible to generate other types of output.
We could, for example, have an extension with would implement something like:
.. maintainers:: <subdir>
Which would call get-maintainers in order to parse a subsystem-specific
set of entries and printing the maintainership details.
This could be added at the subsystem-specific profile, for the subsystems
that have it.
>
> Also, that file is nearly 18K lines long. If some unsuspecting person
> generates a PDF and prints it, they're going to get something along the
> lines of 300 pages of MAINTAINERS, which may not quite be what they had
> in mind. It costs (almost) nothing to put that into HTML output, but
> other formats could be painful.
Even if we go for adding a Sphinx tag that would produce a parsed
output for a system-specific profile, we'll still have several other
subsystems that won't have a profile for a while, so I would still
consider having somewhere an output with its contents. Yeah, someone
might be tempted to print it, but we could place it on a separate PDF,
in order to minimize the risks of someone printing the 300+ pages.
>
> So I dunno, we need to think this through a bit...
>
> jon
Thanks,
Mauro
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
@ 2019-09-21 19:45 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 227+ messages in thread
From: Mauro Carvalho Chehab @ 2019-09-21 19:45 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Kees Cook, ksummit-discuss, Linux Media Mailing List
Em Sat, 21 Sep 2019 13:13:07 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 18 Sep 2019 08:23:26 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > A simple/lazy solution would be to apply the enclosed patch - or a
> > variant of it that would place the contents of MAINTAINERS outside
> > process/index.html, and add instructions about how to use
> > get_maintainers.pl.
> >
> > Jon,
> >
> > Please let me know if you're willing to accept something like that.
>
> [Sorry for the slowness, I'm kind of tuned out this week]
>
> I guess we could do that as a short-term thing.
>
> In truth, though, this thing is a database; printing it out linearly is
> perhaps not the best thing we could do. There should be better ways we
> could provide access to it.
Yeah, as this is a database, instead of just outputting it on a
formatted way, it is possible to generate other types of output.
We could, for example, have an extension with would implement something like:
.. maintainers:: <subdir>
Which would call get-maintainers in order to parse a subsystem-specific
set of entries and printing the maintainership details.
This could be added at the subsystem-specific profile, for the subsystems
that have it.
>
> Also, that file is nearly 18K lines long. If some unsuspecting person
> generates a PDF and prints it, they're going to get something along the
> lines of 300 pages of MAINTAINERS, which may not quite be what they had
> in mind. It costs (almost) nothing to put that into HTML output, but
> other formats could be painful.
Even if we go for adding a Sphinx tag that would produce a parsed
output for a system-specific profile, we'll still have several other
subsystems that won't have a profile for a while, so I would still
consider having somewhere an output with its contents. Yeah, someone
might be tempted to print it, but we could place it on a separate PDF,
in order to minimize the risks of someone printing the 300+ pages.
>
> So I dunno, we need to think this through a bit...
>
> jon
Thanks,
Mauro
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-21 8:56 ` Jani Nikula
@ 2019-09-23 15:58 ` Doug Anderson
-1 siblings, 0 replies; 227+ messages in thread
From: Doug Anderson @ 2019-09-23 15:58 UTC (permalink / raw)
To: Jani Nikula
Cc: ksummit, Mauro Carvalho Chehab, Dan Carpenter, Linux Media Mailing List
Hi,
On Sat, Sep 21, 2019 at 1:56 AM Jani Nikula <jani.nikula@intel.com> wrote:
>
> On Fri, 20 Sep 2019, Doug Anderson <dianders@chromium.org> wrote:
> > On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> >> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up
> >> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding
> >> LKML automatically is a good idea if other mailing lists are already
> >> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it
> >> when no other mailing list is appropriate certainly makes sense).
> >
> > Please don't do this, as it means the patch won't be findable on the
> > "LKML" patchwork instance at:
> >
> > https://lore.kernel.org/patchwork/project/lkml/list/
> >
> > Having LKML copied on all patches is also nice because it makes it
> > easier to respond to a patch that was posted to a list you didn't
> > subscribe to. I subscribe to LKML and have it redirected to a folder
> > that I never look at. Then if I want to find an email thread I can
> > search that folder and easily respond from within my normal email
> > client.
> >
> > Is there any downside to CCing LKML?
>
> I think the question becomes, do we want *everything* posted to LKML?
I swear that I was involved in a conversation in the past where
someone suggested to stop CCing LKML on patches and Jonathan Corbet
jumped in and said that he supported CCing LKML on all patches. I
searched for that conversation and couldn't find it, so it's possible
I dreamed it. Maybe he can confirm?
> For example, based on the last 30 days, the kernel the monthly addition
> to LKML traffic from my corner of the kernel would be in this ballpark:
>
> $ notmuch count date:30d.. to:intel-gfx@lists.freedesktop.org or to:dri-devel@lists.freedesktop.org and not to linux-kernel@vger.kernel.org and subject:PATCH
> 96904
>
> OTOH LKML is already a firehose that's impossible to drink from, so not
> much difference there...
Right. At this point I think LKML is just useful as a dumping ground
and not a place to look for patches or conversations without filters.
It feels fine to keep using it that way. Having another list (like
ksummit-discuss) for conversations with a higher signal-to-noise ratio
seems like a fine way forward to me.
-Doug
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-23 15:58 ` Doug Anderson
0 siblings, 0 replies; 227+ messages in thread
From: Doug Anderson @ 2019-09-23 15:58 UTC (permalink / raw)
To: Jani Nikula
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Dan Carpenter, ksummit,
Linux Media Mailing List, Jonathan Corbet
Hi,
On Sat, Sep 21, 2019 at 1:56 AM Jani Nikula <jani.nikula@intel.com> wrote:
>
> On Fri, 20 Sep 2019, Doug Anderson <dianders@chromium.org> wrote:
> > On Fri, Sep 20, 2019 at 7:54 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> >> And remove Kees Cook and Colin King ? :-) Jokes aside, brushing up
> >> get_maintainer.pl a bit is a good idea. I'm for instance not sure adding
> >> LKML automatically is a good idea if other mailing lists are already
> >> CC'ed, as it's a bit of a /dev/null (albeit with logging, so CC'ing it
> >> when no other mailing list is appropriate certainly makes sense).
> >
> > Please don't do this, as it means the patch won't be findable on the
> > "LKML" patchwork instance at:
> >
> > https://lore.kernel.org/patchwork/project/lkml/list/
> >
> > Having LKML copied on all patches is also nice because it makes it
> > easier to respond to a patch that was posted to a list you didn't
> > subscribe to. I subscribe to LKML and have it redirected to a folder
> > that I never look at. Then if I want to find an email thread I can
> > search that folder and easily respond from within my normal email
> > client.
> >
> > Is there any downside to CCing LKML?
>
> I think the question becomes, do we want *everything* posted to LKML?
I swear that I was involved in a conversation in the past where
someone suggested to stop CCing LKML on patches and Jonathan Corbet
jumped in and said that he supported CCing LKML on all patches. I
searched for that conversation and couldn't find it, so it's possible
I dreamed it. Maybe he can confirm?
> For example, based on the last 30 days, the kernel the monthly addition
> to LKML traffic from my corner of the kernel would be in this ballpark:
>
> $ notmuch count date:30d.. to:intel-gfx@lists.freedesktop.org or to:dri-devel@lists.freedesktop.org and not to linux-kernel@vger.kernel.org and subject:PATCH
> 96904
>
> OTOH LKML is already a firehose that's impossible to drink from, so not
> much difference there...
Right. At this point I think LKML is just useful as a dumping ground
and not a place to look for patches or conversations without filters.
It feels fine to keep using it that way. Having another list (like
ksummit-discuss) for conversations with a higher signal-to-noise ratio
seems like a fine way forward to me.
-Doug
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-23 15:58 ` Doug Anderson
@ 2019-09-23 16:04 ` Jonathan Corbet
-1 siblings, 0 replies; 227+ messages in thread
From: Jonathan Corbet @ 2019-09-23 16:04 UTC (permalink / raw)
To: Doug Anderson
Cc: ksummit, Mauro Carvalho Chehab, Dan Carpenter, Linux Media Mailing List
On Mon, 23 Sep 2019 08:58:28 -0700
Doug Anderson <dianders@chromium.org> wrote:
> I swear that I was involved in a conversation in the past where
> someone suggested to stop CCing LKML on patches and Jonathan Corbet
> jumped in and said that he supported CCing LKML on all patches.
I don't *think* I said that, I have no particular reason to argue for
doing that...? There are people out there who feel that absolutely
everything needs to be on LKML, but I don't really have a strong opinion
on that matter.
jon
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-23 16:04 ` Jonathan Corbet
0 siblings, 0 replies; 227+ messages in thread
From: Jonathan Corbet @ 2019-09-23 16:04 UTC (permalink / raw)
To: Doug Anderson
Cc: Jani Nikula, Laurent Pinchart, Mauro Carvalho Chehab,
Dan Carpenter, ksummit, Linux Media Mailing List
On Mon, 23 Sep 2019 08:58:28 -0700
Doug Anderson <dianders@chromium.org> wrote:
> I swear that I was involved in a conversation in the past where
> someone suggested to stop CCing LKML on patches and Jonathan Corbet
> jumped in and said that he supported CCing LKML on all patches.
I don't *think* I said that, I have no particular reason to argue for
doing that...? There are people out there who feel that absolutely
everything needs to be on LKML, but I don't really have a strong opinion
on that matter.
jon
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
2019-09-21 19:13 ` Jonathan Corbet
@ 2019-09-23 22:45 ` Kees Cook
-1 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-23 22:45 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, ksummit-discuss, Linux Media Mailing List
On Sat, Sep 21, 2019 at 01:13:07PM -0600, Jonathan Corbet wrote:
> Also, that file is nearly 18K lines long. If some unsuspecting person
> generates a PDF and prints it, they're going to get something along the
> lines of 300 pages of MAINTAINERS, which may not quite be what they had
> in mind. It costs (almost) nothing to put that into HTML output, but
> other formats could be painful.
Is this something that can be specifically excluded from the non-HTML
outputs? (Or rather, specifically included in only the HTML output?) I
don't see a way to do that exactly... maybe in my RFC only the html
target would get the "real" file?
--
Kees Cook
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation)
@ 2019-09-23 22:45 ` Kees Cook
0 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-23 22:45 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, ksummit-discuss, Linux Media Mailing List
On Sat, Sep 21, 2019 at 01:13:07PM -0600, Jonathan Corbet wrote:
> Also, that file is nearly 18K lines long. If some unsuspecting person
> generates a PDF and prints it, they're going to get something along the
> lines of 300 pages of MAINTAINERS, which may not quite be what they had
> in mind. It costs (almost) nothing to put that into HTML output, but
> other formats could be painful.
Is this something that can be specifically excluded from the non-HTML
outputs? (Or rather, specifically included in only the HTML output?) I
don't see a way to do that exactly... maybe in my RFC only the html
target would get the "real" file?
--
Kees Cook
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-19 6:56 ` Dan Carpenter
@ 2019-09-25 17:13 ` Joe Perches
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-25 17:13 UTC (permalink / raw)
To: Dan Carpenter, Mauro Carvalho Chehab
Cc: ksummit-discuss, Linux Media Mailing List
On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote:
> When I sent a patch, I use get_maintainer.pl then I add whoever the
> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> Cook from the CC list because they worked all over the tree and I know
> them. I also normally remove LKML if there is another mailing list but
> at least one subsystem uses LKML for patchwork so this isn't safe.
>
> So the safest instructions are "Use get_matainer.pl and add the person
> who wrote the commit in the Fixes tag".
Maybe add this:
Add the signers of any commit referenced in a "Fixes: <commit>" line
of a patch description.
---
scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 5ef59214c555..34085d146fa2 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -26,6 +26,7 @@ my $email = 1;
my $email_usename = 1;
my $email_maintainer = 1;
my $email_reviewer = 1;
+my $email_fixes = 1;
my $email_list = 1;
my $email_moderated_list = 1;
my $email_subscriber_list = 0;
@@ -249,6 +250,7 @@ if (!GetOptions(
'r!' => \$email_reviewer,
'n!' => \$email_usename,
'l!' => \$email_list,
+ 'fixes!' => \$email_fixes,
'moderated!' => \$email_moderated_list,
's!' => \$email_subscriber_list,
'multiline!' => \$output_multiline,
@@ -503,6 +505,7 @@ sub read_mailmap {
## use the filenames on the command line or find the filenames in the patchfiles
my @files = ();
+my @fixes = (); # If a patch description includes Fixes: lines
my @range = ();
my @keyword_tvi = ();
my @file_emails = ();
@@ -568,6 +571,8 @@ foreach my $file (@ARGV) {
my $filename2 = $2;
push(@files, $filename1);
push(@files, $filename2);
+ } elsif (m/^Fixes:\s+([0-9a-fA-F]{6,40})/) {
+ push(@fixes, $1) if ($email_fixes);
} elsif (m/^\+\+\+\s+(\S+)/ or m/^---\s+(\S+)/) {
my $filename = $1;
$filename =~ s@^[^/]*/@@;
@@ -598,6 +603,7 @@ foreach my $file (@ARGV) {
}
@file_emails = uniq(@file_emails);
+@fixes = uniq(@fixes);
my %email_hash_name;
my %email_hash_address;
@@ -612,7 +618,6 @@ my %deduplicate_name_hash = ();
my %deduplicate_address_hash = ();
my @maintainers = get_maintainers();
-
if (@maintainers) {
@maintainers = merge_email(@maintainers);
output(@maintainers);
@@ -927,6 +932,10 @@ sub get_maintainers {
}
}
+ foreach my $fix (@fixes) {
+ vcs_add_commit_signers($fix, "blamed_fixes");
+ }
+
foreach my $email (@email_to, @list_to) {
$email->[0] = deduplicate_email($email->[0]);
}
@@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
--roles => show roles (status:subsystem, git-signer, list, etc...)
--rolestats => show roles and statistics (commits/total_commits, %)
--file-emails => add email addresses found in -f file (default: 0 (off))
+ --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
--scm => print SCM tree(s) if any
--status => print status if any
--subsystem => print subsystem name if any
@@ -1730,6 +1740,32 @@ sub vcs_is_hg {
return $vcs_used == 2;
}
+sub vcs_add_commit_signers {
+ return if (!vcs_exists());
+
+ my ($commit, $desc) = @_;
+ my $commit_count = 0;
+ my $commit_authors_ref;
+ my $commit_signers_ref;
+ my $stats_ref;
+ my @commit_authors = ();
+ my @commit_signers = ();
+ my $cmd;
+
+ $cmd = $VCS_cmds{"find_commit_signers_cmd"};
+ $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
+
+ ($commit_count, $commit_signers_ref, $commit_authors_ref, $stats_ref) = vcs_find_signers($cmd, "");
+ @commit_authors = @{$commit_authors_ref} if defined $commit_authors_ref;
+ @commit_signers = @{$commit_signers_ref} if defined $commit_signers_ref;
+
+ foreach my $signer (@commit_signers) {
+ $signer = deduplicate_email($signer);
+ }
+
+ vcs_assign($desc, 1, @commit_signers);
+}
+
sub interactive_get_maintainers {
my ($list_ref) = @_;
my @list = @$list_ref;
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply related [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-25 17:13 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-25 17:13 UTC (permalink / raw)
To: Dan Carpenter, Mauro Carvalho Chehab
Cc: ksummit-discuss, Linux Media Mailing List, Andrew Morton
On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote:
> When I sent a patch, I use get_maintainer.pl then I add whoever the
> wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> Cook from the CC list because they worked all over the tree and I know
> them. I also normally remove LKML if there is another mailing list but
> at least one subsystem uses LKML for patchwork so this isn't safe.
>
> So the safest instructions are "Use get_matainer.pl and add the person
> who wrote the commit in the Fixes tag".
Maybe add this:
Add the signers of any commit referenced in a "Fixes: <commit>" line
of a patch description.
---
scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 5ef59214c555..34085d146fa2 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -26,6 +26,7 @@ my $email = 1;
my $email_usename = 1;
my $email_maintainer = 1;
my $email_reviewer = 1;
+my $email_fixes = 1;
my $email_list = 1;
my $email_moderated_list = 1;
my $email_subscriber_list = 0;
@@ -249,6 +250,7 @@ if (!GetOptions(
'r!' => \$email_reviewer,
'n!' => \$email_usename,
'l!' => \$email_list,
+ 'fixes!' => \$email_fixes,
'moderated!' => \$email_moderated_list,
's!' => \$email_subscriber_list,
'multiline!' => \$output_multiline,
@@ -503,6 +505,7 @@ sub read_mailmap {
## use the filenames on the command line or find the filenames in the patchfiles
my @files = ();
+my @fixes = (); # If a patch description includes Fixes: lines
my @range = ();
my @keyword_tvi = ();
my @file_emails = ();
@@ -568,6 +571,8 @@ foreach my $file (@ARGV) {
my $filename2 = $2;
push(@files, $filename1);
push(@files, $filename2);
+ } elsif (m/^Fixes:\s+([0-9a-fA-F]{6,40})/) {
+ push(@fixes, $1) if ($email_fixes);
} elsif (m/^\+\+\+\s+(\S+)/ or m/^---\s+(\S+)/) {
my $filename = $1;
$filename =~ s@^[^/]*/@@;
@@ -598,6 +603,7 @@ foreach my $file (@ARGV) {
}
@file_emails = uniq(@file_emails);
+@fixes = uniq(@fixes);
my %email_hash_name;
my %email_hash_address;
@@ -612,7 +618,6 @@ my %deduplicate_name_hash = ();
my %deduplicate_address_hash = ();
my @maintainers = get_maintainers();
-
if (@maintainers) {
@maintainers = merge_email(@maintainers);
output(@maintainers);
@@ -927,6 +932,10 @@ sub get_maintainers {
}
}
+ foreach my $fix (@fixes) {
+ vcs_add_commit_signers($fix, "blamed_fixes");
+ }
+
foreach my $email (@email_to, @list_to) {
$email->[0] = deduplicate_email($email->[0]);
}
@@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
--roles => show roles (status:subsystem, git-signer, list, etc...)
--rolestats => show roles and statistics (commits/total_commits, %)
--file-emails => add email addresses found in -f file (default: 0 (off))
+ --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
--scm => print SCM tree(s) if any
--status => print status if any
--subsystem => print subsystem name if any
@@ -1730,6 +1740,32 @@ sub vcs_is_hg {
return $vcs_used == 2;
}
+sub vcs_add_commit_signers {
+ return if (!vcs_exists());
+
+ my ($commit, $desc) = @_;
+ my $commit_count = 0;
+ my $commit_authors_ref;
+ my $commit_signers_ref;
+ my $stats_ref;
+ my @commit_authors = ();
+ my @commit_signers = ();
+ my $cmd;
+
+ $cmd = $VCS_cmds{"find_commit_signers_cmd"};
+ $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
+
+ ($commit_count, $commit_signers_ref, $commit_authors_ref, $stats_ref) = vcs_find_signers($cmd, "");
+ @commit_authors = @{$commit_authors_ref} if defined $commit_authors_ref;
+ @commit_signers = @{$commit_signers_ref} if defined $commit_signers_ref;
+
+ foreach my $signer (@commit_signers) {
+ $signer = deduplicate_email($signer);
+ }
+
+ vcs_assign($desc, 1, @commit_signers);
+}
+
sub interactive_get_maintainers {
my ($list_ref) = @_;
my @list = @$list_ref;
^ permalink raw reply related [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-25 17:13 ` Joe Perches
@ 2019-09-25 18:40 ` Kees Cook
-1 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-25 18:40 UTC (permalink / raw)
To: Joe Perches
Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter,
Linux Media Mailing List
On Wed, Sep 25, 2019 at 10:13:37AM -0700, Joe Perches wrote:
> On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote:
> > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > Cook from the CC list because they worked all over the tree and I know
> > them. I also normally remove LKML if there is another mailing list but
> > at least one subsystem uses LKML for patchwork so this isn't safe.
> >
> > So the safest instructions are "Use get_matainer.pl and add the person
> > who wrote the commit in the Fixes tag".
>
> Maybe add this:
>
> Add the signers of any commit referenced in a "Fixes: <commit>" line
> of a patch description.
Oh yes please! I've always done this manually, so that's a nice bit of
automation. :)
>
> ---
> scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 5ef59214c555..34085d146fa2 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -26,6 +26,7 @@ my $email = 1;
> my $email_usename = 1;
> my $email_maintainer = 1;
> my $email_reviewer = 1;
> +my $email_fixes = 1;
> my $email_list = 1;
> my $email_moderated_list = 1;
> my $email_subscriber_list = 0;
> @@ -249,6 +250,7 @@ if (!GetOptions(
> 'r!' => \$email_reviewer,
> 'n!' => \$email_usename,
> 'l!' => \$email_list,
> + 'fixes!' => \$email_fixes,
> 'moderated!' => \$email_moderated_list,
> 's!' => \$email_subscriber_list,
> 'multiline!' => \$output_multiline,
> @@ -503,6 +505,7 @@ sub read_mailmap {
> ## use the filenames on the command line or find the filenames in the patchfiles
>
> my @files = ();
> +my @fixes = (); # If a patch description includes Fixes: lines
> my @range = ();
> my @keyword_tvi = ();
> my @file_emails = ();
> @@ -568,6 +571,8 @@ foreach my $file (@ARGV) {
> my $filename2 = $2;
> push(@files, $filename1);
> push(@files, $filename2);
> + } elsif (m/^Fixes:\s+([0-9a-fA-F]{6,40})/) {
Is "6" a safe lower bound here? I thought 12 was the way to go?
$ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail
238 8
300 7
330 14
344 6
352 11
408 40
425 10
735 16
1866 13
31446 12
Hmpf, 6 is pretty high up there...
> + push(@fixes, $1) if ($email_fixes);
> } elsif (m/^\+\+\+\s+(\S+)/ or m/^---\s+(\S+)/) {
> my $filename = $1;
> $filename =~ s@^[^/]*/@@;
> @@ -598,6 +603,7 @@ foreach my $file (@ARGV) {
> }
>
> @file_emails = uniq(@file_emails);
> +@fixes = uniq(@fixes);
>
> my %email_hash_name;
> my %email_hash_address;
> @@ -612,7 +618,6 @@ my %deduplicate_name_hash = ();
> my %deduplicate_address_hash = ();
>
> my @maintainers = get_maintainers();
> -
> if (@maintainers) {
> @maintainers = merge_email(@maintainers);
> output(@maintainers);
> @@ -927,6 +932,10 @@ sub get_maintainers {
> }
> }
>
> + foreach my $fix (@fixes) {
> + vcs_add_commit_signers($fix, "blamed_fixes");
> + }
> +
> foreach my $email (@email_to, @list_to) {
> $email->[0] = deduplicate_email($email->[0]);
> }
> @@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
> --roles => show roles (status:subsystem, git-signer, list, etc...)
> --rolestats => show roles and statistics (commits/total_commits, %)
> --file-emails => add email addresses found in -f file (default: 0 (off))
> + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
Should "Tested-by" and "Co-developed-by" get added to @signature_tags ?
> --scm => print SCM tree(s) if any
> --status => print status if any
> --subsystem => print subsystem name if any
> @@ -1730,6 +1740,32 @@ sub vcs_is_hg {
> return $vcs_used == 2;
> }
>
> +sub vcs_add_commit_signers {
> + return if (!vcs_exists());
> +
> + my ($commit, $desc) = @_;
> + my $commit_count = 0;
> + my $commit_authors_ref;
> + my $commit_signers_ref;
> + my $stats_ref;
> + my @commit_authors = ();
> + my @commit_signers = ();
> + my $cmd;
> +
> + $cmd = $VCS_cmds{"find_commit_signers_cmd"};
> + $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
> +
> + ($commit_count, $commit_signers_ref, $commit_authors_ref, $stats_ref) = vcs_find_signers($cmd, "");
> + @commit_authors = @{$commit_authors_ref} if defined $commit_authors_ref;
> + @commit_signers = @{$commit_signers_ref} if defined $commit_signers_ref;
> +
> + foreach my $signer (@commit_signers) {
> + $signer = deduplicate_email($signer);
> + }
> +
> + vcs_assign($desc, 1, @commit_signers);
> +}
@commit_authors is unused?
> +
> sub interactive_get_maintainers {
> my ($list_ref) = @_;
> my @list = @$list_ref;
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
Yay! :)
--
Kees Cook
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-25 18:40 ` Kees Cook
0 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-25 18:40 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit-discuss,
Linux Media Mailing List
On Wed, Sep 25, 2019 at 10:13:37AM -0700, Joe Perches wrote:
> On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote:
> > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > Cook from the CC list because they worked all over the tree and I know
> > them. I also normally remove LKML if there is another mailing list but
> > at least one subsystem uses LKML for patchwork so this isn't safe.
> >
> > So the safest instructions are "Use get_matainer.pl and add the person
> > who wrote the commit in the Fixes tag".
>
> Maybe add this:
>
> Add the signers of any commit referenced in a "Fixes: <commit>" line
> of a patch description.
Oh yes please! I've always done this manually, so that's a nice bit of
automation. :)
>
> ---
> scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 5ef59214c555..34085d146fa2 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -26,6 +26,7 @@ my $email = 1;
> my $email_usename = 1;
> my $email_maintainer = 1;
> my $email_reviewer = 1;
> +my $email_fixes = 1;
> my $email_list = 1;
> my $email_moderated_list = 1;
> my $email_subscriber_list = 0;
> @@ -249,6 +250,7 @@ if (!GetOptions(
> 'r!' => \$email_reviewer,
> 'n!' => \$email_usename,
> 'l!' => \$email_list,
> + 'fixes!' => \$email_fixes,
> 'moderated!' => \$email_moderated_list,
> 's!' => \$email_subscriber_list,
> 'multiline!' => \$output_multiline,
> @@ -503,6 +505,7 @@ sub read_mailmap {
> ## use the filenames on the command line or find the filenames in the patchfiles
>
> my @files = ();
> +my @fixes = (); # If a patch description includes Fixes: lines
> my @range = ();
> my @keyword_tvi = ();
> my @file_emails = ();
> @@ -568,6 +571,8 @@ foreach my $file (@ARGV) {
> my $filename2 = $2;
> push(@files, $filename1);
> push(@files, $filename2);
> + } elsif (m/^Fixes:\s+([0-9a-fA-F]{6,40})/) {
Is "6" a safe lower bound here? I thought 12 was the way to go?
$ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail
238 8
300 7
330 14
344 6
352 11
408 40
425 10
735 16
1866 13
31446 12
Hmpf, 6 is pretty high up there...
> + push(@fixes, $1) if ($email_fixes);
> } elsif (m/^\+\+\+\s+(\S+)/ or m/^---\s+(\S+)/) {
> my $filename = $1;
> $filename =~ s@^[^/]*/@@;
> @@ -598,6 +603,7 @@ foreach my $file (@ARGV) {
> }
>
> @file_emails = uniq(@file_emails);
> +@fixes = uniq(@fixes);
>
> my %email_hash_name;
> my %email_hash_address;
> @@ -612,7 +618,6 @@ my %deduplicate_name_hash = ();
> my %deduplicate_address_hash = ();
>
> my @maintainers = get_maintainers();
> -
> if (@maintainers) {
> @maintainers = merge_email(@maintainers);
> output(@maintainers);
> @@ -927,6 +932,10 @@ sub get_maintainers {
> }
> }
>
> + foreach my $fix (@fixes) {
> + vcs_add_commit_signers($fix, "blamed_fixes");
> + }
> +
> foreach my $email (@email_to, @list_to) {
> $email->[0] = deduplicate_email($email->[0]);
> }
> @@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
> --roles => show roles (status:subsystem, git-signer, list, etc...)
> --rolestats => show roles and statistics (commits/total_commits, %)
> --file-emails => add email addresses found in -f file (default: 0 (off))
> + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
Should "Tested-by" and "Co-developed-by" get added to @signature_tags ?
> --scm => print SCM tree(s) if any
> --status => print status if any
> --subsystem => print subsystem name if any
> @@ -1730,6 +1740,32 @@ sub vcs_is_hg {
> return $vcs_used == 2;
> }
>
> +sub vcs_add_commit_signers {
> + return if (!vcs_exists());
> +
> + my ($commit, $desc) = @_;
> + my $commit_count = 0;
> + my $commit_authors_ref;
> + my $commit_signers_ref;
> + my $stats_ref;
> + my @commit_authors = ();
> + my @commit_signers = ();
> + my $cmd;
> +
> + $cmd = $VCS_cmds{"find_commit_signers_cmd"};
> + $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
> +
> + ($commit_count, $commit_signers_ref, $commit_authors_ref, $stats_ref) = vcs_find_signers($cmd, "");
> + @commit_authors = @{$commit_authors_ref} if defined $commit_authors_ref;
> + @commit_signers = @{$commit_signers_ref} if defined $commit_signers_ref;
> +
> + foreach my $signer (@commit_signers) {
> + $signer = deduplicate_email($signer);
> + }
> +
> + vcs_assign($desc, 1, @commit_signers);
> +}
@commit_authors is unused?
> +
> sub interactive_get_maintainers {
> my ($list_ref) = @_;
> my @list = @$list_ref;
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
Yay! :)
--
Kees Cook
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-25 17:13 ` Joe Perches
@ 2019-09-26 10:25 ` Geert Uytterhoeven
-1 siblings, 0 replies; 227+ messages in thread
From: Geert Uytterhoeven @ 2019-09-26 10:25 UTC (permalink / raw)
To: Joe Perches
Cc: Mauro Carvalho Chehab, ksummit, Dan Carpenter, Linux Media Mailing List
Hi Joe,
On Wed, Sep 25, 2019 at 7:32 PM Joe Perches <joe@perches.com> wrote:
> On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote:
> > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > Cook from the CC list because they worked all over the tree and I know
> > them. I also normally remove LKML if there is another mailing list but
> > at least one subsystem uses LKML for patchwork so this isn't safe.
> >
> > So the safest instructions are "Use get_matainer.pl and add the person
> > who wrote the commit in the Fixes tag".
>
> Maybe add this:
>
> Add the signers of any commit referenced in a "Fixes: <commit>" line
> of a patch description.
>
> ---
> scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 37 insertions(+), 1 deletion(-)
Thanks! I gave it a quick try for my first fix after returning from ER, and it
did the right thing.
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-26 10:25 ` Geert Uytterhoeven
0 siblings, 0 replies; 227+ messages in thread
From: Geert Uytterhoeven @ 2019-09-26 10:25 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit, Linux Media Mailing List
Hi Joe,
On Wed, Sep 25, 2019 at 7:32 PM Joe Perches <joe@perches.com> wrote:
> On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote:
> > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > Cook from the CC list because they worked all over the tree and I know
> > them. I also normally remove LKML if there is another mailing list but
> > at least one subsystem uses LKML for patchwork so this isn't safe.
> >
> > So the safest instructions are "Use get_matainer.pl and add the person
> > who wrote the commit in the Fixes tag".
>
> Maybe add this:
>
> Add the signers of any commit referenced in a "Fixes: <commit>" line
> of a patch description.
>
> ---
> scripts/get_maintainer.pl | 38 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 37 insertions(+), 1 deletion(-)
Thanks! I gave it a quick try for my first fix after returning from ER, and it
did the right thing.
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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-25 18:40 ` Kees Cook
@ 2019-09-26 15:14 ` Joe Perches
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-26 15:14 UTC (permalink / raw)
To: Kees Cook
Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter,
Linux Media Mailing List
On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote:
> On Wed, Sep 25, 2019 at 10:13:37AM -0700, Joe Perches wrote:
> > On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote:
> > > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > > Cook from the CC list because they worked all over the tree and I know
> > > them. I also normally remove LKML if there is another mailing list but
> > > at least one subsystem uses LKML for patchwork so this isn't safe.
> > >
> > > So the safest instructions are "Use get_matainer.pl and add the person
> > > who wrote the commit in the Fixes tag".
> >
> > Maybe add this:
> >
> > Add the signers of any commit referenced in a "Fixes: <commit>" line
> > of a patch description.
>
> Oh yes please! I've always done this manually, so that's a nice bit of
> automation. :)
>
> Is "6" a safe lower bound here? I thought 12 was the way to go?
[]
> $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail
> 238 8
> 300 7
> 330 14
> 344 6
> 352 11
> 408 40
> 425 10
> 735 16
> 1866 13
> 31446 12
>
> Hmpf, 6 is pretty high up there...
Yes, but your grep then col2 isn't right.
You are counting all the 'Fixes: commit <foo>' output
as 6 because that's the length of 'commit'.
I also think the length of the hex commit value doesn't
matter much as it's got to be a specific single commit
SHA1 anyway, otherwise the commit id lookup will fail.
> > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
> > --roles => show roles (status:subsystem, git-signer, list, etc...)
> > --rolestats => show roles and statistics (commits/total_commits, %)
> > --file-emails => add email addresses found in -f file (default: 0 (off))
> > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
>
> Should "Tested-by" and "Co-developed-by" get added to @signature_tags ?
All "<foo>-by:" signatures are added.
> @commit_authors is unused?
Yes, authors are already required to sign-off so
it's just duplicating already existing signatures.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-26 15:14 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-26 15:14 UTC (permalink / raw)
To: Kees Cook
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit-discuss,
Linux Media Mailing List
On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote:
> On Wed, Sep 25, 2019 at 10:13:37AM -0700, Joe Perches wrote:
> > On Thu, 2019-09-19 at 09:56 +0300, Dan Carpenter wrote:
> > > When I sent a patch, I use get_maintainer.pl then I add whoever the
> > > wrote the commit from the Fixes tag. Then I remove Colin King and Kees
> > > Cook from the CC list because they worked all over the tree and I know
> > > them. I also normally remove LKML if there is another mailing list but
> > > at least one subsystem uses LKML for patchwork so this isn't safe.
> > >
> > > So the safest instructions are "Use get_matainer.pl and add the person
> > > who wrote the commit in the Fixes tag".
> >
> > Maybe add this:
> >
> > Add the signers of any commit referenced in a "Fixes: <commit>" line
> > of a patch description.
>
> Oh yes please! I've always done this manually, so that's a nice bit of
> automation. :)
>
> Is "6" a safe lower bound here? I thought 12 was the way to go?
[]
> $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail
> 238 8
> 300 7
> 330 14
> 344 6
> 352 11
> 408 40
> 425 10
> 735 16
> 1866 13
> 31446 12
>
> Hmpf, 6 is pretty high up there...
Yes, but your grep then col2 isn't right.
You are counting all the 'Fixes: commit <foo>' output
as 6 because that's the length of 'commit'.
I also think the length of the hex commit value doesn't
matter much as it's got to be a specific single commit
SHA1 anyway, otherwise the commit id lookup will fail.
> > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
> > --roles => show roles (status:subsystem, git-signer, list, etc...)
> > --rolestats => show roles and statistics (commits/total_commits, %)
> > --file-emails => add email addresses found in -f file (default: 0 (off))
> > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
>
> Should "Tested-by" and "Co-developed-by" get added to @signature_tags ?
All "<foo>-by:" signatures are added.
> @commit_authors is unused?
Yes, authors are already required to sign-off so
it's just duplicating already existing signatures.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-26 15:14 ` Joe Perches
@ 2019-09-26 15:53 ` Kees Cook
-1 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-26 15:53 UTC (permalink / raw)
To: Joe Perches
Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter,
Linux Media Mailing List
On Thu, Sep 26, 2019 at 08:14:03AM -0700, Joe Perches wrote:
> On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote:
> > Is "6" a safe lower bound here? I thought 12 was the way to go?
> []
> > $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail
> > 238 8
> > 300 7
> > 330 14
> > 344 6
> > 352 11
> > 408 40
> > 425 10
> > 735 16
> > 1866 13
> > 31446 12
> >
> > Hmpf, 6 is pretty high up there...
>
> Yes, but your grep then col2 isn't right.
> You are counting all the 'Fixes: commit <foo>' output
> as 6 because that's the length of 'commit'.
the [a-f0-9]{1,40} already excludes "commit".
> I also think the length of the hex commit value doesn't
> matter much as it's got to be a specific single commit
> SHA1 anyway, otherwise the commit id lookup will fail.
Fail enough. We do already have 6-digit SHA1 collisions, so it seemed
like using more than 6 would be nicer? *shrug* I don't have a strong
opinion. :)
>
> > > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
> > > --roles => show roles (status:subsystem, git-signer, list, etc...)
> > > --rolestats => show roles and statistics (commits/total_commits, %)
> > > --file-emails => add email addresses found in -f file (default: 0 (off))
> > > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
> >
> > Should "Tested-by" and "Co-developed-by" get added to @signature_tags ?
>
> All "<foo>-by:" signatures are added.
Ah, I'd missed where that happened. I do note that's only when
git-all-signature-types is set, which is default 0. (/me goes to add
this to his invocations...)
my $email_git_all_signature_types = 0;
...
if ($email_git_all_signature_types) {
$signature_pattern = "(.+?)[Bb][Yy]:";
} else {
$signature_pattern = "\(" . join("|", @signature_tags) . "\)";
}
> > @commit_authors is unused?
>
> Yes, authors are already required to sign-off so
> it's just duplicating already existing signatures.
Sure, it just seemed odd to populate it if it wasn't going to be used.
--
Kees Cook
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-26 15:53 ` Kees Cook
0 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-26 15:53 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit-discuss,
Linux Media Mailing List
On Thu, Sep 26, 2019 at 08:14:03AM -0700, Joe Perches wrote:
> On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote:
> > Is "6" a safe lower bound here? I thought 12 was the way to go?
> []
> > $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail
> > 238 8
> > 300 7
> > 330 14
> > 344 6
> > 352 11
> > 408 40
> > 425 10
> > 735 16
> > 1866 13
> > 31446 12
> >
> > Hmpf, 6 is pretty high up there...
>
> Yes, but your grep then col2 isn't right.
> You are counting all the 'Fixes: commit <foo>' output
> as 6 because that's the length of 'commit'.
the [a-f0-9]{1,40} already excludes "commit".
> I also think the length of the hex commit value doesn't
> matter much as it's got to be a specific single commit
> SHA1 anyway, otherwise the commit id lookup will fail.
Fail enough. We do already have 6-digit SHA1 collisions, so it seemed
like using more than 6 would be nicer? *shrug* I don't have a strong
opinion. :)
>
> > > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
> > > --roles => show roles (status:subsystem, git-signer, list, etc...)
> > > --rolestats => show roles and statistics (commits/total_commits, %)
> > > --file-emails => add email addresses found in -f file (default: 0 (off))
> > > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
> >
> > Should "Tested-by" and "Co-developed-by" get added to @signature_tags ?
>
> All "<foo>-by:" signatures are added.
Ah, I'd missed where that happened. I do note that's only when
git-all-signature-types is set, which is default 0. (/me goes to add
this to his invocations...)
my $email_git_all_signature_types = 0;
...
if ($email_git_all_signature_types) {
$signature_pattern = "(.+?)[Bb][Yy]:";
} else {
$signature_pattern = "\(" . join("|", @signature_tags) . "\)";
}
> > @commit_authors is unused?
>
> Yes, authors are already required to sign-off so
> it's just duplicating already existing signatures.
Sure, it just seemed odd to populate it if it wasn't going to be used.
--
Kees Cook
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-26 15:53 ` Kees Cook
@ 2019-09-26 16:02 ` Joe Perches
-1 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-26 16:02 UTC (permalink / raw)
To: Kees Cook
Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter,
Linux Media Mailing List
On Thu, 2019-09-26 at 08:53 -0700, Kees Cook wrote:
> On Thu, Sep 26, 2019 at 08:14:03AM -0700, Joe Perches wrote:
> > On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote:
> > > Is "6" a safe lower bound here? I thought 12 was the way to go?
> > []
> > > $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail
> > > 238 8
> > > 300 7
> > > 330 14
> > > 344 6
> > > 352 11
> > > 408 40
> > > 425 10
> > > 735 16
> > > 1866 13
> > > 31446 12
> > >
> > > Hmpf, 6 is pretty high up there...
> >
> > Yes, but your grep then col2 isn't right.
> > You are counting all the 'Fixes: commit <foo>' output
> > as 6 because that's the length of 'commit'.
>
> the [a-f0-9]{1,40} already excludes "commit".
No it doesn't as commit starts with c which matches [a-f0-9]{1,40}
Try your original egrep command line yourself.
Maybe use:
$ git log | egrep 'Fixes: [a-f0-9]{1,40}' | awk '{ if (length($2) == 6) { print $0;} }'
The first few matches are
the commit referenced in Fixes: below replaced the call to
Fixes: commit 18a992787896 ("ARM: ux500: move soc_id driver to drivers/soc")
Fixes: commit 0580dde59438 ("ASoC: simple-card-utils: add asoc_simple_debug_info()")
Since Fixes: 8c5421c016a4 ("perf pmu: Display pmu name when printing
Fixes: commit 961fb3c206dc ("ASoC: rockchip: rk3399_gru_sound: don't select unnecessary Platform")
> > I also think the length of the hex commit value doesn't
> > matter much as it's got to be a specific single commit
> > SHA1 anyway, otherwise the commit id lookup will fail.
>
> Fail enough. We do already have 6-digit SHA1 collisions, so it seemed
> like using more than 6 would be nicer? *shrug* I don't have a strong
> opinion. :)
>
> > > > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
> > > > --roles => show roles (status:subsystem, git-signer, list, etc...)
> > > > --rolestats => show roles and statistics (commits/total_commits, %)
> > > > --file-emails => add email addresses found in -f file (default: 0 (off))
> > > > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
> > >
> > > Should "Tested-by" and "Co-developed-by" get added to @signature_tags ?
> >
> > All "<foo>-by:" signatures are added.
>
> Ah, I'd missed where that happened. I do note that's only when
> git-all-signature-types is set, which is default 0. (/me goes to add
> this to his invocations...)
>
> my $email_git_all_signature_types = 0;
> ...
> if ($email_git_all_signature_types) {
> $signature_pattern = "(.+?)[Bb][Yy]:";
> } else {
> $signature_pattern = "\(" . join("|", @signature_tags) . "\)";
> }
>
> > > @commit_authors is unused?
> >
> > Yes, authors are already required to sign-off so
> > it's just duplicating already existing signatures.
>
> Sure, it just seemed odd to populate it if it wasn't going to be used.
It's a generic function.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-26 16:02 ` Joe Perches
0 siblings, 0 replies; 227+ messages in thread
From: Joe Perches @ 2019-09-26 16:02 UTC (permalink / raw)
To: Kees Cook
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit-discuss,
Linux Media Mailing List
On Thu, 2019-09-26 at 08:53 -0700, Kees Cook wrote:
> On Thu, Sep 26, 2019 at 08:14:03AM -0700, Joe Perches wrote:
> > On Wed, 2019-09-25 at 11:40 -0700, Kees Cook wrote:
> > > Is "6" a safe lower bound here? I thought 12 was the way to go?
> > []
> > > $ git log | egrep 'Fixes: [a-f0-9]{1,40}' | col2 | awk '{print length }' | sort | uniq -c | sort -n | tail
> > > 238 8
> > > 300 7
> > > 330 14
> > > 344 6
> > > 352 11
> > > 408 40
> > > 425 10
> > > 735 16
> > > 1866 13
> > > 31446 12
> > >
> > > Hmpf, 6 is pretty high up there...
> >
> > Yes, but your grep then col2 isn't right.
> > You are counting all the 'Fixes: commit <foo>' output
> > as 6 because that's the length of 'commit'.
>
> the [a-f0-9]{1,40} already excludes "commit".
No it doesn't as commit starts with c which matches [a-f0-9]{1,40}
Try your original egrep command line yourself.
Maybe use:
$ git log | egrep 'Fixes: [a-f0-9]{1,40}' | awk '{ if (length($2) == 6) { print $0;} }'
The first few matches are
the commit referenced in Fixes: below replaced the call to
Fixes: commit 18a992787896 ("ARM: ux500: move soc_id driver to drivers/soc")
Fixes: commit 0580dde59438 ("ASoC: simple-card-utils: add asoc_simple_debug_info()")
Since Fixes: 8c5421c016a4 ("perf pmu: Display pmu name when printing
Fixes: commit 961fb3c206dc ("ASoC: rockchip: rk3399_gru_sound: don't select unnecessary Platform")
> > I also think the length of the hex commit value doesn't
> > matter much as it's got to be a specific single commit
> > SHA1 anyway, otherwise the commit id lookup will fail.
>
> Fail enough. We do already have 6-digit SHA1 collisions, so it seemed
> like using more than 6 would be nicer? *shrug* I don't have a strong
> opinion. :)
>
> > > > > @@ -1031,6 +1040,7 @@ MAINTAINER field selection options:
> > > > --roles => show roles (status:subsystem, git-signer, list, etc...)
> > > > --rolestats => show roles and statistics (commits/total_commits, %)
> > > > --file-emails => add email addresses found in -f file (default: 0 (off))
> > > > + --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
> > >
> > > Should "Tested-by" and "Co-developed-by" get added to @signature_tags ?
> >
> > All "<foo>-by:" signatures are added.
>
> Ah, I'd missed where that happened. I do note that's only when
> git-all-signature-types is set, which is default 0. (/me goes to add
> this to his invocations...)
>
> my $email_git_all_signature_types = 0;
> ...
> if ($email_git_all_signature_types) {
> $signature_pattern = "(.+?)[Bb][Yy]:";
> } else {
> $signature_pattern = "\(" . join("|", @signature_tags) . "\)";
> }
>
> > > @commit_authors is unused?
> >
> > Yes, authors are already required to sign-off so
> > it's just duplicating already existing signatures.
>
> Sure, it just seemed odd to populate it if it wasn't going to be used.
It's a generic function.
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
2019-09-26 16:02 ` Joe Perches
@ 2019-09-26 16:24 ` Kees Cook
-1 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-26 16:24 UTC (permalink / raw)
To: Joe Perches
Cc: Mauro Carvalho Chehab, ksummit-discuss, Dan Carpenter,
Linux Media Mailing List
On Thu, Sep 26, 2019 at 09:02:07AM -0700, Joe Perches wrote:
> > the [a-f0-9]{1,40} already excludes "commit".
>
> No it doesn't as commit starts with c which matches [a-f0-9]{1,40}
Whoops! Yes, sorry, you're right. I needed a trailing whitespace in the
regex.
--
Kees Cook
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation
@ 2019-09-26 16:24 ` Kees Cook
0 siblings, 0 replies; 227+ messages in thread
From: Kees Cook @ 2019-09-26 16:24 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Carpenter, Mauro Carvalho Chehab, ksummit-discuss,
Linux Media Mailing List
On Thu, Sep 26, 2019 at 09:02:07AM -0700, Joe Perches wrote:
> > the [a-f0-9]{1,40} already excludes "commit".
>
> No it doesn't as commit starts with c which matches [a-f0-9]{1,40}
Whoops! Yes, sorry, you're right. I needed a trailing whitespace in the
regex.
--
Kees Cook
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
2019-09-11 15:48 ` Dan Williams
(?)
@ 2019-10-01 13:55 ` Jonathan Corbet
-1 siblings, 0 replies; 227+ messages in thread
From: Jonathan Corbet @ 2019-10-01 13:55 UTC (permalink / raw)
To: Dan Williams
Cc: vishal.l.verma, ksummit-discuss, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov,
Mauro Carvalho Chehab, Steve French, Tobin C. Harding
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-10-01 13:55 ` Jonathan Corbet
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-10-01 13:55 ` Jonathan Corbet
0 siblings, 0 replies; 227+ 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, Martin K. Petersen,
Daniel Vetter, Joe Perches, Dmitry Vyukov, Alexandre Belloni,
vishal.l.verma, 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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
2019-10-01 13:55 ` Jonathan Corbet
(?)
@ 2019-10-01 18:17 ` Martin K. Petersen
-1 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-10-01 18:17 UTC (permalink / raw)
To: Jonathan Corbet
Cc: vishal.l.verma, ksummit-discuss, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov,
Mauro Carvalho Chehab, Steve French, Tobin C. Harding
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-10-01 18:17 ` Martin K. Petersen
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-10-01 18:17 ` Martin K. Petersen
0 siblings, 0 replies; 227+ messages in thread
From: Martin K. Petersen @ 2019-10-01 18:17 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Dan Williams, linux-kernel, Thomas Gleixner,
Mauro Carvalho Chehab, Steve French, Greg Kroah-Hartman,
Linus Torvalds, Tobin C. Harding, Olof Johansson,
Martin K. Petersen, Daniel Vetter, Joe Perches, Dmitry Vyukov,
Alexandre Belloni, vishal.l.verma, 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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
2019-10-01 13:55 ` Jonathan Corbet
(?)
@ 2019-11-07 20:13 ` Jonathan Corbet
-1 siblings, 0 replies; 227+ messages in thread
From: Jonathan Corbet @ 2019-11-07 20:13 UTC (permalink / raw)
To: Dan Williams
Cc: vishal.l.verma, ksummit-discuss, linux-nvdimm,
Greg Kroah-Hartman, linux-kernel, Dmitry Vyukov,
Mauro Carvalho Chehab, Steve French, Tobin C. Harding
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
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-11-07 20:13 ` Jonathan Corbet
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-11-07 20:13 ` Jonathan Corbet
0 siblings, 0 replies; 227+ 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, Martin K. Petersen,
Daniel Vetter, Joe Perches, Dmitry Vyukov, Alexandre Belloni,
vishal.l.verma, 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
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
2019-11-07 20:13 ` Jonathan Corbet
(?)
@ 2019-11-08 2:41 ` Dan Williams
-1 siblings, 0 replies; 227+ messages in thread
From: Dan Williams @ 2019-11-08 2:41 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Vishal L Verma, ksummit, linux-nvdimm, Greg Kroah-Hartman,
Linux Kernel Mailing List, Dmitry Vyukov, Mauro Carvalho Chehab,
Steve French, Tobin C. Harding
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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
^ permalink raw reply [flat|nested] 227+ messages in thread
* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-11-08 2:41 ` Dan Williams
0 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
@ 2019-11-08 2:41 ` Dan Williams
0 siblings, 0 replies; 227+ 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,
Martin K. Petersen, Daniel Vetter, Joe Perches, Dmitry Vyukov,
Alexandre Belloni, Vishal L Verma, 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.
^ permalink raw reply [flat|nested] 227+ 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
-1 siblings, 0 replies; 227+ 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] 227+ messages in thread
* Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles
@ 2020-04-29 13:55 ` Roman Bolshakov
0 siblings, 0 replies; 227+ messages in thread
From: Roman Bolshakov @ 2020-04-29 13:55 UTC (permalink / raw)
To: martin.petersen
Cc: bvanassche, dave.jiang, dvyukov, gregkh, ksummit-discuss,
linux-kernel, linux-nvdimm, mchehab, me, stfrench,
vishal.l.verma, 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
^ permalink raw reply [flat|nested] 227+ messages in thread
end of thread, other threads:[~2020-04-29 14:01 UTC | newest]
Thread overview: 227+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-11 15:48 [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
2019-09-11 15:48 ` Dan Williams
2019-09-11 15:48 ` Dan Williams
2019-09-11 15:48 ` [Ksummit-discuss] [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 15:48 ` Dan Williams
2019-09-13 15:37 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2019-09-13 15:37 ` Mauro Carvalho Chehab
2019-09-13 15:37 ` Mauro Carvalho Chehab
2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
2019-09-11 15:48 ` Dan Williams
2019-09-11 15:48 ` Dan Williams
2019-09-11 17:34 ` [Ksummit-discuss] " Verma, Vishal L
2019-09-11 17:34 ` Verma, Vishal L
2019-09-16 12:35 ` Jani Nikula
2019-09-16 12:35 ` Jani Nikula
2019-09-16 12:35 ` Jani Nikula
2019-10-01 13:55 ` Jonathan Corbet
2019-10-01 13:55 ` Jonathan Corbet
2019-10-01 13:55 ` Jonathan Corbet
2019-10-01 18:17 ` [Ksummit-discuss] " Martin K. Petersen
2019-10-01 18:17 ` Martin K. Petersen
2019-10-01 18:17 ` Martin K. Petersen
2019-11-07 20:13 ` [Ksummit-discuss] " Jonathan Corbet
2019-11-07 20:13 ` Jonathan Corbet
2019-11-07 20:13 ` Jonathan Corbet
2019-11-08 2:41 ` [Ksummit-discuss] " Dan Williams
2019-11-08 2:41 ` Dan Williams
2019-11-08 2:41 ` Dan Williams
2019-09-11 15:48 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
2019-09-11 15:48 ` Dan Williams
2019-09-11 15:48 ` Dan Williams
2019-09-11 17:42 ` [Ksummit-discuss] " Vishal Verma
2019-09-11 17:42 ` Vishal Verma
2019-09-11 17:42 ` Vishal Verma
2019-09-11 17:45 ` Dave Jiang
2019-09-11 17:45 ` Dave Jiang
2019-09-11 18:43 ` [Ksummit-discuss] " Dan Carpenter
2019-09-11 18:43 ` Dan Carpenter
2019-09-11 18:43 ` Dan Carpenter
2019-09-11 22:11 ` Jens Axboe
2019-09-11 22:11 ` Jens Axboe
2019-09-11 22:11 ` Jens Axboe
2019-09-12 7:41 ` Dan Williams
2019-09-12 7:41 ` Dan Williams
2019-09-12 7:41 ` Dan Williams
2019-09-12 8:24 ` Miguel Ojeda
2019-09-12 8:24 ` Miguel Ojeda
2019-09-12 10:18 ` Joe Perches
2019-09-12 10:18 ` Joe Perches
2019-09-12 10:18 ` Joe Perches
2019-09-12 11:02 ` Joe Perches
2019-09-12 11:02 ` Joe Perches
2019-09-12 14:17 ` Dan Williams
2019-09-12 14:17 ` Dan Williams
2019-09-12 14:51 ` Joe Perches
2019-09-12 14:51 ` Joe Perches
2019-09-12 14:42 ` Miguel Ojeda
2019-09-12 14:42 ` Miguel Ojeda
2019-09-13 7:09 ` Jonathan Corbet
2019-09-13 7:09 ` Jonathan Corbet
2019-09-13 7:09 ` Jonathan Corbet
2019-09-13 11:48 ` Dan Carpenter
2019-09-13 11:48 ` Dan Carpenter
2019-09-13 11:48 ` Dan Carpenter
2019-09-13 12:18 ` Dan Williams
2019-09-13 12:18 ` Dan Williams
2019-09-13 12:18 ` Dan Williams
2019-09-13 15:00 ` Randy Dunlap
2019-09-13 15:00 ` Randy Dunlap
2019-09-13 15:00 ` Randy Dunlap
2019-09-13 15:46 ` Rob Herring
2019-09-13 15:46 ` Rob Herring
2019-09-13 15:46 ` Rob Herring
2019-09-13 16:42 ` Joe Perches
2019-09-13 16:42 ` Joe Perches
2019-09-13 16:42 ` Joe Perches
2019-09-13 19:32 ` Rob Herring
2019-09-13 19:32 ` Rob Herring
2019-09-13 19:32 ` Rob Herring
2019-09-13 17:57 ` Geert Uytterhoeven
2019-09-13 17:57 ` Geert Uytterhoeven
2019-09-13 17:57 ` Geert Uytterhoeven
2019-09-16 12:42 ` Jani Nikula
2019-09-16 12:42 ` Jani Nikula
2019-09-16 12:42 ` Jani Nikula
2019-09-17 16:16 ` Jason Gunthorpe
2019-09-17 21:59 ` Dan Williams
2019-09-17 21:59 ` Dan Williams
2019-09-17 21:59 ` Dan Williams
2019-09-13 21:44 ` Martin K. Petersen
2019-09-13 21:44 ` Martin K. Petersen
2019-09-13 21:44 ` Martin K. Petersen
2019-09-16 7:01 ` Dan Carpenter
2019-09-16 7:01 ` Dan Carpenter
2019-09-16 7:01 ` Dan Carpenter
2019-09-16 17:08 ` Martin K. Petersen
2019-09-16 17:08 ` Martin K. Petersen
2019-09-16 17:08 ` Martin K. Petersen
2019-09-16 17:15 ` Mark Brown
2019-09-16 17:15 ` Mark Brown
2019-09-13 2:11 ` Aneesh Kumar K.V
2019-09-13 2:11 ` Aneesh Kumar K.V
2019-09-13 5:00 ` Greg KH
2019-09-13 5:00 ` Greg KH
2019-09-11 20:30 ` Joe Perches
2019-09-11 20:30 ` Joe Perches
2019-09-11 20:30 ` Joe Perches
2019-09-13 16:19 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Mauro Carvalho Chehab
2019-09-13 16:19 ` Mauro Carvalho Chehab
2019-09-13 16:19 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2019-09-17 3:35 ` [Ksummit-discuss] single maintainer profile directory (was Re: [PATCH] media: add a subsystem profile documentation) Kees Cook
2019-09-17 3:35 ` single maintainer profile directory (was Re: [Ksummit-discuss] " Kees Cook
2019-09-17 13:28 ` [Ksummit-discuss] single maintainer profile directory (was " Mauro Carvalho Chehab
2019-09-17 13:28 ` single maintainer profile directory (was Re: [Ksummit-discuss] " Mauro Carvalho Chehab
2019-09-17 16:33 ` [Ksummit-discuss] single maintainer profile directory (was " Kees Cook
2019-09-17 16:33 ` single maintainer profile directory (was Re: [Ksummit-discuss] " Kees Cook
2019-09-18 11:23 ` [Ksummit-discuss] single maintainer profile directory (was " Mauro Carvalho Chehab
2019-09-18 11:23 ` Mauro Carvalho Chehab
2019-09-18 17:39 ` Kees Cook
2019-09-18 17:39 ` Kees Cook
2019-09-18 18:35 ` Mauro Carvalho Chehab
2019-09-18 18:35 ` Mauro Carvalho Chehab
2019-09-21 19:13 ` Jonathan Corbet
2019-09-21 19:13 ` Jonathan Corbet
2019-09-21 19:45 ` Mauro Carvalho Chehab
2019-09-21 19:45 ` Mauro Carvalho Chehab
2019-09-23 22:45 ` Kees Cook
2019-09-23 22:45 ` Kees Cook
2019-09-18 12:36 ` [Ksummit-discuss] [PATCH] media: add a subsystem profile documentation Laurent Pinchart
2019-09-18 12:36 ` Laurent Pinchart
2019-09-18 13:57 ` Mauro Carvalho Chehab
2019-09-18 13:57 ` Mauro Carvalho Chehab
2019-09-18 17:27 ` Laurent Pinchart
2019-09-18 17:27 ` Laurent Pinchart
2019-09-18 18:48 ` Mauro Carvalho Chehab
2019-09-18 18:48 ` Mauro Carvalho Chehab
2019-09-19 7:08 ` Dan Carpenter
2019-09-19 7:08 ` Dan Carpenter
2019-09-20 5:29 ` Joe Perches
2019-09-20 5:29 ` Joe Perches
2019-09-20 14:09 ` Daniel Vetter
2019-09-20 14:09 ` Daniel Vetter
2019-09-19 6:56 ` Dan Carpenter
2019-09-19 6:56 ` Dan Carpenter
2019-09-19 7:22 ` Geert Uytterhoeven
2019-09-19 7:22 ` Geert Uytterhoeven
2019-09-19 8:49 ` Jani Nikula
2019-09-19 8:49 ` Jani Nikula
2019-09-19 8:58 ` Geert Uytterhoeven
2019-09-19 8:58 ` Geert Uytterhoeven
2019-09-19 9:52 ` Jani Nikula
2019-09-19 9:52 ` Jani Nikula
2019-09-20 14:53 ` Laurent Pinchart
2019-09-20 14:53 ` Laurent Pinchart
2019-09-20 14:59 ` Doug Anderson
2019-09-20 14:59 ` Doug Anderson
2019-09-21 8:56 ` Jani Nikula
2019-09-21 8:56 ` Jani Nikula
2019-09-23 15:58 ` Doug Anderson
2019-09-23 15:58 ` Doug Anderson
2019-09-23 16:04 ` Jonathan Corbet
2019-09-23 16:04 ` Jonathan Corbet
2019-09-19 9:52 ` Mauro Carvalho Chehab
2019-09-19 9:52 ` Mauro Carvalho Chehab
2019-09-25 17:13 ` Joe Perches
2019-09-25 17:13 ` Joe Perches
2019-09-25 18:40 ` Kees Cook
2019-09-25 18:40 ` Kees Cook
2019-09-26 15:14 ` Joe Perches
2019-09-26 15:14 ` Joe Perches
2019-09-26 15:53 ` Kees Cook
2019-09-26 15:53 ` Kees Cook
2019-09-26 16:02 ` Joe Perches
2019-09-26 16:02 ` Joe Perches
2019-09-26 16:24 ` Kees Cook
2019-09-26 16:24 ` Kees Cook
2019-09-26 10:25 ` Geert Uytterhoeven
2019-09-26 10:25 ` Geert Uytterhoeven
2019-09-18 13:59 ` [Ksummit-discuss] [PATCH v2] " Mauro Carvalho Chehab
2019-09-18 13:59 ` Mauro Carvalho Chehab
2019-09-18 14:07 ` André Almeida
2019-09-18 14:11 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2019-09-18 14:11 ` Mauro Carvalho Chehab
2019-09-11 16:40 ` [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen
2019-09-11 16:40 ` Martin K. Petersen
2019-09-11 16:40 ` Martin K. Petersen
2019-09-12 13:31 ` [Ksummit-discuss] " Bart Van Assche
2019-09-12 13:31 ` Bart Van Assche
2019-09-12 13:31 ` Bart Van Assche
2019-09-12 15:34 ` Joe Perches
2019-09-12 15:34 ` Joe Perches
2019-09-12 15:34 ` Joe Perches
2019-09-12 20:01 ` Bart Van Assche
2019-09-12 20:01 ` Bart Van Assche
2019-09-12 20:01 ` Bart Van Assche
2019-09-12 20:34 ` Joe Perches
2019-09-12 20:34 ` Joe Perches
2019-09-12 20:34 ` Joe Perches
2019-09-13 14:26 ` Rob Herring
2019-09-13 14:26 ` Rob Herring
2019-09-13 14:26 ` Rob Herring
2019-09-13 18:42 ` Joe Perches
2019-09-13 18:42 ` Joe Perches
2019-09-13 18:42 ` Joe Perches
2019-09-13 19:17 ` Mauro Carvalho Chehab
2019-09-13 19:17 ` Mauro Carvalho Chehab
2019-09-13 19:17 ` Mauro Carvalho Chehab
2019-09-13 20:33 ` Joe Perches
2019-09-13 20:33 ` Joe Perches
2019-09-13 20:33 ` Joe Perches
2019-09-13 12:56 ` Matthew Wilcox
2019-09-13 12:56 ` Matthew Wilcox
2019-09-13 13:54 ` Mauro Carvalho Chehab
2019-09-13 13:54 ` Mauro Carvalho Chehab
2019-09-13 13:54 ` Mauro Carvalho Chehab
2019-09-13 14:59 ` Guenter Roeck
2019-09-13 14:59 ` Guenter Roeck
2019-09-13 14:59 ` Guenter Roeck
2019-09-13 22:03 ` Martin K. Petersen
2019-09-13 22:03 ` Martin K. Petersen
2019-09-13 22:03 ` Martin K. Petersen
2020-04-29 13:55 ` Roman Bolshakov
2020-04-29 13:55 ` Roman Bolshakov
2019-09-12 13:10 ` Bart Van Assche
2019-09-12 13:10 ` Bart Van Assche
2019-09-12 13:10 ` Bart Van Assche
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.