Hi. On Wed, 2005-09-28 at 08:01, Pavel Machek wrote: > Hi! > > > > > > Later on, when the system wakes up and the image is restored, drivers are > > > > > asked to resume the devices. The problem is that now the drivers think > > > > > the devices are in FREEZE when in fact they are really in SUSPEND. The > > > > > difference is significant and it can cause errors in the resume procedure. > > > > > > > > No; devices are in FREEZE if their driver was in kernel, and in some kind > > > > of power up state when not. Drivers should just handle both. > > > > > > For USB, that "some kind of power up state" will in fact be SUSPEND. > > > > Excuse me taking a step back, but I think you guys might be solving a > > problem that doesn't exist... > > > > How do USB drivers get into a suspend state? At suspend time, before the > > atomic copy is made they have been told to FREEZE. At resume time, prior > > to the atomic restore, they have been told to FREEZE. The state > > They have been told to freeze _if you have usb built in_, and not > modular. Imagine kernel with usb as a module, doing resume from kernel > command line. usb will be in "just powered on" state. Yes, that's true. If the usb modules are loaded when suspending and not loaded when resuming or vice versa, you'll get inconsistencies: State at suspend State at resume Image state Built in Built in Freeze->Freeze Loaded modules Unloaded modules Undefined->Freeze Unloaded modules Loaded modules Freeze->Undefined I guess there are three possible solutions: 1) Leave things as they are and say it is the user's problem if they make the state inconsistent. 2) Keep knowledge of the device states across the atomic restore and use that information in deciding what to do in device resume/powerup. 3) Make device drivers handle the situation properly without knowledge of what state the hardware is really in (or check the real state - where possible - and rely on that in deciding what to do). 2 seems to me to make for the most reliable solution. Regards, Nigel > Pavel --
