- Jan 02, 2024
-
-
Fabio Estevam authored
Introduce thermal_zone_device_critical_reboot() to trigger an emergency reboot. It is a counterpart of thermal_zone_device_critical() with the difference that it will force a reboot instead of shutdown. The motivation for doing this is to allow the thermal subystem to trigger a reboot when the temperature reaches the critical temperature. Signed-off-by:
Fabio Estevam <festevam@denx.de> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20231129124330.519423-3-festevam@gmail.com
-
Fabio Estevam authored
Add some helper functions to make it easier introducing the support for thermal reboot. No functional change. Signed-off-by:
-
- Dec 11, 2023
-
-
Dongmin Lee authored
When kernel_can_power_off() returns false, and reboot has called with LINUX_REBOOT_CMD_POWER_OFF, kernel_halt() will be initiated instead of actual power off function. However, in this situation, Kernel never explicitly notifies user that system halted instead of requested power off. Since halt and power off perform different behavior, and user initiated reboot call with power off command, not halt, This could be unintended behavior to user, like this: ~ # poweroff -f [ 3.581482] reboot: System halted Therefore, this explicitly notifies user that poweroff is not available, and halting has been occured as an alternative behavior instead: ~ # poweroff -f [ 4.123668] reboot: Power off not available: System halted instead [akpm@linux-foundation.org: tweak comment text] Link: https://lkml.kernel.org/r/20231104113320.72440-1-ldmldm05@gmail.com Signed-off-by:
Dongmin Lee <ldmldm05@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
- Jul 28, 2023
-
-
Benjamin Bara authored
If the dev is known (e.g. a devm-based sys_off_handler is used), it can be passed to the handler's callback to have it available there. Otherwise, cb_data might be set to the dev in most of the cases. Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
Benjamin Bara <benjamin.bara@skidata.com> Link: https://lore.kernel.org/r/20230327-tegra-pmic-reboot-v7-3-18699d5dcd76@skidata.com Signed-off-by:
Lee Jones <lee@kernel.org>
-
Benjamin Bara authored
As the emergency restart does not call kernel_restart_prepare(), the system_state stays in SYSTEM_RUNNING. Since bae1d3a0, this hinders i2c_in_atomic_xfer_mode() from becoming active, and therefore might lead to avoidable warnings in the restart handlers, e.g.: [ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114 [ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70 ... [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c Avoid these by setting the correct system_state. Fixes: bae1d3a0 ("i2c: core: remove use of in_atomic()") Cc: stable@vger.kernel.org # v5.2+ Reviewed-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
- Oct 04, 2022
-
-
Kai-Heng Feng authored
Add SYS_OFF_MODE_RESTART_PREPARE callbacks to be invoked before a system restart. Suggested-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> [ rjw: Changelog edits ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Jun 23, 2022
-
-
Petr Mladek authored
This reverts commit 2bb2b7b5. The testing of 5.19 release candidates revealed missing synchronization between early and regular console functionality. It would be possible to start the console kthreads later as a workaround. But it is clear that console lock serialized console drivers between each other. It opens a big area of possible problems that were not considered by people involved in the development and review. printk() is crucial for debugging kernel issues and console output is very important part of it. The number of consoles is huge and a proper review would take some time. As a result it need to be reverted for 5.19. Link: https://lore.kernel.org/r/YrBdjVwBOVgLfHyb@alley Signed-off-by:
Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20220623145157.21938-7-pmladek@suse.com
-
Petr Mladek authored
This reverts commit b87f0230. The testing of 5.19 release candidates revealed missing synchronization between early and regular console functionality. It would be possible to start the console kthreads later as a workaround. But it is clear that console lock serialized console drivers between each other. It opens a big area of possible problems that were not considered by people involved in the development and review. printk() is crucial for debugging kernel issues and console output is very important part of it. The number of consoles is huge and a proper review would take some time. As a result it need to be reverted for 5.19. Link: https://lore.kernel.org/r/YrBdjVwBOVgLfHyb@alley Signed-off-by:
-
- Jun 15, 2022
-
-
Petr Mladek authored
There are reports that the console kthreads block the global console lock when the system is going down, for example, reboot, panic. First part of the solution was to block kthreads in these problematic system states so they stopped handling newly added messages. Second part of the solution is to wait when for the kthreads when they are actively printing. It solves the problem when a message was printed before the system entered the problematic state and the kthreads managed to step in. A busy waiting has to be used because panic() can be called in any context and in an unknown state of the scheduler. There must be a timeout because the kthread might get stuck or sleeping and never release the lock. The timeout 10s is an arbitrary value inspired by the softlockup timeout. Link: https://lore.kernel.org/r/20220610205038.GA3050413@paulmck-ThinkPad-P17-Gen-1 Link: https://lore.kernel.org/r/CAMdYzYpF4FNTBPZsEFeWRuEwSies36QM_As8osPWZSr2q-viEA@mail.gmail.com Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Link: https://lore.kernel.org/r/20220615162805.27962-3-pmladek@suse.com
-
- Jun 07, 2022
-
-
Dmitry Osipenko authored
There are other methods of powering off machine than the reboot syscall. Previously we missed to cover those methods and it created power-off regression for some machines, like the PowerPC e500. Fix this problem by moving the legacy sys-off handler registration to the latest phase of power-off process and making the kernel_can_power_off() check the legacy pm_power_off presence. Tested-by: Michael Ellerman <mpe@ellerman.id.au> # ppce500 Reported-by: Michael Ellerman <mpe@ellerman.id.au> # ppce500 Fixes: da007f17 ("kernel/reboot: Change registration order of legacy power-off handler") Signed-off-by:
-
- Jun 02, 2022
-
-
Dmitry Osipenko authored
The register_platform_power_off() fails on m68k platform due to the memory allocation error that happens at a very early boot time when memory allocator isn't available yet. Fix it by using a static sys-off handler for the platform-level power-off handlers. Fixes: f0f7e526 ("m68k: Switch to new sys-off handler API") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
- May 25, 2022
-
-
Dmitry Osipenko authored
We're unconditionally registering sys-off handler for the legacy pm_power_off() callback, this causes problem for platforms that don't use power-off handlers at all and should be halted. Now reboot syscall assumes that there is a power-off handler installed and tries to power off system instead of halting it. To fix the trouble, move the handler's registration to the reboot syscall and check the pm_power_off() presence. Fixes: 0e2110d2 ("kernel/reboot: Add kernel_can_power_off()") Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by:
-
- May 19, 2022
-
-
Dmitry Osipenko authored
Add devm_register_restart_handler() helper that registers sys-off handler using restart mode and with a default priority. Most drivers will want to register restart handler with a default priority, so this helper will reduce the boilerplate code and make code easier to read and follow. Signed-off-by:
-
Dmitry Osipenko authored
Add devm_register_power_off_handler() helper that registers sys-off handler using power-off mode and with a default priority. Most drivers will want to register power-off handler with a default priority, so this helper will reduce the boilerplate code and make code easier to read and follow. Signed-off-by:
-
Dmitry Osipenko authored
All pm_power_off_prepare() users were converted to sys-off handler API. Remove the obsolete global callback variable. Signed-off-by:
-
Dmitry Osipenko authored
Add platform-level registration helpers that will ease transition of the arch/platform power-off callbacks to the new sys-off based API, allowing us to remove the global pm_power_off variable in the future. Signed-off-by:
-
Dmitry Osipenko authored
Add kernel_can_power_off() helper that replaces open-coded checks of the global pm_power_off variable. This is a necessary step towards supporting chained power-off handlers. Signed-off-by:
-
Dmitry Osipenko authored
Add weak stub for the global pm_power_off callback variable. This will allow us to remove pm_power_off definitions from arch/ code and transition to the new sys-off based API that will replace the global variable. Signed-off-by:
-
Dmitry Osipenko authored
Add do_kernel_power_off() helper that will remove open-coded pm_power_off invocations from the architecture code. This is the first step on the way to remove the global pm_power_off variable, which will allow us to implement consistent power-off chaining support. Signed-off-by:
-
Dmitry Osipenko authored
Wrap legacy power-off callbacks into sys-off handlers in order to support co-existence of both legacy and new callbacks while we're in process of upgrading legacy callbacks to the new API. Signed-off-by:
-
Dmitry Osipenko authored
In order to support power-off chaining we need to get rid of the global pm_* variables, replacing them with the new kernel API functions that support chaining. Introduce new generic sys-off handler API that brings the following features: 1. Power-off and restart handlers are registered using same API function that supports chaining, hence all power-off and restart modes will support chaining using this unified function. 2. Prevents notifier priority collisions by disallowing registration of multiple handlers at the non-default priority level. 3. Supports passing opaque user argument to callback, which allows us to remove global variables from drivers. This patch adds support of the following sys-off modes: - SYS_OFF_MODE_POWER_OFF_PREPARE that replaces global pm_power_off_prepare variable and provides chaining support for power-off-prepare handlers. - SYS_OFF_MODE_POWER_OFF that replaces global pm_power_off variable and provides chaining support for power-off handlers. - SYS_OFF_MODE_RESTART that provides a better restart API, removing a need from drivers to have a global scratch variable by utilizing the opaque callback argument. Signed-off-by:
-
- May 09, 2022
-
-
YueHaibing authored
If CONFIG_SYSCTL is n, build warn: kernel/reboot.c:443:20: error: ‘kernel_reboot_sysctls_init’ defined but not used [-Werror=unused-function] static void __init kernel_reboot_sysctls_init(void) ^~~~~~~~~~~~~~~~~~~~~~~~~~ Move kernel_reboot_sysctls_init() to #ifdef block to fix this. Fixes: 06d17766 ("kernel/reboot: move reboot sysctls to its own file") Signed-off-by:YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Luis Chamberlain <mcgrof@kernel.org>
-
- Apr 22, 2022
-
-
John Ogness authored
Once kthread printing is available, console printing will no longer occur in the context of the printk caller. However, there are some special contexts where it is desirable for the printk caller to directly print out kernel messages. Using pr_flush() to wait for threaded printers is only possible if the caller is in a sleepable context and the kthreads are active. That is not always the case. Introduce printk_prefer_direct_enter() and printk_prefer_direct_exit() functions to explicitly (and globally) activate/deactivate preferred direct console printing. The term "direct console printing" refers to printing to all enabled consoles from the context of the printk caller. The term "prefer" is used because this type of printing is only best effort. If the console is currently locked or other printers are already actively printing, the printk caller will need to rely on the other contexts to handle the printing. This preferred direct printing is how all printing has been handled until now (unless it was explicitly deferred). When kthread printing is introduced, there may be some unanticipated problems due to kthreads being unable to flush important messages. In order to minimize such risks, preferred direct printing is activated for the primary important messages when the system experiences general types of major errors. These are: - emergency reboot/shutdown - cpu and rcu stalls - hard and soft lockups - hung tasks - warn - sysrq Note that since kthread printing does not yet exist, no behavior changes result from this commit. This is only implementing the counter and marking the various places where preferred direct printing is active. Signed-off-by:
John Ogness <john.ogness@linutronix.de> Reviewed-by:
-
- Apr 06, 2022
-
-
tangmeng authored
kernel/sysctl.c is a kitchen sink where everyone leaves their dirty dishes, this makes it very difficult to maintain. To help with this maintenance let's start by moving sysctls to places where they actually belong. The proc sysctl maintainers do not want to know what sysctl knobs you wish to add for your own piece of code, we just care about the core logic. All filesystem syctls now get reviewed by fs folks. This commit follows the commit of fs, move the poweroff_cmd and ctrl-alt-del sysctls to its own file, kernel/reboot.c. Signed-off-by:
tangmeng <tangmeng@uniontech.com> Signed-off-by:
-
- Oct 20, 2021
-
-
Eric W. Biederman authored
Link: https://lkml.kernel.org/r/20211020174406.17889-3-ebiederm@xmission.com Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com>
-
- Oct 17, 2021
-
-
Some drivers like Qualcomm pm8941-pwrkey need to access 'reboot_mode' for triggering reboot between cold and warm mode. Export the symbol, so that drivers built as module can still access the symbol. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20210714095850.27185-2-shawn.guo@linaro.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- Jun 21, 2021
-
-
Matti Vaittinen authored
There can be few cases when we need to shut-down the system in order to protect the hardware. Currently this is done at least by the thermal core when temperature raises over certain limit. Some PMICs can also generate interrupts for example for over-current or over-voltage, voltage drops, short-circuit, ... etc. On some systems these are a sign of hardware failure and only thing to do is try to protect the rest of the hardware by shutting down the system. Add shut-down logic which can be used by all subsystems instead of implementing the shutdown in each subsystem. The logic is stolen from thermal_core with difference of using atomic_t instead of a mutex in order to allow calls directly from IRQ context and changing the WARN() to pr_emerg() as discussed here: https://lore.kernel.org/lkml/YJuPwAZroVZ%2Fw633@alley/ and here: https://lore.kernel.org/linux-iommu/20210331093104.383705-4-geert+renesas@glider.be/ Signed-off-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by:
Mark Brown <broonie@kernel.org>
-
- Mar 18, 2021
-
-
Josef Bacik authored
This reverts commit d60cd063. This patch causes a panic when rebooting my Dell Poweredge r440. I do not have the full panic log as it's lost at that stage of the reboot and I do not have a serial console. Reverting this patch makes my system able to reboot again. Signed-off-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
-
- Dec 16, 2020
-
-
Matteo Croce authored
Not all the reboot settings from both the kernel command line or sysfs interface are available to all platforms. Filter out reboot_type and reboot_force which are x86 only, and also remove reboot_cpu on kernels without SMP support. This saves some space, and avoid confusing the user with settings which will have no effect. Link: https://lkml.kernel.org/r/20201130173717.198952-3-mcroce@linux.microsoft.com Signed-off-by:
Matteo Croce <mcroce@microsoft.com> Reviewed-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Matteo Croce authored
Patch series "reboot: sysfs improvements". Some improvements to the sysfs reboot interface: hide not working settings and support machines with known reboot quirks. This patch (of 2): On some machines a quirk can force a specific reboot type. Quirks are found during a DMI scan, the list of machines which need special reboot handling is defined in reboot_dmi_table. The kernel command line reboot= option overrides this via a global variable `reboot_default`, so that the reboot type requested in the command line is really performed. This was not true when setting the reboot type via the new sysfs interface. Fix this by setting reboot_default upon the first change, like reboot_setup() does for the command line. Link: https://lkml.kernel.org/r/20201130173717.198952-1-mcroce@linux.microsoft.com Link: https://lkml.kernel.org/r/20201130173717.198952-2-mcroce@linux.microsoft.com Signed-off-by:
-
Matteo Croce authored
BOOT_CF9_SAFE_STR is an internal value used only by the x86 code and it's not possible to set it from userspace. Remove it, and rename 'cf9_force' to 'pci', so to make it coherent with the kernel command line reboot= option. Tested with this script: cd /sys/kernel/reboot/ for i in cold warm hard soft gpio; do echo $i >mode read j <mode [ $i = $j ] || echo "mode $i != $j" done for i in bios acpi kbd triple efi pci; do echo $i >type read j <type [ $i = $j ] || echo "type $i != $j" done for i in $(seq 0 $(nproc --ignore=1)); do echo $i >cpu read j <cpu [ $i = $j ] || echo "cpu $i != $j" done for i in 0 1; do echo $i >force read j <force [ $i = $j ] || echo "force $i != $j" done Link: https://lkml.kernel.org/r/20201113015900.543923-1-mcroce@linux.microsoft.com Fixes: eab8da48579d ("reboot: allow to specify reboot mode via sysfs") Signed-off-by:
-
Matteo Croce authored
The kernel cmdline reboot= option offers some sort of control on how the reboot is issued. We don't always know in advance what type of reboot to perform. Sometimes a warm reboot is preferred to persist certain memory regions across the reboot. Others a cold one is needed to apply a future system update that makes a memory memory model change, like changing the base page size or resizing a persistent memory region. Or simply we want to enable reboot_force because we noticed that something bad happened. Add handles in sysfs to allow setting these reboot options, so they can be changed when the system is booted, other than at boot time. The handlers are under <sysfs>/kernel/reboot, can be read to get the current configuration and written to alter it. # cd /sys/kernel/reboot/ # grep . * cpu:0 force:0 mode:cold type:acpi # echo 2 >cpu # echo yes >force # echo soft >mode # echo bios >type # grep . * cpu:2 force:1 mode:soft type:bios Before setting anything, check for CAP_SYS_BOOT capability, so it's possible to allow an unpriviledged process to change these settings simply by relaxing the handles permissions, without opening them to the world. [natechancellor@gmail.com: fix variable assignments in type_store] Link: https://lkml.kernel.org/r/20201112035023.974748-1-natechancellor@gmail.com Link: https://github.com/ClangBuiltLinux/linux/issues/1197 Link: https://lkml.kernel.org/r/20201110202746.9690-1-mcroce@linux.microsoft.com Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
-
Matteo Croce authored
Small improvements to the code, without changing the way it works: - use a local variable, to avoid a small time lapse where reboot_cpu can have an invalid value - comment the code which is not easy to understand at a glance - merge two identical code blocks into one - replace pointer arithmetics with equivalent array syntax Link: https://lkml.kernel.org/r/20201103214025.116799-4-mcroce@linux.microsoft.com Signed-off-by:
-
- Nov 14, 2020
-
-
Matteo Croce authored
Limit the CPU number to num_possible_cpus(), because setting it to a value lower than INT_MAX but higher than NR_CPUS produces the following error on reboot and shutdown: BUG: unable to handle page fault for address: ffffffff90ab1bb0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c09067 P4D 1c09067 PUD 1c0a063 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 1 Comm: systemd-shutdow Not tainted 5.9.0-rc8-kvm #110 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:migrate_to_reboot_cpu+0xe/0x60 Code: ea ea 00 48 89 fa 48 c7 c7 30 57 f1 81 e9 fa ef ff ff 66 2e 0f 1f 84 00 00 00 00 00 53 8b 1d d5 ea ea 00 e8 14 33 fe ff 89 da <48> 0f a3 15 ea fc bd 00 48 89 d0 73 29 89 c2 c1 e8 06 65 48 8b 3c RSP: 0018:ffffc90000013e08 EFLAGS: 00010246 RAX: ffff88801f0a0000 RBX: 0000000077359400 RCX: 0000000000000000 RDX: 0000000077359400 RSI: 0000000000000002 RDI: ffffffff81c199e0 RBP: ffffffff81c1e3c0 R08: ffff88801f41f000 R09: ffffffff81c1e348 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 00007f32bedf8830 R14: 00000000fee1dead R15: 0000000000000000 FS: 00007f32bedf8980(0000) GS:ffff88801f480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff90ab1bb0 CR3: 000000001d057000 CR4: 00000000000006a0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __do_sys_reboot.cold+0x34/0x5b do_syscall_64+0x2d/0x40 Fixes: 1b3a5d02 ("reboot: move arch/x86 reboot= handling to generic kernel") Signed-off-by: -
Matteo Croce authored
Patch series "fix parsing of reboot= cmdline", v3. The parsing of the reboot= cmdline has two major errors: - a missing bound check can crash the system on reboot - parsing of the cpu number only works if specified last Fix both. This patch (of 2): This reverts commit 616feab7. kstrtoint() and simple_strtoul() have a subtle difference which makes them non interchangeable: if a non digit character is found amid the parsing, the former will return an error, while the latter will just stop parsing, e.g. simple_strtoul("123xyx") = 123. The kernel cmdline reboot= argument allows to specify the CPU used for rebooting, with the syntax `s####` among the other flags, e.g. "reboot=warm,s31,force", so if this flag is not the last given, it's silently ignored as well as the subsequent ones. Fixes: 616feab7 ("kernel/reboot.c: convert simple_strtoul to kstrtoint") Signed-off-by:
-
- Nov 10, 2020
-
-
Kai-Heng Feng authored
After reboot, it's not possible to use hotkeys to enter BIOS setup and boot menu on some HP laptops. BIOS folks identified the root cause is the missing _PTS call, and BIOS is expecting _PTS to do proper reset. Using S5 for reboot is default behavior under Windows, "A full shutdown (S5) occurs when a system restart is requested" [1], so let's do the same here. [1] https://docs.microsoft.com/en-us/windows/win32/power/system-power-states Signed-off-by:
-
- Jul 01, 2020
-
-
Mike Rapoport authored
The unicore32 port do not seem maintained for a long time now, there is no upstream toolchain that can create unicore32 binaries and all the links to prebuilt toolchains for unicore32 are dead. Even compilers that were available are not supported by the kernel anymore. Guenter Roeck says: I have stopped building unicore32 images since v4.19 since there is no available compiler that is still supported by the kernel. I am surprised that support for it has not been removed from the kernel. Remove unicore32 port. Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Guenter Roeck <linux@roeck-us.net>
-
- May 30, 2020
-
-
Kees Cook authored
To turn the KMSG_DUMP_* reasons into a more ordered list, collapse the redundant KMSG_DUMP_(RESTART|HALT|POWEROFF) reasons into KMSG_DUMP_SHUTDOWN. The current users already don't meaningfully distinguish between them, so there's no need to, as discussed here: https://lore.kernel.org/lkml/CA+CK2bAPv5u1ih5y9t5FUnTyximtFCtDYXJCpuyjOyHNOkRdqw@mail.gmail.com/ Link: https://lore.kernel.org/lkml/20200515184434.8470-2-keescook@chromium.org/ Reviewed-by:
Pavel Tatashin <pasha.tatashin@soleen.com> Reviewed-by:
Kees Cook <keescook@chromium.org>
-
- May 21, 2019
-
-
Thomas Gleixner authored
Add SPDX license identifiers to all files which: - Have no license information of any form - Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- May 15, 2019
-
-
Aaro Koskinen authored
Allow specifying reboot_mode for panic only. This is needed on systems where ramoops is used to store panic logs, and user wants to use warm reset to preserve those, while still having cold reset on normal reboots. Link: http://lkml.kernel.org/r/20190322004735.27702-1-aaro.koskinen@iki.fi Signed-off-by:
Aaro Koskinen <aaro.koskinen@nokia.com> Reviewed-by:
-
