On Monday, October 20, 2014 09:12:17 PM Guenter Roeck wrote:Isn't a notifier call chain nothing but a list of methods, with its priority
Various drivers implement architecture and/or device specific means to
remove power from the system. For the most part, those drivers set the
global variable pm_power_off to point to a function within the driver.
This mechanism has a number of drawbacks. Typically only one scheme
to remove power is supported (at least if pm_power_off is used).
At least in theory there can be multiple means remove power, some of
which may be less desirable. For example, some mechanisms may only
power off the CPU or the CPU card, while another may power off the
entire system. Others may really just execute a restart sequence
or drop into the ROM monitor. Using pm_power_off can also be racy
if the function pointer is set from a driver built as module, as the
driver may be in the process of being unloaded when pm_power_off is
called. If there are multiple poweroff handlers in the system, removing
a module with such a handler may inadvertently reset the pointer to
pm_power_off to NULL, leaving the system with no means to remove power.
Introduce a system poweroff handler call chain to solve the described
problems. This call chain is expected to be executed from the
architecture specific machine_power_off() function. Drivers providing
system poweroff functionality are expected to register with this call chain.
By using the priority field in the notifier block, callers can control
poweroff handler execution sequence and thus ensure that the poweroff
handler with the optimal capabilities to remove power for a given system
is called first.
Well, I must admit to having second thoughts regarding this particular
mechanism. Namely, notifiers don't seem to be the best way of expressing
what's needed from the design standpoint.
It looks like we need a list of power off methods and a way to select one
of them, so it seems that using a plist would be a natural choice here?