Hi! > > > > 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". > > The issue at hand is that some device drivers may need to know what the > target sleep state of the system will be when their .suspend() routines are > being executed. Currently, there's no means of passing that information to the > drivers and my question is how to do this. > > IMO it can be done in two different ways: > 1) via a .suspend() argument > 2) via a global variable that the drivers can read. Just do 1). Global variables are ugly, and we already have space in pm_message_t. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
