PERFORCE change 39117 for review

[Warner Losh]

http://perforce.freebsd.org/chv.cgi?CH=39117

Change 39117 by imp at imp_koguchi on 2003/10/03 15:59:36

	Add comments to jhb's latest additions.

Affected files ...

.. //depot/projects/power/notes#6 edit

Differences ...

==== //depot/projects/power/notes#6 (text+ko) ====

@@ -22,10 +22,19 @@
       our power shadow tree in the acpi_SetPowerState() function.
 - define a bus method for powering up/down devices
   - bus_set_powerstate(parent, child, state) where state is on or off
+  # actually on/off is insufficient for a power management daemon that
+  # wants to actively manage the D level of a device.  We should make
+  # this more flexible so that it can be mapped into states that are
+  # neither on or off.
 - define either a device or syscall for asking new-bus to dispatch
   commands to a given device
+  # devctl is the perfect place for this, in one of my trees I have
+  # ioctls for doing this already.
   - The power command would be sent to the parent device using
     device_get_parent() for the simple case (power off fdc0)
+  # would also potentially need a method for powering off arbitrary devices
+  # in the tree that aren't attached for busses whose default policy is
+  # to not power down unattached devices.
 - define a bus method to locate a child of a specific device by name
   using a 'parent:child' syntax where the format of the "child" string
   is defined by the parent driver.  Thus, 'pci0:<slot>:<func>' might be
@@ -34,12 +43,22 @@
   - Convert device_power() to use this method to look up the child device
     if the name contains a colon instead of treating the name as a pure
     name of the child device
+  # We have almost what we need now in the location_str stuff.  However,
+  # that's more of a 'long string' rather than the short string that's
+  # wanted for this.
 - Perhaps rename device_power() to device_command() to allow for other
   commands like eject, etc.
+  # methods should be unique.  Command interfaces to userland should dispatch
+  # the right method.  Otherwise we've reinvented ioctl :-)
 - convert to a model of suspending the device via device_suspend()/resume()
   rather than detach()/attach()
   - This may require fixes to drivers so that they continue to function
     appropriately when their hardware has been suspended
+  # NO.  This cannot be implemented reliably.  pccard bridges do not tell
+  # us that a device has been removed while the system was asleep.  That's
+  # why we detach/reattach on suspend/resume for devices on pccard/cardbus
+  # bridges.  usb bridges can tell about this, and they properly use the
+  # suspend/resume functions.
 
 The second stage will be to make the powering off of devices more automated.
 This is still in early design stage.  It may involve a powerd, it may