On Fri, Oct 05, 2007 at 02:24:01PM -0700, Matt Thomas wrote:
>
>> joerg@britannica.bec.de said:
>>> bool pnp_device_register(dev_t, bool (*suspend)(dev_t),
>>>     bool (*resume)(dev_t));
>
> is dev_t supposed to be device_t?

Yes.

> How do you control which D1,D2,D3 state to suspend to?
> register should indicate which states are supported?

At the moment it is up to the bus handler to use whatever it wants.
The first implementation would use D3hot for all PCI devices that
support PCI-PM. Once the device property support is merged, it would be
adjustable on a per-device base. This will likely go hand-in-hand with
an extension of the bus API. But I want to defer that discussion to the
right point.

I don't think register has to include the supported states as they are
either trivial (just on or off) or need some bus support. I don't think
complicating the API is justified at the current time.

> How do you deal with, say, an audio device which is inactive
> so it wants to automatically powers itself down?  does it need
> to go through the system pnp calls or can it do a private suspend
> behind the system's back.

The device itself should do nothing of that sort. That's what the device
classes and handlers are for. I have an experimental patch for the
jmcneill-pm to power down a network interface if it is not IFF_UP.

Jared wants to do similiar things for the audio devices. In general, the
decision about when to power down or not should be left for higher
layers to decide. A device is certainly not the right place.

> I think a reprobe is also needed.  (think a laptop docking station)

Hot plug support is a separate problem domain and has to be addressed at
the bus level.

Joerg