- 03 Apr, 2014 40 commits
-
-
Christopher Covington authored
A commit hook for the Gerrit code review server [1] inserts change identifiers so Gerrit can track patches through multiple revisions. These identifiers are noise in the context of the upstream kernel. (Many Gerrit servers are private. Even given a public instance, given only a Change-Id, one must guess which server a change was tracked on. Patches submitted to the Linux kernel mailing lists should be able to stand on their own. If it's truly useful to reference code review on a Gerrit server, a URL is a much clearer way to do so.) Thus, issue an error when a Change-Id line is encountered before the Signed-off-by. 1. https://gerrit.googlesource.com/gerrit/+/master/gerrit-server/src/main/resources/com/google/gerrit/server/tools/root/hooks/commit-msgSigned-off-by:
Christopher Covington <cov@codeaurora.org> Cc: Joe Perches <joe@perches.com> Cc: Andy Whitcroft <apw@shadowen.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrew Morton authored
Revert commit 7e4915e7 ("checkpatch: add warning of future __GFP_NOFAIL use"). There are no plans to remove __GFP_NOFAIL. __GFP_NOFAIL exists to a) centralise the retry-allocation-for-ever operation into the core allocator, which is the appropriate implementation site and b) permit us to identify code sites which aren't handling memory exhaustion appropriately. Cc: David Rientjes <rientjes@google.com> Cc: Joe Perches <joe@perches.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Joe Perches authored
Networking prefers this style, so warn when it's not used. Networking uses: void foo(int bar) { int baz; code... } not void foo(int bar) { int baz; code... } There are a limited number of false positives when using macros to declare variables like: WARNING: networking uses a blank line after declarations #330: FILE: net/ipv4/inet_hashtables.c:330: + int dif = sk->sk_bound_dev_if; + INET_ADDR_COOKIE(acookie, saddr, daddr) Signed-off-by:Joe Perches <joe@perches.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Florian Vaussard authored
Improve the vendor name match in vendor-prefix.txt by only matching the exact vendor name at the beginning of lines. Signed-off-by:
Florian Vaussard <florian.vaussard@epfl.ch> Cc: Joe Perches <joe@perches.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Florian Vaussard authored
Look for ".compatible = "foo" strings not only in .dts files, but in .c and .h too. Signed-off-by:
-
Florian Vaussard authored
With a compatible string like compatible = "foo"; checkpatch will currently try to find "foo" in vendor-prefixes.txt, which is wrong since the vendor prefix is empty in this specific case. Skip the vendor test if the compatible is not like compatible = "vendor,something"; Signed-off-by:
-
Florian Vaussard authored
The current vendor compatible check will not match vendors with dashes, like: compatible="asahi-kasei" Signed-off-by:
-
Joe Perches authored
The current octal permissions test is very slow. When patch ("checkpatch: add checks for constant non-octal permissions") was added, processing time approximately tripled. Regain almost all of the performance by not looping through all the possible functions unless the line contains one of the functions. Signed-off-by: -
Yogesh Chaudhari authored
Modify warning message when printk is used in a patch. It mentions to use subsystem_dbg instead of netdev_dbg as the first preferred format of logging debug messages. Signed-off-by:
Yogesh Chaudhari <mr.yogesh@gmail.com> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
This test is a bit noisy and opinions seem to agree that it should not warn in a lot more situations. It seems people agree that: return (foo || bar); and return foo || bar; are both acceptable style and checkpatch should be silent about them. For now, it warns on parentheses around a simple constant or a single function or a ternary. return (foo); return (foo(bar)); return (foo ? bar : baz); The last ternary test may be quieted in the future. Modify the deparenthesize function to only strip balanced leading and trailing parentheses. Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Cc: Monam Agarwal <monamagarwal123@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Signed-off-by:
-
Joe Perches authored
It's very common to have normal block comments for the initial comments of a file description preface. So for files in drivers/net and net/ don't emit a warning when the first comment block in the file uses the normal block comment style and not the networking block comment style. Signed-off-by:
-
Joe Perches authored
Instead of array indexing $_, use temporary variables like all the other subroutines in the script use. Signed-off-by:
-
Joe Perches authored
static const char* arrays create smaller text as each function call does not have to populate the array. Emit a warning when char *arrays aren't static const and the array is not apparently global by being declared in the first column. Signed-off-by:
-
Joe Perches authored
checkpatch could not distinguish between a variable in a struct named jiffies and the normal jiffies. foo->jiffies would emit a "Comparing jiffies" arning. Update the $Compare variable to do a negative look-behind for "-" when finding a ">" so that a pointer dereference like -> isn't a comparison. Signed-off-by:
-
Joe Perches authored
Change a test of $dstat to $line to avoid possibly emitting the sscanf warning multiple times. Signed-off-by:
-
Joe Perches authored
When checking permissions, make sure 4 octal digits are used, but allow a single 0 too. Signed-off-by:
-
Joe Perches authored
Emit a warning when using any of these __constant_<foo> forms: __constant_cpu_to_be[x] __constant_cpu_to_le[x] __constant_be[x]_to_cpu __constant_le[x]_to_cpu __constant_htons __constant_ntohs Using any of these outside of include/uapi/ isn't preferred as using the function without __constant_ is identical when the argument is a constant. Signed-off-by:
-
Joe Perches authored
umode_t permissions are sometimes mistakenly written with decimal constants. Verify that numeric permissions are using octal. Add a list of the most commonly used functions and macros that have umode_t permissions and the argument position. Add a $Octal type to $Constant. Allow $LvalOrFunc to be a pointer indirection too. Signed-off-by:
-
Joe Perches authored
Checks for some function pointer return styles are too strict. Fix them. Multiple spaces after function pointer return types are allowed. int (*foo)(int bar) Spaces after function pointer returns of pointer types are not required. int *(*foo)(int bar) Signed-off-by:
-
Joe Perches authored
Holger reported: : The macro udelay cannot handle large values because of loss-of-precision. : : IMHO udelay on ARM is broken, because it also cannot work with fast : ARM processors (where bogomips >= 3355, which is in sight now). It's : just not broken enough that someone did something against it ... so : the current kludge is good enough. Until then, warn on long udelay uses. Also fix uses of $line that should have been $herecurr. Signed-off-by:
Holger Schurig <holgerschurig@gmail.com> Cc: Sujith Manoharan <sujith@msujith.org> Cc: John Linville <linville@tuxdriver.com> Signed-off-by:
-
Rashika Kheria authored
Include appropriate header file include/linux/decompress/inflate.h in lib/decompress_inflate.c because it has prototype declaration of function defined in lib/decompress_inflate.c. Also, fix the guard around the header file include/linux/decompress/inflate.h to use a more unique guard symbol. This avoids conflict with the INFLATE_H defined by zlib_inflate/inflate.h. This eliminates the following warning in lib/decompress_inflate.c: lib/decompress_inflate.c:35:17: warning: no previous prototype for `gunzip' [-Wmissing-prototypes] Signed-off-by:
Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by:
-
Rashika Kheria authored
Add prototype declarations of functions in lib/clz_ctz.c. These functions are required by GCC builtins and hence can not be removed despite of their unreferenced appearance in kernel source. This eliminates the following warning in lib/clz_ctz.c: lib/clz_ctz.c:16:12: warning: no previous prototype for `__ctzsi2' [-Wmissing-prototypes] lib/clz_ctz.c:22:12: warning: no previous prototype for `__clzsi2' [-Wmissing-prototypes] lib/clz_ctz.c:44:12: warning: no previous prototype for `__clzdi2' [-Wmissing-prototypes] lib/clz_ctz.c:50:12: warning: no previous prototype for `__ctzdi2' [-Wmissing-prototypes] Signed-off-by:
Chanho Min <chanho.min@lge.com> Signed-off-by:
-
Daniel Borkmann authored
These are just some very minor and misc cleanups in the PRNG. In prandom_u32() we store the result in an unsigned long which is unnecessary as it should be u32 instead that we get from prandom_u32_state(). prandom_bytes_state()'s comment is in kdoc format, so change it into such as it's done everywhere else. Also, use the normal comment style for the header comment. Last but not least for readability, add some newlines. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Steven Rostedt authored
Having a discussion about sparse warnings in the kernel, and that we should clean them up, I decided to pick a random file to do so. This happened to be devres.c which gives the following warnings: CHECK lib/devres.c lib/devres.c:83:9: warning: cast removes address space of expression lib/devres.c:117:31: warning: incorrect type in return expression (different address spaces) lib/devres.c:117:31: expected void [noderef] <asn:2>* lib/devres.c:117:31: got void * lib/devres.c:125:31: warning: incorrect type in return expression (different address spaces) lib/devres.c:125:31: expected void [noderef] <asn:2>* lib/devres.c:125:31: got void * lib/devres.c:136:26: warning: incorrect type in assignment (different address spaces) lib/devres.c:136:26: expected void [noderef] <asn:2>*[assigned] dest_ptr lib/devres.c:136:26: got void * lib/devres.c:226:9: warning: cast removes address space of expression Mostly it's just the use of typecasting to void * without adding __force, or returning ERR_PTR(-ESOMEERR) without typecasting to a __iomem type. I added a helper macro IOMEM_ERR_PTR() that does the typecast to make the code a little nicer than adding ugly typecasts to the code. Signed-off-by:Steven Rostedt <rostedt@goodmis.org> Cc: Tejun Heo <tj@kernel.org> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Stefano Babic <sbabic@denx.de> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Jinyoung Park <jinyoungp@nvidia.com> Signed-off-by:
-
Liu Ying authored
We don't have to update a backlight status every time a blanking or unblanking event comes because the backlight status may have already been what we want. Another thought is that one backlight device may be shared by multiple framebuffers. We don't hope blanking one of the framebuffers may turn the backlight off for all the other framebuffers, since they are likely being active to display something. This patch makes the backlight status be updated only when the relevant backlight device's use count changes from zero to one or from one to zero. Signed-off-by:
Liu Ying <Ying.Liu@freescale.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Liu Ying authored
We don't have to update the state and fb_blank properties of a backlight device every time a blanking or unblanking event comes because they may have already been what we want. Another thought is that one backlight device may be shared by multiple framebuffers. The backlight driver should take the backlight device as a resource shared by all the associated framebuffers. This patch adds some logic to record each framebuffer's backlight usage to determine the backlight device use count and whether the two properties should be updated or not. To be more specific, only one unblank operation on a certain blanked framebuffer may increase the backlight device's use count by one, while one blank operation on a certain unblanked framebuffer may decrease the use count by one, because the userspace is likely to unblank an unblanked framebuffer or blank a blanked framebuffer. Signed-off-by:
-
Joe Perches authored
Seems he's gone off to bigger/better things. So long, etc... Signed-off-by:
-
Michal Simek authored
microblaze-uclinux mailing list is almost dead and it is just causing troubles for non subscribers which are getting email about waiting for moderator. Approval never happens. Move it to LKML. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Reported-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
-
