- 03 Apr, 2014 40 commits
-
-
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 <joe@perches.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
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:
Josh Triplett <josh@joshtriplett.org> Signed-off-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:
-
Opensource [Steve Twiss] authored
Dialog Semiconductor Ltd would like to add a new section called DIALOG SEMICONDUCTOR DRIVERS which contains a new e-mail address that can cover all Dialog supported drivers: support.opensource@diasemi.com. Signed-off-by:
Opensource [Steve Twiss] <stwiss.opensource@diasemi.com> Signed-off-by:
David Dajun Chen <david.chen@diasemi.com> Cc: Mark Brown <broonie@linaro.org> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
Mark it so. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Signed-off-by:
-
Max Filippov authored
Now that irqchip drivers for xtensa live outside arch/xtensa we'd like to add them to our maintenance list. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Cc: Chris Zankel <chris@zankel.net> Cc: Marc Gauthier <marc@cadence.com> Signed-off-by:
-
Geert Uytterhoeven authored
Paul Mundt's email address bounces regularly, and he hasn't taken any SuperH patches for about one year. Signed-off-by:
Geert Uytterhoeven <geert+renesas@linux-m68k.org> Suggested-by:
Paul Bolle <pebolle@tiscali.nl> Cc: Paul Mundt <paul.mundt@gmail.com> Cc: Magnus Damm <magnus.damm@gmail.com> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Simon Horman <horms@verge.net.au> Signed-off-by:
-
Jingoo Han authored
Bryan Wu and Lee Jones volunteer to maintain backlight drivers and help to setup git-tree for backlight subsystem. Thus, I add them as backlight co-maintainers. Signed-off-by:
Bryan Wu <cooloney@gmail.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Jane Li authored
Fix a warning about possible circular locking dependency. If do in following sequence: enter suspend -> resume -> plug-out CPUx (echo 0 > cpux/online) lockdep will show warning as following: ====================================================== [ INFO: possible circular locking dependency detected ] 3.10.0 #2 Tainted: G O ------------------------------------------------------- sh/1271 is trying to acquire lock: (console_lock){+.+.+.}, at: console_cpu_notify+0x20/0x2c but task is already holding lock: (cpu_hotplug.lock){+.+.+.}, at: cpu_hotplug_begin+0x2c/0x58 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (cpu_hotplug.lock){+.+.+.}: lock_acquire+0x98/0x12c mutex_lock_nested+0x50/0x3d8 cpu_hotplug_begin+0x2c/0x58 _cpu_up+0x24/0x154 cpu_up+0x64/0x84 smp_init+0x9c/0xd4 kernel_init_freeable+0x78/0x1c8 kernel_init+0x8/0xe4 ret_from_fork+0x14/0x2c -> #1 (cpu_add_remove_lock){+.+.+.}: lock_acquire+0x98/0x12c mutex_lock_nested+0x50/0x3d8 disable_nonboot_cpus+0x8/0xe8 suspend_devices_and_enter+0x214/0x448 pm_suspend+0x1e4/0x284 try_to_suspend+0xa4/0xbc process_one_work+0x1c4/0x4fc worker_thread+0x138/0x37c kthread+0xa4/0xb0 ret_from_fork+0x14/0x2c -> #0 (console_lock){+.+.+.}: __lock_acquire+0x1b38/0x1b80 lock_acquire+0x98/0x12c console_lock+0x54/0x68 console_cpu_notify+0x20/0x2c notifier_call_chain+0x44/0x84 __cpu_notify+0x2c/0x48 cpu_notify_nofail+0x8/0x14 _cpu_down+0xf4/0x258 cpu_down+0x24/0x40 store_online+0x30/0x74 dev_attr_store+0x18/0x24 sysfs_write_file+0x16c/0x19c vfs_write+0xb4/0x190 SyS_write+0x3c/0x70 ret_fast_syscall+0x0/0x48 Chain exists of: console_lock --> cpu_add_remove_lock --> cpu_hotplug.lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(cpu_hotplug.lock); lock(cpu_add_remove_lock); lock(cpu_hotplug.lock); lock(console_lock); *** DEADLOCK *** There are three locks involved in two sequence: a) pm suspend: console_lock (@suspend_console()) cpu_add_remove_lock (@disable_nonboot_cpus()) cpu_hotplug.lock (@_cpu_down()) b) Plug-out CPUx: cpu_add_remove_lock (@(cpu_down()) cpu_hotplug.lock (@_cpu_down()) console_lock (@console_cpu_notify()) => Lockdeps prints warning log. There should be not real deadlock, as flag of console_suspended can protect this. Although console_suspend() releases console_sem, it doesn't tell lockdep about it. That results in the lockdep warning about circular locking when doing the following: enter suspend -> resume -> plug-out CPUx (echo 0 > cpux/online) Fix the problem by telling lockdep we actually released the semaphore in console_suspend() and acquired it again in console_resume(). Signed-off-by:Jane Li <jiel@marvell.com> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Simon Kågström authored
The double asmlinkage was introduced in commit 7ff9554b ("printk: convert byte-buffer to variable-length record buffer"). Signed-off-by:
Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by:
-
Petr Mladek authored
This is just a tiny optimization. It removes duplicate computation of the message size. Signed-off-by:
Petr Mladek <pmladek@suse.cz> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jan Kara <jack@suse.cz> Cc: Michal Hocko <mhocko@suse.cz> Cc: Kay Sievers <kay@vrfy.org> Signed-off-by:
-
Petr Mladek authored
It seems that we have newer used the last byte in the ring buffer. In fact, we have newer used the last 4 bytes because of padding. First problem is in the check for free space. The exact number of free bytes is enough to store the length of data. Second problem is in the check where the ring buffer is rotated. The left side counts the first unused index. It is unused, so it might be the same as the size of the buffer. Note that the first problem has to be fixed together with the second one. Otherwise, the buffer is rotated even when there is enough space on the end of the buffer. Then the beginning of the buffer is rewritten and valid entries get corrupted. Signed-off-by:
-
Petr Mladek authored
There is no check for potential "text_len" overflow. It is not needed because only valid level is detected. It took me some time to understand why. It would deserve a comment ;-) Signed-off-by:
-
Petr Mladek authored
The kernel log level "c" was removed in commit 61e99ab8 ("printk: remove the now unnecessary "C" annotation for KERN_CONT"). It is no longer detected in printk_get_level(). Hence we do not need to check it in vprintk_emit. Signed-off-by:
-
Petr Mladek authored
The check for the exact log level is already done in printk_get_level. We do not need to duplicate it in printk_skip_level. Signed-off-by:
-
Ryan Mallon authored
All in-kernel users of %n in format strings have now been removed and the %n directive is ignored. Remove the handling of %n so that it is treated the same as any other invalid format string directive. Keep a warning in place to deter new instances of %n in format strings. Signed-off-by:
Ryan Mallon <rmallon@gmail.com> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
![Opensource [Steve Twiss]'s avatar](https://secure.gravatar.com/avatar/8bfdd5af09bcb6e4ec372c6dcf8f4491?s=80&d=identicon "Opensource [Steve Twiss]")
