From patchwork Mon Jan 13 16:25:25 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ahmad Fatoum X-Patchwork-Id: 13937747 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B537233543 for ; Mon, 13 Jan 2025 16:26:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736785581; cv=none; b=aJeNMOaC/Fj+F0wZ8Vf2qt8v1HYck748lMC27L3EfEQsel7ugnpDXi4pO8+0ylB+sIiSgDDqKWAQW3a8bH+bfTVkbLoy8cSdTVsQjDJGHDwg0lBnZzKQ8heRT7ZkXvxR75Yvr7+Gtgfe/L/JmjgEQQp7RMQt7GgVGkM+tJfPIU8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736785581; c=relaxed/simple; bh=sFLyBSuLrvullFBEAJNO+fofARBeP56USsuwBnXypkg=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=eALyOL7Zijrllup+Dl+mZNR9alA4LWZz1jhkZL9FjQGsfaitWqIuHZ6qHnq+gkBdDUa8mnitphTGYfbqJGlt8yOsNA9QDDRYooxmjq5Y58Gr+gqNHxdvr8BVOhat3fJasJfPGgl9EW80QZSOaZXbjaQwA7xLMZ/ZxehnM+4wgU8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tXNFs-0000JE-AS; Mon, 13 Jan 2025 17:25:32 +0100 Received: from dude05.red.stw.pengutronix.de ([2a0a:edc0:0:1101:1d::54]) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tXNFp-000HzE-2Z; Mon, 13 Jan 2025 17:25:30 +0100 Received: from localhost ([::1] helo=dude05.red.stw.pengutronix.de) by dude05.red.stw.pengutronix.de with esmtp (Exim 4.96) (envelope-from ) id 1tXNFq-007FQL-2t; Mon, 13 Jan 2025 17:25:30 +0100 From: Ahmad Fatoum Subject: [PATCH v2 00/12] reboot: support runtime configuration of emergency hw_protection action Date: Mon, 13 Jan 2025 17:25:25 +0100 Message-Id: <20250113-hw_protection-reboot-v2-0-161d3fc734f0@pengutronix.de> Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAHU+hWcC/22NwQ6CMBBEf4Xs2Zp2QaSe/A9DDMICe2nJtiKG8 O9WEm8e32TmzQqBhCnAJVtBaObA3iXAQwbt2LiBFHeJATUWBk2lxtd9Eh+pjamphB7eR2VLe8o Lm5+xbCBNJ6Gel117qxOPHKKX9/4ym2/6E9r/wtkorbDMG92arq80XidywzOKd7wcO4J627YPZ ZUH3L0AAAA= X-Change-ID: 20241218-hw_protection-reboot-96953493726a To: Andrew Morton , Daniel Lezcano , Fabio Estevam , "Rafael J. Wysocki" , Zhang Rui , Lukasz Luba , Jonathan Corbet , Serge Hallyn , Liam Girdwood , Mark Brown , Matti Vaittinen , Benson Leung , Tzung-Bi Shih , Guenter Roeck , Rob Herring , Krzysztof Kozlowski , Conor Dooley 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, Ahmad Fatoum , Matteo Croce X-Mailer: b4 0.14.2 X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-security-module@vger.kernel.org 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. --- Changes in v2: - Added Rob's dt-bindings Acked-by - Add kernel-doc for all newly introduced enums, functions and function parameters (lkp) - Fix kernel-doc warning for do_kernel_restart even though it wasn't introduced in this series (lkp) - Rename the work function and object in patch 2 already to align with the functional change - - Link to v1: https://lore.kernel.org/r/20241219-hw_protection-reboot-v1-0-263a0c1df802@pengutronix.de --- Ahmad Fatoum (12): 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: describe do_kernel_restart's cmd argument in kernel-doc reboot: rename now misleading __hw_protection_shutdown 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 | 36 ++++-- include/uapi/linux/capability.h | 1 + kernel/reboot.c | 140 ++++++++++++++++----- 13 files changed, 195 insertions(+), 73 deletions(-) --- base-commit: 78d4f34e2115b517bcbfe7ec0d018bbbb6f9b0b8 change-id: 20241218-hw_protection-reboot-96953493726a Best regards,