Hi! > > 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. Well, I guess we all agreed that passing struct to the drivers is one possible way to go. I guess I should find some time and code that patch. > > 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... That is not what I mean. In non-modular resume case, this happens: firmware boot kernel boot it initializes device XYZ because it is build in freeze it freezes device XYZ new kernel is atomically copied in new kernel unfreezes all devices ...including device XYZ but when kernel is modular: firmware boot kernel boot module for XYZ is not here, device is not initialized freeze ...and not frozen new kernel is atomically copied in new kernel unfreezes all devices ...and may get nasty surprise while resuming XYZ > > 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 ? It should return D3 (because we *know* no interrupts/DMAs are running in D3.). Then there should be separate call system_state_is_freeze() [probably with less ugly name :-)]. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
