Re: Broken PM semantics (WAS: PATCH: Shutdown IDE before powering off).

[Pavel Machek]

Hi!

> > Thus wrote Bartlomiej Zolnierkiewicz:
> > > 
> > > On Thursday 22 of January 2004 17:02, Jeff Garzik wrote:
> > > > I'm either shock or very very worried that the reboot notifier that
> > > > flushes IDE in 2.4.x, ide_notifier, is nowhere to be seen in 2.6.x :(
> > > > That seems like the real problem -- the code _used_ to be there.
> > > 
> > > Yep, it should be re-added.  I wonder when/why it was removed?
> 
> Ideally, it should use the same mecanism as the PM requests...
> 
> In fact, the shutdown is just a special case of PM request. I think
> ultimately, we should drop the various "shutdown()" functions in the
> drivers in favor of a "state" selector for PM. That goes along with
> the current problem of "state" in PM beeing completely bogus. The
> constants defined by linux/pm.h are in no way related to what
> the various drivers have come to expect.
> 
> enum {
>         PM_SUSPEND_ON,
>         PM_SUSPEND_STANDBY,
>         PM_SUSPEND_MEM,
>         PM_SUSPEND_DISK,
>         PM_SUSPEND_MAX,
> };
>                                                                                                                    
> Which basically gives is MEM=2 and DISK=3, while drivers usually
> expect MEM=3 and DISK=4 while nobody really cares about 2 except
> some specific stuffs in the arch code (or radeonfb on pmacs...)
> 
> We should get rid of this assumption that we are passing a D-type
> anyway. I suggest we define once for all that what we are passing
> down the driver is really the overall system state we are getting
> to, that is MEM,DISK,KEXEC,SHUTDOWN, eventually STANDBY if we
> ever do something like that (useful for handhelds that have a
> special idle state and really don't care about scheduling whne
> nothing happens for a while).

Agreed. Or at least document that it takes D states
and BUG-ON on invalid values...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/