commit 9960914954298eafb09f21ac1b042c79032f271f Author: Greg Kroah-Hartman Date: Fri Feb 6 06:53:48 2015 -0800 Linux 3.18.6 commit a6df13631781815752638547a49222610929f89e Author: Stefano Stabellini Date: Fri Nov 21 11:07:39 2014 +0000 xen/arm/arm64: introduce xen_arch_need_swiotlb commit a4dba130891271084344c12537731542ec77cb85 upstream. Introduce an arch specific function to find out whether a particular dma mapping operation needs to bounce on the swiotlb buffer. On ARM and ARM64, if the page involved is a foreign page and the device is not coherent, we need to bounce because at unmap time we cannot execute any required cache maintenance operations (we don't know how to find the pfn from the mfn). No change of behaviour for x86. Signed-off-by: Stefano Stabellini Reviewed-by: David Vrabel Reviewed-by: Catalin Marinas Acked-by: Ian Campbell Acked-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit b2f21d1b7bc80150f2b7d1fecae5f64c9ead26fa Author: Catalin Marinas Date: Wed Dec 10 11:02:09 2014 +0000 clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64 commit d6ad36913083d683aad4e02e53580c995f1a6ede upstream. Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical timers when requested) introduces the use of physical counters in the ARM architected timer driver. However, he arm64 kernel uses CNTVCT in VDSO. When booting in EL2, the kernel switches to the physical timers to make things easier for KVM but it continues to use the virtual counter both in user and kernel. While in such scenario CNTVCT == CNTPCT (since CNTVOFF is initialised by the kernel to 0), we want to spot firmware bugs corrupting CNTVOFF early (which would affect CNTVCT). Signed-off-by: Catalin Marinas Tested-by: Yingjoe Chen Cc: Daniel Lezcano Signed-off-by: Arnd Bergmann Fixes: 0b46b8a718c6 ("clocksource: arch_timer: Fix code to use physical timers when requested") Cc: Ian Campbell Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit 793332a4439c431437b26ebcdef7833f46464d06 Author: Viktor Babrian Date: Sun Jan 18 20:01:40 2015 +0100 can: c_can: end pending transmission on network stop (ifdown) commit 7ffd7b4e169d619e66928fe5d997723f2c6f1056 upstream. Put controller into init mode in network stop to end pending transmissions. The issue is observed in cases when transmitted frame is not acked. Signed-off-by: Viktor Babrian Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 427a5746b4215b154efb85b07781799b79f8958c Author: Andrew Duggan Date: Mon Dec 8 15:01:59 2014 -0800 HID: rmi: Check for additional ACM registers appended to F11 data report commit 8414947a2018a98cf3adc975dc279f41ba30ab11 upstream. If a touchpad reports the F11 data40 register then this indicates that the touchpad reports additional ACM (Accidental Contact Mitigation) data after the F11 data in the HID attention report. These additional bytes shift the position of the F30 button data causing the driver to incorrectly report button state when this functionality is present. This patch accounts for the additional data in the report. Fixes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398533 Signed-off-by: Andrew Duggan Signed-off-by: Jiri Kosina Cc: Joseph Salisbury Signed-off-by: Greg Kroah-Hartman commit ce9555406a478683c4d4641ae8b0b35845084c39 Author: Stephane Eranian Date: Thu Jan 22 21:38:34 2015 +0100 perf/rapl: Fix crash in rapl_scale() commit 98b008dff8452653909d9263efda925873e8d8bb upstream. This patch fixes a systematic crash in rapl_scale() due to an invalid pointer. The bug was introduced by commit: 89cbc76768c2 ("x86: Replace __get_cpu_var uses") The fix is simple. Just put the parenthesis where it needs to be, i.e., around rapl_pmu. To my surprise, the compiler was not complaining about passing an integer instead of a pointer. Reported-by: Vince Weaver Tested-by: Vince Weaver Fixes: 89cbc76768c2 ("x86: Replace __get_cpu_var uses") Signed-off-by: Stephane Eranian Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: cl@linux.com Cc: Linus Torvalds Link: http://lkml.kernel.org/r/20150122203834.GA10228@thinkpad Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 09c0adc9931641d16412fc4d955861680f49c9b0 Author: Kan Liang Date: Thu Jan 22 07:50:53 2015 +0000 perf/x86/intel: Add model number for Airmont commit ef454caeb740ee4e1b89aeb7f7692d5ddffb6830 upstream. Intel Airmont supports the same architectural and non-architectural performance monitoring events as Silvermont. Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Linus Torvalds Link: http://lkml.kernel.org/r/1421913053-99803-1-git-send-email-kan.liang@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 5a4a00b10aaf65d5a2a49f0691aa64118666d85e Author: Greg Thelen Date: Mon Jan 26 12:58:38 2015 -0800 memcg: remove extra newlines from memcg oom kill log commit 0346dadbf041a2606bcb5bd27828b0d105897f4a upstream. Commit e61734c55c24 ("cgroup: remove cgroup->name") added two extra newlines to memcg oom kill log messages. This makes dmesg hard to read and parse. The issue affects 3.15+. Example: Task in /t <<< extra #1 killed as a result of limit of /t <<< extra #2 memory: usage 102400kB, limit 102400kB, failcnt 274712 Remove the extra newlines from memcg oom kill messages, so the messages look like: Task in /t killed as a result of limit of /t memory: usage 102400kB, limit 102400kB, failcnt 240649 Fixes: e61734c55c24 ("cgroup: remove cgroup->name") Signed-off-by: Greg Thelen Acked-by: Michal Hocko Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8a71cc4d0874abd45c479f3e2830470d0dcd8b84 Author: Jan Kara Date: Thu Oct 9 16:03:13 2014 +0200 quota: Switch ->get_dqblk() and ->set_dqblk() to use bytes as space units commit 14bf61ffe6ac54afcd1e888a4407fe16054483db upstream. Currently ->get_dqblk() and ->set_dqblk() use struct fs_disk_quota which tracks space limits and usage in 512-byte blocks. However VFS quotas track usage in bytes (as some filesystems require that) and we need to somehow pass this information. Upto now it wasn't a problem because we didn't do any unit conversion (thus VFS quota routines happily stuck number of bytes into d_bcount field of struct fd_disk_quota). Only if you tried to use Q_XGETQUOTA or Q_XSETQLIM for VFS quotas (or Q_GETQUOTA / Q_SETQUOTA for XFS quotas), you got bogus results. Hardly anyone tried this but reportedly some Samba users hit the problem in practice. So when we want interfaces compatible we need to fix this. We bite the bullet and define another quota structure used for passing information from/to ->get_dqblk()/->set_dqblk. It's somewhat sad we have to have more conversion routines in fs/quota/quota.c and another copying of quota structure slows down getting of quota information by about 2% but it seems cleaner than overloading e.g. units of d_bcount to bytes. Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 77ca136e76732ec03cc71c8b802c5fef8a70e0dd Author: Jeremiah Mahler Date: Mon Jan 12 11:01:03 2015 -0800 drm/i915: fix inconsistent brightness after resume commit 13f3fbe827d09e3182023c8c54058cbf97aa146e upstream. commit 6dda730e55f412a6dfb181cae6784822ba463847 Author: Jani Nikula Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness introduced a bug which resulted in inconsistent brightness levels on different machines. If a suspended was entered with the screen off some machines would resume with the screen at minimum brightness and others at maximum brightness. The following commands can be used to produce this behavior. xset dpms force off sleep 1 sudo systemctl suspend (resume ...) The root cause of this problem is a comparison which checks to see if the backlight level is zero when the panel is enabled. If it is zero, it is set to the maximum level. Unfortunately, not all machines have a minimum level of zero. On those machines the level is left at the minimum instead of begin set to the maximum. Fix the bug by updating the comparison to check for the minimum backlight level instead of zero. Also, expand the comparison for the possible case when the level is less than the minimum. Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness") Signed-off-by: Jeremiah Mahler Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 50a466845fafb078ff44be9389ac767347ff8bc6 Author: David Woodhouse Date: Tue Jan 20 17:21:42 2015 +0000 drm/i915: Init PPGTT before context enable commit f48a01651b1758550c4d3ee65ec726dfa0658780 upstream. Commit 82460d972 ("drm/i915: Rework ppgtt init to no require an aliasing ppgtt") introduced a regression on Broadwell, triggering the following IOMMU fault at startup: vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem dmar: DRHD: handling fault status reg 2 dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000 DMAR:[fault reason 23] Unknown fbcon: inteldrmfb (fb0) is primary device Further commentary from Daniel: I sugggested this change to David after staring at the offending patch for a while. I have no idea and theory whatsoever why this would upset the gpu less than the other way round. But it seems to work. David promised to chase hw people a bit more to get a more meaningful answer. Wrt the comment that this deletes: I've done some digging and afaict loading context before ppgtt enable was once required before our recent restructuring of the context/ppgtt init code: Before that context sw setup (i.e. allocating the default context) and hw setup was smashed together. Also the setup of the default context was the bit that actually allocated the aliasing ppgtt structures. Which is the reason for the context before ppgtt depency. Or was, since with all the untangling there's no no real depency any more (functional, who knows what the hw is doing), so the comment is just stale. Signed-off-by: David Woodhouse Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit bcee607f44722b338e65f62ac5ff426894c704b8 Author: Rodrigo Vivi Date: Mon Jan 19 16:16:15 2015 -0800 drm/i915: BDW Fix Halo PCI IDs marked as ULT. commit 6b96d705f3cf435b0b8835b12c9742513c77fed6 upstream. BDW with PCI-IDs ended in "2" aren't ULT, but HALO. Let's fix it and at least allow VGA to work on this units. v2: forgot ammend and v1 doesn't compile Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220 Cc: Xion Zhang Cc: Guo Jinxian Cc: Jani Nikula Signed-off-by: Rodrigo Vivi Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 817697b83f3c399018c7c6bc25be68c5453b14c8 Author: Bob Paauwe Date: Thu Dec 18 09:51:26 2014 -0800 drm/i915: Only fence tiled region of object. commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream. When creating a fence for a tiled object, only fence the area that makes up the actual tiles. The object may be larger than the tiled area and if we allow those extra addresses to be fenced, they'll get converted to addresses beyond where the object is mapped. This opens up the possiblity of writes beyond the end of object. To prevent this, we adjust the size of the fence to only encompass the area that makes up the actual tiles. The extra space is considered un-tiled and now behaves as if it was a linear object. Testcase: igt/gem_tiled_fence_overflow Reported-by: Dan Hettena Signed-off-by: Bob Paauwe Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit e63fea163319d9784abc0c82aeaef451cc80116e Author: Rob Clark Date: Mon Jan 26 10:11:08 2015 -0500 drm: fix fb-helper vs MST dangling connector ptrs (v2) commit 2148f18fdb45f31ca269a7787fbc24053cd42e70 upstream. VT switch back/forth from console to xserver (for example) has potential to go horribly wrong if a dynamic DP MST connector ends up in the saved modeset that is restored when switching back to fbcon. When removing a dynamic connector, don't forget to clean up the saved state. v1: original v2: null out set->fb if no more connectors to avoid making i915 cranky Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968 Signed-off-by: Rob Clark Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit f1d5aa46638effd121eeccf5fbffc65c55df9403 Author: Mugunthan V N Date: Thu Jan 22 15:19:22 2015 +0530 drivers: net: cpsw: discard dual emac default vlan configuration commit 02a54164c52ed6eca3089a0d402170fbf34d6cf5 upstream. In Dual EMAC, the default VLANs are used to segregate Rx packets between the ports, so adding the same default VLAN to the switch will affect the normal packet transfers. So returning error on addition of dual EMAC default VLANs. Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to break dual EMAC port separations. Fixes: d9ba8f9e6298 (driver: net: ethernet: cpsw: dual emac interface implementation) Reported-by: Felipe Balbi Signed-off-by: Mugunthan V N Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ba31c58d468aa22cc8b9ec0eb896b75a868e4bd1 Author: Ashay Jaiswal Date: Thu Jan 8 18:54:25 2015 +0530 regulator: core: fix race condition in regulator_put() commit 83b0302d347a49f951e904184afe57ac3723476e upstream. The regulator framework maintains a list of consumer regulators for a regulator device and protects it from concurrent access using the regulator device's mutex lock. In the case of regulator_put() the consumer is removed and regulator device's parameters are updated without holding the regulator device's mutex. This would lead to a race condition between the regulator_put() and any function which traverses the consumer list or modifies regulator device's parameters. Fix this race condition by holding the regulator device's mutex in case of regulator_put. Signed-off-by: Ashay Jaiswal Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 198bcce84a87bb9dcdb754d25252b69d7cbe855b Author: Andrey Ryabinin Date: Mon Jan 26 12:58:46 2015 -0800 drivers/rtc/rtc-s5m.c: terminate s5m_rtc_id array with empty element commit 45cd15e600ec8006305ce83f62c7208c2cb7a052 upstream. Array of platform_device_id elements should be terminated with empty element. Fixes: 5bccae6ec458 ("rtc: s5m-rtc: add real-time clock driver for s5m8767") Signed-off-by: Andrey Ryabinin Reviewed-by: Krzysztof Kozlowski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 072ef65108c3fe4d4371da6037922a805c1a9001 Author: Mika Westerberg Date: Mon Dec 29 10:33:36 2014 +0200 spi/pxa2xx: Clear cur_chip pointer before starting next message commit c957e8f084e0d21febcd6b8a0ea9631eccc92f36 upstream. Once the current message is finished, the driver notifies SPI core about this by calling spi_finalize_current_message(). This function queues next message to be transferred. If there are more messages in the queue, it is possible that the driver is asked to transfer the next message at this point. When spi_finalize_current_message() returns the driver clears the drv_data->cur_chip pointer to NULL. The problem is that if the driver already started the next message clearing drv_data->cur_chip will cause NULL pointer dereference which crashes the kernel like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 IP: [] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] PGD 78bb8067 PUD 37712067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G O 3.18.0-rc4-mjo #5 Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014 task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000 RIP: 0010:[] [] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] RSP: 0018:ffff88007a823d08 EFLAGS: 00010202 RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430 RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98 R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000 FS: 0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0 Stack: ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89 0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006 ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204 Call Trace: [] giveback+0x69/0xa0 [spi_pxa2xx_platform] [] pump_transfers+0x710/0x740 [spi_pxa2xx_platform] [] ? pick_next_task_fair+0x744/0x830 [] tasklet_action+0xa9/0xe0 [] __do_softirq+0xee/0x280 [] run_ksoftirqd+0x20/0x40 [] smpboot_thread_fn+0xff/0x1b0 [] ? SyS_setgroups+0x150/0x150 [] kthread+0xcd/0xf0 [] ? kthread_create_on_node+0x180/0x180 [] ret_from_fork+0x7c/0xb0 Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message(). Reported-by: Martin Oldfield Signed-off-by: Mika Westerberg Acked-by: Robert Jarzmik Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d483628b80156d80bf001fa8b55c95b828183fe4 Author: Michel Dänzer Date: Thu Jan 22 18:58:46 2015 +0900 drm/radeon: Restore GART table contents after pinning it in VRAM v3 commit 5636d2f842c7bd7800002868ead3d6b809d385a0 upstream. The GART table BO has to be moved out of VRAM for suspend/resume. Any updates to the GART table during that time were silently dropped without this change. This caused GPU lockups on resume in some cases, see the bug reports referenced below. This might also make GPU reset more robust in some cases, as we no longer rely on the GART table in VRAM being preserved across the GPU lockup/reset. v2: Add logic to radeon_gart_table_vram_pin directly instead of reinstating radeon_gart_restore v3: Move code after assignment of rdev->gart.table_addr so that the GART TLB flush can work as intended, add code comment explaining why we're doing this Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267 Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 588039c3367dffaf19775468528d57e904c965fb Author: Michel Dänzer Date: Wed Jan 21 17:36:35 2015 +0900 drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry commit cb65890610dca287718a63bd8a5d9ce3dc80c3d7 upstream. get_page_entry calculates the GART page table entry, which is just written to the GART page table by set_page_entry. This is a prerequisite for the following fix. Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c818bed668ca4e1848b93d9c914de5116c5add09 Author: Thomas Hellstrom Date: Wed Jan 14 02:33:39 2015 -0800 drm/vmwgfx: Replace the hw mutex with a hw spinlock commit 496eb6fd2c3fd13f4b914e537598e5c86ce4f52a upstream. Fixes a case where we call vmw_fifo_idle() from within a wait function with task state !TASK_RUNNING, which is illegal. In addition, make the locking fine-grained, so that it is performed once for every read- and write operation. This is of course more costly, but we don't perform much register access in the timing critical paths anyway. Instead we have the extra benefit of being sure that we don't forget the hw lock around register accesses. I think currently the kms code was quite buggy w r t this. This fixes Red Hat Bugzilla Bug 1180796 Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Greg Kroah-Hartman commit bc8eeafab3b7e4f79ea422d50753160a005f4e15 Author: Joe Thornber Date: Wed Jan 28 12:07:46 2015 +0000 dm cache: fix missing ERR_PTR returns and handling commit 766a78882ddf79b162243649d7dfdbac1fb6fb88 upstream. Commit 9b1cc9f251 ("dm cache: share cache-metadata object across inactive and active DM tables") mistakenly ignored the use of ERR_PTR returns. Restore missing IS_ERR checks and ERR_PTR returns where appropriate. Reported-by: Dan Carpenter Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit e046f3ddf3568776755e165baffb8067125511dc Author: Joe Thornber Date: Mon Jan 26 11:38:21 2015 +0000 dm thin: don't allow messages to be sent to a pool target in READ_ONLY or FAIL mode commit 2a7eaea02b99b6e267b1e89c79acc6e9a51cee3b upstream. You can't modify the metadata in these modes. It's better to fail these messages immediately than let the block-manager deny write locks on metadata blocks. Otherwise these failed metadata changes will trigger 'needs_check' to get set in the metadata superblock -- requiring repair using the thin_check utility. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 6ab11bbf0eeed2bf7a2bfb3a7880a0bbed10cbd9 Author: Thomas Petazzoni Date: Wed Jan 28 12:55:45 2015 +0100 ARM: mvebu: don't set the PL310 in I/O coherency mode when I/O coherency is disabled commit dcad68876c21bac709b01eda24e39d4410dc36a8 upstream. Since commit f2c3c67f00 (merge commit that adds commit "ARM: mvebu: completely disable hardware I/O coherency"), we disable I/O coherency on Armada EBU platforms. However, we continue to initialize the coherency fabric, because this coherency fabric is needed on Armada XP for inter-CPU coherency. Unfortunately, due to this, we also continued to execute the coherency fabric initialization code for Armada 375/38x, which switched the PL310 into I/O coherent mode. This has the effect of disabling the outer cache sync operation: this is needed when I/O coherency is enabled to work around a PCIe/L2 deadlock. But obviously, when I/O coherency is disabled, having the outer cache sync operation is crucial. Therefore, this commit fixes the armada_375_380_coherency_init() so that the PL310 is switched to I/O coherent mode only if I/O coherency is enabled. Without this fix, all devices using DMA are broken on Armada 375/38x. Signed-off-by: Thomas Petazzoni Acked-by: Gregory CLEMENT Tested-by: Gregory CLEMENT Signed-off-by: Andrew Lunn Signed-off-by: Greg Kroah-Hartman commit d5b481842040c799a4e5cec6089d8853d8f540f9 Author: Jean-Christophe PLAGNIOL-VILLARD Date: Fri Jan 16 16:31:05 2015 +0100 pinctrl: at91: allow to have disabled gpio bank commit a0b957f306fa4d0a39f4ffe5e5e25e856e6be46e upstream. Today we expect that all the bank are enabled, and count the number of banks used by the pinctrl based on it instead of using the last bank id enabled. So switch to it, set the chained IRQ at runtime based on enabled banks and wait only the number of enabled gpio controllers at probe time. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Ludovic Desroches Acked-by: Nicolas Ferre Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit a916db4b2568837bc2f5bc3e2a97329af26c8dc4 Author: Johannes Berg Date: Fri Jan 23 11:10:12 2015 +0100 nl80211: fix per-station group key get/del and memory leak commit 0fa7b39131576dd1baa6ca17fca53c65d7f62249 upstream. In case userspace attempts to obtain key information for or delete a unicast key, this is currently erroneously rejected unless the driver sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it was never noticed. Fix that, and while at it fix a potential memory leak: the error path in the get_key() function was placed after allocating a message but didn't free it - move it to a better place. Luckily admin permissions are needed to call this operation. Fixes: e31b82136d1ad ("cfg80211/mac80211: allow per-station GTKs") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d75bd2a69490b16806f08ab79f4078e8d8bcbe6c Author: Luciano Coelho Date: Wed Jan 21 22:19:34 2015 +0200 mac80211: only roll back station states for WDS when suspending commit 2af81d6718f5ec92b1d787e0fe79b0d3b6f78601 upstream. In normal cases (i.e. when we are fully associated), cfg80211 takes care of removing all the stations before calling suspend in mac80211. But in the corner case when we suspend during authentication or association, mac80211 needs to roll back the station states. But we shouldn't roll back the station states in the suspend function, because this is taken care of in other parts of the code, except for WDS interfaces. For AP types of interfaces, cfg80211 takes care of disconnecting all stations before calling the driver's suspend code. For station interfaces, this is done in the quiesce code. For WDS interfaces we still need to do it here, so move the code into a new switch case for WDS. Signed-off-by: Luciano Coelho Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit aefbc0b5c64ca719760ccb2cf26f0a3e313a57d9 Author: Mathy Vanhoef Date: Tue Jan 20 15:05:08 2015 +0100 mac80211: properly set CCK flag in radiotap commit 3a5c5e81d8128a9e43abc52b75dd21d3da7a0cfc upstream. Fix a regression introduced by commit a5e70697d0c4 ("mac80211: add radiotap flag and handling for 5/10 MHz") where the IEEE80211_CHAN_CCK channel type flag was incorrectly replaced by the IEEE80211_CHAN_OFDM flag. This commit fixes that by using the CCK flag again. Fixes: a5e70697d0c4 ("mac80211: add radiotap flag and handling for 5/10 MHz") Signed-off-by: Mathy Vanhoef Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 0c217359ae6264d1747ded9d55dc0929f0e9b890 Author: Trond Myklebust Date: Wed Jan 21 14:37:44 2015 -0500 NFSv4.1: Fix an Oops in nfs41_walk_client_list commit 3175e1dcec40fab1a444c010087f2068b6b04732 upstream. If we start state recovery on a client that failed to initialise correctly, then we are very likely to Oops. Reported-by: "Mkrtchyan, Tigran" Link: http://lkml.kernel.org/r/130621862.279655.1421851650684.JavaMail.zimbra@desy.de Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 19387f4d87f68cb8e8c7388a27c43b5e1b7a3b59 Author: Peng Tao Date: Tue Jan 20 07:44:29 2015 +0800 nfs: fix dio deadlock when O_DIRECT flag is flipped commit ee8a1a8b160a87dc3a9c81a86796aa4db85ea815 upstream. We only support swap file calling nfs_direct_IO. However, application might be able to get to nfs_direct_IO if it toggles O_DIRECT flag during IO and it can deadlock because we grab inode->i_mutex in nfs_file_direct_write(). So return 0 for such case. Then the generic layer will fall back to buffer IO. Signed-off-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 203ba54a3d85ed962f96421f78afe61016bdf514 Author: Jochen Hein Date: Thu Jan 22 12:03:15 2015 -0800 Input: i8042 - add noloop quirk for Medion Akoya E7225 (MD98857) commit 1d90d6d5522befa8efa1a7ea406be65cf865ded4 upstream. Without this the aux port does not get detected, and consequently the touchpad will not work. With this patch the touchpad is detected: $ dmesg | grep -E "(SYN|i8042|serio)" pnp 00:03: Plug and Play ACPI device, IDs SYN1d22 PNP0f13 (active) i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126800, board id: 2863, fw id: 1473085 input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6 dmidecode excerpt for this laptop is: Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Medion Product Name: Akoya E7225 Version: 1.0 Signed-off-by: Jochen Hein Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 424befd7b14a74e1d3b50c1cb7575077dc00fc97 Author: Rainer Koenig Date: Tue Jan 27 15:15:11 2015 -0800 Input: elantech - add more Fujtisu notebooks to force crc_enabled commit 47c1ffb2b6b630894e9a16442611c056ab21c057 upstream. Add two more Fujitsu LIFEBOOK models that also ship with the Elantech touchpad and don't work with crc_disabled to the quirk list. Signed-off-by: Rainer Koenig Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 74a0ac496f2faf5be7ea75f32e6cd3d77b1a6204 Author: Peter Hutterer Date: Mon Jan 19 16:29:25 2015 -0800 Input: synaptics - adjust min/max for Lenovo ThinkPad X1 Carbon 2nd commit 8543cf1c247909ce85850ca6e2714adba351d6aa upstream. LEN0037 found in the Lenovo ThinkPad X1 Carbon 2nd (2014 model) Reported-and-tested-by: Bjoern Olausson Signed-off-by: Peter Hutterer Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 5e1b35cfd680fe9d67bb2754393ff8e1e8ddf713 Author: Paul Osmialowski Date: Mon Jan 19 17:03:33 2015 +0100 i2c: s3c2410: fix ABBA deadlock by keeping clock prepared commit 34e81ad5f0b60007c95995eb7803da7e00c6c611 upstream. This patch solves deadlock between clock prepare mutex and regmap mutex reported by Tomasz Figa in [1] by implementing solution from [2]: "always leave the clock of the i2c controller in a prepared state". [1] https://lkml.org/lkml/2014/7/2/171 [2] https://lkml.org/lkml/2014/7/2/207 On each i2c transfer handled by s3c24xx_i2c_xfer(), clk_prepare_enable() was called, which calls clk_prepare() then clk_enable(). clk_prepare() takes prepare_lock mutex before proceeding. Note that i2c transfer functions are invoked from many places in kernel, typically with some other additional lock held. It may happen that function on CPU1 (e.g. regmap_update_bits()) has taken a mutex (i.e. regmap lock mutex) then it attempts i2c communication in order to proceed (so it needs to obtain clock related prepare_lock mutex during transfer preparation stage due to clk_prepare() call). At the same time other task on CPU0 wants to operate on clock (e.g. to (un)prepare clock for some other reason) so it has taken prepare_lock mutex. CPU0: CPU1: clk_disable_unused() regulator_disable() clk_prepare_lock() map->lock(map->lock_arg) regmap_read() s3c24xx_i2c_xfer() map->lock(map->lock_arg) clk_prepare_lock() Implemented solution from [2] leaves i2c clock prepared. Preparation is done in s3c24xx_i2c_probe() function. Without this patch, it is immediately unprepared by clk_disable_unprepare() call. I've replaced this call with clk_disable() and I've added clk_unprepare() call in s3c24xx_i2c_remove(). The s3c24xx_i2c_xfer() function now uses clk_enable() instead of clk_prepare_enable() (and clk_disable() instead of clk_unprepare_disable()). Signed-off-by: Paul Osmialowski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit f1764f870c6743fa2f308601e1003de58b35b931 Author: Hans de Goede Date: Mon Jan 12 13:34:33 2015 +0100 uas: Add no-report-opcodes quirk for Simpletech devices with id 4971:8017 commit 8a870880bd6f17b7ccef69a6432ab8df8775fcf6 upstream. Like some other uas devices these devices hang when a report-opcodes scsi command is send to them. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1124119 Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 6e340560ac33732816cef0c6b11ed04d1efb3839 Author: Dmitry Nezhevenko Date: Mon Jan 12 19:13:01 2015 +0200 usb-storage/SCSI: blacklist FUA on JMicron 152d:2566 USB-SATA controller commit bf5c4136fa5ce471bdbf4cf59a813e32755fd014 upstream. It looks like FUA support is broken on JMicron 152d:2566 bridge: [223159.885704] sd 7:0:0:0: [sdc] Write Protect is off [223159.885706] sd 7:0:0:0: [sdc] Mode Sense: 47 00 10 08 [223159.885942] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA [223283.691677] sd 7:0:0:0: [sdc] [223283.691680] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [223283.691681] sd 7:0:0:0: [sdc] [223283.691682] Sense Key : Illegal Request [current] [223283.691684] sd 7:0:0:0: [sdc] [223283.691685] Add. Sense: Invalid field in cdb [223283.691686] sd 7:0:0:0: [sdc] CDB: [223283.691687] Write(10): 2a 08 15 d0 83 0d 00 00 01 00 [223283.691690] blk_update_request: critical target error, dev sdc, sector 2927892584 This patch adds blacklist flag so that sd will not use FUA Signed-off-by: Dmitry Nezhevenko Cc: Phil Dibowitz Cc: Alan Stern Signed-off-by: Greg Kroah-Hartman commit f97b23ddb479fe44f6f34dd55aa90cf0e8d6312a Author: Macpaul Lin Date: Fri Jan 23 14:39:02 2015 +0800 USB: Add OTG PET device to TPL commit e5dff0e80463cc3fa236e898ef1491b40be70b19 upstream. OTG device shall support this device for allowing compliance automated testing. The modification is derived from Pavankumar and Vijayavardhans' previous work. Signed-off-by: Macpaul Lin Cc: Pavankumar Kondeti Cc: Vijayavardhan Vennapusa Signed-off-by: Greg Kroah-Hartman commit 0539097d55226ad671f1434763573d4ec8d00ff4 Author: Ilya Dryomov Date: Mon Jan 19 18:13:43 2015 +0300 rbd: fix rbd_dev_parent_get() when parent_overlap == 0 commit ae43e9d05eb4bd324155292f889fbd001c4faea8 upstream. The comment for rbd_dev_parent_get() said * We must get the reference before checking for the overlap to * coordinate properly with zeroing the parent overlap in * rbd_dev_v2_parent_info() when an image gets flattened. We * drop it again if there is no overlap. but the "drop it again if there is no overlap" part was missing from the implementation. This lead to absurd parent_ref values for images with parent_overlap == 0, as parent_ref was incremented for each img_request and virtually never decremented. Fix this by leveraging the fact that refresh path calls rbd_dev_v2_parent_info() under header_rwsem and use it for read in rbd_dev_parent_get(), instead of messing around with atomics. Get rid of barriers in rbd_dev_v2_parent_info() while at it - I don't see what they'd pair with now and I suspect we are in a pretty miserable situation as far as proper locking goes regardless. Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 186eb06e60d4961d03a6404e32ae0aa39eb8a8bf Author: Ilya Dryomov Date: Mon Jan 19 12:06:14 2015 +0300 rbd: drop parent_ref in rbd_dev_unprobe() unconditionally commit e69b8d414f948c242ad9f3eb2b7e24fba783dbbd upstream. This effectively reverts the last hunk of 392a9dad7e77 ("rbd: detect when clone image is flattened"). The problem with parent_overlap != 0 condition is that it's possible and completely valid to have an image with parent_overlap == 0 whose parent state needs to be cleaned up on unmap. The next commit, which drops the "clone image now standalone" logic, opens up another window of opportunity to hit this, but even without it # cat parent-ref.sh #!/bin/bash rbd create --image-format 2 --size 1 foo rbd snap create foo@snap rbd snap protect foo@snap rbd clone foo@snap bar rbd resize --allow-shrink --size 0 bar rbd resize --size 1 bar DEV=$(rbd map bar) rbd unmap $DEV leaves rbd_device/rbd_spec/etc and rbd_client along with ceph_client hanging around. My thinking behind calling rbd_dev_parent_put() unconditionally is that there shouldn't be any requests in flight at that point in time as we are deep into unmap sequence. Hence, even if rbd_dev_unparent() caused by flatten is delayed by in-flight requests, it will have finished by the time we reach rbd_dev_unprobe() caused by unmap, thus turning unconditional rbd_dev_parent_put() into a no-op. Fixes: http://tracker.ceph.com/issues/10352 Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit a95d8381459678b518fe3900f058f6b3abdd2c36 Author: Clemens Ladisch Date: Sun Jan 25 14:34:29 2015 +0100 ALSA: seq-dummy: remove deadlock-causing events on close commit 0767e95bb96d7fdddcd590fb809e6975d93aebc5 upstream. When the last subscriber to a "Through" port has been removed, the subscribed destination ports might still be active, so it would be wrong to send "all sounds off" and "reset controller" events to them. The proper place for such a shutdown would be the closing of the actual MIDI port (and close_substream() in rawmidi.c already can do this). This also fixes a deadlock when dummy_unuse() tries to send events to its own port that is already locked because it is being freed. Reported-by: Peter Billam Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 71708851d3e019d6090f46bcff4dff432271a219 Author: Laurent Dufour Date: Thu Jan 15 18:23:47 2015 +0100 powerpc/xmon: Fix another endiannes issue in RTAS call from xmon commit e6eb2eba494d6f99e69ca3c3748cd37a2544ab38 upstream. The commit 3b8a3c010969 ("powerpc/pseries: Fix endiannes issue in RTAS call from xmon") was fixing an endianness issue in the call made from xmon to RTAS. However, as Michael Ellerman noticed, this fix was not complete, the token value was not byte swapped. This lead to call an unexpected and most of the time unexisting RTAS function, which is silently ignored by RTAS. This fix addresses this hole. Reported-by: Michael Ellerman Signed-off-by: Laurent Dufour Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit bccd8fd860a19ee12253c726d08ee4747d46bec9 Author: Ahmed S. Darwish Date: Mon Jan 26 07:25:43 2015 +0200 can: kvaser_usb: Fix state handling upon BUS_ERROR events commit e638642b08c170d2021b706f0b1c4f4ae93d8cbd upstream. While being in an ERROR_WARNING state, and receiving further bus error events with error counters still in the ERROR_WARNING range of 97-127 inclusive, the state handling code erroneously reverts back to ERROR_ACTIVE. Per the CAN standard, only revert to ERROR_ACTIVE when the error counters are less than 96. Moreover, in certain Kvaser models, the BUS_ERROR flag is always set along with undefined bits in the M16C status register. Thus use bitwise operators instead of full equality for checking that register against bus errors. Signed-off-by: Ahmed S. Darwish Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 1c13b0f01abf717dee7e2637fea78b971f867e85 Author: Ahmed S. Darwish Date: Mon Jan 26 07:24:06 2015 +0200 can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT commit 14c10c2a1dd8eb8e00b750b521753260befa2789 upstream. On some x86 laptops, plugging a Kvaser device again after an unplug makes the firmware always ignore the very first command. For such a case, provide some room for retries instead of completely exiting the driver init code. Signed-off-by: Ahmed S. Darwish Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 40b50e09ad8b82c84b9f325a723fafea84352338 Author: Ahmed S. Darwish Date: Mon Jan 26 07:22:54 2015 +0200 can: kvaser_usb: Send correct context to URB completion commit 3803fa6977f1de15fda4e8646c8fec97c8045cae upstream. Send expected argument to the URB completion hander: a CAN netdevice instead of the network interface private context `kvaser_usb_net_priv'. This was discovered by having some garbage in the kernel log in place of the netdevice names: can0 and can1. Signed-off-by: Ahmed S. Darwish Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 97a4392559eddacf1e6b1b227706e15f902da930 Author: Ahmed S. Darwish Date: Mon Jan 26 07:20:39 2015 +0200 can: kvaser_usb: Do not sleep in atomic context commit ded5006667318c06df875609535176bd33f243a1 upstream. Upon receiving a hardware event with the BUS_RESET flag set, the driver kills all of its anchored URBs and resets all of its transmit URB contexts. Unfortunately it does so under the context of URB completion handler `kvaser_usb_read_bulk_callback()', which is often called in an atomic context. While the device is flooded with many received error packets, usb_kill_urb() typically sleeps/reschedules till the transfer request of each killed URB in question completes, leading to the sleep in atomic bug. [3] In v2 submission of the original driver patch [1], it was stated that the URBs kill and tx contexts reset was needed since we don't receive any tx acknowledgments later and thus such resources will be locked down forever. Fortunately this is no longer needed since an earlier bugfix in this patch series is now applied: all tx URB contexts are reset upon CAN channel close. [2] Moreover, a BUS_RESET is now treated _exactly_ like a BUS_OFF event, which is the recommended handling method advised by the device manufacturer. [1] http://article.gmane.org/gmane.linux.network/239442 http://www.webcitation.org/6Vr2yagAQ [2] can: kvaser_usb: Reset all URB tx contexts upon channel close 889b77f7fd2bcc922493d73a4c51d8a851505815 [3] Stacktrace: [] dump_stack+0x45/0x57 [] __schedule_bug+0x41/0x4f [] __schedule+0x5f1/0x700 [] ? _raw_spin_unlock_irqrestore+0xa/0x10 [] schedule+0x24/0x70 [] usb_kill_urb+0x65/0xa0 [] ? prepare_to_wait_event+0x110/0x110 [] usb_kill_anchored_urbs+0x48/0x80 [] kvaser_usb_unlink_tx_urbs+0x18/0x50 [kvaser_usb] [] kvaser_usb_rx_error+0xc0/0x400 [kvaser_usb] [] ? vprintk_default+0x1a/0x20 [] kvaser_usb_read_bulk_callback+0x4c1/0x5f0 [kvaser_usb] [] __usb_hcd_giveback_urb+0x5e/0xc0 [] usb_hcd_giveback_urb+0x41/0x110 [] finish_urb+0x98/0x180 [ohci_hcd] [] ? acct_account_cputime+0x17/0x20 [] ? local_clock+0x15/0x30 [] ohci_work+0x1fb/0x5a0 [ohci_hcd] [] ? process_backlog+0xb1/0x130 [] ohci_irq+0xeb/0x270 [ohci_hcd] [] usb_hcd_irq+0x21/0x30 [] handle_irq_event_percpu+0x43/0x120 [] handle_irq_event+0x3d/0x60 [] handle_fasteoi_irq+0x74/0x110 [] handle_irq+0x1d/0x30 [] do_IRQ+0x57/0x100 [] common_interrupt+0x6a/0x6a Signed-off-by: Ahmed S. Darwish Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit f9525833c02ce8a78953bbc4d0b489c9569e7be1 Author: Jan Kara Date: Wed Jan 28 08:38:20 2015 +0100 udf: Release preallocation on last writeable close commit b07ef35244424cbeda9844198607c7077099c82c upstream. Commit 6fb1ca92a640 "udf: Fix race between write(2) and close(2)" changed the condition when preallocation is released. The idea was that we don't want to release the preallocation for an inode on close when there are other writeable file descriptors for the inode. However the condition was written in the opposite way so we released preallocation only if there were other writeable file descriptors. Fix the problem by changing the condition properly. Fixes: 6fb1ca92a6409a9d5b0696447cd4997bc9aaf5a2 Reported-by: Fabian Frederick Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 75229a2678e7f1eaaaeb02a28685c61990d77f47 Author: Peter Ujfalusi Date: Fri Jan 16 11:20:25 2015 +0200 ASoC: omap-mcbsp: Correct CBM_CFS dai format configuration commit 20602e34cd33dd452bc1836fa7c9b59978f75db0 upstream. We should select FSR also to be driven by McBSP, not only FSX. Signed-off-by: Peter Ujfalusi Acked-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c78af348836a8d91fddc033ae68bee5dc76241c7 Author: Geert Uytterhoeven Date: Tue Jan 13 21:03:37 2015 +0100 ASoC: simple-card: Fix crash in asoc_simple_card_unref() commit 7ddfdb5c5a5b51bdd2cb749d8341d763b079d520 upstream. If asoc_simple_card_probe() fails, asoc_simple_card_unref() may be called before dev_set_drvdata(), causing a NULL pointer dereference in asoc_simple_card_unref(): Unable to handle kernel NULL pointer dereference at virtual address 000000d4 ... PC is at asoc_simple_card_unref+0x14/0x48 LR is at asoc_simple_card_probe+0x3d4/0x40c This typically happens because asoc_simple_card_parse_of() returns -EPROBE_DEFER, but other failure modes are possible. devm_snd_soc_register_card()/snd_soc_register_card() may fail either before or after dev_set_drvdata(). Pass a snd_soc_card pointer instead of a platform_device pointer to asoc_simple_card_unref() to fix this. Note that if CONFIG_OF_DYNAMIC=n, of_node_put() is a dummy, and gcc may optimize away the loop over card->dai_link, never actually dereferencing card, and thus avoiding the crash... Signed-off-by: Geert Uytterhoeven Fixes: e512e001dafa54e5 ("ASoC: simple-card: Fix the reference count of device nodes") Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 971784f01272ee66ad16d01837203a701f5bbcab Author: Qais Yousef Date: Wed Jan 14 08:47:29 2015 +0000 ASoC: soc-compress.c: fix NULL dereference commit d3268a40d4b19ff7bee23f52eabbc4e96bb685e8 upstream. In soc_new_compress() when rtd->dai_link->dynamic is set, we create the pcm substreams with this call: ret = snd_pcm_new_internal(rtd->card->snd_card, new_name, num, 1, 0, &be_pcm); which passes 0 as capture_count leading to be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream being NULL, hence when trying to set rtd a few lines below we get an oops. Fix by using rtd->dai_link->dpcm_playback and rtd->dai_link->dpcm_capture as playback_count and capture_count to snd_pcm_new_internal(). Signed-off-by: Qais Yousef Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 260571582b72d12cfbd38b76ff5e4c43820ed08c Author: Aurelien BOUIN Date: Mon Dec 29 16:13:51 2014 -0800 ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers commit adc60298c80efef4c2d7a7860b91b450931a7cf8 upstream. The xDC field should have 5 bit width according to Reference Manual. Thus this patch fixes it. Signed-off-by: Aurelien BOUIN Signed-off-by: Nicolin Chen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2b298f993f0b33bd02085bb0cc31e6c11d17389b Author: Peter Rosin Date: Thu Jan 8 22:56:30 2015 +0100 ASoC: pcm512x: Fix DSP program selection commit 3a8e5019846736046c0af9dbee3f921c0456141a upstream. The DSP programs are listed out of order. Signed-off-by: Peter Rosin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit aaadfdb3aa857602c74406b068fce5d484504191 Author: Zidan Wang Date: Wed Dec 31 11:39:14 2014 +0800 ASoC: wm8960: Fix capture sample rate from 11250 to 11025 commit 22ee76daddb87f88d2336d1b4737ef27c4f307ac upstream. wm8960 codec can't support sample rate 11250, it must be 11025. Signed-off-by: Zidan Wang Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 338dcaf53e1997a07139016eb62cd42a4dbc15e3 Author: Linus Torvalds Date: Thu Jan 29 11:15:17 2015 -0800 vm: make stack guard page errors return VM_FAULT_SIGSEGV rather than SIGBUS commit 9c145c56d0c8a0b62e48c8d71e055ad0fb2012ba upstream. The stack guard page error case has long incorrectly caused a SIGBUS rather than a SIGSEGV, but nobody actually noticed until commit fee7e49d4514 ("mm: propagate error from stack expansion even for guard page") because that error case was never actually triggered in any normal situations. Now that we actually report the error, people noticed the wrong signal that resulted. So far, only the test suite of libsigsegv seems to have actually cared, but there are real applications that use libsigsegv, so let's not wait for any of those to break. Reported-and-tested-by: Takashi Iwai Tested-by: Jan Engelhardt Acked-by: Heiko Carstens # "s390 still compiles and boots" Cc: linux-arch@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4c0720f26e8ab64144fab7b09e725b986ec540a5 Author: Guenter Roeck Date: Thu Jan 29 19:15:33 2015 -0800 arc: mm: Fix build failure commit e262eb9381ad51b5de7a9e762ee773bbd25ce650 upstream. Fix misspelled define. Fixes: 33692f27597f ("vm: add VM_FAULT_SIGSEGV handling support") Signed-off-by: Guenter Roeck Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit da7f8de9647a8401c36e0bff69dfa58b066a4c47 Author: Linus Torvalds Date: Thu Jan 29 10:51:32 2015 -0800 vm: add VM_FAULT_SIGSEGV handling support commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream. The core VM already knows about VM_FAULT_SIGBUS, but cannot return a "you should SIGSEGV" error, because the SIGSEGV case was generally handled by the caller - usually the architecture fault handler. That results in lots of duplication - all the architecture fault handlers end up doing very similar "look up vma, check permissions, do retries etc" - but it generally works. However, there are cases where the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV. In particular, when accessing the stack guard page, libsigsegv expects a SIGSEGV. And it usually got one, because the stack growth is handled by that duplicated architecture fault handler. However, when the generic VM layer started propagating the error return from the stack expansion in commit fee7e49d4514 ("mm: propagate error from stack expansion even for guard page"), that now exposed the existing VM_FAULT_SIGBUS result to user space. And user space really expected SIGSEGV, not SIGBUS. To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those duplicate architecture fault handlers about it. They all already have the code to handle SIGSEGV, so it's about just tying that new return value to the existing code, but it's all a bit annoying. This is the mindless minimal patch to do this. A more extensive patch would be to try to gather up the mostly shared fault handling logic into one generic helper routine, and long-term we really should do that cleanup. Just from this patch, you can generally see that most architectures just copied (directly or indirectly) the old x86 way of doing things, but in the meantime that original x86 model has been improved to hold the VM semaphore for shorter times etc and to handle VM_FAULT_RETRY and other "newer" things, so it would be a good idea to bring all those improvements to the generic case and teach other architectures about them too. Reported-and-tested-by: Takashi Iwai Tested-by: Jan Engelhardt Acked-by: Heiko Carstens # "s390 still compiles and boots" Cc: linux-arch@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7b483af8df05ac6f74cfad572472d7d25942ef55 Author: Andy Shevchenko Date: Fri Jan 2 17:48:51 2015 +0200 spi: dw-mid: fix FIFO size commit 67bf9cda4b498b8cea4a40be67a470afe57d2e88 upstream. The FIFO size is 40 accordingly to the specifications, but this means 0x40, i.e. 64 bytes. This patch fixes the typo and enables FIFO size autodetection for Intel MID devices. Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support) Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 128e53423c64343f4974fbcb29758a86a40dad35 Author: Axel Lin Date: Mon Jan 5 09:32:56 2015 +0800 spi: dw: Fix detecting FIFO depth commit d297933cc7fcfbaaf2d37570baac73287bf0357d upstream. Current code tries to find the highest valid fifo depth by checking the value it wrote to DW_SPI_TXFLTR. There are a few problems in current code: 1) There is an off-by-one in dws->fifo_len setting because it assumes the latest register write fails so the latest valid value should be fifo - 1. 2) We know the depth could be from 2 to 256 from HW spec, so it is not necessary to test fifo == 257. In the case fifo is 257, it means the latest valid setting is fifo = 256. So after the for loop iteration, we should check fifo == 2 case instead of fifo == 257 if detecting the FIFO depth fails. This patch fixes above issues. Signed-off-by: Axel Lin Reviewed-and-tested-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 179ac907a28e4d890314757f921880121642e3e5 Author: Kees Cook Date: Mon Jan 26 12:58:35 2015 -0800 x86, build: replace Perl script with Shell script commit d69911a68c865b152a067feaa45e98e6bb0f655b upstream. Commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd") added Perl to the required build environment. This reimplements in shell the Perl script used to find the size of the kernel with bss and brk added. Signed-off-by: Kees Cook Reported-by: Rob Landley Acked-by: Rob Landley Cc: Anca Emanuel Cc: Fengguang Wu Cc: Junjie Mao Cc: Kees Cook Cc: Thomas Gleixner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman