- 04 Oct, 2008 10 commits
-
-
Sven Wegener authored
On initialization, we first do the ioremap and then register the led devices. On deinitialization, we do it in reverse order. This prevents someone calling into the brightness_set functions with an invalid latch_address. Signed-off-by:
Sven Wegener <sven.wegener@stealer.net> Acked-by:
Rod Whitby <rod@whitby.id.au> Acked-by:
Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Haavard Skinnemoen authored
The tasklet checks RAW.BLOCK twice, and does not check RAW.XFER. This is obviously wrong, and could theoretically cause the driver to hang. Reported-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Acked-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Michael Kerrisk authored
The "Documentation" section of this file mentions that when an interface change is made, I should be CCed with info about the change (so that man-pages can document it). Additionally request that this info be CCed to the new linux-api@vger.kernel.org list. Signed-off-by:
Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by:
-
Michael Kerrisk authored
Mention that patches that change the kernel-userland interface should be CCed to the new list linux-api@vger.kernel.org. Signed-off-by:
-
Michael Kerrisk authored
Nowadays, man-pages has an associated mailing list. Mention that list in MAINTAINERS. Signed-off-by:
-
Paul Jackson authored
Remove myself from the kernel MAINTAINERS file for cpusets. I am leaving SGI and probably will not be active in Linux kernel work. I can be reached at <pj@usa.net>. Contact Derek Fults <dfults@sgi.com> for future SGI+cpuset related issues. I'm off to the next chapter of this good life. Signed-off-by:
Paul Jackson <pj@sgi.com> Cc: Paul Menage <menage@google.com> Cc: Derek Fults <dfults@sgi.com> Cc: John Hesterberg <jh@sgi.com> Cc: Paul Jackson <pj@usa.net> Signed-off-by:
-
Andrew Morton authored
include/linux/stacktrace.h:13: warning: 'struct task_struct' declared inside parameter list (This might be a hard error on sparc64, which uses this header and has -Werror) Reported-by:
"Randy.Dunlap" <rdunlap@xenotime.net> Acked-by:
Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by:
-
Lennert Buytenhek authored
Accept zero (the default!) as a per-transfer clock speed override. Signed-off-by:
Lennert Buytenhek <buytenh@marvell.com> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Krzysztof Helt authored
Fix infinite recursive notifier in the fbdev layer. This causes recursive locking. Dmitry Baryshkov found the problem and confirmed that the patch fixes the bug. After doing # echo 1 > /sys/class/graphics/fb0/blank I got the following in my kernel log: ============================================= [ INFO: possible recursive locking detected ] 2.6.27-rc6-00086-gda63874-dirty #97 --------------------------------------------- echo/1564 is trying to acquire lock: ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c but task is already holding lock: ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c other info that might help us debug this: 2 locks held by echo/1564: #0: (&buffer->mutex){--..}, at: [<c00ddde0>] sysfs_write_file+0x30/0x80 #1: ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c stack backtrace: [<c0029fe4>] (dump_stack+0x0/0x14) from [<c0060ce0>] (print_deadlock_bug+0xa4/0xd0) [<c0060c3c>] (print_deadlock_bug+0x0/0xd0) from [<c0060e54>] (check_deadlock+0x148/0x17c) r6:c397a1e0 r5:c397a530 r4:c04fcf98 [<c0060d0c>] (check_deadlock+0x0/0x17c) from [<c00637e8>] (validate_chain+0x3c4/0x4f0) [<c0063424>] (validate_chain+0x0/0x4f0) from [<c0063efc>] (__lock_acquire+0x5e8/0x6b4) [<c0063914>] (__lock_acquire+0x0/0x6b4) from [<c006402c>] (lock_acquire+0x64/0x78) [<c0063fc8>] (lock_acquire+0x0/0x78) from [<c0316ca8>] (down_read+0x4c/0x60) r7:00000009 r6:ffffffff r5:c0427a40 r4:c005a384 [<c0316c5c>] (down_read+0x0/0x60) from [<c005a384>] (__blocking_notifier_call_chain+0x38/0x6c) r5:c0427a40 r4:c0427a74 [<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28) r8:00000009 r7:c086d640 r6:c3967940 r5:00000000 r4:c38984b8 [<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24) [<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70) [<c014c128>] (fb_blank+0x0/0x70) from [<c0155978>] (fbcon_blank+0x114/0x1bc) r5:00000001 r4:c38984b8 [<c0155864>] (fbcon_blank+0x0/0x1bc) from [<c0170ea8>] (do_blank_screen+0x1e0/0x2a0) [<c0170cc8>] (do_blank_screen+0x0/0x2a0) from [<c0154024>] (fbcon_fb_blanked+0x74/0x94) r5:c3967940 r4:00000001 [<c0153fb0>] (fbcon_fb_blanked+0x0/0x94) from [<c0154228>] (fbcon_event_notify+0x100/0x12c) r5:fffffffe r4:c39bc194 [<c0154128>] (fbcon_event_notify+0x0/0x12c) from [<c005a0d4>] (notifier_call_chain+0x38/0x7c) [<c005a09c>] (notifier_call_chain+0x0/0x7c) from [<c005a3a0>] (__blocking_notifier_call_chain+0x54/0x6c) r8:c3b51ea0 r7:00000009 r6:ffffffff r5:c0427a40 r4:c0427a74 [<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28) r8:00000001 r7:c3a7e000 r6:00000000 r5:00000000 r4:c38984b8 [<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24) [<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70) [<c014c128>] (fb_blank+0x0/0x70) from [<c014e450>] (store_blank+0x54/0x7c) r5:c38984b8 r4:c3b51ec4 [<c014e3fc>] (store_blank+0x0/0x7c) from [<c017981c>] (dev_attr_store+0x28/0x2c) r8:00000001 r7:c042bf80 r6:c39eba10 r5:c3967c30 r4:c38e0140 [<c01797f4>] (dev_attr_store+0x0/0x2c) from [<c00ddaac>] (flush_write_buffer+0x54/0x68) [<c00dda58>] (flush_write_buffer+0x0/0x68) from [<c00dde08>] (sysfs_write_file+0x58/0x80) r8:c3b51f78 r7:c3bcb070 r6:c39eba10 r5:00000001 r4:00000001 [<c00dddb0>] (sysfs_write_file+0x0/0x80) from [<c009de04>] (vfs_write+0xb8/0x148) [<c009dd4c>] (vfs_write+0x0/0x148) from [<c009e384>] (sys_write+0x44/0x70) r7:00000004 r6:c3bcb070 r5:00000000 r4:00000000 [<c009e340>] (sys_write+0x0/0x70) from [<c0025d00>] (ret_fast_syscall+0x0/0x2c) r6:4001b000 r5:00000001 r4:401dc658 Signed-off-by:Krzysztof Helt <krzysztof.h1@wp.pl> Reported-by:
Dmitry Baryshkov <dbaryshkov@gmail.com> Testted-by:
-
Marcin Slusarz authored
When userspace uses SIGIO notification and forgets to disable it before closing file descriptor, rtc->async_queue contains stale pointer to struct file. When user space enables again SIGIO notification in different process, kernel dereferences this (poisoned) pointer and crashes. So disable SIGIO notification on close. Kernel panic: (second run of qemu (requires echo 1024 > /sys/class/rtc/rtc0/max_user_freq)) general protection fault: 0000 [1] PREEMPT CPU 0 Modules linked in: af_packet snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq usbhid tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 tda9875 uhci_hcd ehci_hcd usbcore bttv snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer ir_common compat_ioctl32 snd_page_alloc videodev v4l1_compat snd_mpu401_uart snd_rawmidi v4l2_common videobuf_dma_sg videobuf_core snd_seq_device snd btcx_risc soundcore tveeprom i2c_viapro Pid: 5781, comm: qemu-system-x86 Not tainted 2.6.27-rc6 #363 RIP: 0010:[<ffffffff8024f891>] [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f RSP: 0000:ffffffff80674cb8 EFLAGS: 00010002 RAX: ffff8800224c62f0 RBX: 0000000000000046 RCX: 0000000000000002 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800224c62f0 RBP: ffffffff80674d08 R08: 0000000000000002 R09: 0000000000000001 R10: ffffffff80238941 R11: 0000000000000001 R12: 0000000000000000 R13: 6b6b6b6b6b6b6b6b R14: ffff88003a450080 R15: 0000000000000000 FS: 00007f98b69516f0(0000) GS:ffffffff80623200(0000) knlGS:00000000f7cc86d0 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000a87000 CR3: 0000000022598000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process qemu-system-x86 (pid: 5781, threadinfo ffff880028812000, task ffff88003a450080) Stack: ffffffff80674cf8 0000000180238440 0000000200000002 0000000000000000 ffff8800224c62f0 0000000000000046 0000000000000000 0000000000000002 0000000000000002 0000000000000000 ffffffff80674d68 ffffffff8024fc7a Call Trace: <IRQ> [<ffffffff8024fc7a>] lock_acquire+0x85/0xa9 [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184 [<ffffffff80491d1f>] _read_lock+0x3e/0x4a [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184 [<ffffffff8029cb62>] send_sigio+0x2a/0x184 [<ffffffff8024fb97>] ? __lock_acquire+0x6e1/0x73f [<ffffffff8029cd4d>] ? kill_fasync+0x2c/0x4e [<ffffffff8029cd10>] __kill_fasync+0x54/0x65 [<ffffffff8029cd5b>] kill_fasync+0x3a/0x4e [<ffffffff80402896>] rtc_update_irq+0x9c/0xa5 [<ffffffff80404640>] cmos_interrupt+0xae/0xc0 [<ffffffff8025d1c1>] handle_IRQ_event+0x25/0x5a [<ffffffff8025e5e4>] handle_edge_irq+0xdd/0x123 [<ffffffff8020da34>] do_IRQ+0xe4/0x144 [<ffffffff8020bad6>] ret_from_intr+0x0/0xf <EOI> [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad [<ffffffff8033fe67>] ? clear_page_c+0x7/0x10 [<ffffffff8026fc10>] ? get_page_from_freelist+0x385/0x450 [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad [<ffffffff80280aac>] ? anon_vma_prepare+0x2e/0xf6 [<ffffffff80279400>] ? handle_mm_fault+0x227/0x6a5 [<ffffffff80494716>] ? do_page_fault+0x494/0x83f [<ffffffff8049251d>] ? error_exit+0x0/0xa9 Code: cc 41 39 45 28 74 24 e8 5e 1d 0f 00 85 c0 0f 84 6a 03 00 00 83 3d 8f a9 aa 00 00 be 47 03 00 00 0f 84 6a 02 00 00 e9 53 03 00 00 <41> ff 85 38 01 00 00 45 8b be 90 06 00 00 41 83 ff 2f 76 24 e8 RIP [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f RSP <ffffffff80674cb8> ---[ end trace 431877d860448760 ]--- Kernel panic - not syncing: Aiee, killing interrupt handler! Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Acked-by:
Alessandro Zummo <alessandro.zummo@towertech.it> Acked-by:
-
- 03 Oct, 2008 18 commits
-
-
git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds authored
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] SMTC: Fix SMTC dyntick support. [MIPS] SMTC: Close tiny holes in the SMTC IPI replay system. [MIPS] SMTC: Fix holes in SMTC and FPU affinity support. [MIPS] SMTC: Build fix: Fix filename in Makefile [MIPS] Build fix: Fix irq flags type
-
git://git390.osdl.marist.edu/pub/scm/linux-2.6Linus Torvalds authored
* 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6: [S390] qdio: prevent stack clobber [S390] nohz: Fix __udelay.
-
Linus Torvalds authored
.. small detail, but the silly e1000e initcall warning debugging caused me to look at this code. Rather than gouge my eyes out with a spoon, I just fixed it. Signed-off-by: -
Jan Glauber authored
Don't print more information than fits into the string on the stack. Combine the informational output of qdio to fit into one line. Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Heiko Carstens authored
This fixes a regression that came with 934b2857 ("[S390] nohz/sclp: disable timer on synchronous waits."). If udelay() gets called from a disabled context it sets the clock comparator to a value where it expects the next interrupt. When the interrupt happens the clock comparator gets not reset and therefore the interrupt condition doesn't get cleared. The result is an endless timer interrupt loop. In addition this patch fixes also the following: rcutorture reveals that our __udelay implementation is still buggy, since it might schedule tasklets, but prevents their execution: NOHZ: local_softirq_pending 42 NOHZ: local_softirq_pending 02 NOHZ: local_softirq_pending 142 NOHZ: local_softirq_pending 02 To fix this we make sure that only the clock comparator interrupt is enabled when the enabled wait psw is loaded. Also no code gets called anymore which might schedule tasklets. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Kevin D. Kissell authored
Rework of SMTC support to make it work with the new clock event system, allowing "tickless" operation, and to make it compatible with the use of the "wait_irqoff" idle loop. The new clocking scheme means that the previously optional IPI instant replay mechanism is now required, and has been made more robust. Signed-off-by:
Kevin D. Kissell <kevink@paralogos.com> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Kevin D. Kissell authored
Signed-off-by:
-
Kevin D. Kissell authored
Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Though from a hardware perspective it would be sensible to use only a 32-bit unsigned int type Linux defines interrupt flags to be stored in an unsigned long and nothing else. Signed-off-by: -
Linus Torvalds authored
Doing 'WARN_ON(preempt_count())' was horribly horribly wrong, and would cause tons of warnings at bootup if PREEMPT was enabled because the initcalls currently run with the kernel lock, which increments the preempt count. At the same time, the warning was also insufficient, since it didn't check that interrupts were enabled. The proper debug function to use for something that can sleep and wants a warning if it's called in the wrong context is 'might_sleep()'. Reported-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Linus Torvalds authored
This is loosely based on a patch by Jesse Barnes to check the user-space PCI mappings though the sysfs interfaces. Quoting Jesse's original explanation: It's fairly common for applications to map PCI resources through sysfs. However, with the current implementation, it's possible for an application to map far more than the range corresponding to the resourceN file it opened. This patch plugs that hole by checking the range at mmap time, similar to what is done on platforms like sparc64 in their lower level PCI remapping routines. It was initially put together to help debug the e1000e NVRAM corruption problem, since we initially thought an X driver might be walking past the end of one of its mappings and clobbering the NVRAM. It now looks like that's not the case, but doing the check is still important for obvious reasons. and this version of the patch differs in that it uses a helper function to clarify the code, and does all the checks in pages (instead of bytes) in order to avoid overflows when doing "<< PAGE_SHIFT" etc. Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jesse Brandeburg authored
Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
Thomas Gleixner authored
This patch adds a mutex to the e1000e driver that would help catch any collisions of two e1000e threads accessing hardware at the same time. description and patch updated by Jesse Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jesse Brandeburg authored
the stats lock is left over from e1000, e1000e no longer has the adjust tbi stats function that required the addition of the stats lock to begin with. adding a mutex to acquire_swflag helped catch this one too. Signed-off-by:
-
Jesse Brandeburg authored
thanks to tglx, we're finding some interesting reentrancy issues. this patch removes the phy read from inside a spinlock, paving the way for removing the spinlock completely. The phy read was only feeding a statistic that wasn't used. Signed-off-by:
-
Jesse Brandeburg authored
e1000e was apparently calling two functions that attempted to reserve the SWFLAG bit for exclusive (to hardware and firmware) access to the PHY and NVM (aka eeprom). These accesses could possibly call msleep to wait for the resource which is not allowed from interrupt context. Signed-off-by:
-
Jesse Brandeburg authored
in the process of debugging things, noticed that the swflag is not reset by the driver after reset, and the swflag is probably not reset unless management firmware clears it after 100ms. Signed-off-by:
-
- 02 Oct, 2008 12 commits
-
-
Andy Whitcroft authored
When we initialise a compound page we initialise the page flags and head page pointer for all base pages spanned by that page. When we initialise a gigantic page (a page of order greater than or equal to MAX_ORDER) we have to initialise more than MAX_ORDER_NR_PAGES pages. Currently we assume that all elements of the mem_map in this page are contigious in memory. However this is only guarenteed out to MAX_ORDER_NR_PAGES pages, and with SPARSEMEM enabled they will not be contigious. This leads us to walk off the end of the first section and scribble on everything which follows, BAD. When we reach a MAX_ORDER_NR_PAGES boundary we much locate the next section of the mem_map. As gigantic pages can only be maximally aligned we know this will occur at exact multiple of MAX_ORDER_NR_PAGES pages from the start of the page. This is a bug fix for the gigantic page support in hugetlbfs. Credit to Mel Gorman for spotting the issue. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Jon Tollefson <kniht@linux.vnet.ibm.com> Signed-off-by:
-
Nick Piggin authored
The previous patch db203d53 ("mm: tiny-shmem fix lock ordering: mmap_sem vs i_mutex") to fix the lock ordering in tiny-shmem breaks shared anonymous and IPC memory on NOMMU architectures because it was using the expanding truncate to signal ramfs to allocate a physically contiguous RAM backing the inode (otherwise it is unusable for "memory mapping" it to userspace). However do_truncate is what caused the lock ordering error, due to it taking i_mutex. In this case, we can actually just call ramfs directly to allocate memory for the mapping, rather than go via truncate. Acked-by:
David Howells <dhowells@redhat.com> Acked-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
Nick Piggin <npiggin@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Gerald Schaefer authored
__test_page_isolated_in_pageblock() in mm/page_isolation.c has a comment saying that the caller must hold zone->lock. But the only caller of that function, test_pages_isolated(), does not hold zone->lock and the lock is also not acquired anywhere before. This patch adds the missing zone->lock to test_pages_isolated(). We reproducibly run into BUG_ON(!PageBuddy(page)) in __offline_isolated_pages() during memory hotplug stress test, see trace below. This patch fixes that problem, it would be good if we could have it in 2.6.27. kernel BUG at /home/autobuild/BUILD/linux-2.6.26-20080909/mm/page_alloc.c:4561! illegal operation: 0001 [#1] PREEMPT SMP Modules linked in: dm_multipath sunrpc bonding qeth_l3 dm_mod qeth ccwgroup vmur CPU: 1 Not tainted 2.6.26-29.x.20080909-s390default #1 Process memory_loop_all (pid: 10025, task: 2f444028, ksp: 2b10dd28) Krnl PSW : 040c0000 801727ea (__offline_isolated_pages+0x18e/0x1c4) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 Krnl GPRS: 00000000 7e27fc00 00000000 7e27fc00 00000000 00000400 00014000 7e27fc01 00606f00 7e27fc00 00013fe0 2b10dd28 00000005 80172662 801727b2 2b10dd28 Krnl Code: 801727de: 5810900c l %r1,12(%r9) 801727e2: a7f4ffb3 brc 15,80172748 801727e6: a7f40001 brc 15,801727e8 >801727ea: a7f4ffbc brc 15,80172762 801727ee: a7f40001 brc 15,801727f0 801727f2: a7f4ffaf brc 15,80172750 801727f6: 0707 bcr 0,%r7 801727f8: 0017 unknown Call Trace: ([<0000000000172772>] __offline_isolated_pages+0x116/0x1c4) [<00000000001953a2>] offline_isolated_pages_cb+0x22/0x34 [<000000000013164c>] walk_memory_resource+0xcc/0x11c [<000000000019520e>] offline_pages+0x36a/0x498 [<00000000001004d6>] remove_memory+0x36/0x44 [<000000000028fb06>] memory_block_change_state+0x112/0x150 [<000000000028ffb8>] store_mem_state+0x90/0xe4 [<0000000000289c00>] sysdev_store+0x34/0x40 [<00000000001ee048>] sysfs_write_file+0xd0/0x178 [<000000000019b1a8>] vfs_write+0x74/0x118 [<000000000019b9ae>] sys_write+0x46/0x7c [<000000000011160e>] sysc_do_restart+0x12/0x16 [<0000000077f3e8ca>] 0x77f3e8ca Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Dan Carpenter authored
Found by static checker (http://repo.or.cz/w/smatch.git). Signed-off-by:
Dan Carpenter <error27@gmail.com> Acked-by:
-
Pascal Terjan authored
Only register the braille driver VT and keyboard notifiers when the braille console is used. Avoids eating insert or backspace keys. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11242Signed-off-by:
Pascal Terjan <pterjan@mandriva.com> Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: <stable@kernel.org> Signed-off-by:
-
Nick Piggin authored
Fix inotify lock order reversal with mmap_sem due to holding locks over copy_to_user. Signed-off-by:
"Daniel J Blueman" <daniel.blueman@gmail.com> Tested-by:
-
David Winn authored
Commit 22af89aa ("fbcon: replace mono_col macro with static inline") changed the order of operations for computing monochrome color values. This generates 0xffff000f instead of 0x0000000f for a 4 bit monochrome color, leading to image corruption if it is passed to cfb_imageblit or other similar functions. Fix it up. Cc: Harvey Harrison <harvey.harrison@gmail.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: <stable@kernel.org> [2.6.26.x] Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6: ALSA: snd-powermac: HP detection for 1st iMac G3 SL ALSA: snd-powermac: mixers for PowerMac G4 AGP ASoC: Set correct name for WM8753 rec mixer output
-
Takashi Iwai authored
-
Risto Suominen authored
Correct headphone detection for 1st generation iMac G3 Slot-loading (Screamer). This patch fixes the regression in the recent snd-powermac which doesn't support some G3/G4 PowerMacs: http://lkml.org/lkml/2008/10/1/220Signed-off-by:Risto Suominen <Risto.Suominen@gmail.com> Tested-by:
Mariusz Kozlowski <m.kozlowski@tuxland.pl> Cc: stable@kernel.org Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Risto Suominen authored
Add mixer controls for PowerMac G4 AGP (Screamer). This patch fixes the regression in the recent snd-powermac which doesn't support some G3/G4 PowerMacs: http://lkml.org/lkml/2008/10/1/220Signed-off-by: -
Rob Sims authored
Rob Sims wrote: "I can't seem to turn on register 0x17, bit 3 in the sound chip, except by codec_reg_write; the mixer lacks direct or indirect control. It seems there are two names for the output of the rec mixer: Capture ST Mixer Playback Mixer Would the following do the trick?" I confirm that this solves the audio problems I was having. Signed-off-by:
Jonas Bonn <jonas.bonn@gmail.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
