reboot: add support for configuring emergency hardware protection action

We currently leave the decision of whether to shutdown or reboot to
protect hardware in an emergency situation to the individ

reboot: add support for configuring emergency hardware protection action

We currently leave the decision of whether to shutdown or reboot to
protect hardware in an emergency situation to the individual drivers.

This works out in some cases, where the driver detecting the critical
failure has inside knowledge: It binds to the system management controller
for example or is guided by hardware description that defines what to do.

In the general case, however, the driver detecting the issue can't know
what the appropriate course of action is and shouldn't be dictating the
policy of dealing with it.

Therefore, add a global hw_protection toggle that allows the user to
specify whether shutdown or reboot should be the default action when the
driver doesn't set policy.

This introduces no functional change yet as hw_protection_trigger() has no
callers, but these will be added in subsequent commits.

[[email protected]: hide unused hw_protection_attr]
Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Cc: Benson Leung <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Matteo Croce <[email protected]>
Cc: Matti Vaittinen <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Rob Herring (Arm) <[email protected]>
Cc: Rui Zhang <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

reboot: indicate whether it is a HARDWARE PROTECTION reboot or shutdown

It currently depends on the caller, whether we attempt a hardware
protection shutdown (poweroff) or a reboot. A follow-up com

reboot: indicate whether it is a HARDWARE PROTECTION reboot or shutdown

It currently depends on the caller, whether we attempt a hardware
protection shutdown (poweroff) or a reboot. A follow-up commit will make
this partially user-configurable, so it's a good idea to have the
emergency message clearly state whether the kernel is going for a reboot
or a shutdown.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Cc: Benson Leung <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Matteo Croce <[email protected]>
Cc: Matti Vaittinen <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Rob Herring (Arm) <[email protected]>
Cc: Rui Zhang <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

reboot: rename now misleading __hw_protection_shutdown symbols

The __hw_protection_shutdown function name has become misleading since it
can cause either a shutdown (poweroff) or a reboot depending

reboot: rename now misleading __hw_protection_shutdown symbols

The __hw_protection_shutdown function name has become misleading since it
can cause either a shutdown (poweroff) or a reboot depending on its
argument.

To avoid further confusion, let's rename it, so it doesn't suggest that a
poweroff is all it can do.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Cc: Benson Leung <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Matteo Croce <[email protected]>
Cc: Matti Vaittinen <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Rob Herring (Arm) <[email protected]>
Cc: Rui Zhang <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

reboot: describe do_kernel_restart's cmd argument in kernel-doc

A W=1 build rightfully complains about the function's kernel-doc being
incomplete.

Describe its single parameter to fix this.

Link:

reboot: describe do_kernel_restart's cmd argument in kernel-doc

A W=1 build rightfully complains about the function's kernel-doc being
incomplete.

Describe its single parameter to fix this.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Cc: Benson Leung <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Matteo Croce <[email protected]>
Cc: Matti Vaittinen <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Rob Herring (Arm) <[email protected]>
Cc: Rui Zhang <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

reboot: reboot, not shutdown, on hw_protection_reboot timeout

hw_protection_shutdown() will kick off an orderly shutdown and if that
takes longer than a configurable amount of time, an emergency shu

reboot: reboot, not shutdown, on hw_protection_reboot timeout

hw_protection_shutdown() will kick off an orderly shutdown and if that
takes longer than a configurable amount of time, an emergency shutdown
will occur.

Recently, hw_protection_reboot() was added for those systems that don't
implement a proper shutdown and are better served by rebooting and having
the boot firmware worry about doing something about the critical
condition.

On timeout of the orderly reboot of hw_protection_reboot(), the system
would go into shutdown, instead of reboot. This is not a good idea, as
going into shutdown was explicitly not asked for.

Fix this by always doing an emergency reboot if hw_protection_reboot() is
called and the orderly reboot takes too long.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 79fa723ba84c ("reboot: Introduce thermal_zone_device_critical_reboot()")
Signed-off-by: Ahmad Fatoum <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Matti Vaittinen <[email protected]>
Cc: Benson Leung <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Matteo Croce <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Rob Herring (Arm) <[email protected]>
Cc: Rui Zhang <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

reboot: replace __hw_protection_shutdown bool action parameter with an enum

Patch series "reboot: support runtime configuration of emergency
hw_protection action", v3.

We currently leave the decisi

reboot: replace __hw_protection_shutdown bool action parameter with an enum

Patch series "reboot: support runtime configuration of emergency
hw_protection action", v3.

We currently leave the decision of whether to shutdown or reboot to
protect hardware in an emergency situation to the individual drivers.

This works out in some cases, where the driver detecting the critical
failure has inside knowledge: It binds to the system management controller
for example or is guided by hardware description that defines what to do.

This is inadequate in the general case though as a driver reporting e.g.
an imminent power failure can't know whether a shutdown or a reboot would
be more appropriate for a given hardware platform.

To address this, this series adds a hw_protection kernel parameter and
sysfs toggle that can be used to change the action from the shutdown
default to reboot. A new hw_protection_trigger API then makes use of this
default action.

My particular use case is unattended embedded systems that don't have
support for shutdown and that power on automatically when power is
supplied:

- A brief power cycle gets detected by the driver
- The kernel powers down the system and SoC goes into shutdown mode
- Power is restored
- The system remains oblivious to the restored power
- System needs to be manually power cycled for a duration long enough
to drain the capacitors

With this series, such systems can configure the kernel with
hw_protection=reboot to have the boot firmware worry about critical
conditions.


This patch (of 12):

Currently __hw_protection_shutdown() either reboots or shuts down the
system according to its shutdown argument.

To make the logic easier to follow, both inside __hw_protection_shutdown
and at caller sites, lets replace the bool parameter with an enum.

This will be extra useful, when in a later commit, a third action is added
to the enumeration.

No functional change.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Cc: Benson Leung <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Matteo Croce <[email protected]>
Cc: Matti Vaittinen <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Rui Zhang <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

Flush console log from kernel_power_off()

Kernels built with CONFIG_PREEMPT_RT=y can lose significant console output
and shutdown time, which hides shutdown-time RCU issues from rcutorture.
Therefor

Flush console log from kernel_power_off()

Kernels built with CONFIG_PREEMPT_RT=y can lose significant console output
and shutdown time, which hides shutdown-time RCU issues from rcutorture.
Therefore, make pr_flush() public and invoke it after then last print
in kernel_power_off().

[ paulmck: Apply John Ogness feedback. ]
[ paulmck: Appy Sebastian Andrzej Siewior feedback. ]
[ paulmck: Apply kernel test robot feedback. ]

Signed-off-by: Paul E. McKenney <[email protected]>
Reviewed-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Link: https://lore.kernel.org/r/5f743488-dc2a-4f19-bdda-cf50b9314832@paulmck-laptop
Signed-off-by: Boqun Feng <[email protected]>

show more ...

treewide: const qualify ctl_tables where applicable

Add the const qualifier to all the ctl_tables in the tree except for
watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
loadpin_sysc

treewide: const qualify ctl_tables where applicable

Add the const qualifier to all the ctl_tables in the tree except for
watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
drivers/inifiniband dirs). These are special cases as they use a
registration function with a non-const qualified ctl_table argument or
modify the arrays before passing them on to the registration function.

Constifying ctl_table structs will prevent the modification of
proc_handler function pointers as the arrays would reside in .rodata.
This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
constify the ctl_table argument of proc_handlers") constified all the
proc_handlers.

Created this by running an spatch followed by a sed command:
Spatch:
virtual patch

@
depends on !(file in "net")
disable optional_qualifier
@

identifier table_name != {
watchdog_hardlockup_sysctl,
iwcm_ctl_table,
ucma_ctl_table,
memory_allocation_profiling_sysctls,
loadpin_sysctl_table
};
@@

+ const
struct ctl_table table_name [] = { ... };

sed:
sed --in-place \
-e "s/struct ctl_table .table = &uts_kern/const struct ctl_table *table = \&uts_kern/" \
kernel/utsname_sysctl.c

Reviewed-by: Song Liu <[email protected]>
Acked-by: Steven Rostedt (Google) <[email protected]> # for kernel/trace/
Reviewed-by: Martin K. Petersen <[email protected]> # SCSI
Reviewed-by: Darrick J. Wong <[email protected]> # xfs
Acked-by: Jani Nikula <[email protected]>
Acked-by: Corey Minyard <[email protected]>
Acked-by: Wei Liu <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Reviewed-by: Bill O'Donnell <[email protected]>
Acked-by: Baoquan He <[email protected]>
Acked-by: Ashutosh Dixit <[email protected]>
Acked-by: Anna Schumaker <[email protected]>
Signed-off-by: Joel Granados <[email protected]>

show more ...

kernel/reboot: replace sprintf() with sysfs_emit()

As Documentation/filesystems/sysfs.rst suggested, show() should only use
sysfs_emit() or sysfs_emit_at() when formatting the value to be returned
t

kernel/reboot: replace sprintf() with sysfs_emit()

As Documentation/filesystems/sysfs.rst suggested, show() should only use
sysfs_emit() or sysfs_emit_at() when formatting the value to be returned
to user space.

No functional change intended.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: zhangguopeng <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Joel Granados <[email protected]>
Cc: Thomas Weißschuh <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

reboot: move reboot_notifier_list to kernel/reboot.c

All the functions related to the reboot notifier list are in
kernel/reboot.c. Move the list itself, too. As there are no direct users
anymore,

reboot: move reboot_notifier_list to kernel/reboot.c

All the functions related to the reboot notifier list are in
kernel/reboot.c. Move the list itself, too. As there are no direct users
anymore, make the declaration static.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Weißschuh <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

kernel misc: Remove the now superfluous sentinel elements from ctl_table array

This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (

kernel misc: Remove the now superfluous sentinel elements from ctl_table array

This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https://lore.kernel.org/all/ZO5Yx5JFogGi%[email protected]/)

Remove the sentinel from ctl_table arrays. Reduce by one the values used
to compare the size of the adjusted arrays.

Signed-off-by: Joel Granados <[email protected]>

show more ...

reboot: Introduce thermal_zone_device_critical_reboot()

Introduce thermal_zone_device_critical_reboot() to trigger an
emergency reboot.

It is a counterpart of thermal_zone_device_critical() with th

reboot: Introduce thermal_zone_device_critical_reboot()

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 <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal/core: Prepare for introduction of thermal reboot

Add some helper functions to make it easier introducing the support
for thermal reboot.

No functional change.

Signed-off-by: Fabio Estevam

thermal/core: Prepare for introduction of thermal reboot

Add some helper functions to make it easier introducing the support
for thermal reboot.

No functional change.

Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

kernel/reboot: explicitly notify if halt occurred instead of power off

When kernel_can_power_off() returns false, and reboot has called with
LINUX_REBOOT_CMD_POWER_OFF, kernel_halt() will be initiat

kernel/reboot: explicitly notify if halt occurred instead of power off

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

[[email protected]: tweak comment text]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Dongmin Lee <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

kernel/reboot: Add device to sys_off_handler

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_dat

kernel/reboot: Add device to sys_off_handler

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 <[email protected]>
Signed-off-by: Benjamin Bara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

kernel/reboot: emergency_restart: Set correct system_state

As the emergency restart does not call kernel_restart_prepare(), the
system_state stays in SYSTEM_RUNNING.

Since bae1d3a05a8b, this hinder

kernel/reboot: emergency_restart: Set correct system_state

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: [email protected] # v5.2+
Reviewed-by: Dmitry Osipenko <[email protected]>
Tested-by: Nishanth Menon <[email protected]>
Signed-off-by: Benjamin Bara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

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 <[email protected]>

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 <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Kai-Heng Feng <[email protected]>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

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 <[email protected]>
Tested-by: Paul E. McKenney <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

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 <[email protected]> # ppce500
Reported-by: Michael Ellerman <[email protected]> # ppce500
Fixes: da007f171fc9 ("kernel/reboot: Change registration order of legacy power-off handler")
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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 <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...