linux/drivers, branch v2.6.25-rc5

bluetooth: Add another Broadcom device

2008-03-07T23:20:03Z

This adds another Broadcom BCM2045 based device to the blacklist, with these settings the micro dongle works on my system. Signed-off-by: Karsten Keil Acked-by: Marcel Holtmann Signed-off-by: Linus Torvalds

ide: update references to Documentation/ide/ide.txt (v2)

2008-03-07T20:53:50Z

Fix all references to Documentation/ide/ide.txt. Add/update ide/00-INDEX file. Signed-off-by: Randy Dunlap Signed-off-by: Bartlomiej Zolnierkiewicz

ide: fix buggy code in ide_register_hw()

2008-03-07T20:53:49Z

Relocating the index to come after finding the hwif pointer. Signed-off-by: Peter Teoh Reported-by: Adrian Bunk Signed-off-by: Bartlomiej Zolnierkiewicz

ide: fix enabling DMA on it821x in "smart" mode

2008-03-07T20:53:49Z

ide_tune_dma() should return '1' if IDE_HFLAG_NO_SET_MODE host flag is set. Cc: Sergei Shtylyov Signed-off-by: Bartlomiej Zolnierkiewicz

ide-cd: mark REQ_TYPE_ATA_PC write requests with REQ_RW flag

2008-03-07T20:53:49Z

On Thursday 06 March 2008, walt wrote: > For me, this commit causes the problem it's intended to fix: > > commit 9f10d9ee0ac6d79d7bc8b9a158bf4a29322d84d3 > Author: Bartlomiej Zolnierkiewicz > Date: Tue Feb 26 21:50:35 2008 +0100 > > ide-cd: fix 'ireason' handling for REQ_TYPE_ATA_PC requests > > This fixes some hangs caused by not finishing the transfer before ending > the request and also makes use of 'ireason == 1' quirk for spurious IRQs. > > When I mount a CD there is a long delay, and I see this error message: > > hdc: ide_cd_check_ireason: wrong transfer direction! > cdrom: failed setting lba address space > hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest } > ide: failed opcode was: unknown > hdc: drive not ready for command > > > When I revert this commit everything works properly again, including > CD burning. It turned out that REQ_TYPE_ATA_PC write requests were not marked as such (the previous commit assumed them to be). Reported-by: walt Tested-by: walt Reviewed-by: Borislav Petkov Signed-off-by: Bartlomiej Zolnierkiewicz

gigaset: fix Oops on module unload regression

2008-03-07T19:06:08Z

The card state mutex was only initialized when a device was connected, but used during unload unconditionally, leading to an Oops if a driver was loaded and unloaded again without ever connecting a device. Fix this by initializing the mutex as soon as the structure is allocated. Also add a missing mutex unlock revealed in the same execution path. This fixes a possible Oops in 2.6.25-rc that was introduced by commit e468c04894f36045cf93d1384183a461014b6840 ("Gigaset: permit module unload"). Thanks to Roland Kletzing for reporting this problem. Signed-off-by: Tilman Schmidt Tested-by: Roland Kletzing Cc: Hansjoerg Lipp Cc: Karsten Keil Signed-off-by: Linus Torvalds

drivers/char/esp.c: fix bootup lockup

2008-03-07T18:05:13Z

randconfig testing found a bootup lockup in drivers/char/esp.c because of a spinlock that wasn't correctly initialized. I'm not sure why it became more prominent in 2.6.25-rc4, the bug seems rather old and i've been doing allyesconfig bootups for ages with CONFIG_ESP enabled. This fixes this bootup lockup: PM: Adding info for No Bus:ttyP63 ttyP32 at 0x0240 (irq = 0) is an ESP primary port BUG: spinlock lockup on CPU#0, swapper/1, f56dd004 Pid: 1, comm: swapper Not tainted 2.6.25-rc4-sched-devel.git-x86-latest.git #402 [] _raw_spin_lock+0x134/0x140 [] _spin_lock_irqsave+0x5e/0x80 [] ? espserial_init+0x2be/0x6e0 [] espserial_init+0x2be/0x6e0 [] kernel_init+0x83/0x260 [] ? espserial_init+0x0/0x6e0 [] ? restore_nocheck_notrace+0x0/0xe [] ? kernel_init+0x0/0x260 [] ? kernel_init+0x0/0x260 [] kernel_thread_helper+0x7/0x10 ======================= kzalloc() is not the way to initialize spinlocks anymore. Signed-off-by: Ingo Molnar Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.25

2008-03-07T03:32:33Z

* git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.25: sh: Fix up the sh64 build. sh: Fix up SH7710 VoIP-GW build. sh: Flag PMB support as EXPERIMENTAL. sh: Update r7780mp defconfig. fb: hitfb: Balance probe/remove section annotations. sh: hp6xx: Fix up hp6xx_apm build failure. fb: pvr2fb: Fix up remaining section mismatch. sh: Fix up section mismatches. sh: hp6xx: Correct APM output. sh: update se7780 defconfig sh: replace remaining __FUNCTION__ occurrences sh: export copy-page() to modules sh_ksyms_32.c update for gcc 4.3 sh/mm/pg-sh7705.c must #include

fb: hitfb: Balance probe/remove section annotations.

2008-03-06T04:56:33Z

hitfb presently has probe using __init whilst remove uses __devexit. As this device can't possibly be hotplugged, switch to __exit and __exit_p() instead. Signed-off-by: Paul Mundt

fb: pvr2fb: Fix up remaining section mismatch.

2008-03-06T04:39:18Z

Building with CONFIG_DEBUG_SECTION_MISMATCH=y reports: CC drivers/video/pvr2fb.o LD drivers/video/built-in.o WARNING: drivers/video/built-in.o(.text+0xb9b0): Section mismatch in reference from the function pvr2fb_check_var() to the variable .devinit.data:pvr2_fix The function pvr2fb_check_var() references the variable __devinitdata pvr2_fix. This is often because pvr2fb_check_var lacks a __devinitdata annotation or the annotation of pvr2_fix is wrong. This is obviously crap as no such reference exists, but it's a bit closer to reality from older versions which blamed the PCI table. The real problem was a reference to pvr2_var.vmode from pvr2fb_check_var(), as pvr2_var is flagged as __devinitdata (pvr2_fix is also, so at least that part is right). pvr2_var.vmode is just a fancy way of saying FB_VMODE_NONINTERLACED, so we just reference that explicitly instead. Signed-off-by: Paul Mundt