> 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). > I'm not sure what you want to do with "take the control of main.c". If > you do device calls in different order, or diverge in something > visible to drivers, you'll create maintanance nightmare. Is it really > impossible to handle ppc without adding more callbacks? I'm pretty sure it's impossible to handle anything correctly. Your x86 implementation may "happen" to work but I'm really not confident about it. > [Modulo apm emulation, I see why you need callbacks there, but that > should not be there or it should be in generic code, anyways]. There are other things that need proper massaging. > > 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. BEn.
