Dnia Tue, Feb 15, 2022 at 06:03:30PM +0100, Ard Biesheuvel napisał(a):
> But if we want to prevent registering some custom code to be run before > efi_reboot(), that new API would have to be rejected as well, for the
> same reason. So what is the point?
>
Ah, yes, you are right. The emmc example does reset the emmc, after all,
which one could use as argument that it "violates" the EFI mandate.
Sorry, I guess you'll be stuck with out-of-tree code (and, realistically,
so is everyone using emmc in an arm64 based system with an EFI restart
handler which does not implement emmc reset). Actually, turns out that
the emmc restart handling code is not reliable anyway, since for example
x86 doesn't use/support the restart handler call chain, and neither
do several other architectures.
Rich firmware like EFI and ACPI implies that the firmware knows how to
manage the hardware.
In an ideal world, probably yes. When I move there, I will probably have
less concerns :)
Other options for you might be to disable EFI restart handling in your
system (assuming that is possible), or to implement the necessary code
as part of the EFI restart handler, ie outside Linux, again if that is
possible.
Either implement EFI reset properly, or not at all. Adding code to the
OS that forces it to reason about whether or not EFI reset can be
called safely simply means that the EFI implementation is broken and
should probably be avoided entirely.
That is black-and-white thinking. There are shades of gray, too :)
Imagine this sitation - you have a SoC and the vendor delivers this SoC
together with support and code for that SoC. You use it to build some
platform around that SoC but that platform is much more complicated than
the basic one. It is custom and specific to your needs. The vendor
provided firmware, together with the EFI implementation can handle
reseting the SoC without problems but you also have some additional
parts in your platform you would like to handle. Why, in such a case, I
should not use the existing EFI implementation and just build on top of
that? Avoiding using it entirely does not seem reasonable to me. It
might also not be possible as you might not know all the details to
reimplement it.
On PC/Server world, that approach might be feasible - the vendor knows
the usecase for their product well enough to support all the cases. But
ARM64 is being often used for other, so called "embedded", usecases.
People working in "embedded" often have unique needs and I do understand
that mainline kernel cannot support all of them. But when supporting
them is easy and does not require some ugly hacks to be added, why not?
For years we were implementing ways to overcome limitations in
hardware and vendor software implementations. restart_handler mechanism
is quite pretty example of that, one which isn't really hacky, does not
introduce maintainabity problems if widely used. Why not support it on
ARM64 as well? Only because in ideal world it wouldn't be needed? :)
I understand it should not be needed in EFI world and there are
approaches that could be used instead of that one, but they all seem
like taking a sledgehammer to crack a nut.
Krzysztof
