user/sven/linux.git, branch v3.14.13

Linux 3.14.13

2014-07-17T23:21:11Z

ACPI / battery: Retry to get battery information if failed during probing

2014-07-17T23:21:06Z

commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream. Some machines (eg. Lenovo Z480) ECs are not stable during boot up and causes battery driver fails to be loaded due to failure of getting battery information from EC sometimes. After several retries, the operation will work. This patch is to retry to get battery information 5 times if the first try fails. [ backport to 3.14.5: removed second parameter in acpi_battery_update(), introduced by the commit 9e50bc14a7f58b5d8a55973b2d69355852ae2dae (ACPI / battery: Accelerate battery resume callback)] [naszar : backport to 3.14.5] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581 Reported-and-tested-by: naszar Cc: All applicable Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

x86, ioremap: Speed up check for RAM pages

2014-07-17T23:21:06Z

commit c81c8a1eeede61e92a15103748c23d100880cc8a upstream. In __ioremap_caller() (the guts of ioremap), we loop over the range of pfns being remapped and checks each one individually with page_is_ram(). For large ioremaps, this can be very slow. For example, we have a device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+ seconds -- sometimes long enough to trigger the soft lockup detector! Internally, page_is_ram() calls walk_system_ram_range() on a single page. Instead, we can make a single call to walk_system_ram_range() from __ioremap_caller(), and do our further checks only for any RAM pages that we find. For the common case of MMIO, this saves an enormous amount of work, since the range being ioremapped doesn't intersect system RAM at all. With this change, ioremap on our 256 GiB BAR takes less than 1 second. Signed-off-by: Roland Dreier Link: http://lkml.kernel.org/r/1399054721-1331-1-git-send-email-roland@kernel.org Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64

2014-07-17T23:21:06Z

commit fb43e8477ed9006c4f397f904c691a120503038c upstream. powerpc:allmodconfig has been failing for some time with the following error. arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 A number of attempts to fix the problem by moving around code have been unsuccessful and resulted in failed builds for some configurations and the discovery of toolchain bugs. Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead. While this is less than perfect, it avoids substantial code changes which would otherwise be necessary just to make COMPILE_TEST builds happy and might have undesired side effects. Signed-off-by: Guenter Roeck Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

drivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for typo issue

2014-07-17T23:21:06Z

commit c863810cefc7ffd782e5648a21bfb36a32c8b081 upstream. It is only a typo issue, the related commit: "1fbc4c4 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of pr_debug()" The related error (unicore32 with allmodconfig): CC [M] drivers/rtc/rtc-puv3.o drivers/rtc/rtc-puv3.c: In function 'puv3_rtc_setpie': drivers/rtc/rtc-puv3.c:74: error: implicit declaration of function 'dev_debug' Signed-off-by: Chen Gang Acked-by: Xuetao Guan Signed-off-by: Xuetao Guan Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

drivers/rtc/rtc-puv3.c: remove "&dev->" for typo issue

2014-07-17T23:21:06Z

commit 73fa540618d8b1f8c2266934f23bd84bb9e28d9e upstream. It is only a typo issue, the related commit: "1fbc4c4 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of pr_debug()" The related error (for unicore32 with allmodconfig): CC [M] drivers/rtc/rtc-puv3.o drivers/rtc/rtc-puv3.c: In function 'puv3_rtc_setalarm': drivers/rtc/rtc-puv3.c:143: error: 'struct device' has no member named 'dev' Signed-off-by: Chen Gang Acked-by: Xuetao Guan Signed-off-by: Xuetao Guan Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

ring-buffer: Check if buffer exists before polling

2014-07-17T23:21:06Z

commit 8b8b36834d0fff67fc8668093f4312dd04dcf21d upstream. The per_cpu buffers are created one per possible CPU. But these do not mean that those CPUs are online, nor do they even exist. With the addition of the ring buffer polling, it assumes that the caller polls on an existing buffer. But this is not the case if the user reads trace_pipe from a CPU that does not exist, and this causes the kernel to crash. Simple fix is to check the cpu against buffer bitmask against to see if the buffer was allocated or not and return -ENODEV if it is not. More updates were done to pass the -ENODEV back up to userspace. Link: http://lkml.kernel.org/r/5393DB61.6060707@oracle.com Reported-by: Sasha Levin Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman

DMA, CMA: fix possible memory leak

2014-07-17T23:21:06Z

commit fe8eea4f4a3f299ef83ed090d5354698ebe4fda8 upstream. We should free memory for bitmap when we find zone mismatch, otherwise this memory will leak. Additionally, I copy code comment from PPC KVM's CMA code to inform why we need to check zone mis-match. Signed-off-by: Joonsoo Kim Acked-by: Zhang Yanfei Reviewed-by: Michal Nazarewicz Reviewed-by: Aneesh Kumar K.V Acked-by: Minchan Kim Cc: "Aneesh Kumar K.V" Cc: Marek Szyprowski Cc: Michal Nazarewicz Cc: Paolo Bonzini Cc: Gleb Natapov Cc: Alexander Graf Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drm/i915: Don't clobber the GTT when it's within stolen memory

2014-07-17T23:21:06Z

commit f1e1c2129b79cfdaf07bca37c5a10569fe021abe upstream. On most gen2-4 platforms the GTT can be (or maybe always is?) inside the stolen memory region. If that's the case, reduce the size of the stolen memory appropriately to make make sure we don't clobber the GTT. v2: Deal with gen4 36 bit physical address Signed-off-by: Ville Syrjälä Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151 Acked-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/radeon: stop poisoning the GART TLB

2014-07-17T23:21:06Z

commit 0986c1a55ca64b44ee126a2f719a6e9f28cbe0ed upstream. When we set the valid bit on invalid GART entries they are loaded into the TLB when an adjacent entry is loaded. This poisons the TLB with invalid entries which are sometimes not correctly removed on TLB flush. For stable inclusion the patch probably needs to be modified a bit. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman