Re: [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()

[Pavel Machek <pavel@suse.cz>]

On Út 25-04-06 16:13:41, David Brownell wrote:
> 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.

Or you can simply adds flags field to pm_message_t.

> 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

After kexec, you hit device-init path, while after swsusp resume, you
hit... well resume(). That's quite different.

> 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.

You identified that problem yourselves: it will break drivers.

Add flags field and be done with it... please?
								Pavel
-- 
Thanks for all the (sleeping) penguins.