If included in patch descriptions, this will function much like the
--ignore flag.
Checkpatch-ignore: EMAIL_SUBJECT
Signed-off-by: Brendan Jackman <jackmanb@xxxxxxxxxx>
---
Documentation/dev-tools/checkpatch.rst | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index abb3ff6820766ee0c29112b256bcc44ce41fffba..b1d5616c72029d3d8c8c236cd8d05bb839018c0a 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -10,8 +10,12 @@ also be run on file contexts and without the kernel tree.
Checkpatch is not always right. Your judgement takes precedence over checkpatch
messages. If your code looks better with the violations, then its probably
-best left alone.
+best left alone. If you do that, consider adding the Checkpatch-ignore patch
+footer to record this decision.
+For example::
+
+ Checkpatch-ignore: EMAIL_SUBJECT,MACRO_ARG_REUSE
Options
=======
@@ -114,6 +118,9 @@ Available options:
Checkpatch will not emit messages for the specified types.
+ Note that violations can also be permanently disabled using the
+ Checkpatch-ignore patch footer.
+
Example::
./scripts/checkpatch.pl mypatch.patch --ignore EMAIL_SUBJECT,BRACES
--
2.47.1.613.gc27f4b7a9f-goog
