[PATCH v3 1/2] firmware: psci: Refactor EFI runtime PSCI reset handling

[Aswin Murugan]

On 2/18/2026 1:44 AM, Heinrich Schuchardt wrote:
> Am 13. Februar 2026 12:05:26 MEZ schrieb Aswin Murugan <aswin.murugan at oss.qualcomm.com>:
>> The current PSCI-based EFI runtime reset implementation is always enabled
>> when CONFIG_PSCI_RESET is set, but it does not support the extra arguments
>> required for specialized reset modes. As a result, reboot requests such as
>> bootloader mode or EDL mode are ignored and fall back to a normal reboot.
> Are the "specialized" reset modes defined in the PSCI specification or at least compliant to it? Where can I find the description of these reset modes.
The specialized reset modes are not defined as standard PSCI reset 
modes, but they are supported through the *PSCI SYSTEM_RESET2* call [1], 
which is explicitly designed for vendor‑specific reset types. 
SYSTEM_RESET2 takes two parameters reset_type and cookie. Together, 
these parameters enable platform firmware to handle specialized reset 
behaviors modes such as bootloader, recovery, EDL, and others that are 
defined by the SoC vendor.
> If you don't want to use U-Boot's PSCI implementation, why don't you simply disable the PSCI driver?
We still rely on the PSCI‑based reset flow in U‑Boot for normal 
functionality, so disabling the PSCI driver entirely would not be 
suitable for us. Our intention is only to avoid invoking the PSCI reset 
path specifically during EFI runtime reboot requests, since those are 
handled differently. Outside of the EFI runtime reboot case, U‑Boot 
should continue to use its PSCI implementation as usual. [1] 
https://developer.arm.com/documentation/den0022/fb/?lang=en Thanks, Aswin