devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Fabio Estevam <festevam@denx.de>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Lukasz Luba <lukasz.luba@arm.com>,
	Jonathan Corbet <corbet@lwn.net>, Serge Hallyn <serge@hallyn.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Benson Leung <bleung@chromium.org>,
	Tzung-Bi Shih <tzungbi@kernel.org>,
	Guenter Roeck <groeck@chromium.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-security-module@vger.kernel.org,
	chrome-platform@lists.linux.dev, devicetree@vger.kernel.org,
	kernel@pengutronix.de, Matteo Croce <mcroce@microsoft.com>
Subject: Re: [PATCH 00/11] reboot: support runtime configuration of emergency hw_protection action
Date: Sun, 22 Dec 2024 11:38:06 +0200	[thread overview]
Message-ID: <dc8d1cdf-dff4-48fc-a03d-aeab9be22e44@gmail.com> (raw)
In-Reply-To: <20241219-hw_protection-reboot-v1-0-263a0c1df802@pengutronix.de>

On 19/12/2024 09:31, Ahmad Fatoum 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.

Sometimes it can. There are platforms where the hardware is such we know 
that poweroff or reboot are the way to go. In such case the driver 
should get the information from the hardware description (like device-tree).

> 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

This sounds like a consequence of a hardware design as restoring the 
power doesn't wake up the SoC(?)

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

I am not against the change though. Just wondering if this is still a 
consequence of the hardware design, and if the device-tree would be 
proper place to indicate that poweroff shouldn't be used.

I'm about to leave my computer behind for holidays, so I am probably not 
able to do a proper review until the next year. Thus this quick comment 
:) Also, no strong opinion so I'm not expecting anyone to hold back 
waiting for me!

Good luck and happy holidays!
-- Matti

> ---
> Ahmad Fatoum (11):
>        reboot: replace __hw_protection_shutdown bool action parameter with an enum
>        reboot: reboot, not shutdown, on hw_protection_reboot timeout
>        docs: thermal: sync hardware protection doc with code
>        reboot: rename now misleading hw_protection symbols
>        reboot: indicate whether it is a HARDWARE PROTECTION reboot or shutdown
>        reboot: add support for configuring emergency hardware protection action
>        regulator: allow user configuration of hardware protection action
>        platform/chrome: cros_ec_lpc: prepare for hw_protection_shutdown removal
>        dt-bindings: thermal: give OS some leeway in absence of critical-action
>        thermal: core: allow user configuration of hardware protection action
>        reboot: retire hw_protection_reboot and hw_protection_shutdown helpers
> 
>   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                             |  25 +++--
>   include/uapi/linux/capability.h                    |   1 +
>   kernel/reboot.c                                    | 122 ++++++++++++++++-----
>   13 files changed, 173 insertions(+), 66 deletions(-)
> ---
> base-commit: 78d4f34e2115b517bcbfe7ec0d018bbbb6f9b0b8
> change-id: 20241218-hw_protection-reboot-96953493726a
> 
> Best regards,


  parent reply	other threads:[~2024-12-22  9:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19  7:31 [PATCH 00/11] reboot: support runtime configuration of emergency hw_protection action Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 01/11] reboot: replace __hw_protection_shutdown bool action parameter with an enum Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 02/11] reboot: reboot, not shutdown, on hw_protection_reboot timeout Ahmad Fatoum
2024-12-20  6:12   ` kernel test robot
2025-01-06 14:28     ` Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 03/11] docs: thermal: sync hardware protection doc with code Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 04/11] reboot: rename now misleading hw_protection symbols Ahmad Fatoum
2024-12-20  6:56   ` kernel test robot
2024-12-19  7:31 ` [PATCH 05/11] reboot: indicate whether it is a HARDWARE PROTECTION reboot or shutdown Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 06/11] reboot: add support for configuring emergency hardware protection action Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 07/11] regulator: allow user configuration of " Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 08/11] platform/chrome: cros_ec_lpc: prepare for hw_protection_shutdown removal Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 09/11] dt-bindings: thermal: give OS some leeway in absence of critical-action Ahmad Fatoum
2025-01-02 17:33   ` Rob Herring (Arm)
2024-12-19  7:31 ` [PATCH 10/11] thermal: core: allow user configuration of hardware protection action Ahmad Fatoum
2024-12-19  7:31 ` [PATCH 11/11] reboot: retire hw_protection_reboot and hw_protection_shutdown helpers Ahmad Fatoum
2024-12-22  9:38 ` Matti Vaittinen [this message]
2024-12-22  9:58   ` [PATCH 00/11] reboot: support runtime configuration of emergency hw_protection action Ahmad Fatoum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc8d1cdf-dff4-48fc-a03d-aeab9be22e44@gmail.com \
    --to=mazziesaccount@gmail.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=bleung@chromium.org \
    --cc=broonie@kernel.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@denx.de \
    --cc=groeck@chromium.org \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=mcroce@microsoft.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=serge@hallyn.com \
    --cc=tzungbi@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).