Am Freitag, 7. September 2012, 10:04:24 schrieb Alex Courbot:

quoted

For your power_seq_run function you write that it simply returns an error
code on failure and looking through it I also just found the error return
statement. This would leave a device half turned on.

So I'm wondering, if it shouldn't turn off all the things it turned on
until the step that produced the error. All your possible step types
(execpt the delay) are booleans, so it should be possible to simply
negate them when backtracking through the previous steps.

Indeed, I think you raised an important point. Right now all step types are
invertible, but we cannot rely on that statement to be true forever. For
instance, one short-term improvement will be to allow finer regulator
control, like voltage setting. In this case, how can we go back to the
initial state without recording it?

If e.g. the power on sequence fails at step N (of M steps for that
sequence), one could try playing the corresponding power off sequence
(either completely of from step M - N), but then again we cannot rely on
sequences to be perfectly symetrical. Maybe this is more something for the
calling driver to check for and control?

Am Freitag, 7. September 2012, 10:15:03 schrieb Mark Brown:

On Fri, Sep 07, 2012 at 05:04:24PM +0900, Alex Courbot wrote:

quoted

If e.g. the power on sequence fails at step N (of M steps for that
sequence), one could try playing the corresponding power off sequence
(either completely of from step M - N), but then again we cannot rely on
sequences to be perfectly symetrical. Maybe this is more something for
the calling driver to check for and control?

That had been my thought too - depending on what the sequence is for it
may be that the corrective action is something very different to
reversing the sequence, for example a device reset may be required.

If I understood the description correctly, the power sequence should be 
transparent to the driver, as it implements board specific actions and 
shouldn't bother the driver with it to much. Therefore my thoughts went along 
the lines how gpio_request_array handles this, always producing a sane state 
at the end.

Recording the previous state, could be done by making a copy of the current 
sequence, and just noting the previous values (including voltages etc) in the 
respective entries. And in the error case running this new sequence from the 
error point instead to power down again.


As both Alex and Mark wrote, reversing the sequence might be the action of 
choice only for some devices, but others might need to run a completely 
different powerdown sequence and still others would need special handling.

Would it be possible to encode this in the sequence definition, something like
	on-error = "reverse"

	on-error = "sequence"
	error-seq = <&other_sequence>

	on-error = "driver"
with better names and types of course.

This would keep the power sequence transparent to most drivers and only the 
real esoteric ones would need to do their special handling on their own.


Heiko