Am Donnerstag 27 September 2007 schrieb Rafael J. Wysocki: > On Thursday, 27 September 2007 21:59, Oliver Neukum wrote: > > Am Donnerstag 27 September 2007 schrieb Rafael J. Wysocki: > > > On Thursday, 27 September 2007 21:37, Oliver Neukum wrote: > > > > Am Donnerstag 27 September 2007 schrieb Rafael J. Wysocki: > > > > > > But there's a problem, in that the resume methods don't take a message > > > > > > parameter. So they wouldn't know whether they were doing a runtime > > > > > > resume or a system resume. > > > > > > > > > > This is a general problem with the .resume() routines. > > > > > > > > > > If you want to use one for runtime resume, the driver needs to preserve > > > > > information allowing it to figure out what kind of resume is going to happen. > > > > > > > > How? Suppose you > > > > > > > > 1) runtime suspend > > > > 2) whole system suspend > > > > 3) whole system resume > > > > > > > > What kind of resume do you do? > > > > > > System resume, I'd guess. > > > > How do you know unless resume() tells you to do so? > > > > > Anyway, if we are going to stop using the freezer during suspend, the locking > > > requirements will probably have to unified between the runtime and system > > > suspend. > > > > Even so, eg. for storage devices you should unquiesce them in case of runtime > > suspend, which makes no sense otherwise. > > OK > > What exactly would you like to do? Put the stuff into struct device and move the autosuspend code into driver core. Regards Oliver _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
