There's some odd bug in gcc-4.2 where it miscompiles a simple loop whent
he loop counter is of type 'unsigned char' and it should count to 128.
The compiler will incorrectly decide that a trivial loop like this:
unsigned char i, ...
for (i = 0; i < 128; i++) {
..
is endless, and will compile it to a single instruction that just
branches to itself.
This was triggered by the addition of '-fno-strict-overflow', and we
could play games with compiler versions and go back to '-fwrapv'
instead, but the trivial way to avoid it is to just make the loop
induction variable be an 'int' instead.
Thanks to Krzysztof Oledzki for reporting and testing and to Troy Moure
for digging through assembler differences and finding it.
Reported-and-tested-by: Krzysztof Oledzki <olel@ans.pl>
Found-by: Troy Moure <twmoure@szypr.net>
Gcc-bug-acked-by: Ian Lance Taylor <iant@google.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The connector documentation states that the argument to the callback
function is always a pointer to a struct cn_msg, but rather than encode it
in the API itself, it uses a void pointer everywhere. This doesn't make
much sense to encode the pointer in documentation as it prevents proper C
type checking from occurring and can easily allow people to use the wrong
pointer type. So convert the argument type to an explicit struct cn_msg
pointer.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Users get confused by this driver. It's really a special purpose
embedded driver, and causes a lot of problems if enabled. So hide it
under EMBEDDED by default, and make sure it doesn't get enabled with
the i915 DRM driver.
Dave, I'm hoping you can feed this to Linus through your tree. It's
appropriate for 2.6.31 I think.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT
This will make hardirq.h inclusion cheaper for every PREEMPT=n config
(which includes allmodconfig/allyesconfig, BTW)
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove call to the mx3fb_set_par() and the mx3fb_blank() before the
register_framebuffer().
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove call to the fb_set_par() before the register_framebuffer().
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove not needed locking of the fb_info->mm_lock mutex before a
frambuffer is registered.
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove call to the fsl_diu_set_par before the register_framebuffer().
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Tested-by: "Kai Jiang" <b18973@freescale.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 5fd29d6ccb ("printk: clean up
handling of log-levels and newlines") changed printk semantics. printk
lines with multiple KERN_<level> prefixes are no longer emitted as
before the patch.
<level> is now included in the output on each additional use.
Remove all uses of multiple KERN_<level>s in formats.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 4148df9b0f.
Let's hope that the mm_lock initialization is now correct with all
drivers, following Krzysztof's patches.
Requested-by: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove redundant locking by the mm_lock mutex before a second head of
matrox framebuffer is registered.
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove redundant call to the matroxfb_update_fix() before matrox
frambuffer is registered.
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove redundant call to the w100fb_set_par() before w100 frambuffer is
registered.
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove redundant locking of the fb_info->mm_lock mutex before the
frambuffer is registered.
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove redundant call to the encode_fix() before i810 frambuffer is
registered.
This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf059 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>