Re: swsusp issues

Pavel Machek
2005-06-04T06:13:40Z

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

Hi!

> > swsusp/powerdown and swsusp/reboot cases should really only require
> > save_processor_state and friends filled by architecture... And at
> > least i386 and x86-64 (and possibly ia64) will have basically same
> > code for all the stuff except save_processor_state and friends...
>
> Eugh.... No. Maybe you can get away without the arch callbackcs on x86,
> but there are a bunch of things that need to be properly saved/restored
> even for basic swsusp that don't fit in the driver model. (Besides, you
> don't even call device_power_down, so the stuffs that are sysdev's
> aren't dealt with properly neither).

Well, we might want to fix not calling device_power_down...

> > > We could provide an "example" default implementation that does only
> > > swsusp that an arch can "drop in" if you want, but archs have to
> > > implement the various "inline" callbacks anyway (save_processor_state &
> > > friends).
> >
> > ...aha, so you know that much code can be shared :-). Yes, "example"
> > implementation should work okay. Use "example" implementation, add
> > custom save_processor_state, and you should have working
> > swsusp/powerdown...
>
> I don't care a bit about sharing code in that area. "How much" amounts
> to 3 function calls, so honestly, that is not an issue. I agree with
> Patrick here, the toplevel enter_state() function should probably just
> be arch code.

Well, if we are talking about single function (enter_state) being
moved to arch code... that should be okay. It is really simple
function.

Pavel