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

Aswin Murugan aswin.murugan at oss.qualcomm.com
Tue Feb 17 20:06:51 CET 2026


On 2/13/2026 4:55 PM, Ilias Apalodimas wrote:
> Hi Ashwin
>
> On Fri, 13 Feb 2026 at 13:06, Aswin Murugan
> <aswin.murugan at oss.qualcomm.com> wrote:
>> 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.
>>
>> Add CONFIG_EFI_PSCI_RESET_RUNTIME to give platforms explicit control over
> Is there anything missing and you can't use EFI_HAVE_RUNTIME_RESET?
Thanks for the feedback, Ilias
This is a kernel‑level limitation based on drivers/firmware/efi/reboot.c 
[1] implementation in Linux. The efi_reboot function intentionally 
ignores the reboot data string and always passes NULL to ResetSystem. As 
a result, special reboot modes like "bootloader" or "recovery" aren’t 
forwarded through EFI_HAVE_RUNTIME_RESET.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/reboot.c?h=v6.13#n46

>
>> the PSCI-specific EFI runtime reset path. This allows a platform to disable
>> U-Boot's PSCI reset handler when needed so that the kernel can perform the
>> reset with the correct arguments for special reboot modes.
>>
>> The option defaults to enabled to maintain backward compatibility with the
>> existing behavior.
>>
>> Signed-off-by: Aswin Murugan <aswin.murugan at oss.qualcomm.com>
>> ---
>> Changes in v3:
>> - Commit message has been updated, no change in code
>>
>> Changes in v2:
>> - As per review comments made default y for EFI_PSCI_RESET_RUNTIME config
>> ---
>>   drivers/firmware/psci.c | 4 ++--
>>   lib/efi_loader/Kconfig  | 8 ++++++++
>>   2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
>> index 2e3223e1c32..009c6153d0c 100644
>> --- a/drivers/firmware/psci.c
>> +++ b/drivers/firmware/psci.c
>> @@ -244,7 +244,7 @@ static void __maybe_unused do_psci_probe(void)
>>          uclass_get_device_by_name(UCLASS_FIRMWARE, DRIVER_NAME, &dev);
>>   }
>>
>> -#if IS_ENABLED(CONFIG_EFI_LOADER) && IS_ENABLED(CONFIG_PSCI_RESET)
>> +#if IS_ENABLED(CONFIG_EFI_PSCI_RESET_RUNTIME)
>>   efi_status_t efi_reset_system_init(void)
>>   {
>>          do_psci_probe();
>> @@ -266,7 +266,7 @@ void __efi_runtime EFIAPI efi_reset_system(enum efi_reset_type reset_type,
>>          while (1)
>>                  ;
>>   }
>> -#endif /* IS_ENABLED(CONFIG_EFI_LOADER) && IS_ENABLED(CONFIG_PSCI_RESET) */
>> +#endif /* IS_ENABLED(CONFIG_EFI_PSCI_RESET_RUNTIME) */
> You also have to adjust the RT config table in
> lib/efi_loader/efi_runtime.c, but I really think we should reuse
> EFI_HAVE_RUNTIME_RESET
EFI_HAVE_RUNTIME_RESET is enabled by default & depends on PSCI_RESET config,
So even if i disabled EFI_HAVE_RUNTIME_RESET  on defconfig it was 
overridden, since PSCI_RESET is enabled it was auto enabling it, hence 
introduced a new config CONFIG_EFI_PSCI_RESET_RUNTIME to control psci 
based EFI runtime reset control.

Thanks,
Aswin
>
> Cheers
> /Ilias
>>   #ifdef CONFIG_PSCI_RESET
>>   void reset_misc(void)
>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
>> index 13e44be1d06..3882de273bb 100644
>> --- a/lib/efi_loader/Kconfig
>> +++ b/lib/efi_loader/Kconfig
>> @@ -106,6 +106,14 @@ config EFI_HAVE_RUNTIME_RESET
>>          depends on ARCH_BCM283X || FSL_LAYERSCAPE || PSCI_RESET || \
>>                     SANDBOX || SYSRESET_SBI || SYSRESET_X86
>>
>> +config EFI_PSCI_RESET_RUNTIME
>> +       bool "EFI Runtime PSCI Reset Support"
>> +       default y if EFI_LOADER && PSCI_RESET
>> +       depends on ARM_PSCI_FW
>> +       help
>> +         Enable PSCI-based reset implementation for EFI runtime services.
>> +         This allows the OS to reset the system through EFI runtime calls.
>> +
>>   endmenu
>>
>>   menu "UEFI Variables"
>> --
>> 2.34.1
>>


More information about the U-Boot mailing list