On Mon, 2004-10-18 at 03:54, Pavel Machek wrote: > Hi! > > > With the correct list address this time... > > > > BTW, When do we plan the next irc meeting ? > > I guess we should do more patches and less meetings :-). That isn't the point. The patches are easily done, but for once, I want to make sure we all agree on the semantics before coding anything. I'm definitely not a fan of meetings, despite beeing at IBM, but I'm tired of seeing broken band aid patches on top of eachother with infinite debates following each time. > Yes. In swsusp, no-modules case, hardware is always > initialized. [Because kernel did almost normal boot, and that > initializes devices, right?] Ugh... devices are usually initialized by the firmware on boot... > In swsusp, modules case, hardware is not initializes... and that is > not nice thing to do to a driver I realize. How so ? They are in the state they were at boot. A module can deal with them in that state when it's loaded. It has to do the same when unfrozen. > That should be rather easy to add. > > Note: If we say that this is "real resume after suspend", it is > possible that hardware still was initialized (swsusp, no-modules case, > see above). I'm not sure what you exactly mean by "initialized" here, but the problem is the same anyway. > I'd prefer drivers not to look inside struct for now. All but 2 should > be handled by "system_to_pci_level()"... and that can return scalar > just fine. What would it return "freeze" ? D0 ? -1 ? Ben.
