Jingoo Han [Wed, 20 Mar 2013 04:07:54 +0000 (15:07 +1100)]
drivers/rtc/class.c: use struct device as the first argument for devm_rtc_device_register()
Other devm_* APIs use 'struct device *dev' as the first argument. Thus,
in order to sync with other devm_* functions, struct device is used as the
first argument for devm_rtc_device_register().
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Tejun Heo <tj@kernel.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jingoo Han [Wed, 20 Mar 2013 04:07:54 +0000 (15:07 +1100)]
drivers/rtc/rtc-v3020.c: use gpio_request_array()
Using gpio_request_array()/gpio_free_array() can make the code simpler
because it can set the direction and initial value in one shot and the for
loop is unnecessary.
Also, struct v3020_gpio is removed, because the struct v3020_gpio is
replaced with struct gpio.
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Move the calls to memcpy_fromio() up into the loop in dmi_scan_machine(),
and move the signature checks back down into dmi_decode(). We need to
check at 16-byte intervals but keep a 32-byte buffer for an SMBIOS entry,
so shift the buffer after each iteration.
Merge smbios_present() into dmi_present(), so we look for an SMBIOS
signature at the beginning of the given buffer and then for a DMI
signature at an offset of 16 bytes.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Reported-by: Tim McGrath <tmhikaru@gmail.com> Tested-by: Tim Mcgrath <tmhikaru@gmail.com> Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Steven Rostedt [Wed, 20 Mar 2013 04:07:49 +0000 (15:07 +1100)]
init: scream bloody murder if interrupts are enabled too early
As I was testing a lot of my code recently, and having several
"successes", I accidentally noticed in the dmesg this little line:
[ 0.000000] start_kernel(): bug: interrupts were enabled *very* early, fixing it
Sure enough, one of my patches two commits ago enabled interrupts early.
The sad part here is that I never noticed it, and I ran several tests with
ktest too, and ktest did not notice this line.
What ktest looks for (and so does many other automated testing scripts) is
a back trace produced by a WARN_ON() or BUG(). As a back trace was never
produced, my buggy patch could have slipped into linux-next, or even
worse, mainline.
Adding a WARN(!irqs_disabled()) makes this bug a little more obvious:
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Calgary: detecting Calgary via BIOS EBDA area
[ 0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[ 0.000000] Memory: 2003252k/2054848k available (4857k kernel code, 460k absent, 51136k reserved, 6210k data, 1096k init)
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: at /home/rostedt/work/git/linux-trace.git/init/main.c:543 start_kernel+0x21e/0x415()
[ 0.000000] Hardware name: To Be Filled By O.E.M.
[ 0.000000] Interrupts were enabled *very* early, fixing it
[ 0.000000] Modules linked in:
[ 0.000000] Pid: 0, comm: swapper/0 Not tainted 3.8.0-test+ #286
[ 0.000000] Call Trace:
[ 0.000000] [<ffffffff81037b79>] warn_slowpath_common+0x83/0x9b
[ 0.000000] [<ffffffff81037c34>] warn_slowpath_fmt+0x46/0x48
[ 0.000000] [<ffffffff81ae4a39>] start_kernel+0x21e/0x415
[ 0.000000] [<ffffffff81ae4623>] ? repair_env_string+0x56/0x56
[ 0.000000] [<ffffffff81ae4312>] x86_64_start_reservations+0x10e/0x112
[ 0.000000] [<ffffffff81ae4120>] ? early_idt_handlers+0x120/0x120
[ 0.000000] [<ffffffff81ae4418>] x86_64_start_kernel+0x102/0x111
[ 0.000000] ---[ end trace 007d8b0491b4f5d8 ]---
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[ 0.000000] NR_IRQS:4352 nr_irqs:712 16
[ 0.000000] Console: colour VGA+ 80x25
[ 0.000000] console [ttyS0] enabled, bootconsole disabled
Do you see it?
The original version of this patch just slapped a WARN_ON() in there and
kept the printk(). Ard van Breemen suggested using the WARN() interface,
which makes the code a bit cleaner.
Also, while examining other warnings in init/main.c, I found two other
locations that deserve a bloody murder scream if their conditions are hit,
and updated them accordingly.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Cc: Ard van Breemen <ard@telegraafnet.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").
/*
* Generate 16 random bytes for userspace PRNG seeding.
*/
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));
The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.
With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878
Analyzed by John Sobecki.
Signed-off-by: Jie Liu <jeff.liu@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andreas Dilger <aedilger@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Arnd Bergmann <arnn@arndb.de> Cc: John Sobecki <john.sobecki@oracle.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Eric Wong [Wed, 20 Mar 2013 04:07:48 +0000 (15:07 +1100)]
epoll: cleanup: hoist out f_op->poll calls
This reduces the amount of code inside the ready list iteration loops for
better readability IMHO.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Eric Wong [Wed, 20 Mar 2013 04:07:48 +0000 (15:07 +1100)]
epoll: lock ep->mtx in ep_free to silence lockdep
Technically we do not need to hold ep->mtx during ep_free since we are
certain there are no other users of ep at that point. However, lockdep
complains with a "suspicious rcu_dereference_check() usage!" message; so
lock the mutex before ep_remove to silence the warning.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Arve Hjønnevåg <arve@android.com> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: NeilBrown <neilb@suse.de>, Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Paton J. Lewis [Wed, 20 Mar 2013 04:07:47 +0000 (15:07 +1100)]
epoll: support for disabling items, and a self-test app
It is not currently possible to reliably delete epoll items when using the
same epoll set from multiple threads. After calling epoll_ctl with
EPOLL_CTL_DEL, another thread might still be executing code related to an
event for that epoll item (in response to epoll_wait). Therefore the
deleting thread does not know when it is safe to delete resources
pertaining to the associated epoll item because another thread might be
using those resources.
The deleting thread could wait an arbitrary amount of time after calling
epoll_ctl with EPOLL_CTL_DEL and before deleting the item, but this is
inefficient and could result in the destruction of resources before
another thread is done handling an event returned by epoll_wait.
This patch enhances epoll_ctl to support EPOLL_CTL_DISABLE, which disables
an epoll item. If epoll_ctl returns -EBUSY in this case, then another
thread may handling a return from epoll_wait for this item. Otherwise if
epoll_ctl returns 0, then it is safe to delete the epoll item. This
allows multiple threads to use a mutex to determine when it is safe to
delete an epoll item and its associated resources, which allows epoll
items to be deleted both efficiently and without error in a multi-threaded
environment. Note that EPOLL_CTL_DISABLE is only useful in conjunction
with EPOLLONESHOT, and using EPOLL_CTL_DISABLE on an epoll item without
EPOLLONESHOT returns -EINVAL.
This patch also adds a new test_epoll self-test program to both
demonstrate the need for this feature and test it.
Signed-off-by: Paton J. Lewis <palewis@adobe.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jason Baron <jbaron@redhat.com> Cc: Paul Holland <pholland@adobe.com> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Eric Wong [Wed, 20 Mar 2013 04:07:47 +0000 (15:07 +1100)]
epoll: comment + BUILD_BUG_ON to prevent epitem bloat
This will prevent us from accidentally introducing a memory bloat
regression here in the future.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Cc: Davide Libenzi <davidel@xmailserver.org>, Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrew Morton [Wed, 20 Mar 2013 04:07:47 +0000 (15:07 +1100)]
epoll-trim-epitem-by-one-cache-line-on-x86_64-fix
use __packed, for all architectures
Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Eric Wong <normalperson@yhbt.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Eric Wong [Wed, 20 Mar 2013 04:07:46 +0000 (15:07 +1100)]
epoll: trim epitem by one cache line
It is common for epoll users to have thousands of epitems, so saving a
cache line on every allocation leads to large memory savings.
Since epitem allocations are cache-aligned, reducing sizeof(struct epitem)
from 136 bytes to 128 bytes will allow it to squeeze under a cache line
boundary on x86_64.
Via /sys/kernel/slab/eventpoll_epi, I see the following changes on my
x86_64 Core2 Duo (which has 64-byte cache alignment):
object_size : 192 => 128
objs_per_slab: 21 => 32
Also, add a BUILD_BUG_ON() to check for future accidental breakage.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Joe Perches [Wed, 20 Mar 2013 04:07:45 +0000 (15:07 +1100)]
checkpatch: add check for reuse of krealloc arg
On Thu, 2013-03-14 at 13:30 +0000, David Woodhouse wrote:
> If krealloc() returns NULL, it *doesn't* free the original. So any code
> of the form 'foo = krealloc(foo, …);' is almost certainly a bug.
So add a check for it to checkpatch.
Signed-off-by: Joe Perches <joe@perches.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Guenter Roeck <linux@roeck-us.net> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleg Nesterov [Wed, 20 Mar 2013 04:07:45 +0000 (15:07 +1100)]
argv_split(): teach it to handle mutable strings
argv_split() allocates argv[count_argc(str)] array and assumes that it
will find the same number of arguments later. This is obviously wrong if
this string can be changed, say, by sysctl.
With this patch argv_split() kstrndup's the whole string and does not
split it, we simply replace the spaces with zeroes and keep the allocated
memory in argv[-1] for argv_free(arg).
We do not use argv[0] because:
- str can be all-spaces or empty. In fact this case is fine,
we could kfree() it before return, but:
- str can have a space at the start, and we can not rely on
kstrndup(skip_spaces(str)) because it can equally race if
this string is mutable.
Also, simplify count_argc() and kill the no longer used skip_arg().
drivers/leds/leds-ot200.c: fix error caused by shifted mask
During the development of this driver an in-house register documentation
was used. The last week some integration tests were done and this problem
was found. It turned out that the released register documentation is
wrong.
The fix is very simple: shift all masks by one.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Bryan Wu <cooloney@gmail.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Stefano Babic [Wed, 20 Mar 2013 04:07:43 +0000 (15:07 +1100)]
video: backlight: add ili922x lcd driver
Add LCD driver for Ilitek ILI9221/ILI9222 controller. The driver uses SPI
interface for controller access and configuration and RGB interface for
graphics data transfer.
Signed-off-by: Stefano Babic <sbabic@denx.de> Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Devendra Naga [Wed, 20 Mar 2013 04:07:43 +0000 (15:07 +1100)]
drivers/video/backlight/adp5520_bl.c: fix compiler warning in adp5520_show()
While compiling with make W=1 (gcc gcc (GCC) 4.7.2 20121109 (Red Hat
4.7.2-8)) found the following warning
drivers/video/backlight/adp5520_bl.c: In function `adp5520_show':
drivers/video/backlight/adp5520_bl.c:146:6: warning: variable `error' set but not used [-Wunused-but-set-variable]
fixed by checking the return value of the variable
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Paul Bolle [Wed, 20 Mar 2013 04:07:43 +0000 (15:07 +1100)]
drivers/video/backlight/Kconfig: fix typo "MACH_SAM9...EK" three times
Fix three typos (originally) introduced by a9a84c37d ("atmel_lcdfb:
backlight control").
Two of these typos were introduced in v2.6.25. (The third was introduced
in 915190f7d4f08 ("[ARM] 5614/1: at91: atmel_lcdfb: add at91sam9g10
support to atmel LCD driver")). Checking these commits reveals that the
default value of 'y' has never been set automatically in all releases
since v2.6.25! Perhaps this line might as well be dropped.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Acked-by: Jingoo Han <jg1.han@samsung.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jingoo Han [Wed, 20 Mar 2013 04:07:38 +0000 (15:07 +1100)]
drivers/video/backlight/l4f00242t03.c: check return value of regulator_enable()
regulator_enable() is marked as as __must_check. Therefore the return
value of regulator_enable() should be checked. Also, this patch checks
return value of regulator_set_voltage().
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
projects / karo-tx-linux.git / log