[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YfThAF9U1DJx0Hja@shikoro>
Date: Sat, 29 Jan 2022 07:38:56 +0100
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Krzysztof Adamski <krzysztof.adamski@...ia.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Peter Collingbourne <pcc@...gle.com>,
Guenter Roeck <linux@...ck-us.net>,
Alexander Sverdlin <alexander.sverdlin@...ia.com>,
Matija Glavinic-Pecotic <matija.glavinic-pecotic.ext@...ia.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] arm64: move efi_reboot to restart handler
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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists