Re: [patch] properly stop devices before poweroff

[Pavel Machek]

Hi!

> > Thats okay, nobody really knows yet. I believe that SUSPEND and HALT
> > are very similar, and flags best way to separate them. I believe that
> > FREEZE and REBOOT are very similar, too, and again would use flags to
> > tell between them.
> 
> I'm not so sure about SUSPEND and HALT being similar.  It might be much faster
> to have a routine that ignores slow state changes and goes directly for
> stopping device activity.  Still, I'm not entirely decided.  On ACPI systems
> SUSPEND should generally work, as it's the intended behavior for S4 which is
> basically like S5 in many cases.  However, having a specific HALT message
> might allow driver developers to clarify this ambiguity on a per-device basis.

Umm, you are right, HALT is somewhere between FREEZE and SUSPEND.

> > First I want type checking for pm_message_t. That's 2.6.12-early
> > material. Then, when it is *really clear* that flags are needed, I'll
> > add them. "really needed" as in "we have a driver where it matters".
> 
> I think it's already clear that we need to pass the specific device state.
> Also the intended global system state transition might be helpful.

Global system state transition should be clear from flags. Specific
device state is needed for selective suspend, elsewhere I'd go for
helper function.

> However, at the moment I'm considering using a slightly different API for
> these sort of things.  It would include "->prepare_state_change()" and
> "->complete_state_change()"  I'll have further justification for these
> changes soon, however, I would like to leave the current stuff around also
> as it would still be useful for shutdown and reboot, non-PM suspend issues,
> and backward compatibilty.

I'd prefer not to have more callbacks (unless absolutely
neccessary). We used to have them, and people got it wrong....

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/