From: Ard Biesheuvel <ardb@kernel.org>
To: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Peter Collingbourne <pcc@google.com>,
Guenter Roeck <linux@roeck-us.net>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Alexander Sverdlin <alexander.sverdlin@nokia.com>,
Matija Glavinic-Pecotic <matija.glavinic-pecotic.ext@nokia.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] arm64: move efi_reboot to restart handler
Date: Wed, 2 Feb 2022 15:01:37 +0100 [thread overview]
Message-ID: <CAMj1kXEP+0ErwmLebw5mswz+jD+Yd_U_U7jmhPR2bKgnMRTWNw@mail.gmail.com> (raw)
In-Reply-To: <Yfp7wZXLKPIYBxmp@localhost.localdomain>
On Wed, 2 Feb 2022 at 13:41, Krzysztof Adamski
<krzysztof.adamski@nokia.com> wrote:
>
> Dnia Tue, Feb 01, 2022 at 01:58:29PM +0000, Mark Rutland napisał(a):
> >> If we use the restart handlers only to reset the system, this is indeed
> >> true. But technically, restart handlers support the scenario where the
> >> handler does some action that does not do reset of the whole system and
> >> passes the control further down the chain, eventually reaching a handler
> >> that will reset the whole system.
> >> This can be done on non-uefi systems without problems but it doesn't
> >> work on UEFI bases arm64 systems and this is a problem for us.
> >>
> >> In other words, I would like to be able to run a restart handler on EFI
> >> based ARM64 systems, just like I can on other systems, just for its
> >> "side effects", not to do the actual reboot. Current code disables this
> >> possibility on an ARM64 EFI system.
> >
> >It sounds like two things are being conflated here:
> >
> >1) A *notification* that a restart will subsequently occur.
> >2) A *request* to initiate a restart.
> >
> >IIUC (1) is supposed to be handled by the existing reboot notifier mechanism
> >(see the reboot_notifier_list) which *is* invoked prior to the EFI reboot
> >today.
> >
> >IMO, using restart handlers as notifiers is an abuse of the interface, and
> >that's the fundamental problem.
> >
> >What am I missing?
>
> You are completly right. It is possible that I would like to be able to
> *abuse* the restart handlers as notifier. You are right that we have a
> reboot_notifier but it is not good enough for my usecase - it is only
> called, well, on reboot. It is not called in case of emergency_restart()
> so in case of a panic, this won't happen. It also is called much earlier
> than restart handlers which also makes a difference in some cases. So I
> see no other choice than to abuse the restart_handler mechanism for that.
>
Why would such a platform implement ResetSystem() in the first place
if it cannot be used?
So the right solution here is for the firmware to publish a
EFI_RT_PROPERTIES_TABLE that describes ResetSystem() as unsupported,
and Linux will happily disregard it and try something else.
Btw please cc linux-efi@vger.kernel.org and myself on future EFI
issues. I found this thread by accident.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-02-02 14:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 13:50 [PATCH v2] arm64: move efi_reboot to restart handler Krzysztof Adamski
2022-01-28 14:21 ` Alexander Sverdlin
2022-01-28 15:14 ` Guenter Roeck
2022-01-28 16:01 ` Mark Rutland
2022-01-28 22:05 ` Krzysztof Adamski
2022-02-01 13:58 ` Mark Rutland
2022-02-02 12:40 ` Krzysztof Adamski
2022-02-02 14:01 ` Ard Biesheuvel [this message]
2022-02-02 16:47 ` Krzysztof Adamski
2022-02-02 17:52 ` Krzysztof Adamski
2022-02-15 8:44 ` Alexander Sverdlin
2022-02-15 8:44 ` Alexander Sverdlin
2022-02-15 14:30 ` Guenter Roeck
2022-02-15 15:01 ` Krzysztof Adamski
2022-02-15 16:57 ` Guenter Roeck
2022-02-15 17:03 ` Ard Biesheuvel
2022-02-16 9:11 ` Krzysztof Adamski
2022-01-28 19:29 ` Wolfram Sang
2022-01-28 22:32 ` Krzysztof Adamski
2022-01-29 6:38 ` Wolfram Sang
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=CAMj1kXEP+0ErwmLebw5mswz+jD+Yd_U_U7jmhPR2bKgnMRTWNw@mail.gmail.com \
--to=ardb@kernel.org \
--cc=alexander.sverdlin@nokia.com \
--cc=catalin.marinas@arm.com \
--cc=krzysztof.adamski@nokia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mark.rutland@arm.com \
--cc=matija.glavinic-pecotic.ext@nokia.com \
--cc=pcc@google.com \
--cc=will@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/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;
as well as URLs for NNTP newsgroup(s).