- 17 May, 2015 40 commits
-
-
Ulrik De Bie authored
[ Upstream commit bd884149 ] On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done. In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that performs the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware). Also the ASUS TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c Cc: stable@vger.kernel.org Reported-and-tested-by:
George Moutsopoulos <gmoutso@yahoo.co.uk> Signed-off-by:
Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Kailang Yang authored
[ Upstream commit d32b6666 ] Switch default pcbeep path to Line in path. Signed-off-by:
Kailang Yang <kailang@realtek.com> Tested-by:
Hui Wang <hui.wang@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
David Henningsson authored
[ Upstream commit 7d1b6e29 ] The ALC256 does not have a mixer nid at 0x0b, and there's no loopback path (the output pins are directly connected to the DACs). This commit fixes an "num_steps = 0 for NID=0xb (ctl = Beep Playback Volume)" error (and as a result, problems with amixer/alsamixer). If there's pcbeep functionality, it certainly isn't controlled by setting an amp on 0x0b, so disable beep functionality (at least for now). Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1446517Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Jo-Philipp Wich authored
[ Upstream commit f2aa1110 ] The Lenovo Thinkpad T450 requires the ALC292_FIXUP_TPT440_DOCK as well in order to get working sound output on the docking stations headphone jack. Patch tested on a Thinkpad T450 (20BVCTO1WW) using kernel 4.0-rc7 in conjunction with a ThinkPad Ultradock. Signed-off-by:
Jo-Philipp Wich <jow@openwrt.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Michael Gernoth authored
[ Upstream commit 91bf0c2d ] The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read acquire the emu_lock before accessing the FPGA. The function used to access the FPGA (snd_emu1010_fpga_read) also tries to take the emu_lock which causes a deadlock. Remove the outer locking in the proc-functions (guarding only the already safe fpga read) to prevent this deadlock. [removed superfluous flags variables too -- tiwai] Signed-off-by:
Michael Gernoth <michael@gernoth.net> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Yves-Alexis Perez authored
[ Upstream commit c0278669 ] This model uses the same dock port as the previous generation. Signed-off-by:
Yves-Alexis Perez <corsac@debian.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Boris Brezillon authored
[ Upstream commit 45912431 ] The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate modification requests to their parents. This causes a bug when the PLLB is left uninitialized by the bootloader (PLL multiplier set to 0, or in other words, PLL rate = 0 Hz). Implement the determinate_rate method and propagate the change rate request to the parent clk. Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by:
Bo Shen <voice.shen@atmel.com> Tested-by:
Michael Turquette <mturquette@linaro.org> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit bbc78c07 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 08debfb1 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit ea16328f ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit b9e45188 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 8c0ae657 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 7a606ac2 ] While this driver was already using a 50ms resume timeout, let's make sure everybody uses the same macro so it's easy to fix later should anything go wrong. It also gives a more "stable" expectation to Linux users. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 7e136bb7 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit b8fb6f79 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 595227db ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 84c0d178 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 309be239 ] Make sure we're using the new macro, so our resume signaling will always pass certification. Based on original work by Bin Liu <Bin Liu <b-liu@ti.com>> Cc: Bin Liu <b-liu@ti.com> Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 62f0342d ] Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Cc: <stable@vger.kernel.org> # v3.10+ Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Axel Lin authored
[ Upstream commit 869aee0f ] The res parameter passed to devm_usb_phy_match() is the location where the pointer to the usb_phy is stored, hence it needs to be dereferenced before comparing to the match data in order to find the correct match. Fixes: 410219dc ("usb: otg: utils: devres: Add API's to associate a device with the phy") Signed-off-by:
Axel Lin <axel.lin@ingics.com> Cc: <stable@vger.kernel.org> # v3.6+ Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit e3c93e1a ] As per Mentor Graphics' documentation, we should always handle TX endpoints before RX endpoints. This patch fixes that error while also updating some hard-to-read comments which were scattered around musb_interrupt(). This patch should be backported as far back as possible since this error has been in the driver since it's conception. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Sebastian Hesselbarth authored
[ Upstream commit a74cd13b ] Fix Dove's register addresses of uart2 and uart3 nodes that seem to be broken since ages due to a copy-and-paste error. Cc: <stable@vger.kernel.org> # 3.7+ Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Charles Keepax authored
[ Upstream commit 4e330ae4 ] There are two PMICs on Cragganmore, currently one dynamically assign its IRQ base and the other uses a fixed base. It is possible for the statically assigned PMIC to fail if its IRQ is taken by the dynamically assigned one. Fix this by statically assigning both the IRQ bases. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Kukjin Kim <kgene@kernel.org> Signed-off-by:
-
Gregory CLEMENT authored
[ Upstream commit 548ae94c ] On Armada 38x SoCs, under heavy I/O load, the system hangs when CPU Idle is enabled. Waiting for a solution to this issue, this patch disables the CPU Idle support for this SoC. As CPU Hot plug support also uses some of the CPU Idle functions it is also affected by the same issue. This patch disables it also for the Armada 38x SoCs. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.17 + Signed-off-by:
-
Andrey Ryabinin authored
[ Upstream commit 8defb336 ] Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel split this is not so, because 2*TASK_SIZE overflows 32 bits, so the actual value of ELF_ET_DYN_BASE is: (2 * TASK_SIZE / 3) = 0x2a000000 When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address. On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000] for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled as it fails to map shadow memory. Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries has a high chance of loading somewhere in between [0x2a000000 - 0x40000000] even if ASLR enabled. This makes ASan with PIE absolutely incompatible. Fix overflow by dividing TASK_SIZE prior to multiplying. After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y): (TASK_SIZE / 3 * 2) = 0x7f555554 [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#MappingSigned-off-by:
Andrey Ryabinin <a.ryabinin@samsung.com> Reported-by:
Maria Guseva <m.guseva@samsung.com> Cc: stable@vger.kernel.org Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
[ Upstream commit 767bf7e7 ] Normally, when a CPU wants to clear a cache line to zero in the external L2 cache, it would generate bus cycles to write each word as it would do with any other data access. However, a Cortex A9 connected to a L2C-310 has a specific feature where the CPU can detect this operation, and signal that it wants to zero an entire cache line. This feature, known as Full Line of Zeros (FLZ), involves a non-standard AXI signalling mechanism which only the L2C-310 can properly interpret. There are separate enable bits in both the L2C-310 and the Cortex A9 - the L2C-310 needs to be enabled and have the FLZ enable bit set in the auxiliary control register before the Cortex A9 has this feature enabled. Unfortunately, the suspend code was not respecting this - it's not obvious from the code: swsusp_arch_suspend() cpu_suspend() /* saves the Cortex A9 auxiliary control register */ arch_save_image() soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */ cpu_resume() /* restores the Cortex A9 registers, inc auxcr */ At this point, we end up with the L2C disabled, but the Cortex A9 with FLZ enabled - which means any memset() or zeroing of a full cache line will fail to take effect. A similar issue exists in the resume path, but it's slightly more complex: swsusp_arch_suspend() cpu_suspend() /* saves the Cortex A9 auxiliary control register */ arch_save_image() /* image with A9 auxcr saved */ ... swsusp_arch_resume() call_with_stack() arch_restore_image() /* restores image with A9 auxcr saved above */ soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */ cpu_resume() /* restores the Cortex A9 registers, inc auxcr */ Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled. There's no need to turn off the L2C in either of these two paths; there are benefits from not doing so - for example, the page copies will be faster with the L2C enabled. Hence, fix this by providing a variant of soft_restart() which can be used without turning the L2 cache controller off, and use it in both of these paths to keep the L2C enabled across the respective resume transitions. Fixes: 8ef418c7 ("ARM: l2c: trial at enabling some Cortex-A9 optimisations") Reported-by:
Sean Cross <xobs@kosagi.com> Tested-by:
-
Andrew Elble authored
[ Upstream commit c1b8940b ] We have observed a BUG() crash in fs/attr.c:notify_change(). The crash occurs during an rsync into a filesystem that is exported via NFS. 1.) fs/attr.c:notify_change() modifies the caller's version of attr. 2.) 6de0ec00 ("VFS: make notify_change pass ATTR_KILL_S*ID to setattr operations") introduced a BUG() restriction such that "no function will ever call notify_change() with both ATTR_MODE and ATTR_KILL_S*ID set". Under some circumstances though, it will have assisted in setting the caller's version of attr to this very combination. 3.) 27ac0ffe ("locks: break delegations on any attribute modification") introduced code to handle breaking delegations. This can result in notify_change() being re-called. attr _must_ be explicitly reset to avoid triggering the BUG() established in #2. 4.) The path that that triggers this is via fs/open.c:chmod_common(). The combination of attr flags set here and in the first call to notify_change() along with a later failed break_deleg_wait() results in notify_change() being called again via retry_deleg without resetting attr. Solution is to move retry_deleg in chmod_common() a bit further up to ensure attr is completely reset. There are other places where this seemingly could occur, such as fs/utimes.c:utimes_common(), but the attr flags are not initially set in such a way to trigger this. Fixes: 27ac0ffe ("locks: break delegations on any attribute modification") Reported-by:
Eric Meddaugh <etmsys@rit.edu> Tested-by:
Andrew Elble <aweits@rit.edu> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit a2c1d531 ] The return values of create_singlethread_workqueue() and power_supply_register() calls were not checked and even on error probe() function returned 0. 1. If allocation of workqueue failed (returning NULL) then further accesses could lead to NULL pointer dereference. The queue_delayed_work() expects workqueue to be non-NULL. 2. If registration of power supply failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 00a588f9 ("power: add driver for battery reading on iPaq h3xxx") Cc: <stable@vger.kernel.org> Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit f852ec46 ] Driver allocates singlethread workqueue in probe but it is not destroyed during removal. Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit a7117f81 ] Driver forgot to unregister charger power supply if registering of battery supply failed in probe(). In such case the memory associated with power supply leaked. Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit 68c3ed6f ] The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Signed-off-by:
-
Steven Rostedt authored
[ Upstream commit 80a9b64e ] It has come to my attention that this_cpu_read/write are horrible on architectures other than x86. Worse yet, they actually disable preemption or interrupts! This caused some unexpected tracing results on ARM. 101.356868: preempt_count_add <-ring_buffer_lock_reserve 101.356870: preempt_count_sub <-ring_buffer_lock_reserve The ring_buffer_lock_reserve has recursion protection that requires accessing a per cpu variable. But since preempt_disable() is traced, it too got traced while accessing the variable that is suppose to prevent recursion like this. The generic version of this_cpu_read() and write() are: #define this_cpu_generic_read(pcp) \ ({ typeof(pcp) ret__; \ preempt_disable(); \ ret__ = *this_cpu_ptr(&(pcp)); \ preempt_enable(); \ ret__; \ }) #define this_cpu_generic_to_op(pcp, val, op) \ do { \ unsigned long flags; \ raw_local_irq_save(flags); \ *__this_cpu_ptr(&(pcp)) op val; \ raw_local_irq_restore(flags); \ } while (0) Which is unacceptable for locations that know they are within preempt disabled or interrupt disabled locations. Paul McKenney stated that __this_cpu_() versions produce much better code on other architectures than this_cpu_() does, if we know that the call is done in a preempt disabled location. I also changed the recursive_unlock() to use two local variables instead of accessing the per_cpu variable twice. Link: http://lkml.kernel.org/r/20150317114411.GE3589@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/20150317104038.312e73d1@gandalf.local.home Cc: stable@vger.kernel.org Acked-by:
Christoph Lameter <cl@linux.com> Reported-by:
Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de> Tested-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit 1915a718 ] The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Fix this by checking return status of power_supply_register() call. In case of failure, clean up sysfs entries and fail the probe. Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit ad774702 ] The commit c2be45f0 ("compal-laptop: Use devm_hwmon_device_register_with_groups") wanted to change the registering of hwmon device to resource-managed version. It mostly did it except the main thing - it forgot to use devm-like function so the hwmon device leaked after device removal or probe failure. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Ian Abbott authored
[ Upstream commit f20fbaad ] `spidev_message()` sums the lengths of the individual SPI transfers to determine the overall SPI message length. It restricts the total length, returning an error if too long, but it does not check for arithmetic overflow. For example, if the SPI message consisted of two transfers and the first has a length of 10 and the second has a length of (__u32)(-1), the total length would be seen as 9, even though the second transfer is actually very long. If the second transfer specifies a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could overrun the spidev's pre-allocated tx buffer before it reaches an invalid user memory address. Fix it by checking that neither the total nor the individual transfer lengths exceed the maximum allowed value. Thanks to Dan Carpenter for reporting the potential integer overflow. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Lucas Stach authored
[ Upstream commit f511ab09 ] They are used to decide if the controller can do DMA on a buffer of a specific length and thus are needed before any transfer is attempted. This fixes a memory leak where the SPI core uses the drivers can_dma() callback to determine if a buffer needs to be mapped. As the watermark levels aren't correct at that point the driver falsely claims to be able to DMA the buffer when it fact it isn't. After the transfer has been done the core uses the same callback to determine if it needs to unmap the buffers. As the driver now correctly claims to not being able to DMA the buffer the core doesn't attempt to unmap the buffer which leaves the SGT leaking. Fixes: f62caccd (spi: spi-imx: add DMA support) Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 9e71c589 ] The reset control for the sunxi mmc controller is optional. Some newer platforms (sun6i, sun8i, sun9i) have it, while older ones (sun4i, sun5i, sun7i) don't. Use the properly stubbed _optional version so the driver does not fail to compile when RESET_CONTROLLER=n. This patch also adds a check for deferred probing on the reset control. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Cc: <stable@vger.kernel.org> # 3.16+ Acked-by:
David Lanzendörfer <david.lanzendoerfer@o2s.ch> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Oliver Neukum authored
[ Upstream commit 323ece54 ] Values directly from descriptors given in debug statements must be converted to native endianness. Signed-off-by:
Oliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Signed-off-by:
-
NeilBrown authored
[ Upstream commit 47d68979 ] Since commit 20d0189b in v3.14-rc1 RAID0 has performed incorrect calculations when the chunksize is not a power of 2. This happens because "sector_div()" modifies its first argument, but this wasn't taken into account in the patch. So restore that first arg before re-using the variable. Reported-by:
Joe Landman <joe.landman@gmail.com> Reported-by:
Dave Chinner <david@fromorbit.com> Fixes: 20d0189b Cc: stable@vger.kernel.org (3.14 and later). Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Alistair Strachan authored
[ Upstream commit 8e43c9c7 ] The android_fence_release() function checks for active sync points by calling list_empty() on the list head embedded on the sync point. However, it is only valid to use list_empty() on nodes that have been initialized with INIT_LIST_HEAD() or list_del_init(). Because the list entry has likely been removed from the active list by sync_timeline_signal(), there is a good chance that this WARN_ON_ONCE() will be hit due to dangling pointers pointing at freed memory (even though the sync drivers did nothing wrong) and memory corruption will ensue as the list entry is removed for a second time, corrupting the active list. This problem can be reproduced quite easily with CONFIG_DEBUG_LIST=y and fences with more than one sync point. Signed-off-by:
Alistair Strachan <alistair.strachan@imgtec.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Colin Cross <ccross@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
