> > IMO it can be done in two different ways:
> > 1) via a .suspend() argument
> > 2) via a global variable that the drivers can read.
For sufficiently small values of "two" that is.
Other solutions that have been described on the PM list include
3) Providing accessors to the information actually needed
in drivers ... e.g. say whether this clock or power domain
will be available in that target state.
4) Act more like "current" ... there's a function returning
whatever "state" struct is settled on. (But ideally
without the pseudo-global.)
I'm amused that nobody really reacted to the technical comments in
my previous posts on this thread. That's unfortunate, since from
where I sit it feels to me like everyone else is a johnny-come-lately
on this issue, and is now grasping at the quickest and dirtiest ways
to work around the issue instead of coming to grasp with the various
underlying issues.
IMO #3 is strongly preferable.
> Just do 1). Global variables are ugly, and we already have space in
> pm_message_t.
There is no space in the ugly pm_message_t structure. Adding to
that would involve creating a **larger** structure and passing it
around on the stack all the time.
Pavel, I know that for some perverse reason you actually like
that structure, and the notion of passing it around *BY VALUE*
instead of by reference. But that approach has never been
universally acclaimed, and has in fact always had opposition;
the only way you got it merged in the first place was to send
in mountains of patches and ignore the negative feedback.
But I really thought the discussion on new PM methods, back a
couple months now, was going to finally get rid of that.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
