- 07 Aug, 2014 40 commits
-
-
Joe Perches authored
All the various for_each loop macros were not tested for trailing brace on the following lines and for bad indentation. Add them. Signed-off-by:
Joe Perches <joe@perches.com> Reported-by:
Greg KH <gregkh@linuxfoundation.org> Cc: Andy Whitcroft <apw@canonical.com Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
Add --fix corrections for ELSE_AFTER_BRACE and WHILE_AFTER_BRACE misuses. if (x) { ... } else { ... } is corrected to if (x) { ... } else { ... } and do { ... } while (x); is corrected to do { ... } while (x); Signed-off-by: -
Joe Perches authored
Style misuses of these types are corrected: typedef struct foo { int bar; }; int foo(int bar) { return bar+1; } int foo(int bar) { return bar+1; } Signed-off-by: -
Joe Perches authored
I copied the which subroutine from get_maintainer.pl. Unfortunately, get_maintainer uses a 4 space indentation so use the proper tab indentation instead. Signed-off-by:
-
Joe Perches authored
Neaten the uses of patch/file line insertions or deletions. Hide the mechanism used. Signed-off-by:
-
Joe Perches authored
This can be valuable to insert or delete blank lines as well as fix misplaced brace or else uses. Store indexes of lines to be added/deleted and the new lines. When creating the --fix file, insert or delete the appropriate lines and update the patch range information. Signed-off-by:
-
Joe Perches authored
Make the fix code a bit easier to read. This should also start to allow an easier mechanism to insert/delete lines eventually too. Signed-off-by:
-
Joe Perches authored
Using break; after a goto or return is unnecessary so emit a warning when the break is at the same indent level. So this emits a warning on: switch (foo) { case 1: goto err; break; } but not on: switch (foo) { case 1: if (bar()) goto err; break; } Signed-off-by: -
Joe Perches authored
Whenever files are added, moved, or deleted, the MAINTAINERS file patterns can be out of sync or outdated. To try to keep MAINTAINERS more up-to-date, add a one-time warning whenever a patch does any of those. Signed-off-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Joe Perches authored
Commit logs have various forms of commit id references. Try to standardize on a 12 character long lower case commit id along with a description of parentheses and the quoted subject line. ie: commit 0123456789ab ("commit description") If git and a git tree exists, look up the commit id and emit the appropriate line as part of the message. Signed-off-by: -
Joe Perches authored
Avoid matching allocs that appear to be known small multiplications of a sizeof with a constant because gcc as of 4.8 cannot optimize the code in a calloc() exactly the same way as an alloc(). Look for numeric constants or what appear to be upper case only macro #defines. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Original-patch-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Joe Perches authored
This --strict test previously worked only for what appeared to be cast to pointer types. Make it work for all casts. Also, there's no reason to show the previous line for this type of message, so don't. Signed-off-by:
-
Joe Perches authored
checkpatch's $Type variable does not match declarations of multiple const * types. This can produce false positives for things like: $ ./scripts/checkpatch.pl -f drivers/staging/comedi/comedidev.h WARNING: Missing a blank line after declarations #60: FILE: drivers/staging/comedi/comedidev.h:60: + const struct comedi_lrange *range_table; + const struct comedi_lrange *const *range_table_list; Fix the $Type variable to support matching multiple "* const" uses. Signed-off-by:
Hartley Sweeten <HartleyS@visionengravers.com> Signed-off-by:
-
Joe Perches authored
Parentheses around &(foo->bar) and *(foo->bar) are unnecessary. Emit a --strict only message on these uses. Signed-off-by:
-
Joe Perches authored
Editing Kconfig dependencies can emit unnecessary messages about missing or too short help entries. Only emit the message when adding help sections to Kconfig files. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Tested-by:
-
Joe Perches authored
Make it consistent with the other missing or multiple blank line tests. Signed-off-by:
-
Joe Perches authored
Multiple consecutive blank lines waste screen space. Emit a --strict only message with these blank lines. Signed-off-by:
-
Joe Perches authored
Add a --strict test asking for a blank line after function/struct/union/enum declarations. Allow exceptions for several attributes and macro uses. Signed-off-by:
-
Rasmus Villemoes authored
This might help a kernel hacker think twice before blindly adding a newline. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Acked-by:
-
Joe Perches authored
There are some patches created by git format-patch that when scanned by checkpatch report errors on lines like To: address.tld This is a checkpatch false positive. Improve the logic a bit to ignore folded email headers to avoid emitting these messages. Signed-off-by:
-
Joe Perches authored
Add a function pointer declaration check to the test for blank line needed after declarations. Signed-off-by:
Bruce W Allan <bruce.w.allan@intel.com> Signed-off-by:
-
Joe Perches authored
A single escaped constant char is not a complex macro. Signed-off-by:
-
Joe Perches authored
Using an else following a break or return can unnecessarily indent code blocks. ie: for (i = 0; i < 100; i++) { int foo = bar(); if (foo < 1) break; else usleep(1); } is generally better written as: for (i = 0; i < 100; i++) { int foo = bar(); if (foo < 1) break; usleep(1); } Warn when a bare else statement is preceded by a break or return indented 1 tab more than the else. Signed-off-by: -
Joe Perches authored
Logging messages that show some type of "out of memory" error are generally unnecessary as there is a generic message and a stack dump done by the memory subsystem. These messages generally increase kernel size without much added value. Emit a warning on these types of messages. This test looks for any inserted message function, then looks at the previous line for an "if (!foo)" or "if (foo == NULL)" test and then looks at the preceding statement for an allocation function like "foo = kmalloc()" ie: this code matches: foo = kmalloc(); if (foo == NULL) { printk("Out of memory\n"); return -ENOMEM; } This test is very crude and incomplete. This test can miss quite a lot of of OOM messages that do not have this specific form. ie: this code does not match: foo = kmalloc(); if (!foo) { rtn = -ENOMEM; printk("Out of memory!\n"); goto out; } This test could also be a false positive when the logging message itself does not specify anything about memory, but I did not find any false positives in my limited testing. spatch could be a better solution but correctness seems non-trivial for that tool too. Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Rasmus Villemoes authored
Apparently, bitmap_andnot is supposed to return whether the new bitmap is empty. But it didn't take potential garbage bits in the last word into account. Signed-off-by:
-
Rasmus Villemoes authored
Apparently, bitmap_and is supposed to return whether the new bitmap is empty. But it didn't take potential garbage bits in the last word into account. Signed-off-by:
-
Rasmus Villemoes authored
There is no guarantee that *src does not contain garbage bits outside the lower nbits, so we need to mask it before the shift-and-assign. Signed-off-by:
-
Rasmus Villemoes authored
__reg_op(..., REG_OP_ALLOC) always returns 0, so we might as well use that and save an instruction. Signed-off-by:
-
Rasmus Villemoes authored
Changing the pos parameter of __reg_op to unsigned allows the compiler to generate slightly smaller and simpler code. Also update its callers bitmap_*_region to receive and pass unsigned int. The return types of bitmap_find_free_region and bitmap_allocate_region are still int to allow a negative error code to be returned. An int is certainly capable of representing any realistic return value. Signed-off-by:
-
Rasmus Villemoes authored
A few lines above, it was stated that positions for non-set bits are mapped to -1, which is obviously also what the code does. Signed-off-by:
-
Rasmus Villemoes authored
We want len to be the index of the first '\n', or the length of the string if there is no newline. This is a good example of the usefulness of strchrnul(). Use that instead, thus eliminating a branch and a call to strlen(). Signed-off-by:
-
Rasmus Villemoes authored
The compiler can generate slightly smaller and simpler code when it knows that "start" is non-negative. Also, use the names "start" and "len" for the two parameters for consistency with bitmap_set. Signed-off-by:
-
Rasmus Villemoes authored
The compiler can generate slightly smaller and simpler code when it knows that "start" is non-negative. Also, use the names "start" and "len" for the two parameters in both header file and implementation, instead of the previous mix. Signed-off-by:
-
Rasmus Villemoes authored
The compiler can generate slightly smaller and simpler code when it knows that "nbits" is non-negative. Since no-one passes a negative bit-count, this shouldn't affect the semantics. I didn't change the return type, since that might change the semantics of some expression containing a call to bitmap_weight(). Certainly an int is capable of holding the result. Signed-off-by:
-
Rasmus Villemoes authored
The compiler can generate slightly smaller and simpler code when it knows that "nbits" is non-negative. Since no-one passes a negative bit-count, this shouldn't affect the semantics. Signed-off-by:
-
Rasmus Villemoes authored
The compiler can generate slightly smaller and simpler code when it knows that "nbits" is non-negative. Since no-one passes a negative bit-count, this shouldn't affect the semantics. Signed-off-by:
-
Rasmus Villemoes authored
This change is only for consistency with the changes to the other bitmap_* functions; it doesn't change the size of the generated code: inside BITS_TO_LONGS there is a sizeof(long), which causes bits to be interpreted as unsigned anyway. Signed-off-by:
-
Rasmus Villemoes authored
Since the extra bits are "don't care", there is no reason to mask the last word to the used bits when complementing. This shaves off yet a few bytes. Signed-off-by:
-
Rasmus Villemoes authored
The compiler can generate slightly smaller and simpler code when it knows that "nbits" is non-negative. Since no-one passes a negative bit-count, this shouldn't affect the semantics. Signed-off-by:
-
Rasmus Villemoes authored
The compiler can generate slightly smaller and simpler code when it knows that "nbits" is non-negative. Since no-one passes a negative bit-count, this shouldn't affect the semantics. Signed-off-by:
-
