summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2013-03-20Revert "drm/i915: reorder setup sequence to have irqs for output setup"Greg Kroah-Hartman
Revert commit 2a9810441fcc26cf3f006f015f8a62094fe57a90 which is commit 52d7ecedac3f96fb562cb482c139015372728638 upstream. This caused problems in 3.8-stable, but all is fine in 3.9-rc. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-20Revert "drm/i915: enable irqs earlier when resuming"Greg Kroah-Hartman
This reverts commit 31f14f4219d2a74b7a6d86c7798f49141b5eccbe which was commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 upstream. It caused problems in the 3.8-stable series, but 3.9-rc is just fine. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ilya Tumaykin <itumaykin@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-20macvlan: Set IFF_UNICAST_FLT flag to prevent unnecessary promisc mode.Vlad Yasevich
[ Upstream commit 87ab7f6f2874f1115817e394a7ed2dea1c72549e ] Macvlan already supports hw address filters. Set the IFF_UNICAST_FLT so that it doesn't needlesly enter PROMISC mode when macvlans are stacked. Signed-of-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20team: unsyc the devices addresses when port is removedVlad Yasevich
[ Upstream commit ba81276b1a5e3cf0674cb0e6d9525e5ae0c98695 ] When a team port is removed, unsync all devices addresses that may have been synched to the port devices. CC: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Acked-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20bonding: fire NETDEV_RELEASE event only on 0 slavesVeaceslav Falico
[ Upstream commit 80028ea1c0afc24d4ddeb8dd2a9992fff03616ca ] Currently, if we set up netconsole over bonding and release a slave, netconsole will stop logging on the whole bonding device. Change the behavior to stop the netconsole only when the last slave is released. Signed-off-by: Veaceslav Falico <vfalico@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20vxlan: fix oops when delete netns containing vxlanZang MingJie
[ Upstream commit 9cb6cb7ed11cd3b69c47bb414983603a6ff20b1d ] The following script will produce a kernel oops: sudo ip netns add v sudo ip netns exec v ip ad add 127.0.0.1/8 dev lo sudo ip netns exec v ip link set lo up sudo ip netns exec v ip ro add 224.0.0.0/4 dev lo sudo ip netns exec v ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev lo sudo ip netns exec v ip link set vxlan0 up sudo ip netns del v where inspect by gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 107] 0xffffffffa0289e33 in ?? () (gdb) bt #0 vxlan_leave_group (dev=0xffff88001bafa000) at drivers/net/vxlan.c:533 #1 vxlan_stop (dev=0xffff88001bafa000) at drivers/net/vxlan.c:1087 #2 0xffffffff812cc498 in __dev_close_many (head=head@entry=0xffff88001f2e7dc8) at net/core/dev.c:1299 #3 0xffffffff812cd920 in dev_close_many (head=head@entry=0xffff88001f2e7dc8) at net/core/dev.c:1335 #4 0xffffffff812cef31 in rollback_registered_many (head=head@entry=0xffff88001f2e7dc8) at net/core/dev.c:4851 #5 0xffffffff812cf040 in unregister_netdevice_many (head=head@entry=0xffff88001f2e7dc8) at net/core/dev.c:5752 #6 0xffffffff812cf1ba in default_device_exit_batch (net_list=0xffff88001f2e7e18) at net/core/dev.c:6170 #7 0xffffffff812cab27 in cleanup_net (work=<optimized out>) at net/core/net_namespace.c:302 #8 0xffffffff810540ef in process_one_work (worker=0xffff88001ba9ed40, work=0xffffffff8167d020) at kernel/workqueue.c:2157 #9 0xffffffff810549d0 in worker_thread (__worker=__worker@entry=0xffff88001ba9ed40) at kernel/workqueue.c:2276 #10 0xffffffff8105870c in kthread (_create=0xffff88001f2e5d68) at kernel/kthread.c:168 #11 <signal handler called> #12 0x0000000000000000 in ?? () #13 0x0000000000000000 in ?? () (gdb) fr 0 #0 vxlan_leave_group (dev=0xffff88001bafa000) at drivers/net/vxlan.c:533 533 struct sock *sk = vn->sock->sk; (gdb) l 528 static int vxlan_leave_group(struct net_device *dev) 529 { 530 struct vxlan_dev *vxlan = netdev_priv(dev); 531 struct vxlan_net *vn = net_generic(dev_net(dev), vxlan_net_id); 532 int err = 0; 533 struct sock *sk = vn->sock->sk; 534 struct ip_mreqn mreq = { 535 .imr_multiaddr.s_addr = vxlan->gaddr, 536 .imr_ifindex = vxlan->link, 537 }; (gdb) p vn->sock $4 = (struct socket *) 0x0 The kernel calls `vxlan_exit_net` when deleting the netns before shutting down vxlan interfaces. Later the removal of all vxlan interfaces, where `vn->sock` is already gone causes the oops. so we should manually shutdown all interfaces before deleting `vn->sock` as the patch does. Signed-off-by: Zang MingJie <zealot0630@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20tun: add a missing nf_reset() in tun_net_xmit()Eric Dumazet
[ Upstream commit f8af75f3517a24838a36eb5797a1a3e60bf9e276 ] Dave reported following crash : general protection fault: 0000 [#1] SMP CPU 2 Pid: 25407, comm: qemu-kvm Not tainted 3.7.9-205.fc18.x86_64 #1 Hewlett-Packard HP Z400 Workstation/0B4Ch RIP: 0010:[<ffffffffa0399bd5>] [<ffffffffa0399bd5>] destroy_conntrack+0x35/0x120 [nf_conntrack] RSP: 0018:ffff880276913d78 EFLAGS: 00010206 RAX: 50626b6b7876376c RBX: ffff88026e530d68 RCX: ffff88028d158e00 RDX: ffff88026d0d5470 RSI: 0000000000000011 RDI: 0000000000000002 RBP: ffff880276913d88 R08: 0000000000000000 R09: ffff880295002900 R10: 0000000000000000 R11: 0000000000000003 R12: ffffffff81ca3b40 R13: ffffffff8151a8e0 R14: ffff880270875000 R15: 0000000000000002 FS: 00007ff3bce38a00(0000) GS:ffff88029fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fd1430bd000 CR3: 000000027042b000 CR4: 00000000000027e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process qemu-kvm (pid: 25407, threadinfo ffff880276912000, task ffff88028c369720) Stack: ffff880156f59100 ffff880156f59100 ffff880276913d98 ffffffff815534f7 ffff880276913db8 ffffffff8151a74b ffff880270875000 ffff880156f59100 ffff880276913dd8 ffffffff8151a5a6 ffff880276913dd8 ffff88026d0d5470 Call Trace: [<ffffffff815534f7>] nf_conntrack_destroy+0x17/0x20 [<ffffffff8151a74b>] skb_release_head_state+0x7b/0x100 [<ffffffff8151a5a6>] __kfree_skb+0x16/0xa0 [<ffffffff8151a666>] kfree_skb+0x36/0xa0 [<ffffffff8151a8e0>] skb_queue_purge+0x20/0x40 [<ffffffffa02205f7>] __tun_detach+0x117/0x140 [tun] [<ffffffffa022184c>] tun_chr_close+0x3c/0xd0 [tun] [<ffffffff8119669c>] __fput+0xec/0x240 [<ffffffff811967fe>] ____fput+0xe/0x10 [<ffffffff8107eb27>] task_work_run+0xa7/0xe0 [<ffffffff810149e1>] do_notify_resume+0x71/0xb0 [<ffffffff81640152>] int_signal+0x12/0x17 Code: 00 00 04 48 89 e5 41 54 53 48 89 fb 4c 8b a7 e8 00 00 00 0f 85 de 00 00 00 0f b6 73 3e 0f b7 7b 2a e8 10 40 00 00 48 85 c0 74 0e <48> 8b 40 28 48 85 c0 74 05 48 89 df ff d0 48 c7 c7 08 6a 3a a0 RIP [<ffffffffa0399bd5>] destroy_conntrack+0x35/0x120 [nf_conntrack] RSP <ffff880276913d78> This is because tun_net_xmit() needs to call nf_reset() before queuing skb into receive_queue Reported-by: Dave Jones <davej@redhat.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20atl1c: restore buffer stateHuang, Xiong
[ Upstream commit 7cb08d7f3a5ea6131f4f243c2080530ac41cb293 ] in the previous commit : f1f220ea1dda078, the BUSY state of buffer is wrongly deleted. this patch just restore it. Signed-off-by: xiong <xiong@qca.qualcomm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20loopdev: remove an user triggerable oopsGuo Chao
commit b1a6650406875b9097a032eed89af50682fe1160 upstream. When loopdev is built as module and we pass an invalid parameter, loop_init() will return directly without deregister misc device, which will cause an oops when insert loop module next time because we left some garbage in the misc device list. Test case: sudo modprobe loop max_part=1024 (failed due to invalid parameter) sudo modprobe loop (oops) Clean up nicely to avoid such oops. Signed-off-by: Guo Chao <yan@linux.vnet.ibm.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Guo Chao <yan@linux.vnet.ibm.com> Cc: M. Hindess <hindessm@uk.ibm.com> Cc: Nikanth Karthikesan <knikanth@suse.de> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Acked-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20loopdev: fix a deadlockGuo Chao
commit 5370019dc2d2c2ff90e95d181468071362934f3a upstream. bd_mutex and lo_ctl_mutex can be held in different order. Path #1: blkdev_open blkdev_get __blkdev_get (hold bd_mutex) lo_open (hold lo_ctl_mutex) Path #2: blkdev_ioctl lo_ioctl (hold lo_ctl_mutex) lo_set_capacity (hold bd_mutex) Lockdep does not report it, because path #2 actually holds a subclass of lo_ctl_mutex. This subclass seems creep into the code by mistake. The patch author actually just mentioned it in the changelog, see commit f028f3b2 ("loop: fix circular locking in loop_clr_fd()"), also see: http://marc.info/?l=linux-kernel&m=123806169129727&w=2 Path #2 hold bd_mutex to call bd_set_size(), I've protected it with i_mutex in a previous patch, so drop bd_mutex at this site. Signed-off-by: Guo Chao <yan@linux.vnet.ibm.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Guo Chao <yan@linux.vnet.ibm.com> Cc: M. Hindess <hindessm@uk.ibm.com> Cc: Nikanth Karthikesan <knikanth@suse.de> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Acked-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20net/mlx4_en: Disable RFS when running in SRIOV modeAmir Vadai
commit a229e488ac3f904d06c20d8d3f47831db3c7a15a upstream. Commit 37706996 "mlx4_en: fix allocation of CPU affinity reverse-map" fixed a bug when mlx4_dev->caps.comp_pool is larger from the device rx rings, but introduced a regression. When the mlx4_core is activating its "legacy mode" (e.g when running in SRIOV mode) w.r.t to EQs/IRQs usage, comp_pool becomes zero and we're crashing on divide by zero alloc_cpu_rmap. Fix that by enabling RFS only when running in non-legacy mode. Reported-by: Yan Burman <yanb@mellanox.com> Cc: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20net/mlx4_en: Initialize RFS filters lock and list in init_netdevAmir Vadai
commit 78fb2de711ec28997bf38bcf3e48e108e907be77 upstream. filters_lock might have been used while it was re-initialized. Moved filters_lock and filters_list initialization to init_netdev instead of alloc_resources which is called every time the device is configured. Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20atmel_lcdfb: fix 16-bpp modes on older SOCsJohan Hovold
commit a79eac7165ed62114e6ca197195aa5060a54f137 upstream. Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp modes for older SOCs which use IBGR:555 (msb is intensity) rather than BGR:565. Use SOC-type to determine the pixel layout. Tested on at91sam9263 and at91sam9g45. Acked-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20mtd: nand: reintroduce NAND_NO_READRDY as NAND_NEED_READRDYBrian Norris
commit 5bc7c33ca93a285dcfe7b7fd64970f6314440ad1 upstream. This partially reverts commit 1696e6bc2ae83734e64e206ac99766ea19e9a14e ("mtd: nand: kill NAND_NO_READRDY"). In that patch I overlooked a few things. The original documentation for NAND_NO_READRDY included "True for all large page devices, as they do not support autoincrement." I was conflating "not support autoincrement" with the NAND_NO_AUTOINCR option, which was in fact doing nothing. So, when I dropped NAND_NO_AUTOINCR, I concluded that I then could harmlessly drop NAND_NO_READRDY. But of course the fact the NAND_NO_AUTOINCR was doing nothing didn't mean NAND_NO_READRDY was doing nothing... So, NAND_NO_READRDY is re-introduced as NAND_NEED_READRDY and applied only to those few remaining small-page NAND which needed it in the first place. Reported-by: Alexander Shiyan <shc_work@mail.ru> Tested-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20w1: fix oops when w1_search is called from netlink connectorMarcin Jurkowski
commit 9d1817cab2f030f6af360e961cc69bb1da8ad765 upstream. On Sat, Mar 02, 2013 at 10:45:10AM +0100, Sven Geggus wrote: > This is the bad commit I found doing git bisect: > 04f482faf50535229a5a5c8d629cf963899f857c is the first bad commit > commit 04f482faf50535229a5a5c8d629cf963899f857c > Author: Patrick McHardy <kaber@trash.net> > Date: Mon Mar 28 08:39:36 2011 +0000 Good job. I was too lazy to bisect for bad commit;) Reading the code I found problematic kthread_should_stop call from netlink connector which causes the oops. After applying a patch, I've been testing owfs+w1 setup for nearly two days and it seems to work very reliable (no hangs, no memleaks etc). More detailed description and possible fix is given below: Function w1_search can be called from either kthread or netlink callback. While the former works fine, the latter causes oops due to kthread_should_stop invocation. This patch adds a check if w1_search is serving netlink command, skipping kthread_should_stop invocation if so. Signed-off-by: Marcin Jurkowski <marcin1j@gmail.com> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Cc: Josh Boyer <jwboyer@gmail.com> Tested-by: Sven Geggus <lists@fuchsschwanzdomain.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20w1-gpio: remove erroneous __exit and __exit_p()Johan Hovold
commit 01230551e7c2fb9a1c2519b356d703851049cbe0 upstream. Commit 8a1861d997 ("w1-gpio: Simplify & get rid of defines") changed (apparently unknowingly) the driver to a hotpluggable platform-device driver but did not not update the section markers for probe and remove (to __devinit/exit, which have since been removed). A later commit fixed the section mismatch for probe, but left remove marked with __exit. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20hwmon: (lineage-pem) Add missing terminating entry for ↵Axel Lin
pem_[input|fan]_attributes commit df069079c153d22adf6c28dcc0b1cf62bba75167 upstream. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20hwmon: (pmbus/ltc2978) Fix temperature reportingGuenter Roeck
commit 8c958c703ef8804093437959221951eaf0e1e664 upstream. On LTC2978, only READ_TEMPERATURE is supported. It reports the internal junction temperature. This register is unpaged. On LTC3880, READ_TEMPERATURE and READ_TEMPERATURE2 are supported. READ_TEMPERATURE is paged and reports external temperatures. READ_TEMPERATURE2 is unpaged and reports the internal junction temperature. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20Fix 4 port and add support for 8 port 'Unknown' PCI serial port cardsScott Ashcroft
commit d13402a4a944e72612a9ec5c9190e35717c02a9d upstream. I've managed to find an 8 port version of the card 4 port card which was discussed here: http://marc.info/?l=linux-serial&m=120760744205314&w=2 Looking back at that thread there were two issues in the original patch. 1) The I/O ports for the UARTs are within BAR2 not BAR0. This can been seen in the original post. 2) A serial quirk isn't needed as these cards have no memory in BAR0 which makes pci_plx9050_init just return. This patch fixes the 4 port support to use BAR2, removes the bogus quirk and adds support for the 8 port card. $ lspci -vvv -n -s 00:08.0 00:08.0 0780: 10b5:9050 (rev 01) Subsystem: 10b5:1588 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 1: I/O ports at ff00 [size=128] Region 2: I/O ports at fe00 [size=64] Region 3: I/O ports at fd00 [size=8] Capabilities: <access denied> Kernel driver in use: serial $ dmesg | grep 0000:00:08.0: [ 0.083320] pci 0000:00:08.0: [10b5:9050] type 0 class 0x000780 [ 0.083355] pci 0000:00:08.0: reg 14: [io 0xff00-0xff7f] [ 0.083369] pci 0000:00:08.0: reg 18: [io 0xfe00-0xfe3f] [ 0.083382] pci 0000:00:08.0: reg 1c: [io 0xfd00-0xfd07] [ 0.083460] pci 0000:00:08.0: PME# supported from D0 D3hot [ 1.212867] 0000:00:08.0: ttyS4 at I/O 0xfe00 (irq = 17) is a 16550A [ 1.233073] 0000:00:08.0: ttyS5 at I/O 0xfe08 (irq = 17) is a 16550A [ 1.253270] 0000:00:08.0: ttyS6 at I/O 0xfe10 (irq = 17) is a 16550A [ 1.273468] 0000:00:08.0: ttyS7 at I/O 0xfe18 (irq = 17) is a 16550A [ 1.293666] 0000:00:08.0: ttyS8 at I/O 0xfe20 (irq = 17) is a 16550A [ 1.313863] 0000:00:08.0: ttyS9 at I/O 0xfe28 (irq = 17) is a 16550A [ 1.334061] 0000:00:08.0: ttyS10 at I/O 0xfe30 (irq = 17) is a 16550A [ 1.354258] 0000:00:08.0: ttyS11 at I/O 0xfe38 (irq = 17) is a 16550A Signed-off-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20TTY: do not reset master's packet modeJiri Slaby
commit b81273a132177edd806476b953f6afeb17b786d5 upstream. Now that login from util-linux is forced to drop all references to a TTY which it wants to hangup (to reach reference count 1) we are seeing issues with telnet. When login closes its last reference to the slave PTY, it also resets packet mode on the *master* side. And we have a race here. What telnet does is fork+exec of `login'. Then there are two scenarios: * `login' closes the slave TTY and resets thus master's packet mode, but even now telnet properly sets the mode, or * `telnetd' sets packet mode on the master, `login' closes the slave TTY and resets master's packet mode. The former case is OK. However the latter happens in much more cases, by the order of magnitude to be precise. So when one tries to login to such a messed telnet setup, they see the following: inux login: ogin incorrect Note the missing first letters -- telnet thinks it is still in the packet mode, so when it receives "linux login" from `login', it considers "l" as the type of the packet and strips it. SuS does not mention how the implementation should behave. Both BSDs I checked (Free and Net) do not reset the flag upon the last close. By this I am resurrecting an old bug, see References. We are hitting it regularly now, i.e. with updated util-linux, ergo login. Here, I am changing a behavior introduced back in 2.1 times. It would better have a long time testing before goes upstream. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Bryan Mason <bmason@redhat.com> References: https://lkml.org/lkml/2009/11/11/223 References: https://bugzilla.redhat.com/show_bug.cgi?id=504703 References: https://bugzilla.novell.com/show_bug.cgi?id=797042 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20TTY: disable debugging warningJiri Slaby
commit 34dcfb8479ab3c3669561eb9279284cb0eda2572 upstream. We added a warning to flush_to_ldisc to report cases when it is called with a NULL tty. It was for debugging purposes and it lead to a patchset from Peter Hurley. The patchset however did not make it to 3.9, so disable the warning now to not disturb people. We can re-add it when the series is in and we are hunting for another bugs. Reported-by: David Miller <davem@davemloft.net> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20tty/serial: Add support for Altera serial portLey Foon Tan
commit e06c93cacb82dd147266fd1bdb2d0a0bd45ff2c1 upstream. Add support for Altera 8250/16550 compatible serial port. Signed-off-by: Ley Foon Tan <lftan@altera.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20tty: serial: fix typo "SERIAL_S3C2412"Paul Bolle
commit c51d41a1dd8f23a06a4ed651ebb9617de7f59368 upstream. The Kconfig symbol SERIAL_S3C2412 got removed in commit da121506eb03ee5daea55404709110b798bd61d9 ("serial: samsung: merge probe() function from all SoC specific extensions"). But it also added a last reference to that symbol. The commit and the tree make clear that CPU_S3C2412 should have been used instead. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20tty: serial: fix typo "ARCH_S5P6450"Paul Bolle
commit 827aa0d36d486f359808c8fb931cf7a71011a09d upstream. This could have been either ARCH_S5P64X0 or CPU_S5P6450. Looking at commit 2555e663b367b8d555e76023f4de3f6338c28d6c ("ARM: S5P64X0: Add UART serial support for S5P6450") - which added this typo - makes clear this should be CPU_S5P6450. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 ↵Wang YanQing
Multi-I/O Controller commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366 upstream. 01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01) Subsystem: Device [1000:0012] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 20 Region 0: I/O ports at e050 [size=8] Region 1: I/O ports at e040 [size=8] Region 2: I/O ports at e030 [size=8] Region 3: I/O ports at e020 [size=8] Region 4: I/O ports at e010 [size=8] Region 5: I/O ports at e000 [size=16] Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20serial: 8250: Keep 8250.<xxxx> module options functional after driver renameJosh Boyer
commit f2b8dfd9e480c3db3bad0c25c590a5d11b31f4ef upstream. With commit 835d844d1 (8250_pnp: do pnp probe before legacy probe), the 8250 driver was renamed to 8250_core. This means any existing usage of the 8259.<xxxx> module parameters or as a kernel command line switch is now broken, as the 8250_core driver doesn't parse options belonging to something called "8250". To solve this, we redefine the module options in a dummy function using a redefined MODULE_PARAM_PREFX when built into the kernel. In the case where we're building as a module, we provide an alias to the old 8250 name. The dummy function prevents compiler errors due to global variable redefinitions that happen as part of the module_param_ macro expansions. Signed-off-by: Josh Boyer <jwboyer@redhat.com> Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20tty/8250_pnp: serial port detection regression since v3.7Sean Young
commit 77e372a3d82e5e4878ce1962207edd766773cc76 upstream. The InsydeH2O BIOS (version dated 09/12/2011) has the following in its pnp resouces for its serial ports: $ cat /sys/bus/pnp/devices/00:0b/resources state = active io disabled irq disabled We do not check if the resources are disabled, and create a bogus ttyS* device. Since commit 835d844d1a28e (8250_pnp: do pnp probe before legacy probe) we get a bogus ttyS0, which prevents the legacy probe from detecting it. Note, the BIOS can also be upgraded, fixing this problem, but for people who can't do that, this fix is needed. Reported-by: Vincent Deffontaines <vincent@gryzor.com> Tested-by: Vincent Deffontaines <vincent@gryzor.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20qcserial: bind to DM/DIAG port on Gobi 1K devicesDan Williams
commit 3f8bc5e4da29c7e05edeca6b475abb4fb01a5a13 upstream. Turns out we just need altsetting 1 and then we can talk to it. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20staging: comedi: dt9812: use CR_CHAN() for channel numberIan Abbott
commit 564c526a1bed5e42b5cd52cfe1752c4296ef17a6 upstream. As pointed out by Dan Carpenper in <http://driverdev.linuxdriverproject.org/pipermail/devel/2013-February/036025.html>, the dt9812 comedi driver's use of the `chanspec` member of `struct comedi_insn` as a channel number is incorrect. Change it to use `CR_CHAN(insn->chanspec)` as the channel number (where `insn` is a pointer to the `struct comedi_insn` being processed). Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Anders Blomdell <anders.blomdell@control.lth.se> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20staging: vt6656: Fix oops on resume from suspend.Malcolm Priestley
commit 6987a6dabfc40222ef767f67b57212fe3a0225fb upstream. Remove usb_put_dev from vt6656_suspend and usb_get_dev from vt6566_resume. These are not normally in suspend/resume functions. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20USB: EHCI: don't check DMA values in QH overlaysAlan Stern
commit feca7746d5d9e84b105a613b7f3b6ad00d327372 upstream. This patch (as1661) fixes a rather obscure bug in ehci-hcd. In a couple of places, the driver compares the DMA address stored in a QH's overlay region with the address of a particular qTD, in order to see whether that qTD is the one currently being processed by the hardware. (If it is then the status in the QH's overlay region is more up-to-date than the status in the qTD, and if it isn't then the overlay's value needs to be adjusted when the QH is added back to the active schedule.) However, DMA address in the overlay region isn't always valid. It sometimes will contain a stale value, which may happen by coincidence to be equal to a qTD's DMA address. Instead of checking the DMA address, we should check whether the overlay region is active and valid. The patch tests the ACTIVE bit in the overlay, and clears this bit when the overlay becomes invalid (which happens when the currently-executing URB is unlinked). This is the second part of a fix for the regression reported at: https://bugs.launchpad.net/bugs/1088733 Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com> Reported-and-tested-by: Stephen Thirlwall <sdt@dr.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20USB: storage: fix Huawei mode switching regressionBjørn Mork
commit ab4b71644a26d1ab92b987b2fd30e17c25e89f85 upstream. This reverts commit 200e0d99 ("USB: storage: optimize to match the Huawei USB storage devices and support new switch command" and the followup bugfix commit cd060956 ("USB: storage: properly handle the endian issues of idProduct"). The commit effectively added a large number of Huawei devices to the deprecated usb-storage mode switching logic. Many of these devices have been in use and supported by the userspace usb_modeswitch utility for years. Forcing the switching inside the kernel causes a number of regressions as a result of ignoring existing onfigurations, and also completely takes away the ability to configure mode switching per device/system/user. Known regressions caused by this: - Some of the devices support multiple modes, using different switching commands. There are existing configurations taking advantage of this. - There is a real use case for disabling mode switching and instead mounting the exposed storage device. This becomes impossible with switching logic inside the usb-storage driver. - At least on device fail as a result of the usb-storage switching command, becoming completely unswitchable. This is possibly a firmware bug, but still a regression because the device work as expected using usb_modeswitch defaults. In-kernel mode switching was deprecated years ago with the development of the more user friendly userspace alternatives. The existing list of devices in usb-storage was only kept to prevent breaking already working systems. The long term plan is to remove the list, not to add to it. Ref: http://permalink.gmane.org/gmane.linux.usb.general/28543 Signed-off-by: Bjørn Mork <bjorn@mork.no> Cc: <fangxiaozhi@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20usb: serial: Add Rigblaster Advantage to device tableSteve Conklin
commit a57e82a18779ab8a5e5a1f5841cef937cf578913 upstream. The Rigblaster Advantage is an amateur radio interface sold by West Mountain Radio. It contains a cp210x serial interface but the device ID is not in the driver. Signed-off-by: Steve Conklin <sconklin@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20USB: added support for Cinterion's products AH6 and PLS8Christian Schmiedl
commit 1941138e1c024ecb5bd797d414928d3eb94d8662 upstream. add support for Cinterion's products AH6 and PLS8 by adding Product IDs and USB_DEVICE tuples. Signed-off-by: Christian Schmiedl <christian.schmiedl@gemalto.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20usb: cp210x new Vendor/Device IDsMatwey V. Kornilov
commit be3101c23394af59694c8a2aae6d07f5da62fea5 upstream. This patch adds support for the Lake Shore Cryotronics devices to the CP210x driver. These lines are ported from cp210x driver distributed by Lake Shore web site: http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz and licensed under the terms of GPLv2. Moreover, I've tested this changes with Lake Shore 335 in my labs. Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20usb: dwc3: core: don't forget to free coherent memoryFelipe Balbi
commit d9b4330adec006c2e8907bdcacd9dcc0e8874d18 upstream. commit 3921426 (usb: dwc3: core: move event buffer allocation out of dwc3_core_init()) introduced a memory leak of the coherent memory we use as event buffers on dwc3 driver. If the driver is compiled as a dynamically loadable module and use constantly loads and unloads the driver, we will continue to leak the coherent memory allocated during ->probe() because dwc3_free_event_buffers() is never called during ->remove(). Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20USB: cdc-wdm: fix buffer overflowOliver Neukum
commit c0f5ecee4e741667b2493c742b60b6218d40b3aa upstream. The buffer for responses must not overflow. If this would happen, set a flag, drop the data and return an error after user space has read all remaining data. Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20USB: option: add Huawei E5331Bjørn Mork
commit daec90e7382cbd0e73eb6861109b3da91e5ab1f3 upstream. Another device using CDC ACM with vendor specific protocol to mark serial functions. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20virtio: rng: disallow multiple device registrations, fixes crashesAmit Shah
commit e84e7a56a3aa2963db506299e29a5f3f09377f9b upstream. The code currently only supports one virtio-rng device at a time. Invoking guests with multiple devices causes the guest to blow up. Check if we've already registered and initialised the driver. Also cleanup in case of registration errors or hot-unplug so that a new device can be used. Reported-by: Peter Krempa <pkrempa@redhat.com> Reported-by: <yunzheng@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20xen/pciback: Don't disable a PCI device that is already disabled.Konrad Rzeszutek Wilk
commit bdc5c1812cea6efe1aaefb3131fcba28cd0b2b68 upstream. While shuting down a HVM guest with pci devices passed through we get this: pciback 0000:04:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100002) ------------[ cut here ]------------ WARNING: at drivers/pci/pci.c:1397 pci_disable_device+0x88/0xa0() Hardware name: MS-7640 Device pciback disabling already-disabled device Modules linked in: Pid: 53, comm: xenwatch Not tainted 3.9.0-rc1-20130304a+ #1 Call Trace: [<ffffffff8106994a>] warn_slowpath_common+0x7a/0xc0 [<ffffffff81069a31>] warn_slowpath_fmt+0x41/0x50 [<ffffffff813cf288>] pci_disable_device+0x88/0xa0 [<ffffffff814554a7>] xen_pcibk_reset_device+0x37/0xd0 [<ffffffff81454b6f>] ? pcistub_put_pci_dev+0x6f/0x120 [<ffffffff81454b8d>] pcistub_put_pci_dev+0x8d/0x120 [<ffffffff814582a9>] __xen_pcibk_release_devices+0x59/0xa0 This fixes the bug. Reported-and-Tested-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-20qcaux: add Franklin U600Dan Williams
commit 2d90e63603ac235aecd7d20e234616e0682c8b1f upstream. 4 ports; AT/PPP is standard CDC-ACM. The other three (added by this patch) are QCDM/DIAG, possibly GPS, and unknown. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14w1-gpio: fix section mismatchHauke Mehrtens
commit 06a8f1feb9e82e5b66f781ba3e39055e3f89a641 upstream. This fixes the following section mismatch: WARNING: drivers/w1/masters/w1-gpio.o(.data+0x188): Section mismatch in reference from the variable w1_gpio_driver to the function .init.text:w1_gpio_probe() The variable w1_gpio_driver references the function __init w1_gpio_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14Revert "xen/blkback: Don't trust the handle from the frontend."Greg Kroah-Hartman
This reverts commit 01c681d4c70d64cb72142a2823f27c4146a02e63 upstream (ef56ca64ea733c3b88f0bb74b04da128b1dc35d8 in this tree), as it wasn't supposed to have been applied to the stable tree. Cc: Jan Beulich <jbeulich@suse.com> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14USB: Fix connected device switch to Inactive state.Sarah Sharp
[This is upstream commit d3b9d7a9051d7024a93c76a84b2f84b3b66ad6d5. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a "USB: Handle warm reset failure on empty port."] A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit transition fails. The current code in hub_events simply issues a warm reset, but does not call any pre-reset or post-reset driver methods (or unbind/rebind drivers without them). Therefore the drivers won't know their device has just been reset. hub_events should instead call usb_reset_device. This means hub_port_reset now needs to figure out whether it should issue a warm reset or a hot reset. Remove the FIXME note about needing disconnect() for a NOTATTACHED device. This patch fixes that. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14USB: Rip out recursive call on warm port reset.Sarah Sharp
[This is upstream commit a24a6078754f28528bc91e7e7b3e6ae86bd936d8. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a "USB: Handle warm reset failure on empty port."] When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14USB: Prepare for refactoring by adding extra udev checks.Sarah Sharp
[This is upstream commit 2d4fa940f99663c82ba55b2244638833b388e4e2. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a "USB: Handle warm reset failure on empty port."] The next patch will refactor the hub port code to rip out the recursive call to hub_port_reset on a failed hot reset. In preparation for that, make sure all code paths can deal with being called with a NULL udev. The usb_device will not be valid if warm reset was issued because a port transitioned to the Inactive or Compliance Mode on a device connect. This patch should have no effect on current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14USB: Don't use EHCI port sempahore for USB 3.0 hubs.Sarah Sharp
[This is upstream commit 0fe51aa5eee51db7c7ecd201d42a977ad79c58b6. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a "USB: Handle warm reset failure on empty port."] The EHCI host controller needs to prevent EHCI initialization when the UHCI or OHCI companion controller is in the middle of a port reset. It uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under an EHCI host controller, so it makes no sense to down the semaphore for USB 3.0 hubs. It also makes the warm port reset code more complex. Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14efi: be more paranoid about available space when creating variablesMatthew Garrett
commit 68d929862e29a8b52a7f2f2f86a0600423b093cd upstream. UEFI variables are typically stored in flash. For various reasons, avaiable space is typically not reclaimed immediately upon the deletion of a variable - instead, the system will garbage collect during initialisation after a reboot. Some systems appear to handle this garbage collection extremely poorly, failing if more than 50% of the system flash is in use. This can result in the machine refusing to boot. The safest thing to do for the moment is to forbid writes if they'd end up using more than half of the storage space. We can make this more finegrained later if we come up with a method for identifying the broken machines. Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14efivars: Disable external interrupt while holding efivars->lockSeiji Aguchi
commit 81fa4e581d9283f7992a0d8c534bb141eb840a14 upstream. [Problem] There is a scenario which efi_pstore fails to log messages in a panic case. - CPUA holds an efi_var->lock in either efivarfs parts or efi_pstore with interrupt enabled. - CPUB panics and sends IPI to CPUA in smp_send_stop(). - CPUA stops with holding the lock. - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC) but it returns without logging messages. [Patch Description] This patch disables an external interruption while holding efivars->lock as follows. In efi_pstore_write() and get_var_data(), spin_lock/spin_unlock is replaced by spin_lock_irqsave/spin_unlock_irqrestore because they may be called in an interrupt context. In other functions, they are replaced by spin_lock_irq/spin_unlock_irq. because they are all called from a process context. By applying this patch, we can avoid the problem above with a following senario. - CPUA holds an efi_var->lock with interrupt disabled. - CPUB panics and sends IPI to CPUA in smp_send_stop(). - CPUA receives the IPI after releasing the lock because it is disabling interrupt while holding the lock. - CPUB waits for one sec until CPUA releases the lock. - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC) And it can hold the lock successfully. Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Acked-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-14gpio: mvebu: Add clk support to prevent lockupAndrew Lunn
commit de88747f514a4e0cca416a8871de2302f4f77790 upstream. The kirkwood SoC GPIO cores use the runit clock. Add code to clk_prepare_enable() runit, otherwise there is a danger of locking up the SoC by accessing the GPIO registers when runit clock is not ticking. Reported-by: Simon Baatz <gmbnomis@gmail.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Simon Baatz <gmbnomis@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-19 15:09:59 +0000