Akinobu Mita [Tue, 26 Jul 2011 10:14:46 +0000 (20:14 +1000)]
ext4_{set,clear}_bit() is defined as __test_and_{set,clear}_bit_le() for
ext4. Only two ext4_{set,clear}_bit() calls check the return value. The
rest of calls ignore the return value and they can be replaced with
__{set,clear}_bit_le().
This changes ext4_{set,clear}_bit() from __test_and_{set,clear}_bit_le()
to __{set,clear}_bit_le() and introduces ext4_test_and_{set,clear}_bit()
for the two places where old bit needs to be returned.
This ext4_{set,clear}_bit() change is considered safe, because if someone
uses these macros without noticing the change, new ext4_{set,clear}_bit
don't have return value and causes compiler errors where the return value
is used.
This also removes unused ext4_find_first_zero_bit().
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Andreas Dilger <adilger.kernel@dilger.ca> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrew Morton [Tue, 26 Jul 2011 10:14:46 +0000 (20:14 +1000)]
i386 allmodconfig:
drivers/built-in.o: In function `aat2870_bl_remove':
aat2870_bl.c:(.text+0x414f9): undefined reference to `backlight_device_unregister'
drivers/built-in.o: In function `aat2870_bl_probe':
aat2870_bl.c:(.text+0x418fc): undefined reference to `backlight_device_register'
aat2870_bl.c:(.text+0x41a31): undefined reference to `backlight_device_unregiste
Cc: Jin Park <jinyoungp@nvidia.com> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Axel Lin <axel.lin@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Axel Lin [Tue, 26 Jul 2011 10:14:45 +0000 (20:14 +1000)]
1. current implementation tests wrong value for setting aat2870_bl->max_current.
2. In current implementation, we cannot differentiate below 2 cases:
a) if pdata->max_current is not set , or
b) pdata->max_current is set to AAT2870_CURRENT_0_45 ( which is also 0 ).
fix it by setting AAT2870_CURRENT_0_45 to be 1 and adjust the equation
in aat2870_brightness() accordingly.
Signed-off-by: Axel Lin <axel.lin@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Samuel Ortiz <sameo@linux.intel.com> Tested-by: Jin Park <jinyoungp@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Axel Lin [Tue, 26 Jul 2011 10:14:45 +0000 (20:14 +1000)]
backlight_device_register() returns ERR_PTR() on error.
Signed-off-by: Axel Lin <axel.lin@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jin Park <jinyoungp@nvidia.com> Cc: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Mark Brown [Tue, 26 Jul 2011 10:14:44 +0000 (20:14 +1000)]
Unless I'm very much missing something these tests are intended to check
if bit zero is set, rather than checking if msk is entirely zero (in which
case the logic would be very confusing. I haven't actually observed any
runtime issues so this may be a misreading of the code on my part.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrea Righi [Tue, 26 Jul 2011 10:14:44 +0000 (20:14 +1000)]
fb_set_suspend() must be called with the console semaphore held, which
means the code path coming in here will first take the console_lock() and
then call lock_fb_info().
However several framebuffer ioctl commands acquire these locks in reverse
order (lock_fb_info() and then console_lock()). This gives rise to
potential AB-BA deadlock.
Fix this by changing the order of acquisition in the ioctl commands that
make use of console_lock().
Signed-off-by: Andrea Righi <arighi@develer.com> Reported-by: Peter Nordström (Palm GBU) <peter.nordstrom@palm.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The buffer 'sc.cpu_mask' is a kernel buffer. If bitmap_parse is used
instead of __bitmap_parse the extra parameter that indicates a kernel
buffer is not needed.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Lars Ellenberg <drbd-dev@lists.linbit.com> Cc: Philipp Reisner <philipp.reisner@linbit.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
A call to va_copy() should always be followed by a call to va_end() in the
same function. In kernel/autit.c::audit_log_vformat() this is not always
done. This patch makes sure va_end() is always called.
Signed-off-by: Jesper Juhl <jj@chaosbits.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The address limit is already set in flush_old_exec() so this
set_fs(USER_DS) is redundant.
Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Ed Wildgoose [Tue, 26 Jul 2011 10:14:38 +0000 (20:14 +1000)]
This new driver replaces the old PCEngines Alix 2/3 LED driver with a new
driver that controls the LEDs through the leds-gpio driver. The old
driver accessed GPIOs directly, which created a conflict and prevented
also loading the cs5535-gpio driver to read other GPIOs on the Alix board.
With this new driver, we hook into leds-gpio which in turn uses GPIO to
control the LEDs and therefore it's possible to control both the LEDs and
access onboard GPIOs
Driver is moved to platform/geode and any other geode initialisation
modules should move here also.
This driver is inspired by leds-net5501.c by Alessandro Zummo.
Ideally, leds-net5501.c should also be moved to platform/geode.
Additionally the driver relies on parts of the patch: 7f131cf3ed ("leds:
leds-alix2c - take port address from MSR) by Daniel Mack to perform
detection of the Alix board.
Signed-off-by: Ed Wildgoose <kernel@wildgooses.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Daniel Mack <daniel@caiaq.de> Reviewed-by: Grant Likely <grant.likely@secretlab.ca> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Ludwig Nussel [Tue, 26 Jul 2011 10:14:38 +0000 (20:14 +1000)]
On x86_32 casting the unsigned int result of get_random_int() to long may
result in a negative value. On x86_32 the range of mmap_rnd() therefore
was -255 to 255. The 32bit mode on x86_64 used 0 to 255 as intended.
The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c") in January
2008.
Signed-off-by: Ludwig Nussel <ludwig.nussel@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
There was one code block that I commented to be able to test the patch dnd
then forgot to uncomment again, and then you removed it but it should
actually have been uncommented rather than removed. So here is the patch
tat corrects the code, to be applied on top of your own patch.
Cc: Len Brown <lenb@kernel.org> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrew Morton [Tue, 26 Jul 2011 10:14:38 +0000 (20:14 +1000)]
- remove commented-out code
- add missing space to printk
- clean up code layout
Cc: Len Brown <lenb@kernel.org> Cc: Matthew Garrett <mjg@redhat.com> Cc: Shérab <Sebastien.Hinderer@ens-lyon.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This makes the iris driver use the platform API, so it is properly exposed
in /sys.
Signed-off-by: Shérab <Sebastien.Hinderer@ens-lyon.org> Cc: Len Brown <lenb@kernel.org> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Shaohua Li [Tue, 26 Jul 2011 10:14:37 +0000 (20:14 +1000)]
Linux supports some optional features, but it should notify the BIOS about
them via the _OSI method. Currently Linux doesn't notify any, which might
make such features not work because the BIOS doesn't know about them.
Jarosz has a system which needs this to make ACPI processor aggregator
device work.
Reported-by: "Jarosz, Sebastian" <sebastian.jarosz@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Acked-by: Matthew Garrett <mjg@redhat.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jean Delvare [Tue, 26 Jul 2011 10:14:36 +0000 (20:14 +1000)]
THERMAL_HWMON is implemented inside the thermal_sys driver and has no
effect on drivers implementing thermal zones, so they shouldn't see
anything related to it in <linux/thermal.h>. Making the THERMAL_HWMON
implementation fully internal has two advantages beyond the cleaner
design:
* This avoids rebuilding all thermal drivers if the THERMAL_HWMON
implementation changes, or if CONFIG_THERMAL_HWMON gets enabled or
disabled.
* This avoids breaking the thermal kABI in these cases too, which should
make distributions happy.
The only drawback I can see is slightly higher memory fragmentation, as
the number of kzalloc() calls will increase by one per thermal zone. But
I doubt it will be a problem in practice, as I've never seen a system with
more than two thermal zones.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Rene Herman <rene.herman@gmail.com> Cc: Len Brown <len.brown@intel.com> Acked-by: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jean Delvare [Tue, 26 Jul 2011 10:14:36 +0000 (20:14 +1000)]
We'll soon need to reuse it.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Rene Herman <rene.herman@gmail.com> Cc: Len Brown <len.brown@intel.com> Acked-by: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jean Delvare [Tue, 26 Jul 2011 10:14:36 +0000 (20:14 +1000)]
It's about time to revert 16d752397301b9 ("thermal: Create
CONFIG_THERMAL_HWMON=n"). Anybody running a kernel >= 2.6.40 would also
be running a recent enough version of lm-sensors.
Actually having CONFIG_THERMAL_HWMON is pretty convenient so instead of
dropping it, we keep it but hide it.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Rene Herman <rene.herman@gmail.com> Cc: Len Brown <len.brown@intel.com> Acked-by: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrew Morton [Tue, 26 Jul 2011 10:14:36 +0000 (20:14 +1000)]
kernel/time.c:578: error: conflicting types for 'jiffies_to_clock_t'
include/linux/jiffies.h:306: note: previous declaration of 'jiffies_to_clock_t' was here
Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: hank <pyu@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The parameter's origin type is long. On an i386 architecture, it can
easily be larger than 0x80000000, causing this function to convert it to a
sign-extended u64 type. Change the type to unsigned long so we get the
correct result.
Signed-off-by: hank <pyu@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
My load tests on PowerPC freeze within minutes in __slab_free(). I
happened to try PPC first, didn't try without this fix on x86.
It looks as if the author was interrupted while devising the new
cmpxchg_double_slab() version of __slab_free(): its decision to
spin_lock_irqsave() depends on several uninitialized fields, and fixing
that (by copying page to new) mostly fixes it.
But I didn't think about it very much, and this may well not be what the
author intends; and I have seen a couple of much rarer freezes in
__slab_free() on PPC (not yet on x86) even after applying this.
Signed-off-by: Hugh Dickins <hughd@google.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Christoph Lameter <cl@linux.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
WANG Cong [Tue, 26 Jul 2011 10:14:34 +0000 (20:14 +1000)]
arch/cris/arch-v10/kernel/irq.c:239: error: implicit declaration of function 'kgdb_init'
arch/cris/arch-v10/kernel/irq.c:240: error: implicit declaration of function 'breakpoint'
Declare these two functions.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrew Morton [Tue, 26 Jul 2011 10:14:33 +0000 (20:14 +1000)]
WARNING: line over 80 characters
#37: FILE: arch/cris/include/asm/thread_info.h:70:
+#define alloc_thread_info_node(tsk, node) ((struct thread_info *) __get_free_pages(GFP_KERNEL,1))
ERROR: space required after that ',' (ctx:VxV)
#37: FILE: arch/cris/include/asm/thread_info.h:70:
+#define alloc_thread_info_node(tsk, node) ((struct thread_info *) __get_free_pages(GFP_KERNEL,1))
^
total: 1 errors, 1 warnings, 18 lines checked
./patches/cris-fix-a-build-error-in-kernel-forkc.patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
projects / karo-tx-linux.git / log