On Wednesday 20 June 2007, Rafael J. Wysocki wrote: > On Wednesday, 20 June 2007 08:18, Shaohua Li wrote: > > On Tue, 2007-06-19 at 13:52 +0200, Rafael J. Wysocki wrote: > > > On Tuesday, 19 June 2007 04:33, Shaohua Li wrote: > > > > Based on David's patch > > > > http://marc.info/?l=linux-acpi&m=117873972806360&w=2 > > > > I slightly changed it. > > > > > > > > Add a helper routine, which gets the sleep state of a ACPI device. > > > > > > Is it going to work with the recent code ordering changes? I mean, > > > acpi_pm_prepare() is now called after device_suspend() (and analogously for > > > the hibernation), so the target ACPI state is not known when the drivers' > > > .suspend() routines are being called. > > > Not. Could pm_message_t have a member indicating the suspend state? > > Well, I thought about that, but I did't know what people on linux-pm would > think about that. Let's get rid of pm_message_t entirely. Didn't we already discuss how the main reasons for it will vanish if drivers get new PM methods? > Alternatively, we could introduce a pm_target() global PM operation that will > set the target sleep state for the entire system. I hope you mean "get the target state"!! If drivers actually need a handle on that state, that'd be a fair approach; make it an opaque type though, platform-specific. But actually I don't see much point to having such a struct. What matters is the attributes of the target state (what resources will be present, especially), and that rarely needs to be indicated by any kind of cookie. Consider the "current" task ... it's implicit, always present (except in IRQ contexts), and hardly ever accessed despite being more fundamental than "target PM state". - 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
