Message-Id: <20250113163300.4dce8816af9d448b6e263140@linux-foundation.org>
Date: Mon, 13 Jan 2025 16:33:00 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>, Fabio Estevam
 <festevam@...x.de>, "Rafael J. Wysocki" <rafael@...nel.org>, Zhang Rui
 <rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>, Jonathan Corbet
 <corbet@....net>, Serge Hallyn <serge@...lyn.com>, Liam Girdwood
 <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Matti Vaittinen
 <mazziesaccount@...il.com>, Benson Leung <bleung@...omium.org>, Tzung-Bi
 Shih <tzungbi@...nel.org>, Guenter Roeck <groeck@...omium.org>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-kernel@...r.kernel.org,
 linux-pm@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-security-module@...r.kernel.org, chrome-platform@...ts.linux.dev,
 devicetree@...r.kernel.org, kernel@...gutronix.de, Matteo Croce
 <mcroce@...rosoft.com>
Subject: Re: [PATCH v2 00/12] reboot: support runtime configuration of
 emergency hw_protection action

On Mon, 13 Jan 2025 17:25:25 +0100 Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:

> 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 seems useful.

>  Documentation/ABI/testing/sysfs-kernel-reboot      |   8 ++
>  Documentation/admin-guide/kernel-parameters.txt    |   6 +
>  .../devicetree/bindings/thermal/thermal-zones.yaml |   5 +-
>  Documentation/driver-api/thermal/sysfs-api.rst     |  25 ++--
>  drivers/platform/chrome/cros_ec_lpc.c              |   2 +-
>  drivers/regulator/core.c                           |   4 +-
>  drivers/regulator/irq_helpers.c                    |  16 +--
>  drivers/thermal/thermal_core.c                     |  17 +--
>  drivers/thermal/thermal_core.h                     |   1 +
>  drivers/thermal/thermal_of.c                       |   7 +-
>  include/linux/reboot.h                             |  36 ++++--
>  include/uapi/linux/capability.h                    |   1 +
>  kernel/reboot.c                                    | 140 ++++++++++++++++-----
>  13 files changed, 195 insertions(+), 73 deletions(-)

I'm not sure what the merge path is.  Maybe the drivers tree, maybe
mm.git's mm-nonmm branches.

We're at -rc7 so I'll save this away and shall revisit after -rc1 with
a view to gathering acks (please) and adding the series to mm-nonmm, thanks.

Powered by blists - more mailing lists