On Tuesday 25 April 2006 2:41 pm, Pavel Machek wrote: > > Well, if we had a pm_should_I_spin_down_drives() it would make sense to me > > that it return FALSE during kernel_restart_prepare() too ... surely kexec > > users have the same issues! > > pm_should_I_spin_down_drives() is incredibly ugly hack, sorry. The name was chosen to be ugly. I'd expect someone to make it prettier; maybe draw ponies around the name or somesuch. ;) However, by the way your pm_message_t changes removed all information about system states, you've forced that family of approach in every driver that needs to know about such states in order to behave correctly. For example, "don't turn off clock X in PM_STANDBY" ... since no driver has a standard way to know about PM_STANDBY, it needs some function accessing state set up by pm_ops.prepare or else it's not going to be able to behave right. > > The third state is the problem scenario, kicking in when the driver was > > statically linked (or modprobed from initramfs, etc), but not during > > your scenario. > > Driver should be able to resume() from state #3. If driver is broken > and can't do that, modify suspend() call to power down hardware. You conveniently edited out the elaboration there. State #3 is no problem by itself ... it's later states, only accessible through door #3. The problem comes from then calling suspend() -- as you advise! -- to force broken/invalid/bogus suspend state into the hardware. It's NOT a driver issue ... it's the fact that calling suspend() there will trash hardware state (needlessly). Drivers should not need to cope with such trashing. > > My patch/suggestion just ensures that instead of that broken state, reset is used. > > in all cases ... not just the "driver not initialized before snapshot resume" case. > > I guess I partially see what you are saying. Behaviour in > driver-modular and driver-non-modular is indeed different and that is > not nice. That's part of it; the other part is that swsusp should never force the hardware to reflect an invalid state (the way it does without my patch). Different behaviours wouldn't be much trouble if they were both correct. > But it would be nice to have less intrusive solution than call reboot > notifiers... Actually, we'd need the notifiers to be called as much as the driver.shutdown() methods ... they are both used to reset hardware. You still haven't come up with a response to my point that starting up a new kernel via swsusp snapshot resume is a system restart in exactly the same way as it is for kexec() ... at this point, there is no better fix for the problem than my original patch, AND you haven't actually identified a single real problem with it. - Dave
