Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
b3d81d3e |
| 15-Jul-2023 |
Benjamin Bara <benjamin.bara@skidata.com> |
kernel/reboot: emergency_restart: Set correct system_state
commit 60466c067927abbcaff299845abd4b7069963139 upstream.
As the emergency restart does not call kernel_restart_prepare(), the system_stat
kernel/reboot: emergency_restart: Set correct system_state
commit 60466c067927abbcaff299845abd4b7069963139 upstream.
As the emergency restart does not call kernel_restart_prepare(), the system_state stays in SYSTEM_RUNNING.
Since bae1d3a05a8b, 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: bae1d3a05a8b ("i2c: core: remove use of in_atomic()") Cc: stable@vger.kernel.org # v5.2+ Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com> Link: https://lore.kernel.org/r/20230327-tegra-pmic-reboot-v7-1-18699d5dcd76@skidata.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0 |
|
#
e7fd8b68 |
| 29-Sep-2022 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
kernel/reboot: Add SYS_OFF_MODE_RESTART_PREPARE mode
Add SYS_OFF_MODE_RESTART_PREPARE callbacks to be invoked before a system restart.
Suggested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
kernel/reboot: Add SYS_OFF_MODE_RESTART_PREPARE mode
Add SYS_OFF_MODE_RESTART_PREPARE callbacks to be invoked before a system restart.
Suggested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50 |
|
#
07a22b61 |
| 23-Jun-2022 |
Petr Mladek <pmladek@suse.com> |
Revert "printk: add functions to prefer direct printing"
This reverts commit 2bb2b7b57f81255c13f4395ea911d6bdc70c9fe2.
The testing of 5.19 release candidates revealed missing synchronization betwee
Revert "printk: add functions to prefer direct printing"
This reverts commit 2bb2b7b57f81255c13f4395ea911d6bdc70c9fe2.
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
show more ...
|
#
20fb0c82 |
| 23-Jun-2022 |
Petr Mladek <pmladek@suse.com> |
Revert "printk: Wait for the global console lock when the system is going down"
This reverts commit b87f02307d3cfbda768520f0687c51ca77e14fc3.
The testing of 5.19 release candidates revealed missing
Revert "printk: Wait for the global console lock when the system is going down"
This reverts commit b87f02307d3cfbda768520f0687c51ca77e14fc3.
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-2-pmladek@suse.com
show more ...
|
Revision tags: v5.15.49, v5.15.48 |
|
#
b87f0230 |
| 15-Jun-2022 |
Petr Mladek <pmladek@suse.com> |
printk: Wait for the global console lock when the system is going down
There are reports that the console kthreads block the global console lock when the system is going down, for example, reboot, p
printk: Wait for the global console lock when the system is going down
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: Petr Mladek <pmladek@suse.com> Tested-by: Paul E. McKenney <paulmck@kernel.org> Link: https://lore.kernel.org/r/20220615162805.27962-3-pmladek@suse.com
show more ...
|
Revision tags: v5.15.47, v5.15.46 |
|
#
2b8c612c |
| 06-Jun-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Fix powering off using a non-syscall code paths
There are other methods of powering off machine than the reboot syscall. Previously we missed to cover those methods and it created pow
kernel/reboot: Fix powering off using a non-syscall code paths
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: da007f171fc9 ("kernel/reboot: Change registration order of legacy power-off handler") Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.45 |
|
#
587b9bfe |
| 31-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Use static handler for register_platform_power_off()
The register_platform_power_off() fails on m68k platform due to the memory allocation error that happens at a very early boot time
kernel/reboot: Use static handler for register_platform_power_off()
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: f0f7e5265b3b ("m68k: Switch to new sys-off handler API") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.44, v5.15.43, v5.15.42 |
|
#
da007f17 |
| 24-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Change registration order of legacy power-off handler
We're unconditionally registering sys-off handler for the legacy pm_power_off() callback, this causes problem for platforms that
kernel/reboot: Change registration order of legacy power-off handler
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: 0e2110d2e910 ("kernel/reboot: Add kernel_can_power_off()") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.18, v5.15.41, v5.15.40, v5.15.39 |
|
#
6779db97 |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Add devm_register_restart_handler()
Add devm_register_restart_handler() helper that registers sys-off handler using restart mode and with a default priority. Most drivers will want to
kernel/reboot: Add devm_register_restart_handler()
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 <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
d2c54153 |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Add devm_register_power_off_handler()
Add devm_register_power_off_handler() helper that registers sys-off handler using power-off mode and with a default priority. Most drivers will w
kernel/reboot: Add devm_register_power_off_handler()
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 <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
5b71808e |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
reboot: Remove pm_power_off_prepare()
All pm_power_off_prepare() users were converted to sys-off handler API. Remove the obsolete global callback variable.
Signed-off-by: Dmitry Osipenko <dmitry.os
reboot: Remove pm_power_off_prepare()
All pm_power_off_prepare() users were converted to sys-off handler API. Remove the obsolete global callback variable.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
fb61375e |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Add register_platform_power_off()
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
kernel/reboot: Add register_platform_power_off()
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 <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
0e2110d2 |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Add kernel_can_power_off()
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 p
kernel/reboot: Add kernel_can_power_off()
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 <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
5d34b41a |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Add stub for pm_power_off
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
kernel/reboot: Add stub for pm_power_off
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 <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
2b6aa733 |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Add do_kernel_power_off()
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
kernel/reboot: Add do_kernel_power_off()
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 <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
7b9a3de9 |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Wrap legacy power-off callbacks into sys-off handlers
Wrap legacy power-off callbacks into sys-off handlers in order to support co-existence of both legacy and new callbacks while we'
kernel/reboot: Wrap legacy power-off callbacks into sys-off handlers
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 <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
232edc2f |
| 09-May-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
kernel/reboot: Introduce sys-off handler API
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 cha
kernel/reboot: Introduce sys-off handler API
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: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.38, v5.15.37 |
|
#
764aaf44 |
| 27-Apr-2022 |
YueHaibing <yuehaibing@huawei.com> |
reboot: Fix build warning without CONFIG_SYSCTL
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
reboot: Fix build warning without CONFIG_SYSCTL
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: 06d177662fb8 ("kernel/reboot: move reboot sysctls to its own file") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
show more ...
|
Revision tags: v5.15.36 |
|
#
2bb2b7b5 |
| 21-Apr-2022 |
John Ogness <john.ogness@linutronix.de> |
printk: add functions to prefer direct printing
Once kthread printing is available, console printing will no longer occur in the context of the printk caller. However, there are some special context
printk: add functions to prefer direct printing
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: Petr Mladek <pmladek@suse.com> Acked-by: Paul E. McKenney <paulmck@kernel.org> # for RCU Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20220421212250.565456-13-john.ogness@linutronix.de
show more ...
|
Revision tags: v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25 |
|
#
06d17766 |
| 16-Feb-2022 |
tangmeng <tangmeng@uniontech.com> |
kernel/reboot: move reboot sysctls to its own file
kernel/sysctl.c is a kitchen sink where everyone leaves their dirty dishes, this makes it very difficult to maintain.
To help with this maintenanc
kernel/reboot: move reboot sysctls to its own file
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: Luis Chamberlain <mcgrof@kernel.org>
show more ...
|
Revision tags: v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15 |
|
#
a52f60fa |
| 20-Oct-2021 |
Eric W. Biederman <ebiederm@xmission.com> |
reboot: Remove the unreachable panic after do_exit in reboot(2)
Link: https://lkml.kernel.org/r/20211020174406.17889-3-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
Revision tags: v5.14.14, v5.14.13 |
|
#
d46b3f5b |
| 16-Oct-2021 |
Shawn Guo <shawn.guo@linaro.org> |
reboot: export symbol 'reboot_mode'
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
reboot: export symbol 'reboot_mode'
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>
show more ...
|
Revision tags: v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42 |
|
#
dfa19b11 |
| 03-Jun-2021 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
reboot: Add hardware protection power-off
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 tempe
reboot: Add hardware protection power-off
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: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/e83ec1ca9408f90c857ea9dcdc57b14d9037b03f.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24 |
|
#
9d3fcb28 |
| 16-Mar-2021 |
Josef Bacik <josef@toxicpanda.com> |
Revert "PM: ACPI: reboot: Use S5 for reboot"
This reverts commit d60cd06331a3566d3305b3c7b566e79edf4e2095.
This patch causes a panic when rebooting my Dell Poweredge r440. I do not have the full p
Revert "PM: ACPI: reboot: Use S5 for reboot"
This reverts commit d60cd06331a3566d3305b3c7b566e79edf4e2095.
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
40247e55 |
| 15-Dec-2020 |
Matteo Croce <mcroce@microsoft.com> |
reboot: hide from sysfs not applicable settings
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_fo
reboot: hide from sysfs not applicable settings
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: Petr Mladek <pmladek@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|