The current SUSPECT_CODE_INDENT test does not recognize several
defective code style defects where code following a logical test is
inappropriately indented.
Before this patch, for code like:
if (foo)
bar();
checkpatch would not emit a warning.
Improve the test to warn when code after a logical test has the same
indentation as the logical test.
Perform the same indentation test for "else" blocks too.
Link: http://lkml.kernel.org/r/df2374b68c4a68af2b7ef08afe486584811f610a.1493683942.git.joe@perches.com
Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Many structs are generally used const and there is a known list of these
structs.
struct definitions should not be generally be declared const.
Add a test for the lack of an open brace immediately after the struct to
avoid definitions.
This avoids the false positive "struct foo should normally be const"
message only when the open brace is on the same line as the definition.
Link: http://lkml.kernel.org/r/0dce709150d712e66f1b90b03827634b53b28085.1491845946.git.joe@perches.com
Signed-off-by: Joe Perches <[email protected]>
Cc: Arthur Brainville <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The existing behavior relies on patch context to identify function
declarations. Add the ability to find function declarations when there
is an open brace in column 1.
This finds function declarations only in specific single line forms
where the function name is on a single line like:
int foo(args...)
{
and
int
foo(args...)
{
It does not recognize function declarations like:
int foo(int bar,
int baz)
{
Link: http://lkml.kernel.org/r/738d74bbbe1a06b80f11ed504818107c68903095.1488155636.git.joe@perches.com
Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Lines containing "} else {" should not be detected as unbalanced braces.
But the second check can be reduced to ".+else\s*{" and it therefore
never checked if the beginning of a line contains any other character
(like the relevant "}"). This check would also return true for "} else
{" and create warnings like
CHECK: Unbalanced braces around else statement
#391: FILE: ./net/batman-adv/tvlv.c:391:
+ } else {
The check can be changed to check the whole line for the missing "}" to
avoid this false positive.
Fixes: 0d1532456c26 ("checkpatch: notice unbalanced else braces in a patch")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Sven Eckelmann <[email protected]>
Acked-by: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
We still have a lot of old addresses for the FSF in the kernel.
willy@harry:~/kernel/idr$ git grep '675 Mass' |wc -l
1502
willy@harry:~/kernel/idr$ git grep '59 Temple' |wc -l
2825
willy@harry:~/kernel/idr$ git grep '51 Franklin' |wc -l
2020
Let's discourage adding the oldest one too.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Matthew Wilcox <[email protected]>
Acked-by: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Pull documentation update from Jonathan Corbet:
"These are the documentation changes for 4.10.
It's another busy cycle for the docs tree, as the sphinx conversion
continues. Highlights include:
- Further work on PDF output, which remains a bit of a pain but
should be more solid now.
- Five more DocBook template files converted to Sphinx. Only 27 to
go... Lots of plain-text files have also been converted and
integrated.
- Images in binary formats have been replaced with more
source-friendly versions.
- Various bits of organizational work, including the renaming of
various files discussed at the kernel summit.
- New documentation for the device_link mechanism.
... and, of course, lots of typo fixes and small updates"
* tag 'docs-4.10' of git://git.lwn.net/linux: (193 commits)
dma-buf: Extract dma-buf.rst
Update Documentation/00-INDEX
docs: 00-INDEX: document directories/files with no docs
docs: 00-INDEX: remove non-existing entries
docs: 00-INDEX: add missing entries for documentation files/dirs
docs: 00-INDEX: consolidate process/ and admin-guide/ description
scripts: add a script to check if Documentation/00-INDEX is sane
Docs: change sh -> awk in REPORTING-BUGS
Documentation/core-api/device_link: Add initial documentation
core-api: remove an unexpected unident
ppc/idle: Add documentation for powersave=off
Doc: Correct typo, "Introdution" => "Introduction"
Documentation/atomic_ops.txt: convert to ReST markup
Documentation/local_ops.txt: convert to ReST markup
Documentation/assoc_array.txt: convert to ReST markup
docs-rst: parse-headers.pl: cleanup the documentation
docs-rst: fix media cleandocs target
docs-rst: media/Makefile: reorganize the rules
docs-rst: media: build SVG from graphviz files
docs-rst: replace bayer.png by a SVG image
...
I generated a patch with `git format-patch` which checkpatch thinks is
invalid:
$ ./scripts/checkpatch.pl lpc-dt/0006-mfd-dt-Move-syscon-bindings-to-syscon-subdirectory.patch
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt | 0
ERROR: Does not appear to be a unified-diff format patch
total: 1 errors, 1 warnings, 0 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
lpc-dt/0006-mfd-dt-Move-syscon-bindings-to-syscon-subdirectory.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
The patch in question was all renames with no edits, giving 100%
similarity and thus no diff markers.
Set '$is_patch = 1;' in the add/remove/rename detection to avoid
generating spurious warnings.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrew Jeffery <[email protected]>
Acked-by: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The previous patch renamed several files that are cross-referenced
along the Kernel documentation. Adjust the links to point to
the right places.
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
The function calls with octal permissions commonly span multiple lines.
The current test is line oriented and fails to find some matches.
Make the test use the $stat variable instead of the $line variable to span
multiple lines.
Also add a few functions to the known functions with permissions list.
Move the SYMBOLIC_PERMS test to a separate section to find all the S_<FOO>
permissions in any form not just those that have specific function names.
This can now find and fix permissions uses like:
.mode = S_<FOO> | S_<BAR>;
Link: http://lkml.kernel.org/r/b51bab60530912aae4ac420119d465c5b206f19f.1475030406.git.joe@perches.com
Signed-off-by: Joe Perches <[email protected]>
Tested-by: Ramiro Oliveira <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
S_<FOO> uses should be avoided where octal is more intelligible.
Linus didst say:
: It's *much* easier to parse and understand the octal numbers, while the
: symbolic macro names are just random line noise and hard as hell to
: understand. You really have to think about it.
:
: So we should rather go the other way: convert existing bad symbolic
: permission bit macro use to just use the octal numbers.
:
: The symbolic names are good for the *other* bits (ie sticky bit, and the
: inode mode _type_ numbers etc), but for the permission bits, the symbolic
: names are just insane crap. Nobody sane should ever use them. Not in the
: kernel, not in user space.
(http://lkml.kernel.org/r/CA+55aFw5v23T-zvDZp-MmD_EYxF8WbafwwB59934FV7g21uMGQ@mail.gmail.com)
Link: http://lkml.kernel.org/r/7232ef011d05a92f4caa86a5e9830d87966a2eaf.1470180926.git.joe@perches.com
Signed-off-by: Joe Perches <[email protected]>
Cc: Linus Torvalds <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signoff was not checked if the filename is '-', indicating reading the
patch from stdin. Commands such as the below would not warn about a
missing signoff, because the patch filename is '-'. This change allows
checkpatch to warn about a missing signoff, even if the input filename
is '-', but only if the patch has a commit message.
git show --pretty=email | scripts/checkpatch.pl -
A more common use of checkpatch with stdin is for piping git diff
through checkpatch. The diff output would not contain a commit message,
and therefore it would not contain a signoff line. For this common use
case, a warning should not be printed about the missing signoff. With
this change we will only warn about a missing signoff if the input
contains a commit message.
git diff | scripts/checkpatch.pl -
Before this patch, a workaround for the first command was to refer to
stdin by a name other than '-'. The workaround is not an elegant
solution, because elsewhere checkpatch uses the fact that filename
equals '-', such as in setting '$vname' to 'Your patch' for stdin. The
command below would report "/dev/stdin has style problems" instead of
"Your patch has style problems."
git show --pretty=email | scripts/checkpatch.pl /dev/stdin
Link: http://lkml.kernel.org/r/48be31e414bddc65bccfa6b1322359be9ba032eb.1469670589.git.allenbh@gmail.com
Signed-off-by: Allen Hubbe <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The __pmem address space was meant to annotate codepaths that touch
persistent memory and need to coordinate a call to wmb_pmem(). Now that
wmb_pmem() is gone, there is little need to keep this annotation.
Cc: Christoph Hellwig <[email protected]>
Cc: Ross Zwisler <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Joe Perches