commit 8b660f48b5734edc272a008a34207cf1a249fcf7 Author: Greg Kroah-Hartman Date: Sun May 17 09:55:21 2015 -0700 Linux 4.0.4 commit bb57ddb587f9b6d8247dadaf63618d4975b9cfc1 Author: Lv Zheng Date: Mon Apr 13 11:48:52 2015 +0800 ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers. commit 1d0a0b2f6df2bf2643fadc990eb143361eca6ada upstream. ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT and ACPI_FORMAT_UINT64() instead of ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT(). This patch also removes above replaced macros as there are no users. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/b6061237 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman commit be3dd6dec338b18676d350271e9846d019f06192 Author: Lv Zheng Date: Mon Apr 13 11:48:46 2015 +0800 ACPICA: Utilities: Cleanup to convert physical address printing formats. commit cc2080b0e5a7c6c33ef5e9ffccbc2b8f6f861393 upstream. ACPICA commit 7f06739db43a85083a70371c14141008f20b2198 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to convert the %p formats. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/7f06739d Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman commit 9bb209af39b8557d29ff4849871ea4add7557999 Author: Lv Zheng Date: Mon Apr 13 11:48:37 2015 +0800 ACPICA: Utilities: Cleanup to enforce ACPI_PHYSADDR_TO_PTR()/ACPI_PTR_TO_PHYSADDR(). commit 6d3fd3cc33d50e4c0d0c0bd172de02caaec3127c upstream. ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf There are code pieces converting pointers using "(acpi_physical_address) x" or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them. Known issues: 1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field For the conversions around the table fields, it is better to fix it with alignment also fixed. So this patch doesn't modify such code. There should be no functional problem by leaving them unchanged. Link: https://github.com/acpica/acpica/commit/154f6d07 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman commit 58cf89ca90017690deec5e2316b744c02cf845fa Author: Lv Zheng Date: Mon Apr 13 11:48:18 2015 +0800 ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address. commit f254e3c57b9d952e987502aefa0804c177dd2503 upstream. ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman commit 5d457f81823abb832f1531e645bc4bf3ec23c876 Author: Al Viro Date: Fri Apr 3 15:23:17 2015 -0400 coredump: accept any write method commit 86cc05840a0da1afcb6b8151b53f3b606457c91b upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit fe3316751728320ca0e3004f79f2bbfbcc41cd10 Author: Alexey Khoroshilov Date: Sat Apr 18 02:53:25 2015 +0300 sound/oss: fix deadlock in sequencer_ioctl(SNDCTL_SEQ_OUTOFBAND) commit bc26d4d06e337ade069f33d3f4377593b24e6e36 upstream. A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND) on /dev/sequencer with TMR_ECHO midi event. In this case the control flow is: sound_ioctl() -> case SND_DEV_SEQ: case SND_DEV_SEQ2: sequencer_ioctl() -> case SNDCTL_SEQ_OUTOFBAND: spin_lock_irqsave(&lock,flags); play_event(); -> case EV_TIMING: seq_timing_event() -> case TMR_ECHO: seq_copy_to_input() -> spin_lock_irqsave(&lock,flags); It seems that spin_lock_irqsave() around play_event() is not necessary, because the only other call location in seq_startplay() makes the call without acquiring spinlock. So, the patch just removes spinlocks around play_event(). By the way, it removes unreachable code in seq_timing_event(), since (seq_mode == SEQ_2) case is handled in the beginning. Compile tested only. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Takashi Iwai Cc: Willy Tarreau Signed-off-by: Greg Kroah-Hartman commit cef320a4049db294105b9d5d567914ed560820fa Author: Mark Rutland Date: Fri Mar 6 12:08:30 2015 +0100 ARM: 8307/1: psci: move psci firmware calls out of line commit c097877319ab61dd045b6497953b4e3df8f2bb44 upstream. arm64 builds with GCC 5 have caused the __asmeq assertions in the PSCI calling code to fire, so move the ARM PSCI calls out of line into their own assembly file for consistency and to safeguard against the same issue occuring with the 32-bit toolchain. [will: brought into line with arm64 implementation] Reported-by: Andy Whitcroft Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit a44d1844deb25c71881e2ee930f892d2b85a49d2 Author: Takeshi Kihara Date: Thu Apr 30 02:03:51 2015 +0900 mmc: sh_mmcif: Fix timeout value for command request commit bad4371d87d1d1ed1aecd9c9cc21c41ac3f289c8 upstream. f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") changed the timeout value from 1000 jiffies to 1s. In the case where HZ is 1000 the values are the same. However, for smaller HZ values the timeout is now smaller, 1s instead of 10s in the case of HZ=100. Since the timeout occurs in spite of a normal data transfer a timeout of 10s seems more appropriate. This restores the previous timeout in the case where HZ=100 and results in an increase over the previous timeout for larger values of HZ. Fixes: f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") Signed-off-by: Takeshi Kihara [horms: rewrote changelog to refer to HZ] Signed-off-by: Simon Horman Signed-off-by: Yoshihiro Kaneko Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4f61e99e285bd85c617a6fda5e9faaa367dea41d Author: Grygorii Strashko Date: Thu Apr 23 13:43:43 2015 +0300 mmc: core: add missing pm event in mmc_pm_notify to fix hib restore commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream. The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(), as result mmc_rescan() could be scheduled and executed at late hibernation restore stages when MMC device is suspended already - which, in turn, will lead to system crash on TI dra7-evm board: WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify(). Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...) Signed-off-by: Grygorii Strashko Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6bf08adad420b7ba8b8c6daf9d45f8dd6216dd27 Author: Chuanxiao Dong Date: Tue Aug 12 12:01:30 2014 +0800 mmc: card: Don't access RPMB partitions for normal read/write commit 4e93b9a6abc0d028daf3c8a00cb77b679d8a4df4 upstream. During kernel boot, it will try to read some logical sectors of each block device node for the possible partition table. But since RPMB partition is special and can not be accessed by normal eMMC read / write CMDs, it will cause below error messages during kernel boot: ... mmc0: Got data interrupt 0x00000002 even though no data operation was in progress. mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00 mmcblk0rpmb: retrying using single block read mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 end_request: I/O error, dev mmcblk0rpmb, sector 0 Buffer I/O error on device mmcblk0rpmb, logical block 0 end_request: I/O error, dev mmcblk0rpmb, sector 8 Buffer I/O error on device mmcblk0rpmb, logical block 1 end_request: I/O error, dev mmcblk0rpmb, sector 16 Buffer I/O error on device mmcblk0rpmb, logical block 2 end_request: I/O error, dev mmcblk0rpmb, sector 24 Buffer I/O error on device mmcblk0rpmb, logical block 3 ... This patch will discard the access request in eMMC queue if it is RPMB partition access request. By this way, it avoids trigger above error messages. Fixes: 090d25fe224c ("mmc: core: Expose access to RPMB partition") Signed-off-by: Yunpeng Gao Signed-off-by: Chuanxiao Dong Tested-by: Michael Shigorin Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d42b3f3da2590c7874571533efa9f64a9520e39a Author: Doug Anderson Date: Fri May 1 09:01:27 2015 -0700 pinctrl: Don't just pretend to protect pinctrl_maps, do it for real commit c5272a28566b00cce79127ad382406e0a8650690 upstream. Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again). A few years ago in (42fed7b pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex. That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this. Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world. Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by: Doug Anderson Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 93b1ce4fd897a37f2cea0a50f647d8c8f2c1b7a5 Author: Christian König Date: Thu May 7 15:19:24 2015 +0200 drm/radeon: more strictly validate the UVD codec commit d52cdfa4a0c6406bbfb33206341eaf1fb1555994 upstream. MPEG 2/4 are only supported since UVD3. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit bc94b3a3124c10470a08c5819b2f31ed66efc3d5 Author: Christian König Date: Thu May 7 15:19:23 2015 +0200 drm/radeon: make UVD handle checking more strict commit a1b403da70e038ca6c6c6fe434d1d873546873a3 upstream. Invalid messages can crash the hw otherwise. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8c59e42272eec940d15b8cf2f7c2324ebb07c2cf Author: Christian König Date: Thu May 7 15:19:22 2015 +0200 drm/radeon: make VCE handle check more strict commit 29c63fe22a17c64e54016040cd882481bd45ee5a upstream. Invalid handles can crash the hw. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3acd0d2a53923c0f6bf205ed50ad2bec39d3c594 Author: monk.liu Date: Tue May 5 09:24:17 2015 +0200 drm/radeon: fix userptr BO unpin bug v3 commit db12973cd581d4e79f4aadd0960948f268d15af7 upstream. Fixing a memory leak with userptrs. v2: clean up the loop, use an iterator instead v3: remove unused variable Signed-off-by: monk.liu Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 88c4cb28e333782838b2101336d75c5765044e4c Author: Alex Deucher Date: Mon May 4 14:35:01 2015 -0400 drm/radeon: don't setup audio on asics that don't support it commit d73a824acc705571c0f47596326d7967fba9a1d9 upstream. bug: https://bugzilla.kernel.org/show_bug.cgi?id=97701 Reported-by: Mikael Pettersson Tested-by: Mikael Pettersson Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a0db475d779ff69c739bcb8a046bee8840d98838 Author: Christian König Date: Fri May 1 12:34:12 2015 +0200 drm/radeon: disable semaphores for UVD V1 (v2) commit 013ead48a843442e63b9426e3bd5df18ca5d054a upstream. Hardware doesn't seem to work correctly, just block userspace in this case. v2: add missing defines Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320 Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ac7e07c8a83db4e9744ea976d405981256b1fddf Author: Xihan Zhang Date: Tue Apr 28 23:48:40 2015 +0800 drm/amdkfd: Initialize sdma vm when creating sdma queue commit 79b066bd76d501cfe8328142153da301f5ca11d1 upstream. This patch fixes a bug where sdma vm wasn't initialized when an sdma queue was created in HWS mode. This caused GPUVM faults to appear on dmesg and it is one of the causes that SDMA queues are not working. Signed-off-by: Xihan Zhang Reviewed-by: Ben Goz Signed-off-by: Oded Gabbay Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5d7e0bf007b984124274cd07e99530502543b822 Author: Oded Gabbay Date: Tue Apr 14 14:13:18 2015 +0300 drm/amdkfd: allow unregister process with queues commit 1e5ec956a057585adaa1365615c82810b2f5356f upstream. Sometimes we might unregister process that have queues, because we couldn't preempt the queues. Until now we blocked it with BUG_ON but instead just print it as debug. Reviewed-by: Ben Goz Signed-off-by: Oded Gabbay Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d226dcb5a72061174d007d36f47a8ffdc28c29ec Author: Jani Nikula Date: Tue May 5 16:32:12 2015 +0300 drm/i915/dp: there is no audio on port A commit 9fcb1704d1d51b12e2f03c78bca013d0cbbb7c98 upstream. The eDP port A register on PCH split platforms has a slightly different register layout from the other ports, with bit 6 being either alternate scrambler reset or reserved, depending on the generation. Our misinterpretation of the bit as audio has lead to warning. Fix this by not enabling audio on port A, since none of our platforms support audio on port A anyway. v2: DDI doesn't have audio on port A either (Sivakumar Thulasimani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89958 Reported-and-tested-by: Chris Bainbridge Reviewed-by: Sivakumar Thulasimani Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 926ccf94d978da143d67bb934a2d2b22adcefbdd Author: Lukas Wunner Date: Mon May 4 15:06:49 2015 +0200 drm/i915: Add missing MacBook Pro models with dual channel LVDS commit 3916e3fd81021fb795bfbdb17f375b6b3685bced upstream. Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz) as a BTO option, both versions used dual channel LVDS even though the smaller one would have fit into a single channel. Notes: Bug report showing that the MacBookPro8,2 with 1440x900 uses dual channel LVDS (this lead to it being hardcoded in intel_lvds.c by Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc): https://bugzilla.kernel.org/show_bug.cgi?id=42842 If i915.lvds_channel_mode=2 is missing even though the machine needs it, every other vertical line is white and consequently, only the left half of the screen is visible (verified by myself on a MacBookPro9,1). Forum posting concerning a MacBookPro6,2 with 1440x900, author is using i915.lvds_channel_mode=2 on the kernel command line, proving that the machine uses dual channels: https://bbs.archlinux.org/viewtopic.php?id=185770 Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all MacBook Pro "A1286" models, and that model number encompasses the MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's driven with dual channel LVDS: http://www.ebay.com/itm/-/400690878560 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286 http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones with i915 graphics and dual channel LVDS, so that list should be complete. And the 8,2 is already in intel_lvds.c. Possible motivation to use dual channel LVDS even on the 1440x900 models: Reduce the number of different parts, i.e. use identical logic boards and display cabling on both versions and the only differing component is the panel. Signed-off-by: Lukas Wunner Acked-by: Jani Nikula [Jani: included notes in the commit message for posterity] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 09af0842dac496aae363719c449cb88dcc953299 Author: Lukas Wunner Date: Sun Apr 12 21:10:35 2015 +0200 drm/i915: Assume dual channel LVDS if pixel clock necessitates it commit 6f317cfe42c9d8a7c9c1a327d2f1bcc517a3cd91 upstream. Single channel LVDS maxes out at 112 MHz, anything above must be dual channel. This avoids the need to specify i915.lvds_channel_mode=2 on all 17" MacBook Pro models with i915 graphics since they had 1920x1200 (193 MHz), plus those 15" pre-retina models which had a resolution of 1680x1050 (119 MHz) as a BTO option. Source for 112 MHz limit of single channel LVDS is section 2.3 of: https://01.org/linuxgraphics/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf v2: Avoid hardcoding 17" models by assuming dual channel LVDS if the resolution necessitates it, suggested by Jani Nikula. v3: Fix typo, thanks Joonas Lahtinen. v4: Split commit in two, suggested by Ville Syrjälä. Signed-off-by: Lukas Wunner Tested-by: Lukas Wunner Reviewed-by: Ville Syrjälä [Jani: included spec reference into the commit message] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit fcfb5aa246c80df8b0a2ccadd7284b4c189149b0 Author: Mario Kleiner Date: Tue Apr 7 06:31:09 2015 +0200 drm: Zero out invalid vblank timestamp in drm_update_vblank_count. commit fdb68e09bbb1c981f24608d7022c7d93cc47b326 upstream. Since commit 844b03f27739135fe1fed2fef06da0ffc4c7a081 we make sure that after vblank irq off, we return the last valid (vblank count, vblank timestamp) pair to clients, e.g., during modesets, which is good. An overlooked side effect of that commit for kms drivers without support for precise vblank timestamping is that at vblank irq enable, when we update the vblank counter from the hw counter, we can't update the corresponding vblank timestamp, so now we have a totally mismatched timestamp for the new count to confuse clients. Restore old client visible behaviour from before Linux 3.17, but zero out the timestamp at vblank counter update (instead of disable as in original implementation) if we can't generate a meaningful timestamp immediately for the new vblank counter. This will fix this regression, so callers know they need to retry again later if they need a valid timestamp, but at the same time preserves the improvements made in the commit mentioned above. Signed-off-by: Mario Kleiner Cc: #v3.17+ Signed-off-by: Greg Kroah-Hartman Cc: Ville Syrjälä Cc: Daniel Vetter Signed-off-by: Dave Airlie commit a314c7d8d9ca0af1d86cf01ebfe102f300cf6fa5 Author: Ulf Hansson Date: Mon Apr 20 16:02:33 2015 +0200 ARM: ux500: Enable GPIO regulator for SD-card for snowball commit 11133db7a836b0cb411faa048f07a38e994d1382 upstream. Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 23e40bdd23740d6ba3d2b2fe821e3c4f91d6c9c8 Author: Ulf Hansson Date: Mon Apr 20 16:02:32 2015 +0200 ARM: ux500: Enable GPIO regulator for SD-card for HREF boards commit f9a8c3914ba85f19c3360b19612d77c47adb8942 upstream. Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 5b7357fcc7de8c5014189ee699269c21ec2bbb1d Author: Ulf Hansson Date: Mon Apr 20 16:02:31 2015 +0200 ARM: ux500: Move GPIO regulator for SD-card into board DTSs commit 53d2669844263fd5fdc70f0eb6a2eb8a21086d8e upstream. The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but instead it's specific to the board. Move the definition of it, into the board DTSs. Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit bded946f04cfec23bfb132fe4000ed55447df679 Author: Nicolas Schichan Date: Wed May 6 18:31:56 2015 +0200 ARM: net fix emit_udiv() for BPF_ALU | BPF_DIV | BPF_K intruction. commit 19fc99d0c6ba7d9b65456496b5bb2169d5f74cd0 upstream. In that case, emit_udiv() will be called with rn == ARM_R0 (r_scratch) and loading rm first into ARM_R0 will result in jit_udiv() function being called the same dividend and divisor. Fix that by loading rn first into ARM_R1 and then rm into ARM_R0. Signed-off-by: Nicolas Schichan Fixes: aee636c4809f (bpf: do not use reciprocal divide) Acked-by: Mircea Gherzan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 56dc2df8fc3843a9fdb75b88fe5e58b40cae2468 Author: Tony Lindgren Date: Mon May 4 08:54:41 2015 -0700 ARM: OMAP2+: Fix omap off idle power consumption creeping up commit 102bcb6ed2d1c3ffcc7269afc957c2df11942085 upstream. If we use a combination of VMODE and I2C4 for retention modes, eventually the off idle power consumption will creep up by about 23mW, even during off mode with I2C4 always staying enabled. Turns out this is because of erratum i531 "Extra Power Consumed When Repeated Start Operation Mode Is Enabled on I2C Interface Dedicated for Smart Reflex (I2C4)" as pointed out by Nishanth Menon . Let's fix the issue by adding i2c_cfg_clear_mask for the bits to clear when initializing the I2C4 adapter so we can clear SREN bit that drives the I2C4 lines low otherwise when there is no traffic. Fixes: 3b8c4ebb7630 ("ARM: OMAP3: Fix idle mode signaling for sys_clkreq and sys_off_mode") Cc: Kevin Hilman Cc: Tero Kristo Reviewed-by: Nishanth Menon Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 88ace8b32afc6668cc7ee5e9ad754ce12d7b7f64 Author: Gregory CLEMENT Date: Tue Apr 14 11:50:13 2015 +0200 ARM: mvebu: armada-xp-openblocks-ax3-4: Disable internal RTC commit 750e30d4076ae5e02ad13a376e96c95a2627742c upstream. There is no crystal connected to the internal RTC on the Open Block AX3. So let's disable it in order to prevent the kernel probing the driver uselessly. Eventually this patches removes the following warning message from the boot log: "rtc-mv d0010300.rtc: internal RTC not ticking" Acked-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 6d3471e5c640f9466ab29493af3a198c7ce0289c Author: Fabio Estevam Date: Tue Apr 14 11:05:04 2015 -0300 ARM: dts: imx23-olinuxino: Fix polarity of LED GPIO commit cfe8c59762244251fd9a5e281d48808095ff4090 upstream. On imx23-olinuxino the LED turns on when level logic high is aplied to GPIO2_1. Fix the gpios property accordingly. Fixes: b34aa1850244 ("ARM: dts: imx23-olinuxino: Remove unneeded "default-on"") Reported-by: Stefan Wahren Signed-off-by: Fabio Estevam Tested-by: Stefan Wahren Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 0559366f72c86288c8d3dc5cae91dfc2f6e26ad9 Author: Stefan Wahren Date: Tue Apr 14 20:37:26 2015 +0000 ARM: dts: imx23-olinuxino: Fix dr_mode of usb0 commit 0fdebe1a2f4d3a8fc03754022fabf8ba95e131a3 upstream. The dr_mode of usb0 on imx233-olinuxino is left to default "otg". Since the green LED (GPIO2_1) on imx233-olinuxino is connected to the same pin as USB_OTG_ID it's possible to disable USB host by LED toggling: echo 0 > /sys/class/leds/green/brightness [ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1 [ 1068.890000] usb usb1: USB disconnect, device number 1 [ 1068.920000] usb 1-1: USB disconnect, device number 2 [ 1068.920000] usb 1-1.1: USB disconnect, device number 3 [ 1069.070000] usb 1-1.2: USB disconnect, device number 4 [ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered [ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11 This patch fixes the issue by setting dr_mode to "host" in the dts file. Reported-by: Harald Geyer Signed-off-by: Stefan Wahren Reviewed-by: Fabio Estevam Reviewed-by: Marek Vasut Acked-by: Peter Chen Fixes: b49312948285 ("ARM: dts: imx23-olinuxino: Add USB host support") Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 159bf42cce6019a077aea84f9e246e5b488c10b0 Author: Marek Vasut Date: Fri Apr 24 13:29:47 2015 +0200 ARM: dts: imx28: Fix AUART4 TX-DMA interrupt name commit 4ada77e37a773168fea484899201e272ab44ba8b upstream. Fix a typo in the TX DMA interrupt name for AUART4. This patch makes AUART4 operational again. Signed-off-by: Marek Vasut Fixes: f30fb03d4d3a ("ARM: dts: add generic DMA device tree binding for mxs-dma") Acked-by: Stefan Wahren Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit ee2fbf087118725889b40fca66f7ec4f84bcb9ff Author: Philipp Zabel Date: Tue Apr 21 15:59:53 2015 +0200 ARM: dts: imx6: phyFLEX: USB VBUS control is active-high commit 7f8d49dcc66a3dd3a8fc3078330b8fb9e616ad3f upstream. The fixed-regulator bindings require a separate property enable-active-high, the standard gpio phandle property polarity setting is ignored. Signed-off-by: Philipp Zabel Fixes: 4fe69a934b1f ("ARM: dts: Add Phytec pfla02 with i.MX6 DualLite/Solo") Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 4cabf902ee1ff0720257144fb5b43b18f22ecb6d Author: Markus Pargmann Date: Fri Apr 24 09:27:33 2015 +0200 ARM: dts: imx25: Add #pwm-cells to pwm4 commit f90d3f0d0a11fa77918fd5497cb616dd2faa8431 upstream. The property '#pwm-cells' is currently missing. It is not possible to use pwm4 without this property. Signed-off-by: Markus Pargmann Fixes: 5658a68fb578 ("ARM i.MX25: Add devicetree") Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit da277d2b51e9f6840235bfddab8edd6912503206 Author: Pavel Machek Date: Sun Mar 1 21:07:08 2015 +0200 ARM: dts: OMAP3-N900: Add microphone bias voltages commit 1819e3034ee26ffadc71880064ed8b8e7d74f52c upstream. N900 audio recording needs that codec provides bias voltage for integrated digital microphone and headset microphone depending which one is used. Digital microphone uses 2 V bias and it comes from the codec A part. Codec B part drives the headset microphone bias and that is set to 2.5 V. Signed-off-by: Pavel Machek [Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit e2e8bfdf6157 ("ASoC: tlv320aic3x: Convert mic bias to a supply widget")] Signed-off-by: Jarkko Nikula Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 69f3181a88e391dbde3ad0b0a1d8722e200e84ac Author: Ming Lei Date: Tue Apr 21 10:00:20 2015 +0800 blk-mq: fix CPU hotplug handling commit 2a34c0872adf252f23a6fef2d051a169ac796cef upstream. hctx->tags has to be set as NULL in case that it is to be unmapped no matter if set->tags[hctx->queue_num] is NULL or not in blk_mq_map_swqueue() because shared tags can be freed already from another request queue. The same situation has to be considered during handling CPU online too. Unmapped hw queue can be remapped after CPU topo is changed, so we need to allocate tags for the hw queue in blk_mq_map_swqueue(). Then tags allocation for hw queue can be removed in hctx cpu online notifier, and it is reasonable to do that after mapping is updated. Reported-by: Dongsu Park Tested-by: Dongsu Park Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f7bbf3add4e037d8fb5f6251b33dda6a029cbdac Author: Ming Lei Date: Tue Apr 21 10:00:19 2015 +0800 blk-mq: fix race between timeout and CPU hotplug commit f054b56c951bf1731ba7314a4c7f1cc0b2977cc9 upstream. Firstly during CPU hotplug, even queue is freezed, timeout handler still may come and access hctx->tags, which may cause use after free, so this patch deactivates timeout handler inside CPU hotplug notifier. Secondly, tags can be shared by more than one queues, so we have to check if the hctx has been unmapped, otherwise still use-after-free on tags can be triggered. Reported-by: Dongsu Park Tested-by: Dongsu Park Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a45c1c367c8d8dc4fd5ee6fb5f92454c6145710a Author: NeilBrown Date: Mon Apr 27 14:12:22 2015 +1000 block: destroy bdi before blockdev is unregistered. commit 6cd18e711dd8075da9d78cfc1239f912ff28968a upstream. Because of the peculiar way that md devices are created (automatically when the device node is opened), a new device can be created and registered immediately after the blk_unregister_region(disk_devt(disk), disk->minors); call in del_gendisk(). Therefore it is important that all visible artifacts of the previous device are removed before this call. In particular, the 'bdi'. Since: commit c4db59d31e39ea067c32163ac961e9c80198fd37 Author: Christoph Hellwig fs: don't reassign dirty inodes to default_backing_dev_info moved the device_unregister(bdi->dev); call from bdi_unregister() to bdi_destroy() it has been quite easy to lose a race and have a new (e.g.) "md127" be created after the blk_unregister_region() call and before bdi_destroy() is ultimately called by the final 'put_disk', which must come after del_gendisk(). The new device finds that the bdi name is already registered in sysfs and complains > [ 9627.630029] WARNING: CPU: 18 PID: 3330 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5a/0x70() > [ 9627.630032] sysfs: cannot create duplicate filename '/devices/virtual/bdi/9:127' We can fix this by moving the bdi_destroy() call out of blk_release_queue() (which can happen very late when a refcount reaches zero) and into blk_cleanup_queue() - which happens exactly when the md device driver calls it. Then it is only necessary for md to call blk_cleanup_queue() before del_gendisk(). As loop.c devices are also created on demand by opening the device node, we make the same change there. Fixes: c4db59d31e39ea067c32163ac961e9c80198fd37 Reported-by: Azat Khuzhin Cc: Christoph Hellwig Signed-off-by: NeilBrown Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit be4f5647b917bcfdab3905ec7d920adaa0a16f86 Author: Rabin Vincent Date: Tue May 5 15:15:56 2015 +0200 Revert "dm crypt: fix deadlock when async crypto algorithm returns -EBUSY" commit c0403ec0bb5a8c5b267fb7e16021bec0b17e4964 upstream. This reverts Linux 4.1-rc1 commit 0618764cb25f6fa9fb31152995de42a8a0496475. The problem which that commit attempts to fix actually lies in the Freescale CAAM crypto driver not dm-crypt. dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns -EINPROGRESS. When the crypto hw's queue if full, the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of -EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done. Crypto drivers for hardware without hardware queueing use the helpers, crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request() and crypto_get_backlog() helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example). dm-crypt (before the patch that needs reverting) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back -EINPROGRESS from the request function). Then, when it sees at least one backlogged request (gets -EBUSY), it waits till that backlogged request is handled (completion gets called with -EINPROGRESS), and then continues. The references to af_alg_wait_for_completion() and af_alg_complete() in that commit's commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt. The problem is that the Freescale CAAM driver, which that commit describes as having being tested with, fails to implement the backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware queue is full, it simply returns -EBUSY without backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously the wait_for_completion() in crypto_convert() where dm-crypto would wait for the completion being called with -EINPROGRESS in the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver. Commit 0618764cb25 incorrectly made dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see -EBUSY. This means that that commit will cause a performance regression on all crypto drivers which implement the API correctly. Revert it. Correct backlog handling should be implemented in the CAAM driver instead. Cc'ing stable purely because commit 0618764cb25 did. If for some reason a stable@ kernel did pick up commit 0618764cb25 it should get reverted. Signed-off-by: Rabin Vincent Reviewed-by: Horia Geanta Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 8c54e6820b5f8225a90cc7b15921b40fcceed1a2 Author: Ben Hutchings Date: Mon Apr 13 00:26:35 2015 +0100 xen-pciback: Add name prefix to global 'permissive' variable commit 8014bcc86ef112eab9ee1db312dba4e6b608cf89 upstream. The variable for the 'permissive' module parameter used to be static but was recently changed to be extern. This puts it in the kernel global namespace if the driver is built-in, so its name should begin with a prefix identifying the driver. Signed-off-by: Ben Hutchings Fixes: af6fc858a35b ("xen-pciback: limit guest control of command register") Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 76762611f64404b4e70d1f124dd896e74212722e Author: Boris Ostrovsky Date: Wed Apr 29 17:10:15 2015 -0400 xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq() commit 16e6bd5970c88a2ac018b84a5f1dd5c2ff1fdf2c upstream. .. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to 'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu(). Signed-off-by: Boris Ostrovsky Tested-by: Annie Li Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 6cd7c4aa82353a52bf3fe69ae2b99a04515fb408 Author: Boris Ostrovsky Date: Wed Apr 29 17:10:14 2015 -0400 xen/console: Update console event channel on resume commit b9d934f27c91b878c4b2e64299d6e419a4022f8d upstream. After a resume the hypervisor/tools may change console event channel number. We should re-query it. Signed-off-by: Boris Ostrovsky Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 2a4de06fb56014a179a0fd5b788cd295c3e6fcbf Author: Boris Ostrovsky Date: Wed Apr 29 17:10:13 2015 -0400 xen/xenbus: Update xenbus event channel on resume commit 16f1cf3ba7303228372d3756677bf7d10e79cf9f upstream. After a resume the hypervisor/tools may change xenbus event channel number. We should re-query it. Signed-off-by: Boris Ostrovsky Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 59d5ac0fdba134670f89259917240bcfd48e60ef Author: Boris Ostrovsky Date: Wed Apr 29 17:10:12 2015 -0400 xen/events: Clear cpu_evtchn_mask before resuming commit 5cec98834989a014a9560b1841649eaca95cf00e upstream. When a guest is resumed, the hypervisor may change event channel assignments. If this happens and the guest uses 2-level events it is possible for the interrupt to be claimed by wrong VCPU since cpu_evtchn_mask bits may be stale. This can happen even though evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that is passed in is not necessarily the original one (from pre-migration times) but instead is freshly allocated during resume and so any information about which CPU the channel was bound to is lost. Thus we should clear the mask during resume. We also need to make sure that bits for xenstore and console channels are set when these two subsystems are resumed. While rebind_evtchn_irq() (which is invoked for both of them on a resume) calls irq_set_affinity(), the latter will in fact postpone setting affinity until handling the interrupt. But because cpu_evtchn_mask will have bits for these two cleared we won't be able to take the interrupt. With that in mind, we need to bind those two channels explicitly in rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a pass through generic irq affinity code later, in case something needs to be updated there as well. (Also replace cpumask_of(0) with cpumask_of(info->cpu) in rebind_evtchn_irq(): it should be set to zero in preceding xen_irq_info_evtchn_setup().) Signed-off-by: Boris Ostrovsky Reported-by: Annie Li Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 30026d29b7a7c82846210f61a514513a2a2aeced Author: Alex Williamson Date: Fri May 1 16:31:41 2015 -0600 vfio: Fix runaway interruptible timeout commit db7d4d7f40215843000cb9d441c9149fd42ea36b upstream. Commit 13060b64b819 ("vfio: Add and use device request op for vfio bus drivers") incorrectly makes use of an interruptible timeout. When interrupted, the signal remains pending resulting in subsequent timeouts occurring instantly. This makes the loop spin at a much higher rate than intended. Instead of making this completely non-interruptible, we can change this into a sort of interruptible-once behavior and use the "once" to log debug information. The driver API doesn't allow us to abort and return an error code. Signed-off-by: Alex Williamson Fixes: 13060b64b819 Signed-off-by: Greg Kroah-Hartman commit 6eff668b18aa465bd4096bcae801364403308ae1 Author: Hans Verkuil Date: Mon Apr 13 11:18:51 2015 -0300 marvell-ccic: fix Y'CbCr ordering commit 2a700d8edffdbfb8200332d96c3147e042b337f1 upstream. Various formats had their byte ordering implemented incorrectly, and the V4L2_PIX_FMT_UYVY is actually impossible to create, instead you get V4L2_PIX_FMT_YVYU. This was working before commit ad6ac452227b7cb93ac79beec092850d178740b1 ("add new formats support for marvell-ccic driver"). That commit broke the original format support and the OLPC XO-1 laptop showed wrong colors ever since (if you are crazy enough to attempt to run the latest kernel on it, like I did). The email addresses of the authors of that patch are no longer valid, so without a way to reach them and ask them about their test setup I am going with what I can test on the OLPC laptop. If this breaks something for someone on their non-OLPC setup, then contact the linux-media mailinglist. My suspicion however is that that commit went in untested. Signed-off-by: Hans Verkuil Acked-by: Jonathan Corbet Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b0108b0d7bd5f1e0c0551094de3bf01cb62ad0d2 Author: Naoya Horiguchi Date: Tue May 5 16:23:46 2015 -0700 mm: soft-offline: fix num_poisoned_pages counting on concurrent events commit 602498f9aa43d4951eece3fd6ad95a6d0a78d537 upstream. If multiple soft offline events hit one free page/hugepage concurrently, soft_offline_page() can handle the free page/hugepage multiple times, which makes num_poisoned_pages counter increased more than once. This patch fixes this wrong counting by checking TestSetPageHWPoison for normal papes and by checking the return value of dequeue_hwpoisoned_huge_page() for hugepages. Signed-off-by: Naoya Horiguchi Acked-by: Dean Nelson Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ae2aafcf1a7132e268c8568627a6721fec6f3d98 Author: Tejun Heo Date: Tue Apr 21 16:49:13 2015 -0400 writeback: use |1 instead of +1 to protect against div by zero commit 464d1387acb94dc43ba772b35242345e3d2ead1b upstream. mm/page-writeback.c has several places where 1 is added to the divisor to prevent division by zero exceptions; however, if the original divisor is equivalent to -1, adding 1 leads to division by zero. There are three places where +1 is used for this purpose - one in pos_ratio_polynom() and two in bdi_position_ratio(). The second one in bdi_position_ratio() actually triggered div-by-zero oops on a machine running a 3.10 kernel. The divisor is x_intercept - bdi_setpoint + 1 == span + 1 span is confirmed to be (u32)-1. It isn't clear how it ended up that but it could be from write bandwidth calculation underflow fixed by c72efb658f7c ("writeback: fix possible underflow in write bandwidth calculation"). At any rate, +1 isn't a proper protection against div-by-zero. This patch converts all +1 protections to |1. Note that bdi_update_dirty_ratelimit() was already using |1 before this patch. Signed-off-by: Tejun Heo Reviewed-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 335d3678d60de9af4f75d4d11d0689b535b271e8 Author: Al Viro Date: Fri May 8 22:53:15 2015 -0400 path_openat(): fix double fput() commit f15133df088ecadd141ea1907f2c96df67c729f0 upstream. path_openat() jumps to the wrong place after do_tmpfile() - it has already done path_cleanup() (as part of path_lookupat() called by do_tmpfile()), so doing that again can lead to double fput(). Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit f0091a53b507d2d27c2348efd44d2dfdf9dc1321 Author: Naoya Horiguchi Date: Tue May 5 16:23:35 2015 -0700 mm/memory-failure: call shake_page() when error hits thp tail page commit 09789e5de18e4e442870b2d700831f5cb802eb05 upstream. Currently memory_failure() calls shake_page() to sweep pages out from pcplists only when the victim page is 4kB LRU page or thp head page. But we should do this for a thp tail page too. Consider that a memory error hits a thp tail page whose head page is on a pcplist when memory_failure() runs. Then, the current kernel skips shake_pages() part, so hwpoison_user_mappings() returns without calling split_huge_page() nor try_to_unmap() because PageLRU of the thp head is still cleared due to the skip of shake_page(). As a result, me_huge_page() runs for the thp, which is broken behavior. One effect is a leak of the thp. And another is to fail to isolate the memory error, so later access to the error address causes another MCE, which kills the processes which used the thp. This patch fixes this problem by calling shake_page() for thp tail case. Fixes: 385de35722c9 ("thp: allow a hwpoisoned head page to be put back to LRU") Signed-off-by: Naoya Horiguchi Reviewed-by: Andi Kleen Acked-by: Dean Nelson Cc: Andrea Arcangeli Cc: Hidetoshi Seto Cc: Jin Dongming Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f8cf2bd9dfe7b3f22435bd884bfeb555ae62652c Author: Eric W. Biederman Date: Fri May 8 16:36:50 2015 -0500 mnt: Fix fs_fully_visible to verify the root directory is visible commit 7e96c1b0e0f495c5a7450dc4aa7c9a24ba4305bd upstream. This fixes a dumb bug in fs_fully_visible that allows proc or sys to be mounted if there is a bind mount of part of /proc/ or /sys/ visible. Reported-by: Eric Windisch Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 1791458ce042a0fb8780976f21837cbf2642f3a5 Author: Johan Hovold Date: Tue Apr 21 17:42:09 2015 +0200 gpio: sysfs: fix memory leaks and device hotplug commit 483d821108791092798f5d230686868112927044 upstream. Unregister GPIOs requested through sysfs at chip remove to avoid leaking the associated memory and sysfs entries. The stale sysfs entries prevented the gpio numbers from being exported when the gpio range was later reused (e.g. at device reconnect). This also fixes the related module-reference leak. Note that kernfs makes sure that any on-going sysfs operations finish before the class devices are unregistered and that further accesses fail. The chip exported flag is used to prevent gpiod exports during removal. This also makes it harder to trigger, but does not fix, the related race between gpiochip_remove and export_store, which is really a race with gpiod_request that needs to be addressed separately. Also note that this would prevent the crashes (e.g. NULL-dereferences) at reconnect that affects pre-3.18 kernels, as well as use-after-free on operations on open attribute files on pre-3.14 kernels (prior to kernfs). Fixes: d8f388d8dc8d ("gpio: sysfs interface") Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 6a07da8c28e46379bf7eec6f0f8cdc68ebe627c7 Author: Jason Gunthorpe Date: Mon Apr 20 14:01:11 2015 -0600 RDMA/CMA: Canonize IPv4 on IPV6 sockets properly commit 285214409a9e5fceba2215461b4682b6069d8e77 upstream. When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to canonize the address family to IPv4, but does not properly process the listening sockaddr to get the listening port, and does not properly set the address family of the canonized sockaddr. Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager") Reported-By: Yotam Kenneth Signed-off-by: Jason Gunthorpe Tested-by: Haggai Eran Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit d6e5098a4a4ac0ec566e3a471e92062a938afde0 Author: Ryusuke Konishi Date: Tue May 5 16:24:00 2015 -0700 nilfs2: fix sanity check of btree level in nilfs_btree_root_broken() commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream. The range check for b-tree level parameter in nilfs_btree_root_broken() is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even though the level is limited to values in the range of 0 to (NILFS_BTREE_LEVEL_MAX - 1). Since the level parameter is read from storage device and used to index nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it can cause memory overrun during btree operations if the boundary value is set to the level parameter on device. This fixes the broken sanity check and adds a comment to clarify that the upper bound NILFS_BTREE_LEVEL_MAX is exclusive. Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d3992fd381e49aab649dd1aec87b05baf32cdf6d Author: Gregory CLEMENT Date: Tue May 5 16:24:05 2015 -0700 rtc: armada38x: fix concurrency access in armada38x_rtc_set_time commit 489405fe5ed38e65f6f82f131a39c67f3bae6045 upstream. While setting the time, the RTC TIME register should not be accessed. However due to hardware constraints, setting the RTC time involves sleeping during 100ms. This sleep was done outside the critical section protected by the spinlock, so it was possible to read the RTC TIME register and get an incorrect value. This patch introduces a mutex for protecting the RTC TIME access, unlike the spinlock it is allowed to sleep in a critical section protected by a mutex. The RTC STATUS register can still be used from the interrupt handler but it has no effect on setting the time. Signed-off-by: Gregory CLEMENT Acked-by: Alexandre Belloni Acked-by: Andrew Lunn Cc: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1fff73f21beb5feffa459e51a552f5c6a6550a86 Author: Junxiao Bi Date: Tue May 5 16:24:02 2015 -0700 ocfs2: dlm: fix race between purge and get lock resource commit b1432a2a35565f538586774a03bf277c27fc267d upstream. There is a race window in dlm_get_lock_resource(), which may return a lock resource which has been purged. This will cause the process to hang forever in dlmlock() as the ast msg can't be handled due to its lock resource not existing. dlm_get_lock_resource { ... spin_lock(&dlm->spinlock); tmpres = __dlm_lookup_lockres_full(dlm, lockid, namelen, hash); if (tmpres) { spin_unlock(&dlm->spinlock); >>>>>>>> race window, dlm_run_purge_list() may run and purge the lock resource spin_lock(&tmpres->spinlock); ... spin_unlock(&tmpres->spinlock); } } Signed-off-by: Junxiao Bi Cc: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9c998de5e629ceeaf23b16997494de074f2ef2a0 Author: Witold Szczeponik Date: Fri May 1 19:05:20 2015 +0200 ACPI / PNP: add two IDs to list for PNPACPI device enumeration commit 622532bb2fad8fe342fb685727ae0be566f6be5d upstream. Commit eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration) changed the way how ACPI devices are enumerated and when they are added to the PNP bus. However, it broke the sound card support on (at least) a vintage IBM ThinkPad 600E: with said commit applied, two of the necessary "CSC01xx" devices are not added to the PNP bus and hence can not be found during the initialization of the "snd-cs4236" module. As a consequence, loading "snd-cs4236" causes null pointer exceptions. The attached patch fixes the problem end re-enables sound on the IBM ThinkPad 600E. Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration) Signed-off-by: Witold Szczeponik Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 317e6bf62361e884e57f915e15a9735e08fe7b3a Author: Jiang Liu Date: Thu Apr 30 12:41:28 2015 +0800 x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff] available on PCI bus commit 2c62e8492ed7358bbe7da51666c7e0f6da9474ee upstream. An IO port or MMIO resource assigned to a PCI host bridge may be consumed by the host bridge itself or available to its child bus/devices. The ACPI specification defines a bit (Producer/Consumer) to tell whether the resource is consumed by the host bridge itself, but firmware hasn't used that bit consistently, so we can't rely on it. Before commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation"), arch/x86/pci/acpi.c ignored all IO port resources defined by acpi_resource_io and acpi_resource_fixed_io to filter out IO ports consumed by the host bridge itself. Commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation") started accepting all IO port and MMIO resources, which caused a regression that IO port resources consumed by the host bridge itself became available to its child devices. Then commit 63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by host bridge itself") ignored resources consumed by the host bridge itself by checking the IORESOURCE_WINDOW flag, which accidently removed MMIO resources defined by acpi_resource_memory24, acpi_resource_memory32 and acpi_resource_fixed_memory32. On x86 and IA64 platforms, all IO port and MMIO resources are assumed to be available to child bus/devices except one special case: IO port [0xCF8-0xCFF] is consumed by the host bridge itself to access PCI configuration space. So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF]. This solution will also ease the way to consolidate ACPI PCI host bridge common code from x86, ia64 and ARM64. Related ACPI table are archived at: https://bugzilla.kernel.org/show_bug.cgi?id=94221 Related discussions at: http://patchwork.ozlabs.org/patch/461633/ https://lkml.org/lkml/2015/3/29/304 Fixes: 63f1789ec716 (Ignore resources consumed by host bridge itself) Reported-by: Bernhard Thaler Signed-off-by: Jiang Liu Reviewed-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9b03ffb2449ccdc79518545d2790857936d06fb6 Author: Chris Bainbridge Date: Wed Apr 29 21:21:40 2015 +0100 ACPI / SBS: Add 5 us delay to fix SBS hangs on MacBook commit 3349fb64b2927407017d970dd5c4daf3c5ad69f8 upstream. Commit 7bc5a2bad0b8 'ACPI: Support _OSI("Darwin") correctly' caused the MacBook firmware to expose the SBS, resulting in intermittent hangs of several minutes on boot, and failure to detect or report the battery. Fix this by adding a 5 us delay to the start of each SMBUS transaction. This timing is the result of experimentation - hangs were observed with 3 us but never with 5 us. Fixes: 7bc5a2bad0b8 'ACPI: Support _OSI("Darwin") correctly' Link: https://bugzilla.kernel.org/show_bug.cgi?id=94651 Signed-off-by: Chris Bainbridge Cc: 3.18+ # 3.18+ [ rjw: Subject and changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 76ccf3828a8d9971c7183796914c0f610e9b904d Author: Tahsin Erdogan Date: Mon May 4 21:15:31 2015 -0700 x86/spinlocks: Fix regression in spinlock contention detection commit e8a4a2696fecb398b0288c43c0e0dbb91e265bb2 upstream. A spinlock is regarded as contended when there is at least one waiter. Currently, the code that checks whether there are any waiters rely on tail value being greater than head. However, this is not true if tail reaches the max value and wraps back to zero, so arch_spin_is_contended() incorrectly returns 0 (not contended) when tail is smaller than head. The original code (before regression) handled this case by casting the (tail - head) to an unsigned value. This change simply restores that behavior. Fixes: d6abfdb20223 ("x86/spinlocks/paravirt: Fix memory corruption on unlock") Signed-off-by: Tahsin Erdogan Cc: peterz@infradead.org Cc: Waiman.Long@hp.com Cc: borntraeger@de.ibm.com Cc: oleg@redhat.com Cc: raghavendra.kt@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/1430799331-20445-1-git-send-email-tahsin@google.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman