- 06 Dec, 2014 40 commits
-
-
Thomas Körper authored
commit 5247a589 upstream. ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX Error) interrupt, which triggers the folloing warning: [ 1153.360705] ------------[ cut here ]------------ [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0() [ 1153.360772] Call Trace: [ 1153.360778] [<c167906f>] dump_stack+0x41/0x52 [ 1153.360782] [<c105bb7e>] warn_slowpath_common+0x7e/0xa0 [ 1153.360784] [<c158b909>] ? skb_release_head_state+0xb9/0xd0 [ 1153.360786] [<c158b909>] ? skb_release_head_state+0xb9/0xd0 [ 1153.360788] [<c105bc42>] warn_slowpath_null+0x22/0x30 [ 1153.360791] [<c158b909>] skb_release_head_state+0xb9/0xd0 [ 1153.360793] [<c158be90>] skb_release_all+0x10/0x30 [ 1153.360795] [<c158bf06>] kfree_skb+0x36/0x80 [ 1153.360799] [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev] [ 1153.360802] [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev] [ 1153.360805] [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402] [ 1153.360809] [<c10a75b5>] handle_irq_event_percpu+0x35/0x180 [ 1153.360811] [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180 [ 1153.360813] [<c10a7731>] handle_irq_event+0x31/0x50 [ 1153.360816] [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120 [ 1153.360818] [<c10a9c10>] ? handle_edge_irq+0x110/0x110 [ 1153.360822] [<c1011b61>] handle_irq+0x71/0x90 [ 1153.360823] <IRQ> [<c168152c>] do_IRQ+0x3c/0xd0 [ 1153.360829] [<c1680b6c>] common_interrupt+0x2c/0x34 [ 1153.360834] [<c107d277>] ? finish_task_switch+0x47/0xf0 [ 1153.360836] [<c167c27b>] __schedule+0x35b/0x7e0 [ 1153.360839] [<c10a5334>] ? console_unlock+0x2c4/0x4d0 [ 1153.360842] [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890 [ 1153.360845] [<c10707b6>] ? process_one_work+0x196/0x370 [ 1153.360847] [<c167c723>] schedule+0x23/0x60 [ 1153.360849] [<c1070de1>] worker_thread+0x161/0x460 [ 1153.360852] [<c1090fcf>] ? __wake_up_locked+0x1f/0x30 [ 1153.360854] [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0 [ 1153.360856] [<c1074f01>] kthread+0xa1/0xc0 [ 1153.360859] [<c1680401>] ret_from_kernel_thread+0x21/0x30 [ 1153.360861] [<c1074e60>] ? kthread_create_on_node+0x110/0x110 [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]--- This patch replaces the kfree_skb() by dev_kfree_skb_any(). Signed-off-by:
Thomas Körper <thomas.koerper@esd.eu> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Christian Sünkenberg authored
commit 18990455 upstream. Intel Multi-Flex LUNs choke on REPORT SUPPORTED OPERATION CODES resulting in sd_mod hanging for several minutes on startup. The issue was introduced with WRITE SAME discovery heuristics. Fixes: 5db44863 ("[SCSI] sd: Implement support for WRITE SAME") Signed-off-by:
Christian Sünkenberg <christian.suenkenberg@hfg-karlsruhe.de> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Nicholas Bellinger authored
commit ab8edab1 upstream. This patch addresses a bug where individual vhost-scsi configfs endpoint groups can be removed from below while active exports to QEMU userspace still exist, resulting in an OOPs. It adds a configfs_depend_item() in vhost_scsi_set_endpoint() to obtain an explicit dependency on se_tpg->tpg_group in order to prevent individual vhost-scsi WWPN endpoints from being released via normal configfs methods while an QEMU ioctl reference still exists. Also, add matching configfs_undepend_item() in vhost_scsi_clear_endpoint() to release the dependency, once QEMU's reference to the individual group at /sys/kernel/config/target/vhost/$WWPN/$TPGT is released. (Fix up vhost_scsi_clear_endpoint() error path - DanC) Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Thor Thayer authored
commit 0a8727e6 upstream. An IOCTL call that calls spi_setup() and then dw_spi_setup() will overwrite the persisted last transfer speed. On each transfer, the SPI speed is compared to the last transfer speed to determine if the clock divider registers need to be updated (did the speed change?). This bug was observed with the spidev driver using spi-config to update the max transfer speed. This fix: Don't overwrite the persisted last transaction clock speed when updating the SPI parameters in dw_spi_setup(). On the next transaction, the new speed won't match the persisted last speed and the hardware registers will be updated. On initialization, the persisted last transaction clock speed will be 0 but will be updated after the first SPI transaction. Move zeroed clock divider check into clock change test because chip->clk_div is zero on startup and would cause a divide-by-zero error. The calculation was wrong as well (can't support odd #). Reported-by:
Vlastimil Setka <setka@vsis.cz> Signed-off-by:
Thor Thayer <tthayer@opensource.altera.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Sagi Grimberg authored
commit 3b726ae2 upstream. In this case the cm_id->context is the isert_np, and the cm_id->qp is NULL, so use that to distinct the cases. Since we don't expect any other events on this cm_id we can just return -1 for explicit termination of the cm_id by the cma layer. Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
-
Roland Dreier authored
commit 885e7b0e upstream. If an initiator sends a zero-length command (e.g. TEST UNIT READY) but sets the transfer direction in the transport layer to indicate a data-out phase, we still shouldn't try to transfer data. At best it's a NOP, and depending on the transport, we might crash on an uninitialized sg list. Reported-by:
Craig Watson <craig.watson@vanguard-rugged.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Bart Van Assche authored
commit ab477c1f upstream. It is not guaranteed to that srp_sq_size is supported by the HCA. So if we failed to create the QP with ENOMEM, try with a smaller srp_sq_size. Keep it up until we hit MIN_SRPT_SQ_SIZE, then fail the connection. Reported-by:
Mark Lehrer <lehrer@gmail.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Greg Kroah-Hartman authored
commit a1f9a407 upstream. The xpad wireless endpoint is not a bulk endpoint on my devices, but rather an interrupt one, so the USB core complains when it is submitted. I'm guessing that the author really did mean that this should be an interrupt urb, but as there are a zillion different xpad devices out there, let's cover out bases and handle both bulk and interrupt endpoints just as easily. Signed-off-by:
"Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Ben Sagal authored
commit bce4f9e7 upstream. The LEN2006 Synaptics touchpad (as found in Thinkpad E540) returns wrong min max values. touchpad-edge-detector output: > Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6 > Move one finger around the touchpad to detect the actual edges > Kernel says: x [1472..5674], y [1408..4684] > Touchpad sends: x [1264..5675], y [1171..4688] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88211Signed-off-by:
Binyamin Sagal <bensagal@gmail.com> Signed-off-by:
-
Vladimir Murzin authored
commit 3f4aa45c upstream. We cannot restart cacheflush safely if a process provides user-defined signal handler and signal is pending. In this case -EINTR is returned and it is expected that process re-invokes syscall. However, there are a few problems with that: * looks like nobody bothers checking return value from cacheflush * but if it did, we don't provide the restart address for that, so the process has to use the same range again * ...and again, what might lead to looping forever So, remove cacheflush restarting code and terminate cache flushing as early as fatal signal is pending. Reported-by:
Chanho Min <chanho.min@lge.com> Signed-off-by:
Vladimir Murzin <vladimir.murzin@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Thomas Petazzoni authored
commit 995ab518 upstream. Under extremely rare conditions, in an MPCore node consisting of at least 3 CPUs, two CPUs trying to perform a STREX to data on the same shared cache line can enter a livelock situation. This patch enables the HW mechanism that overcomes the bug. This fixes the incorrect setup of the STREX backoff delay bit due to a wrong description in the specification. Note that enabling the STREX backoff delay mechanism is done by leaving the bit *cleared*, while the bit was currently being set by the proc-v7.S code. [Thomas: adapt to latest mainline, slightly reword the commit log, add stable markers.] Fixes: de490193 ("arm: mm: Add support for PJ4B cpu and init routines") Signed-off-by:
Nadav Haklai <nadavh@marvell.com> Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit ef59a20b upstream. According to the manuals I have, XScale auxiliary register should be reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to also use c1, c0, 1. The issue was primarily noticed thanks to qemu reporing "unsupported instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255 XScale Core manuals and in PXA270 and PXA320 Developers Guides. Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board. Tested-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by:
-
Gu Zheng authored
commit 835f252c upstream. https://bugzilla.kernel.org/show_bug.cgi?id=86831 Markus reported that when shutting down mysqld (with AIO support, on a ext3 formatted Harddrive) leads to a negative number of dirty pages (underrun to the counter). The negative number results in a drastic reduction of the write performance because the page cache is not used, because the kernel thinks it is still 2 ^ 32 dirty pages open. Add a warn trace in __dec_zone_state will catch this easily: static inline void __dec_zone_state(struct zone *zone, enum zone_stat_item item) { atomic_long_dec(&zone->vm_stat[item]); + WARN_ON_ONCE(item == NR_FILE_DIRTY && atomic_long_read(&zone->vm_stat[item]) < 0); atomic_long_dec(&vm_stat[item]); } [ 21.341632] ------------[ cut here ]------------ [ 21.346294] WARNING: CPU: 0 PID: 309 at include/linux/vmstat.h:242 cancel_dirty_page+0x164/0x224() [ 21.355296] Modules linked in: wutbox_cp sata_mv [ 21.359968] CPU: 0 PID: 309 Comm: kworker/0:1 Not tainted 3.14.21-WuT #80 [ 21.366793] Workqueue: events free_ioctx [ 21.370760] [<c0016a64>] (unwind_backtrace) from [<c0012f88>] (show_stack+0x20/0x24) [ 21.378562] [<c0012f88>] (show_stack) from [<c03f8ccc>] (dump_stack+0x24/0x28) [ 21.385840] [<c03f8ccc>] (dump_stack) from [<c0023ae4>] (warn_slowpath_common+0x84/0x9c) [ 21.393976] [<c0023ae4>] (warn_slowpath_common) from [<c0023bb8>] (warn_slowpath_null+0x2c/0x34) [ 21.402800] [<c0023bb8>] (warn_slowpath_null) from [<c00c0688>] (cancel_dirty_page+0x164/0x224) [ 21.411524] [<c00c0688>] (cancel_dirty_page) from [<c00c080c>] (truncate_inode_page+0x8c/0x158) [ 21.420272] [<c00c080c>] (truncate_inode_page) from [<c00c0a94>] (truncate_inode_pages_range+0x11c/0x53c) [ 21.429890] [<c00c0a94>] (truncate_inode_pages_range) from [<c00c0f6c>] (truncate_pagecache+0x88/0xac) [ 21.439252] [<c00c0f6c>] (truncate_pagecache) from [<c00c0fec>] (truncate_setsize+0x5c/0x74) [ 21.447731] [<c00c0fec>] (truncate_setsize) from [<c013b3a8>] (put_aio_ring_file.isra.14+0x34/0x90) [ 21.456826] [<c013b3a8>] (put_aio_ring_file.isra.14) from [<c013b424>] (aio_free_ring+0x20/0xcc) [ 21.465660] [<c013b424>] (aio_free_ring) from [<c013b4f4>] (free_ioctx+0x24/0x44) [ 21.473190] [<c013b4f4>] (free_ioctx) from [<c003d8d8>] (process_one_work+0x134/0x47c) [ 21.481132] [<c003d8d8>] (process_one_work) from [<c003e988>] (worker_thread+0x130/0x414) [ 21.489350] [<c003e988>] (worker_thread) from [<c00448ac>] (kthread+0xd4/0xec) [ 21.496621] [<c00448ac>] (kthread) from [<c000ec18>] (ret_from_fork+0x14/0x20) [ 21.503884] ---[ end trace 79c4bf42c038c9a1 ]--- The cause is that we set the aio ring file pages as *DIRTY* via SetPageDirty (bypasses the VFS dirty pages increment) when init, and aio fs uses *default_backing_dev_info* as the backing dev, which does not disable the dirty pages accounting capability. So truncating aio ring file will contribute to accounting dirty pages (VFS dirty pages decrement), then error occurs. The original goal is keeping these pages in memory (can not be reclaimed or swapped) in life-time via marking it dirty. But thinking more, we have already pinned pages via elevating the page's refcount, which can already achieve the goal, so the SetPageDirty seems unnecessary. In order to fix the issue, using the __set_page_dirty_no_writeback instead of the nop .set_page_dirty, and dropped the SetPageDirty (don't manually set the dirty flags, don't disable set_page_dirty(), rely on default behaviour). With the above change, the dirty pages accounting can work well. But as we known, aio fs is an anonymous one, which should never cause any real write-back, we can ignore the dirty pages (write back) accounting by disabling the dirty pages (write back) accounting capability. So we introduce an aio private backing dev info (disabled the ACCT_DIRTY/WRITEBACK/ACCT_WB capabilities) to replace the default one. Reported-by:
Markus Königshaus <m.koenigshaus@wut.de> Signed-off-by:
Gu Zheng <guz.fnst@cn.fujitsu.com> Acked-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
-
Jurgen Kramer authored
commit 6e84a8d7 upstream. This patch adds a USB control message delay quirk for a few specific Marantz/Denon devices. Without the delay the DACs will not work properly and produces the following type of messages: Nov 15 10:09:21 orwell kernel: [ 91.342880] usb 3-13: clock source 41 is not valid, cannot use Nov 15 10:09:21 orwell kernel: [ 91.343775] usb 3-13: clock source 41 is not valid, cannot use There are likely other Marantz/Denon devices using the same USB module which exhibit the same problems. But as this cannot be verified I limited the patch to the devices I could test. The following two devices are covered by this path: - Marantz SA-14S1 - Marantz HD-DAC1 Signed-off-by:
Jurgen Kramer <gtmkramer@xs4all.nl> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Alexey Khoroshilov authored
commit efbd50d2 upstream. It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds the missing deallocation. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by:
Matthias Fuchs <matthias.fuchs@esd.eu> Signed-off-by:
-
Lu Baolu authored
commit a1377e53 upstream. When system is being suspended, if host device is not allowed to do wakeup, xhci_suspend() needs to clear all root port wake on bits. Otherwise, some platforms may generate spurious wakeup, even if PCI PME# is disabled. The initial commit ff8cbf25 ("xhci: clear root port wake on bits"), which also got into stable, turned out to not work correctly and had to be reverted, and is now rewritten. Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Suggested-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit c3492dbf upstream. A halted endpoint ring must first be reset, then move the ring dequeue pointer past the problematic TRB. If we start the ring too early after reset, but before moving the dequeue pointer we will end up executing the same problematic TRB again. As we always issue a set transfer dequeue command after a reset endpoint command we can skip starting endpoint rings at reset endpoint command completion. Without this fix we end up trying to handle the same faulty TD for contol endpoints. causing timeout, and failing testusb ctrl_out write tests. Fixes: e9df17eb (USB: xhci: Correct assumptions about number of rings per endpoint.) Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Hans de Goede authored
commit 263e80b4 upstream. This wireless mouse receiver needs a reset-resume quirk to properly come out of reset. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Troy Clark authored
commit 204ec6e0 upstream. Add PIDs for new Matrix Orbital GTT series products. Signed-off-by:
Troy Clark <tclark@matrixorbital.ca> [johan: shorten commit message ] Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Preston Fick authored
commit ffcfe30e upstream. Signed-off-by:
Preston Fick <pffick@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 5d1678a3 upstream. Fix handling of TTY error flags, which are not bitmasks and must specifically not be ORed together as this prevents the line discipline from recognising them. Also insert null characters when reporting overrun errors as these are not associated with the received character. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Johan Hovold authored
commit 855515a6 upstream. Fix reporting of overrun errors, which are not associated with a character. Instead insert a null character and report only once. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Johan Hovold authored
commit 75bcbf29 upstream. Fix reporting of overrun errors, which should only be reported once using the inserted null character. Fixes: 6b8f1ca5 ("USB: ssu100: set tty_flags in ssu100_process_packet") Signed-off-by:
-
Larry Finger authored
commit 6d4556fc upstream. The DLink GO-USB-N150 with revision B1 uses this driver. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Cristina Ciocan authored
commit ccf54555 upstream. The direction field is set on 7 bits, thus we need to AND it with 0111 111 mask in order to retrieve it, that is 0x7F, not 0xCF as it is now. Fixes: ade7ef7b (staging:iio: Differential channel handling) Signed-off-by:
Cristina Ciocan <cristina.ciocan@intel.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Laurent Dufour authored
commit 3b8a3c01 upstream. On pseries system (LPAR) xmon failed to enter when running in LE mode, system is hunging. Inititating xmon will lead to such an output on the console: SysRq : Entering xmon cpu 0x15: Vector: 0 at [c0000003f39ffb10] pc: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70 lr: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70 sp: c0000003f39ffc70 msr: 8000000000009033 current = 0xc0000003fafa7180 paca = 0xc000000007d75e80 softe: 0 irq_happened: 0x01 pid = 14617, comm = bash Bad kernel stack pointer fafb4b0 at eca7cc4 cpu 0x15: Vector: 300 (Data Access) at [c000000007f07d40] pc: 000000000eca7cc4 lr: 000000000eca7c44 sp: fafb4b0 msr: 8000000000001000 dar: 10000000 dsisr: 42000000 current = 0xc0000003fafa7180 paca = 0xc000000007d75e80 softe: 0 irq_happened: 0x01 pid = 14617, comm = bash cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop xmon: WARNING: bad recursive fault on cpu 0x15 The root cause is that xmon is calling RTAS to turn off the surveillance when entering xmon, and RTAS is requiring big endian parameters. This patch is byte swapping the RTAS arguments when running in LE mode. Signed-off-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 415072a0 upstream. Instead of the arch specific quirk which we are deprecating Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 746c9e9f upstream. We have a historical hack that treats missing ranges properties as the equivalent of an empty one. This is needed for ancient PowerMac "bad" device-trees, and shouldn't be enabled for any other PowerPC platform, otherwise we get some nasty layout of devices in sysfs or even duplication when a set of otherwise identically named devices is created multiple times under a different parent node with no ranges property. This fix is needed for the PowerNV i2c busses to be exposed properly and will fix a number of other embedded cases. Signed-off-by:
Grant Likely <grant.likely@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Miaoqing Pan authored
commit 4e6ce4dc upstream. Based on the reference clock, which could be 25MHz or 40MHz, AR_RTC_DERIVED_CLK is programmed differently for AR9340 and AR9550. But, when a chip reset is done, processing the initvals sets the register back to the default value. Fix this by moving the code in ath9k_hw_init_pll() to ar9003_hw_override_ini(). Also, do this override for AR9531. js: remove AR_SREV_9531 test as 9531 support is not in 3.12 yet Signed-off-by:
Miaoqing Pan <miaoqing@qca.qualcomm.com> Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Takashi Iwai authored
commit ea9d0d77 upstream. DPCM can update the FE/BE connection states totally asynchronously from the FE's PCM state. Most of FE/BE state changes are protected by mutex, so that they won't race, but there are still some actions that are uncovered. For example, suppose to switch a BE while a FE's stream is running. This would call soc_dpcm_runtime_update(), which sets FE's runtime_update flag, then sets up and starts BEs, and clears FE's runtime_update flag again. When a device emits XRUN during this operation, the PCM core triggers snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this isn't blocked by the mutex, thus it kicks off DPCM's trigger action. It eventually updates and clears FE's runtime_update flag while soc_dpcm_runtime_update() is running concurrently, and it results in confusion. Usually, for avoiding such a race, we take a lock. There is a PCM stream lock for that purpose. However, as already mentioned, the trigger action is atomic, and we can't take the lock for the whole soc_dpcm_runtime_update() or other operations that include the lengthy jobs like hw_params or prepare. This patch provides an alternative solution. This adds a way to defer the conflicting trigger callback to be executed at the end of FE/BE state changes. For doing it, two things are introduced: - Each runtime_update state change of FEs is protected via PCM stream lock. - The FE's trigger callback checks the runtime_update flag. If it's not set, the trigger action is executed there. If set, mark the pending trigger action and returns immediately. - At the exit of runtime_update state change, it checks whether the pending trigger is present. If yes, it executes the trigger action at this point. Reported-and-tested-by:
Qiao Zhou <zhouqiao@marvell.com> Signed-off-by:
Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by:
-
Charles Keepax authored
commit 9da7a5a9 upstream. We should not free any buffers associated with writing out coefficients to the DSP until all the async writes have completed. This patch updates the out of memory path when allocating a new buffer to include a call to regmap_async_complete. Reported-by:
JS Park <aitdark.park@samsung.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Fabio Estevam authored
commit c251ea7b upstream. On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound to happen 5 seconds after the end of a playback. The SMALL_POP bit should fix this, but its definition is incorrect: according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not bit 1. Fix the definition accordingly and enable the bit as intended per the code comment. After applying this change, no loud 'click' sound is heard after playback Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Kuninori Morimoto authored
commit c1b9b9b1 upstream. FSI doesn't support PAUSE. Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Kuninori Morimoto authored
commit 706c6621 upstream. R-Car sound doesn't support PAUSE. Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info Signed-off-by:
-
Or Gerlitz authored
commit f57915cf upstream. This patch adds a max_send_sge=2 minimum in isert_conn_setup_qp() to ensure outgoing control PDU responses with tx_desc->num_sge=2 are able to function correctly. This addresses a bug with RDMA hardware using dev_attr.max_sge=3, that in the original code with the ConnectX-2 work-around would result in isert_conn->max_sge=1 being negotiated. Originally reported by Chris with ocrdma driver. Reported-by:
Chris Moore <Chris.Moore@emulex.com> Tested-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Chris Moore authored
commit b1a5ad00 upstream. isert has an issue of trying to create a CQ with more CQEs than are supported by the hardware, that currently results in failures during isert_device creation during first session login. This is the isert version of the patch that Minh Tran submitted for iser, and is simple a workaround required to function with existing ocrdma hardware. Signed-off-by:
-
Maxime Ripard authored
commit 6bab4a8a upstream. The interrupts were activated and the handler registered before the clockevent was registered in the probe function. The interrupt handler, however, was making the assumption that the clockevent device was registered. That could cause a null pointer dereference if the timer interrupt was firing during this narrow window. Fix that by moving the clockevent registration before the interrupt is enabled. Reported-by:
Roman Byshko <rbyshko@gmail.com> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit f144d149 upstream. This can be set by quirks/drivers to be used by the architecture code that assigns the MSI addresses. We additionally add verification in the core MSI code that the values assigned by the architecture do satisfy the limitation in order to fail gracefully if they don't (ie. the arch hasn't been updated to deal with that quirk yet). Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Andy Lutomirski authored
commit 82975bc6 upstream. x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set but not on non-paranoid returns. I suspect that this is a mistake and that the code only works because int3 is paranoid. Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a workaround for the x86 bug. With that bug fixed, we can remove _TIF_NOTIFY_RESUME from the uprobes code. Reported-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Kees Cook authored
commit 45e2a9d4 upstream. When setting up permissions on kernel memory at boot, the end of the PMD that was split from bss remained executable. It should be NX like the rest. This performs a PMD alignment instead of a PAGE alignment to get the correct span of memory. Before: ---[ High Kernel Mapping ]--- ... 0xffffffff8202d000-0xffffffff82200000 1868K RW GLB NX pte 0xffffffff82200000-0xffffffff82c00000 10M RW PSE GLB NX pmd 0xffffffff82c00000-0xffffffff82df5000 2004K RW GLB NX pte 0xffffffff82df5000-0xffffffff82e00000 44K RW GLB x pte 0xffffffff82e00000-0xffffffffc0000000 978M pmd After: ---[ High Kernel Mapping ]--- ... 0xffffffff8202d000-0xffffffff82200000 1868K RW GLB NX pte 0xffffffff82200000-0xffffffff82e00000 12M RW PSE GLB NX pmd 0xffffffff82e00000-0xffffffffc0000000 978M pmd [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment. We really should unmap the reminder along with the holes caused by init,initdata etc. but thats a different issue ] Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Toshi Kani <toshi.kani@hp.com> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Wang Nan <wangnan0@huawei.com> Cc: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.netSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
