From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Cc: 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: Sat, 29 Jan 2022 07:38:56 +0100 [thread overview]
Message-ID: <YfThAF9U1DJx0Hja@shikoro> (raw)
In-Reply-To: <YfRu86YoiFpVsqyn@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 1402 bytes --]
Hi Krzysztof,
> 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,
For your patchset, this seems good enough for me because it is decoupled
from PSCI now. I still think a set of defines should be collected in
linux/reboot.h so they can be used in reboot handlers. This is a
different patch series, though.
> 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.
I agree with the upside having more value than the downside.
Happy hacking,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Cc: 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: Sat, 29 Jan 2022 07:38:56 +0100 [thread overview]
Message-ID: <YfThAF9U1DJx0Hja@shikoro> (raw)
In-Reply-To: <YfRu86YoiFpVsqyn@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]
Hi Krzysztof,
> 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,
For your patchset, this seems good enough for me because it is decoupled
from PSCI now. I still think a set of defines should be collected in
linux/reboot.h so they can be used in reboot handlers. This is a
different patch series, though.
> 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.
I agree with the upside having more value than the downside.
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-01-29 6:41 UTC|newest]
Thread overview: 40+ 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 13:50 ` Krzysztof Adamski
2022-01-28 14:21 ` Alexander Sverdlin
2022-01-28 14:21 ` Alexander Sverdlin
2022-01-28 15:14 ` Guenter Roeck
2022-01-28 15:14 ` Guenter Roeck
2022-01-28 16:01 ` Mark Rutland
2022-01-28 16:01 ` Mark Rutland
2022-01-28 22:05 ` Krzysztof Adamski
2022-01-28 22:05 ` Krzysztof Adamski
2022-02-01 13:58 ` Mark Rutland
2022-02-01 13:58 ` Mark Rutland
2022-02-02 12:40 ` Krzysztof Adamski
2022-02-02 12:40 ` Krzysztof Adamski
2022-02-02 14:01 ` Ard Biesheuvel
2022-02-02 14:01 ` Ard Biesheuvel
2022-02-02 16:47 ` Krzysztof Adamski
2022-02-02 16:47 ` Krzysztof Adamski
2022-02-02 17:52 ` 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 8:44 ` Alexander Sverdlin
2022-02-15 8:44 ` Alexander Sverdlin
2022-02-15 14:30 ` Guenter Roeck
2022-02-15 14:30 ` Guenter Roeck
2022-02-15 15:01 ` Krzysztof Adamski
2022-02-15 15:01 ` Krzysztof Adamski
2022-02-15 16:57 ` Guenter Roeck
2022-02-15 16:57 ` Guenter Roeck
2022-02-15 17:03 ` Ard Biesheuvel
2022-02-15 17:03 ` Ard Biesheuvel
2022-02-16 9:11 ` Krzysztof Adamski
2022-02-16 9:11 ` Krzysztof Adamski
2022-01-28 19:29 ` Wolfram Sang
2022-01-28 19:29 ` Wolfram Sang
2022-01-28 22:32 ` Krzysztof Adamski
2022-01-28 22:32 ` Krzysztof Adamski
2022-01-29 6:38 ` Wolfram Sang [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=YfThAF9U1DJx0Hja@shikoro \
--to=wsa+renesas@sang-engineering.com \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.