Re: bus.suspend_prepare()

Pavel Machek
2006-07-26T10:11:29Z

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