On Mon, 16 Jul 2007, Steven M. Bellovin wrote:
> I'm glad to see this; it will help a lot.  A few thoughts...
>
> Disk drivers, at the least, need the ability to wait until many pending
> commands are finished, I suspect.  Perhaps network devices do as well,
> but packet loss at such a time isn't a problem.

I was hoping that someone else could help me out in defining / 
implementing policies for these subsystems, where I'm not quite as 
familiar with how things work.

> A time delay should be added to some requests.  dhclient already has
> problems with autonegotiation (especially 802.11 links, in my
> experience, but also gigE) because of how frequently it does ifconfig
> down/up cycles; this might make it worse.  Disk drives can require a
> few seconds to spin up before they're ready; some component (I'm not
> sure which) is going to need to be cognizant of that delay.

Idle timeouts are currently in use for audio and display devices; this 
shouldn't be an issue.

> There probably needs to be some notion of topology, so that things like
> USB hubs can be powered down at the right time.  We may also need a
> user-level tool to check the power state of various pieces.

I forgot to mention in my first email that device pm handlers are attached 
to device_t, so you should end up with proper topology for free.

To register a power handler, a driver does this at attach time:

   devpm_status_t status;

   status = devpm_register(self, bus, mydriver_power);

Typically the 'bus' arg is parent, but that may not always be the case. 
What then happens, when the PM policy for a specific device requests that 
it changes state, the following happens:

   If bus is defined and we are increasing our power level
     Turn parent bus on
   Set state of device
   If failure
     Return
   Notify bus of state change

This way, a bus can scan all of its children and power itself down when 
everything below it is turned off. The policy will then re-enable the 
parent bus before enabling the device later on.

As for showing current power states from userland, we can probably use 
/dev/drvctl for this.

Cheers,
Jared