pm(9p) [sunos man page]
pm(9P) Kernel Properties for Drivers pm(9P) NAME
pm - Power Management properties DESCRIPTION
The pm-hardware-state property can be used to influence the behavior of the Power Management framework. Its syntax and interpretation is described below. Note that this property is only interpreted by the system immediately after the device has successfully attached. Changes in the property made by the driver after the driver has attached will not be recognized. pm-hardware-state is a string-valued property. The existence of the pm-hardware-state property indicates that a device needs special han- dling by the Power Management framework with regard to its hardware state. If the value of this property is needs-suspend-resume, the device has a hardware state that cannot be deduced by the framework. The frame- work definition of a device with hardware state is one with a reg property. Some drivers, such as SCSI disk and tape drivers, have no reg property but manage devices with "remote" hardware. Such a device must have a pm-hardware-state property with a value of needs-suspend- resume for the system to identify it as needing a call to its detach(9E) entry point with command DDI_SUSPEND when system is suspended, and a call to attach(9E) with command DDI_RESUME when system is resumed. For devices using original Power Management interfaces (which are now obsolete) detach(9E) is also called with DDI_PM_SUSPEND before power is removed from the device, and attach(9E) is called with DDI_PM_RESUME after power is restored. A value of no-suspend-resume indicates that, in spite of the existence of a reg property, a device has no hardware state that needs saving and restoring. A device exporting this property will not have its detach() entry point called with command DDI_SUSPEND when system is sus- pended, nor will its attach() entry point be called with command DDI_RESUME when system is resumed. For devices using the original (and now obsolete) Power Management interfaces, detach(9E) will not be called with DDI_PM_SUSPEND command before power is removed from the device, nor attach(9E) will be called with DDI_PM_RESUME command after power is restored to the device. A value of parental-suspend-resume indicates that the device does not implement the detach(9E) DDI_SUSPEND semantics, nor the attach() DDI_RESUME semantics, but that a call should be made up the device tree by the framework to effect the saving and/or restoring of hardware state for this device. For devices using original Power Management interfaces (which are now obsolete), it also indicates that the device does not implement the detach(9E) DDI_PM_SUSPEND semantics, nor the attach(9E) DDI_PM_RESUME semantics, but that a call should be made up the device tree by the framework to effect the saving and/or restoring the hardware state for this device. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +--------------------------+--------------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +--------------------------+--------------------------------+ |Interface stability |Evolving | +--------------------------+--------------------------------+ SEE ALSO
power.conf(4), pm(7D), attach(9E), detach(9E), pm_busy_component(9F), pm_idle_component(9F), pm-components(9P) Writing Device Drivers SunOS 5.10 20 Jan 2004 pm(9P)
Check Out this Related Man Page
detach(9E) Driver Entry Points detach(9E) NAME
detach - detach or suspend a device SYNOPSIS
#include <sys/ddi.h> #include <sys/sunddi.h> int prefix detach(dev_info_t *dip, ddi_detach_cmd_t cmd); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI) PARAMETERS
dip A pointer to the device's dev_info structure. cmd Type of detach; the driver should return DDI_FAILURE if any value other than DDI_DETACH or DDI_SUSPEND is passed to it. DESCRIPTION
The detach() function complements the attach(9E) routine. DDI_DETACH If cmd is set to DDI_DETACH, detach() is used to remove the state associated with a given instance of a device node prior to the removal of that instance from the system. The detach() function will be called once for each instance of the device for which there has been a successful attach(), once there are no longer any opens on the device. An attached instance of a driver can be successfully detached only once. The detach() function should clean up any per instance data initialized in attach(9E) and call kmem_free(9F) to free any heap allocations. For information on how to unregis- ter interrupt handlers, see ddi_add_intr(9F). This should also include putting the underlying device into a quiescent state so that it will not generate interrupts. Drivers that set up timeout(9F) routines should ensure that they are cancelled before returning DDI_SUCCESS from detach(). If detach() determines a particular instance of the device cannot be removed when requested because of some exceptional condition, detach() must return DDI_FAILURE, which prevents the particular device instance from being detached. This also prevents the driver from being unloaded. A driver instance failing the detach must ensure that no per instance data or state is modified or freed that would compromise the system or subsequent driver operation. The system guarantees that the function will only be called for a particular dev_info node after (and not concurrently with) a successful attach(9E) of that device. The system also guarantees that detach() will only be called when there are no outstanding open(9E) calls on the device. DDI_SUSPEND The DDI_SUSPEND cmd is issued when the entire system is being suspended and power removed from it or when the system must be made quies- cent. It will be issued only to devices which have a reg property or which export a pm-hardware-state property with the value needs-sus- pend-resume. If cmd is set to DDI_SUSPEND, detach() is used to suspend all activity of a device before power is (possibly) removed from the device. The steps associated with suspension must include putting the underlying device into a quiescent state so that it will not generate interrupts or modify or access memory. Once quiescence has been obtained, detach() can be called with outstanding open(9E) requests. It must save the hardware state of the device to memory and block incoming or existing requests until attach() is called with DDI_RESUME. If the device is used to store file systems, then after DDI_SUSPEND is issued, the device should still honor dump(9E) requests as this entry point may be used by suspend-resume operation (see cpr(7)) to save state file. It must do this, however, without disturbing the saved hardware state of the device. If the device driver uses automatic device Power Management interfaces (driver exports pm-components(9P) property), it might need to call pm_raise_power(9F) if the current power level is lower than required to complete the dump(9E) request. Before returning successfully from a call to detach() with a command of DDI_SUSPEND, the driver must cancel any outstanding timeouts and make any driver threads quiescent. If DDI_FAILURE is returned for the DDI_SUSPEND cmd, either the operation to suspend the system or to make it quiescent will be aborted. RETURN VALUES
DDI_SUCCESS For DDI_DETACH, the state associated with the given device was successfully removed. For DDI_SUSPEND, the driver was suc- cessfully suspended. DDI_FAILURE The operation failed or the request was not understood. The associated state is unchanged. CONTEXT
This function is called from user context only. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +--------------------------+--------------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +--------------------------+--------------------------------+ |Interface Stability | Evolving | +--------------------------+--------------------------------+ SEE ALSO
cpr(7), pm(7D), pm(9P), pm-components(9P), attach(9E), dump(9E), open(9E), power(9E), ddi_add_intr(9F), ddi_dev_is_needed(9F), ddi_map_regs(9F), kmem_free(9F), pm_raise_power(9F), timeout(9F) Writing Device Drivers SunOS 5.10 7 Dec 2003 detach(9E)