kernel/linux.git, branch v3.12.12

Linux 3.12.12

2014-02-20T19:08:17+00:00

pinctrl: protect pinctrl_list add

2014-02-20T19:08:02+00:00

commit 7b320cb1ed2dbd2c5f2a778197baf76fd6bf545a upstream. We have few fedora bug reports about list corruption on pinctrl, for example: https://bugzilla.redhat.com/show_bug.cgi?id=1051918 Most likely corruption happen due lack of protection of pinctrl_list when adding new nodes to it. Patch corrects that. Fixes: 42fed7ba44e ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by: Stanislaw Gruszka Acked-by: Stephen Warren Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: vt8500: Change devicetree data parsing

2014-02-20T19:08:02+00:00

commit f17248ed868767567298e1cdf06faf8159a81f7c upstream. Due to an assumption in the VT8500 pinctrl driver, the value passed from devicetree for 'wm,pull' was not explicitly translated before being passed to pinconf. Since v3.10, changes to 'enum pin_config_param', PIN_CONFIG_BIAS_PULL_(UP/DOWN) no longer map 1-to-1 with the expected values in devicetree. This patch adds a small translation between the devicetree values (0..2) and the enum pin_config_param equivalent values. Signed-off-by: Tony Prisk Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: at91: use locked variant of irq_set_handler

2014-02-20T19:08:02+00:00

commit b0dcfd87323ea86501e93d0fa2a98d2fd3579bcf upstream. When setting the gpio irq type, use the __irq_set_handler_locked() variant instead of the irq_set_handler() to prevent false spinlock recursion warning. Signed-off-by: Nicolas Ferre Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

genirq: Generic irq chip requires IRQ_DOMAIN

2014-02-20T19:08:02+00:00

commit 923fa4ea382f592dee2ba3b205befb90cbddf3af upstream. The generic_chip.c uses interfaces from irq_domain.c which is controlled by the IRQ_DOMAIN config option, but there is no Kconfig dependency so the build can fail: linux/kernel/irq/generic-chip.c:400:11: error: 'irq_domain_xlate_onetwocell' undeclared here (not in a function) Select IRQ_DOMAIN when GENERIC_IRQ_CHIP is selected. Signed-off-by: Nitin A Kamble Link: http://lkml.kernel.org/r/1391129410-54548-2-git-send-email-nitin.a.kamble@intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y

2014-02-20T19:08:01+00:00

commit 6583327c4dd55acbbf2a6f25e775b28b3abf9a42 upstream. Commit d61931d89b, "x86: Add optimized popcnt variants" introduced compile flag -fcall-saved-rdi for lib/hweight.c. When combined with options -fprofile-arcs and -O2, this flag causes gcc to generate broken constructor code. As a result, a 64 bit x86 kernel compiled with CONFIG_GCOV_PROFILE_ALL=y prints message "gcov: could not create file" and runs into sproadic BUGs during boot. The gcc people indicate that these kinds of problems are endemic when using ad hoc calling conventions. It is therefore best to treat any file compiled with ad hoc calling conventions as an isolated environment and avoid things like profiling or coverage analysis, since those subsystems assume a "normal" calling conventions. This patch avoids the bug by excluding lib/hweight.o from coverage profiling. Reported-by: Meelis Roos Cc: Andrew Morton Signed-off-by: Peter Oberparleiter Link: http://lkml.kernel.org/r/52F3A30C.7050205@linux.vnet.ibm.com Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

Revert "[media] videobuf_vm_{open,close} race fixes"

2014-02-20T19:08:01+00:00

commit cca36e2eecec2b8fc869a50ffd3bd0adeed92b8b upstream. This reverts commit a242f426108c284049a69710f871cc9f11b13e61. That commit actually caused deadlocks, rather then fixing them. If ext_lock is set to NULL (otherwise videobuf_queue_lock doesn't do anything), then you get this deadlock: The driver's mmap function calls videobuf_mmap_mapper which calls videobuf_queue_lock on q. videobuf_mmap_mapper calls __videobuf_mmap_mapper, __videobuf_mmap_mapper calls videobuf_vm_open and videobuf_vm_open calls videobuf_queue_lock on q (introduced by above patch): deadlocked. This affects drivers using dma-contig and dma-vmalloc. Only dma-sg is not affected since it doesn't call videobuf_vm_open from __videobuf_mmap_mapper. Most drivers these days have a non-NULL ext_lock. Those that still use NULL there are all fairly obscure drivers, which is why this hasn't been seen earlier. Since everything worked perfectly fine for many years I prefer to just revert this patch rather than trying to fix it. videobuf is quite fragile and I rather not touch it too much. Work is (slowly) progressing to move everything over to vb2 or at the very least use non-NULL ext_lock in videobuf. Signed-off-by: Hans Verkuil Cc: Al Viro Reported-by: Pete Eberlein Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

mxl111sf: Fix compile when CONFIG_DVB_USB_MXL111SF is unset

2014-02-20T19:08:01+00:00

commit 13e1b87c986100169b0695aeb26970943665eda9 upstream. Fix the following build error: drivers/media/usb/dvb-usb-v2/ mxl111sf-tuner.h:72:9: error: expected ‘;’, ‘,’ or ‘)’ before ‘struct’ struct mxl111sf_tuner_config *cfg) Signed-off-by: Dave Jones Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

mxl111sf: Fix unintentional garbage stack read

2014-02-20T19:08:01+00:00

commit 866e8d8a9dc1ebb4f9e67197e264ac2df81f7d4b upstream. mxl111sf_read_reg takes an address of a variable to write to as an argument. drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.c:mxl111sf_config_pin_mux_modes passes several uninitialized stack variables to this routine, expecting them to be filled in. In the event that something unexpected happens when reading from the chip, we end up doing a pr_debug of the value passed in, revealing whatever garbage happened to be on the stack. Change the pr_debug to match what happens in the 'success' case, where we assign buf[1] to *data. Spotted with Coverity (Bugs 731910 through 731917) Signed-off-by: Dave Jones Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

af9035: add ID [2040:f900] Hauppauge WinTV-MiniStick 2

2014-02-20T19:08:01+00:00

commit f2e4c5e004691dfe37d0e4b363296f28abdb9bc7 upstream. Add USB ID [2040:f900] for Hauppauge WinTV-MiniStick 2. Device is build upon IT9135 chipset. Tested-by: Stefan Becker Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman