Hi! > > > Hmm ... I just noticed that the swsusp code path (PM_SUSPEND_DISK) > > > is ignoring the new suspend_prepare() mechanism. > > > > > > That doesn't seem like a good thing ... Linus, is there a reason you > > > did it that way? > > > > Just because I found that neither interesting nor testable in my > > environment. > > Yeah, testable is an issue. Maybe a better fix would be to remove > the bus.suspend_prepare() operation for now. Someone with real use > cases could easily add a complete working package that includes that > mechanism plus some testable code that needs it. I like this solution. > > > Why is there no sibling resume_complete()? ISTR > > > that Ben was the advocate of a suspend_prepare(), but the use cases > > > for this call are unclear to me ... > > > > Havign a resume_complete() would be nice for a number of things, like > > reloading firmware etc (which usually requires not just the device being > > back and fully working, but more importantly, requires user space to be > > alive again). > > I thought the idea there was that suspend_prepare() would preload that > firmware into memory, so it could just be written in bus.resume() ... not > that anyone worked through that completely, including the obvious issues > like firmware images which wouldn't fit in available memory. Are there actually cards with _that_ big firmware files? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
