lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 13 Apr 2016 06:10:40 -0700 From: Guenter Roeck <linux@...ck-us.net> To: Mark Rutland <mark.rutland@....com> Cc: Russell King <linux@....linux.org.uk>, Catalin Marinas <catalin.marinas@....com>, Wolfram Sang <wsa@...-dreams.de>, Geert Uytterhoeven <geert@...ux-m68k.org>, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, Lorenzo Pieralisi <lorenzo.pieralisi@....com> Subject: Re: [PATCH 3/6] ARM: PSCI: Register with kernel restart handler On 04/13/2016 04:05 AM, Mark Rutland wrote: > On Fri, Apr 08, 2016 at 05:53:56AM -0700, Guenter Roeck wrote: >> Register with kernel restart handler instead of setting arm_pm_restart >> directly. This enables support for replacing the PSCI restart handler >> with a different handler if necessary for a specific board. >> >> Select a priority of 129 to indicate a higher than default priority, but >> keep it as low as possible since PSCI reset is known to fail on some >> boards. > > For reference, which boards? > Salvator-X, reported by Geert Uytterhoeven. Wolfram Sang also reported that it is broken on a board he is using, but I don't recall if it is the same board. > It's unfortunate that that a PSCI 0.2+ implementation would be lacking a > working SYSTEM_RESET implementation, and it's certainly a mistake to > discourage. > >> Signed-off-by: Guenter Roeck <linux@...ck-us.net> >> --- >> It might make sense to introduce a restart-priority property for devicetree >> based configurations, but I am not sure if this would be acceptable. > >>>From the DT side, I'm not keen on properties for priorities. They're > incredibly fragile and don't really encode a HW property. > Depends. It is a convenient means to say "primary restart method" or "may be broken". > A better option would be to have a property to describe how the PSCI > implementation is broken (e.g. broken-system-reset), and not register > the handler at all in that case. > ... just like this. I'll look into it. Thanks, Guenter > Thanks, > Mark. > >> drivers/firmware/psci.c | 11 +++++++++-- >> 1 file changed, 9 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c >> index 11bfee8b79a9..99fab3ac3fd5 100644 >> --- a/drivers/firmware/psci.c >> +++ b/drivers/firmware/psci.c >> @@ -231,11 +231,18 @@ static int get_set_conduit_method(struct device_node *np) >> return 0; >> } >> >> -static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd) >> +static int psci_sys_reset(struct notifier_block *np, unsigned long action, >> + void *data) >> { >> invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0); >> + return NOTIFY_DONE; >> } >> >> +static struct notifier_block psci_sys_reset_nb = { >> + .notifier_call = psci_sys_reset, >> + .priority = 129, >> +}; >> + >> static void psci_sys_poweroff(void) >> { >> invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0); >> @@ -461,7 +468,7 @@ static void __init psci_0_2_set_functions(void) >> >> psci_ops.migrate_info_type = psci_migrate_info_type; >> >> - arm_pm_restart = psci_sys_reset; >> + register_restart_handler(&psci_sys_reset_nb); >> >> pm_power_off = psci_sys_poweroff; >> } >> -- >> 2.5.0 >> >
Powered by blists - more mailing lists