On Wed, 21 Jun 2006, Alan Stern wrote: > > Isn't it true the only a small minority of drivers need to do anything > special during the save_state() callback? In most cases all the necessary > state is already stored in the driver. So instead of making this a > callback in struct device, how about creating a pre_suspend notifier chain > for drivers to register on? No. That would be horrible. Yet another notifier to register on, rather than just adding a function pointer to the structure that you need to initialize _anyway_. > And ditto for freeze()/unfreeze() -- almost no drivers need to handle > them. So leave the function pointers as NULL. Problem solved. > Hmm. Be careful here. The power level really isn't part of the "state" > that gets saved by save_state(), is it? Why wouldn't it be? That said, I think most drivers can just assume that their normal device state is always D0 and they'll work, so in that sense they don't need to "save" it. > So drivers will have to be very careful, because when restore_state() > starts the device could be in any of several possible states. That's nothing new. It's no different from what we have now, in fact (for exactly the same reasons). It's also no different from what we have now at driver initialization state. > There's an unforunate asymmetry in the design. I don't know why people harp on symmetry so much. The fact is, saving and restoring driver state is fundamentally assymmetric. In one case, the device works in a known state before and after. In the other, it doesn't. Big deal. But as it is, I actually would suggest just keeping the current "resume()" naming, there's no huge reason to change it (and, in fact, semantics won't even change). It's the _suspend_ part I want split up. Linus
