RFC: Common machine reset handling
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest11 patches 9 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/11 | machine-reset: platform generic handlinginclude/ kernel/ kernel/ +2 more | +218 | 0 replies | |
| 2/11 | ARM: use the common machine reset handlingarch/ kernel/ | +9 | 0 replies | |
| 3/11 | ARM64: use the common machine reset handlingarch/ kernel/ | +6 | 0 replies | |
| 4/11 | MIPS: use the common machine reset handlingarch/ kernel/ | +8 | 2 replies | |
| 5/11 | ARM: vexpress: consolidate machine reset funcdrivers/ | +13 | 0 replies | |
| 6/11 | ARM: vexpress: use the common machine reset handlingdrivers/ drivers/ | +39 | 0 replies | |
| 7/11 | ARM: bcm2835: use the common machine reset handlingarch/ arch/ | +19 | 0 replies | |
| 8/11 | ARM: u300: use the common machine reset handlingarch/ drivers/ | +15 | 2 replies | |
| 9/11 | ARM: tps65910: use the common machine reset handlingdrivers/ drivers/ | +9 | 0 replies | |
| 10/11 | max8907: use the common machine reset handlingdrivers/ drivers/ | +9 | 0 replies | |
| 11/11 | ARM: sp805: use the common machine reset handlingdrivers/ drivers/ | +57 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/11] RFC: Common machine reset handling
Hi,
I've been looking for a solution to my bcm4760 watchdog based restart
hook when I noticed that the kernel reboot/shutdown mechanism is having a few unaddressed issues.
Those I identified are:
1) context pointer often needed by the reset hook (currently local static data is used for this pourpose)
2) unclear ownership/policy in case of multiple reset hooks (currently almost nobody seems to care much)
I put together this patchset to explore some possible interface and improve the status, essentially moving away from the function-pointer-assignament kind of reset hook registration.
It is meant to be platform agnostic and sits in kernel/machine_reset.c. It opts in only when needed and when supported.
A common usage, as reset hook provider (drivers, boardfiles):
void restart_hook(void *dev, enum reboot_mode mode, const char *cmd)
{
/* reboot the board */
}void release_hook(void *dev)
{
/* release the hook */
}void init_restart_hook(void *dev)
{
struct reset_hook hook;
reset_hook_init(&hook);
hook.restart = restart_hook;
hook.release = release_hook; /* optional */
set_machine_reset(RESET_RESTART, &hook, dev);
}A common usage, as reset hook consumer (arch specific hooks, kernel):
void machine_restart(char *command)
{
if (_machine_restart)
_machine_restart(command);
else
default_restart(reboot_mode, command);
}void machine_halt(void)
{
if (_machine_halt)
_machine_halt();
else
default_halt();
}void machine_power_off(void)
{
if (pm_power_off)
pm_power_off();
else
default_power_off();
}I don't see these impressive diffstats but at least it's possible to free some static data along the way. Maybe there are some other desiderata that could be satisfied?
Comments are welcome.
Thanks,
Domenico