On 11/15/24 05:35, Lorenzo Pieralisi wrote:
On Wed, Oct 23, 2024 at 09:30:21AM -0700, Elliot Berman wrote:
On Fri, Oct 18, 2024 at 10:42:46PM -0700, Stephen Boyd wrote:
Quoting Elliot Berman (2024-10-18 12:39:48)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 2328ca58bba6..60bc285622ce 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -29,6 +29,8 @@
#include <asm/smp_plat.h>
#include <asm/suspend.h>
+#define REBOOT_PREFIX "mode-"
Maybe move this near the function that uses it.
+
/*
* While a 64-bit OS can make calls with SMC32 calling conventions, for some
* calls it is necessary to use SMC64 to pass or return 64-bit values.
@@ -305,9 +315,29 @@ static int get_set_conduit_method(const struct device_node *np)
return 0;
}
+static void psci_vendor_sys_reset2(unsigned long action, void *data)
+{
+ const char *cmd = data;
+ unsigned long ret;
+ size_t i;
+
+ for (i = 0; i < num_psci_reset_params; i++) {
+ if (!strcmp(psci_reset_params[i].mode, cmd)) {
+ ret = invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2),
+ psci_reset_params[i].reset_type,
+ psci_reset_params[i].cookie, 0);
+ pr_err("failed to perform reset \"%s\": %ld\n",
+ cmd, (long)ret);
Do this intentionally return? Should it be some other function that's
__noreturn instead and a while (1) if the firmware returns back to the
kernel?
Yes, I think it's best to make sure we fall back to the architectural
reset (whether it's the SYSTEM_RESET or architectural SYSTEM_RESET2)
since device would reboot then.
Well, that's one of the doubts I have about enabling this code. From
userspace we are requesting a reboot (I don't even think that user
space knows which reboot modes are actually implemented (?)) and we may
end up issuing one with completely different semantics ?
Are these "reset types" exported to user space ?
AFAICT, they are not, but arguably you already need custom user space
which is capable of doing:
syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
LINUX_REBOOT_CMD_RESTART2, reboot_cmd);
in order to utilize the custom reboot mode. I could imagine that with a
discovery mechanism, a wrapper could be written to check that the
specified command is actually supported before issuing the system call,
or even have the system call do that under the hood.
I don't personally feel like this is very important in the sense that as
long as a fallback exists for an unsupported reboot command specified,
the system does reboot.
--
Florian
