Re: [PATCH v23 00/13] Implement PSCI reboot mode driver for PSCI resets

[Bartosz Golaszewski]

On Tue, 14 Jul 2026 19:16:28 +0200, Shivendra Pratap
<shivendra.pratap@xxxxxxxxxxxxxxxx> said:
> Userspace should be able to initiate device reboots using the various
> PSCI SYSTEM_RESET and SYSTEM_RESET2 types defined by PSCI spec. This
> patch series introduces psci-reboot-mode driver that will induce
> command-based resets to psci driver for executing the device reset.
>
> The PSCI system reset calls takes two arguments: reset_type and cookie.
> It defines predefined reset types, such as warm and cold reset, and
> vendor-specific reset types which are SoC vendor specific. To support
> these requirements, the reboot-mode framework is enhanced in two key
> ways:
> 1. 64-bit magic support: Extend reboot-mode to handle two 32-bit
> arguments (reset_type and cookie) by encoding them into a single 64-bit
> magic value.
> 2. Predefined modes: Add support for predefined reboot modes in the
> framework.
>
> With these enhancements, the patch series enables:
>  - Arch Warm reset and system reset cold as predefined reboot modes.
>  - Vendor-specific resets, configurable via the SoC-specific device tree.
>
> Together, these changes allow userspace to trigger all above PSCI resets
> from userspace.
>
> Note on introducing PSCI-MFD:
> In v19/20, psci-reboot-mode was implemented as a faux-device. Review
> discussion suggested this may not be the best model for firmware-backed
> consumers, and that representing PSCI users as regular platform devices
> would be better. One suggestion was to add a PSCI-MFD driver, allowing
> multiple consumers tied to a single PSCI node "arm,psci-1.0" be probed
> as MFD cells.
>
> Following this, the series adds a PSCI-MFD driver and introduces
> cpuidle-psci-domain and psci-reboot-mode as child cells. To meet the
> psci-reboot-mode requirement, the MFD core is extended to support
> fwnode.
> Reference discussions on this:
> https://lore.kernel.org/all/20260306-faux-dev-with-fwnode-v1-1-792a86a62530@xxxxxxxxxxxxxxxx/
>
> ---
> The patch is tested on rb3Gen2, lemans-ride, lemans-evk, monaco-ride,
> qcs615-ride.
>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@xxxxxxxxxxxxxxxx>
>
> Changes in v23:
> mfd: core: Add firmware-node support to MFD cells
>  - Add named_fwnode-based firmware node support in MFD cells.(by Bart)
>  - Update the release path. (by Bart)
>  - Add checks for duplicate fwnodes.
>  - Update documentation for usage and limitations.
> mfd: psci-mfd: Add psci-reboot-mode child cell
>  - Update for a named_fwnode-based reboot-mode child cell. (By Bart)
>  - Split psci-reboot-mode and psci-cpuidle-domain into separate child
>    cells.
> power: reset: Add psci-reboot-mode driver
>  - Add COMPILE_TEST in Kconfig. (by Bart)
>  - Update to support up to three u32 arguments to accommodate a
>    32-bit reset_type and a 64-bit cookie. (By Sashiko, Lorenzo)
> dt-bindings: arm: Document reboot mode magic
>  - Update to support up to three u32 arguments to accommodate a
>    32-bit reset_type and a 64-bit cookie.
>  - Dropped reviewed by from Bart and Rob due to considerable changes.
> firmware: psci: Introduce command-based resets
>  - Update to support a 64-bit cookie. (By Sashiko, Lorenzo)
>  - Update the flow so unsupported reset commands and any failures during
>    reset command execution fall back to the
>    Linux reboot_mode path. (By Sashiko)
> power: reset: reboot-mode: Add support for predefined reboot modes
>  - Handle errors and free lists in devm_reboot_mode_register(). (by Sashiko)
>  - Update to support up to three u32 arguments.
> power: reset: reboot-mode: Support up to 3 magic values per mode
>  - Patch for 64 bit magic renamed.
>  - Update to support up to three u32 arguments to accommodate a 32-bit
>    reset_type and a 64-bit cookie.
>  - Dropped reviewed by from Bart and Sebastian due to considerable changes.
> - Link to v22: https://lore.kernel.org/r/20260514-arm-psci-system_reset2-vendor-reboots-v22-0-28a5bde07483@xxxxxxxxxxxxxxxx
>

Just wanted to say: thanks for being persistent, we'll get there eventually. :)

Bart