From: Sumit Garg <sumit.garg@kernel.org>
To: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
u-boot@lists.denx.de, casey.connolly@linaro.org,
u-boot-qcom@groups.io, trini@konsulko.com, xypron.glpk@gmx.de,
sjg@chromium.org, michal.simek@amd.com,
gabriel.dalimonte@gmail.com, jan.kiszka@siemens.com,
paul.liu@linaro.org, j-humphreys@ti.com,
neil.armstrong@linaro.org, me@samcday.com,
marek.vasut+renesas@mailbox.org
Subject: Re: [PATCH v3 1/2] firmware: psci: Refactor EFI runtime PSCI reset handling
Date: Fri, 20 Feb 2026 14:52:36 +0530 [thread overview]
Message-ID: <aZgn3J-cwiWv05TC@sumit-xelite> (raw)
In-Reply-To: <174996d6-a4c2-4cf2-b25d-b59a9d7dd767@oss.qualcomm.com>
On Wed, Feb 18, 2026 at 12:36:51AM +0530, Aswin Murugan wrote:
>
> On 2/13/2026 4:55 PM, Ilias Apalodimas wrote:
> > Hi Ashwin
> >
> > On Fri, 13 Feb 2026 at 13:06, Aswin Murugan
> > <aswin.murugan@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
>
Yeah I know about that limitation for which the right EFI approach to
use is EFI_RESET_PLATFORM_SPECIFIC. I tried to implement it here [1] but
looks like needs a bit more testing from UEFI implementations. Would you
be able to give that approach a try?
Having EFI runtime reset service exposed to OS is certainely better than
OS trying to rely on platform/PSCI specific reset approaches.
[1] https://lore.kernel.org/all/20251114085058.2195900-1-sumit.garg@kernel.org/
-Sumit
next prev parent reply other threads:[~2026-02-20 9:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 11:05 [PATCH v3 0/2] qcom: EFI PSCI runtime reset handling and config update Aswin Murugan
2026-02-13 11:05 ` [PATCH v3 1/2] firmware: psci: Refactor EFI runtime PSCI reset handling Aswin Murugan
2026-02-13 11:25 ` Ilias Apalodimas
2026-02-17 19:06 ` Aswin Murugan
2026-02-18 7:36 ` Ilias Apalodimas
2026-02-20 9:22 ` Sumit Garg [this message]
2026-02-17 20:14 ` Heinrich Schuchardt
2026-02-18 6:29 ` Aswin Murugan
2026-02-13 11:05 ` [PATCH v3 2/2] qcom_defconfig: Disable CONFIG_EFI_PSCI_RESET_RUNTIME Aswin Murugan
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=aZgn3J-cwiWv05TC@sumit-xelite \
--to=sumit.garg@kernel.org \
--cc=aswin.murugan@oss.qualcomm.com \
--cc=casey.connolly@linaro.org \
--cc=gabriel.dalimonte@gmail.com \
--cc=ilias.apalodimas@linaro.org \
--cc=j-humphreys@ti.com \
--cc=jan.kiszka@siemens.com \
--cc=marek.vasut+renesas@mailbox.org \
--cc=me@samcday.com \
--cc=michal.simek@amd.com \
--cc=neil.armstrong@linaro.org \
--cc=paul.liu@linaro.org \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot-qcom@groups.io \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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