Skip to content

RFC: Common machine reset handling

Domenico Andreoli linux-arch linux-arm-kernel linux-mips 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest11 patches 9 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/11machine-reset: platform generic handlinginclude/linux/machine_reset.h kernel/Makefile kernel/machine_reset.c +2 more+218 -00 replies
2/11ARM: use the common machine reset handlingarch/arm/kernel/process.c kernel/power/Kconfig+9 -60 replies
3/11ARM64: use the common machine reset handlingarch/arm64/kernel/process.c kernel/power/Kconfig+6 -10 replies
4/11MIPS: use the common machine reset handlingarch/mips/kernel/reset.c kernel/power/Kconfig+8 -12 replies
5/11ARM: vexpress: consolidate machine reset funcdrivers/power/reset/vexpress-poweroff.c+13 -180 replies
6/11ARM: vexpress: use the common machine reset handlingdrivers/power/reset/Kconfig drivers/power/reset/vexpress-poweroff.c+39 -160 replies
7/11ARM: bcm2835: use the common machine reset handlingarch/arm/mach-bcm2835/Kconfig arch/arm/mach-bcm2835/bcm2835.c+19 -120 replies
8/11ARM: u300: use the common machine reset handlingarch/arm/mach-u300/regulator.c drivers/regulator/Kconfig+15 -92 replies
9/11ARM: tps65910: use the common machine reset handlingdrivers/mfd/Kconfig drivers/mfd/tps65910.c+9 -80 replies
10/11max8907: use the common machine reset handlingdrivers/mfd/Kconfig drivers/mfd/max8907.c+9 -50 replies
11/11ARM: sp805: use the common machine reset handlingdrivers/watchdog/Kconfig drivers/watchdog/sp805_wdt.c+57 -00 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

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