From: Krzysztof Adamski <krzysztof.adamski@nokia.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Peter Collingbourne <pcc@google.com>,
Guenter Roeck <linux@roeck-us.net>,
Alexander Sverdlin <alexander.sverdlin@nokia.com>,
Matija Glavinic-Pecotic <matija.glavinic-pecotic.ext@nokia.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] arm64: move efi_reboot to restart handler
Date: Fri, 28 Jan 2022 23:32:19 +0100 [thread overview]
Message-ID: <YfRu86YoiFpVsqyn@localhost.localdomain> (raw)
In-Reply-To: <YfREAiRMjQ9ci4LC@shikoro>
Dnia Fri, Jan 28, 2022 at 08:29:06PM +0100, Wolfram Sang napisał(a):
>
>> + /* We want this to take priority over PSCI which has priority of 129. */
>> + .priority = 130,
>
>Is it an idea to add a #define for the PSCI priority somewhere and use
>here the define + 1? Hardcoded priorities look a bit fragile to me.
>
You are right. Our priority policy for restart handlers isn't really
good and it is hard to choose right priority just about every time a
handler is added.
That being said, after reading Mark's argumentation, I now thing that
just being before PSCI is not enough. I think that a much higher
priority should be used as it is not normal situation that you would
like to run something before efi_reboot().
I would really still like to move the efi_reboot() to the
restart_handler even if you consider running some code before
efi_reboot() crazy. Since 255 is max priorty but using it basically
does not make sense (as this would let to the exact same situation we
have now).
I would use something like 250, or even 254, just to indicate that we
know that most certainly nothing should be run before efi_reboot(), but
still allow those silly people like me, to do what they want in their
system, without the need to run the custom kernel. I think we could even
add a proper comment, so it woudld become something like:
/**
* If you are running UEFI based system, you most certainly should let
* efi_reboot() do a reset for you. If you think you know better, we
* leave you a window of opportunity here by not using maximal priorty
* here.
*/
.priority = 250,
What is the downside of doing that? That we will run through atomic
notfier chain instead of calling efi_reboot directly? Sure this is
slightly more complicated but it works on all our platforms and is
battle proven and we don't worry about that there. And the upside is
that we give people possibility to use their beloved mechanism if they
really like to. Because flexibility is a good thing.
What do you think?
Krzysztof
_______________________________________________
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-01-28 22:34 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
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 [this message]
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=YfRu86YoiFpVsqyn@localhost.localdomain \
--to=krzysztof.adamski@nokia.com \
--cc=alexander.sverdlin@nokia.com \
--cc=catalin.marinas@arm.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).