- 05 Oct, 2012 40 commits
-
-
Andy Shevchenko authored
Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
Commit ec21e2ec ("freescale: Move the Freescale drivers") moved the files, update the pattern. Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Acked-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Uwe Kleine-König authored
Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Yang Bai authored
Signed-off-by:
Yang Bai <hamo.by@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Acked-by:
Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by:
-
George Spelvin authored
Numbering the 8 potential digits 2 though 9 never did make a lot of sense. Signed-off-by:
George Spelvin <linux@horizon.com> Cc: Denys Vlasenko <vda.linux@googlemail.com> Cc: Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
George Spelvin authored
If you're going to have a conditional branch after each 32x32->64-bit multiply, might as well shrink the code and make it a loop. This also avoids using the long multiply for small integers. (This leaves the comments in a confusing state, but that's a separate patch to make review easier.) Signed-off-by:
-
George Spelvin authored
The same multiply-by-inverse technique can be used to convert division by 10000 to a 32x32->64-bit multiply. Signed-off-by:
-
George Spelvin authored
Shrink the reciprocal approximations used in put_dec_full4() based on the comments in put_dec_full9(). Signed-off-by:
-
hongfeng authored
orderly_poweroff is trying to poweroff platform in two steps: step 1: Call user space application to poweroff step 2: If user space poweroff fail, then do a force power off if force param is set. The bug here is, step 1 is always successful with param UMH_NO_WAIT, which obey the design goal of orderly_poweroff. We have two choices here: UMH_WAIT_EXEC which means wait for the exec, but not the process; UMH_WAIT_PROC which means wait for the process to complete. we need to trade off the two choices: If using UMH_WAIT_EXEC, there is potential issue comments by Serge E. Hallyn: The exec will have started, but may for whatever (very unlikely) reason fail. If using UMH_WAIT_PROC, there is potential issue comments by Eric W. Biederman: If the caller is not running in a kernel thread then we can easily get into a case where the user space caller will block waiting for us when we are waiting for the user space caller. Thanks for their excellent ideas, based on the above discussion, we finally choose UMH_WAIT_EXEC, which is much more safe, if the user application really fails, we just complain the application itself, it seems a better choice here. Signed-off-by:Feng Hong <hongfeng@marvell.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Acked-by:
"Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Shawn Guo authored
As kernel_power_off() calls disable_nonboot_cpus(), we may also want to have kernel_restart() call disable_nonboot_cpus(). Doing so can help machines that require boot cpu be the last alive cpu during reboot to survive with kernel restart. This fixes one reboot issue seen on imx6q (Cortex-A9 Quad). The machine requires that the restart routine be run on the primary cpu rather than secondary ones. Otherwise, the secondary core running the restart routine will fail to come to online after reboot. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jiri Kosina authored
Historically, the top three bytes of personality have been used for things such as ADDR_NO_RANDOMIZE, which made sense only for specific architectures. We now however have a flag there that is general no matter the architecture (UNAME26); generally we have to be careful to preserve the personality flags across exec(). This patch fixes tile architecture not to forcefully overwrite personality flags during exec(). In addition to that, we fix two other things along the way: - exec_domain switching is fixed -- set_personality() should always be used instead of directly assigning to current->personality. - as pointed out by Arnd Bergmann, PER_LINUX_32BIT is not used anywhere by tile, so let's just drop that in favor of PER_LINUX Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Acked-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Jiri Kosina authored
Historically, the top three bytes of personality have been used for things such as ADDR_NO_RANDOMIZE, which made sense only for specific architectures. We now however have a flag there that is general no matter the architecture (UNAME26); generally we have to be careful to preserve the personality flags across exec(). This patch tries to fix all architectures that forcefully overwrite personality flags during exec() (ppc32 and s390 have been fixed recently by commits f9783ec8 ("[S390] Do not clobber personality flags on exec") and 59e4c3a2 ("powerpc/32: Don't clobber personality flags on exec") in a similar way already). Signed-off-by:
-
Fengguang Wu authored
It's required for the core fs/namespace.c and many other basic features. Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Acked-by:
Lennox Wu <lennox.wu@gmail.com> Signed-off-by:
-
Geert Uytterhoeven authored
Commit 6afe1a1f ("PM: Remove legacy PM") removed the initialization of retval, causing: arch/frv/kernel/pm.c: In function 'sysctl_pm_do_suspend': arch/frv/kernel/pm.c:165:5: warning: 'retval' may be used uninitialized in this function [-Wuninitialized] Remove the variable completely to fix this, and convert to a proper switch (...) { ... } construct to improve readability. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Joe Mario authored
Fix the const sections for the code generated by crc32 table. There's no ro version of the cacheline aligned section, so we cannot put in const data without a conflict Just don't make the crc tables const for now. [ak@linux.intel.com: some fixes and new description] [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by:
Joe Mario <jmario@redhat.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
[akpm@linux-foundation.org: checkpatch fixes] Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
[akpm@linux-foundation.org: checkpatch fixes] Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
