user/sven/linux.git, branch v2.6.36.3

Linux 2.6.36.3

2011-01-07T22:39:58Z

gspca - sonixj: Add a flag in the driver_info table

2011-01-07T21:58:56Z

commit c6c14330717f9850b4b4c054b81424b9979cd07d upstream. Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

gspca - sonixj: Set the flag for some devices

2011-01-07T21:58:55Z

commit b2272a49e7df37732d73988f00468ce31e1ebc92 upstream. The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same value as other webcams with the same sensor. For now, only two webcams have been so detected: the Microsoft's VX1000 and VX3000. Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

orinoco: initialise priv->hw before assigning the interrupt

2011-01-07T21:58:55Z

commit 229bd792be0bad245b78ed8f119952733a4752e5 upstream. The interrupt handler takes a lock - but since commit bcad6e80f3f this lock goes through an indirection specified in the hermes_t structure. We must therefore initialise the structure before setting up the interrupt handler. Fix orinoco_cs and spectrum_cs Bisected by: Matt Domsch Signed-off by: David Kilroy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

Don't export format_by_forcc on two different drivers

2011-01-07T21:58:54Z

commit a757ee2216211278680dd8ac869aabe7b4a9970d upstream. Drivers should append their name on exported symbols, to avoid conflicts with allyesconfig: drivers/staging/built-in.o: In function `format_by_fourcc': /home/v4l/work_trees/linus/drivers/staging/cx25821/cx25821-video.c:96: multiple definition of `format_by_fourcc' drivers/media/built-in.o:/home/v4l/work_trees/linus/drivers/media/common/saa7146_video.c:88: first defined here Let's rename both occurences with a small shellscript: for i in drivers/staging/cx25821/*.[ch]; do sed s,format_by_fourcc,cx25821_format_by_fourcc,g <$i >a && mv a $i; done for i in drivers/media/common/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g <$i >a && mv a $i; done for i in include/media/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g <$i >a && mv a $i; done Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

mx2_camera: fix pixel clock polarity configuration

2011-01-07T21:58:52Z

commit 42cc37fe20cc680fb58fe12ae5ba718d683b8ca2 upstream. When SOCAM_PCLK_SAMPLE_FALLING, just leave CSICR1_REDGE unset, otherwise we get the inverted behaviour. Signed-off-by: Baruch Siach Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

posix-cpu-timers: workaround to suppress the problems with mt exec

2011-01-07T21:58:52Z

commit e0a70217107e6f9844628120412cb27bb4cea194 upstream. posix-cpu-timers.c correctly assumes that the dying process does posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD timers from signal->cpu_timers list. But, it also assumes that timer->it.cpu.task is always the group leader, and thus the dead ->task means the dead thread group. This is obviously not true after de_thread() changes the leader. After that almost every posix_cpu_timer_ method has problems. It is not simple to fix this bug correctly. First of all, I think that timer->it.cpu should use struct pid instead of task_struct. Also, the locking should be reworked completely. In particular, tasklist_lock should not be used at all. This all needs a lot of nontrivial and hard-to-test changes. Change __exit_signal() to do posix_cpu_timers_exit_group() when the old leader dies during exec. This is not the fix, just the temporary hack to hide the problem for 2.6.37 and stable. IOW, this is obviously wrong but this is what we currently have anyway: cpu timers do not work after mt exec. In theory this change adds another race. The exiting leader can detach the timers which were attached to the new leader. However, the window between de_thread() and release_task() is small, we can pretend that sys_timer_create() was called before de_thread(). Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree()

2011-01-07T21:58:51Z

commit 5cdd2de0a76d0ac47f107c8a7b32d75d25768dc1 upstream. In arch/x86/kernel/microcode_intel.c::generic_load_microcode() we have this: while (leftover) { ... if (get_ucode_data(mc, ucode_ptr, mc_size) || microcode_sanity_check(mc) < 0) { vfree(mc); break; } ... } if (mc) vfree(mc); This will cause a double free of 'mc'. This patch fixes that by just removing the vfree() call in the loop since 'mc' will be freed nicely just after we break out of the loop. There's also a second change in the patch. I noticed a lot of checks for pointers being NULL before passing them to vfree(). That's completely redundant since vfree() deals gracefully with being passed a NULL pointer. Removing the redundant checks yields a nice size decrease for the object file. Size before the patch: text data bss dec hex filename 4578 240 1032 5850 16da arch/x86/kernel/microcode_intel.o Size after the patch: text data bss dec hex filename 4489 240 984 5713 1651 arch/x86/kernel/microcode_intel.o Signed-off-by: Jesper Juhl Acked-by: Tigran Aivazian Cc: Shaohua Li LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead

2011-01-07T21:58:51Z

commit e692cb668fdd5a712c6ed2a2d6f2a36ee83997b4 upstream. When stacking devices, a request_queue is not always available. This forced us to have a no_cluster flag in the queue_limits that could be used as a carrier until the request_queue had been set up for a metadevice. There were several problems with that approach. First of all it was up to the stacking device to remember to set queue flag after stacking had completed. Also, the queue flag and the queue limits had to be kept in sync at all times. We got that wrong, which could lead to us issuing commands that went beyond the max scatterlist limit set by the driver. The proper fix is to avoid having two flags for tracking the same thing. We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the block layer merging functions. The queue_limit 'no_cluster' is turned into 'cluster' to avoid double negatives and to ease stacking. Clustering defaults to being enabled as before. The queue flag logic is removed from the stacking function, and explicitly setting the cluster flag is no longer necessary in DM and MD. Reported-by: Ed Lin Signed-off-by: Martin K. Petersen Acked-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

Sched: fix skip_clock_update optimization

2011-01-07T21:58:51Z

commit f26f9aff6aaf67e9a430d16c266f91b13a5bff64 upstream. idle_balance() drops/retakes rq->lock, leaving the previous task vulnerable to set_tsk_need_resched(). Clear it after we return from balancing instead, and in setup_thread_stack() as well, so no successfully descheduled or never scheduled task has it set. Need resched confused the skip_clock_update logic, which assumes that the next call to update_rq_clock() will come nearly immediately after being set. Make the optimization robust against the waking a sleeper before it sucessfully deschedules case by checking that the current task has not been dequeued before setting the flag, since it is that useless clock update we're trying to save, and clear unconditionally in schedule() proper instead of conditionally in put_prev_task(). Signed-off-by: Mike Galbraith Reported-by: Bjoern B. Brandenburg Tested-by: Yong Zhang Signed-off-by: Peter Zijlstra LKML-Reference: <1291802742.1417.9.camel@marge.simson.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman