cfgmgr_get_state(9r) [osf1 man page]
cfgmgr_get_state(9r) cfgmgr_get_state(9r) NAME
cfgmgr_get_state - General: Determines the configuration state SYNOPSIS
int cfgmgr_get_state( char *driver_name, int *driver_cfg_state ); ARGUMENTS
Specifies the name of the device driver whose configuration state you want to obtain. This name is a string that matches the string you specified for the entry_name item in the /etc/sysconfigtab database. Typically, third-party driver writers specify the driver name (fol- lowed by a colon) in the sysconfigtab file fragment, which gets appended to the /etc/sysconfigtab database during the driver product installation. Returns one of the following state value bits to the driver_cfg_state argument: The specified device driver is in the dynamic configuration state. This means the driver was dynamically configured into the kernel. The specified device driver is in the static configuration state. This means the driver was statically configured into the kernel. DESCRIPTION
The cfgmgr_get_state routine obtains the configuration state of the specified device driver. The specified device driver is in either the static configuration state or the dynamic configuration state. The cfgmgr_get_state routine returns the state value in the driver_cfg_state argument. Driver writers should store this state value in an xx_is_dynamic variable or some similarly named variable. You typically call the cfgmgr_get_state routine in the CFG_OP_CONFIGURE entry point of the device driver's configure routine. RETURN VALUES
Upon successful completion, cfgmgr_get_state returns the value ESUCCESS. This success value indicates that cfgmgr_get_state returned the configuration state of the specified device driver in the driver_cfg_state argument. Otherwise, cfgmgr_get_state returns one of the follow- ing error constants defined in /usr/sys/include/sys/sysconfig.h and /usr/sys/include/sys/errno.h: The device driver that you specified in the driver_name argument does not exist. In this case, cfgmgr_get_state cannot return the configuration state of the specified device driver in the driver_cfg_state argument. The device driver that you specified in the driver_name argument is not a valid name. EXAMPLES
See Writing Device Drivers: Tutorial for a code example of the cfgmgr_get_state interface. SEE ALSO
Routines: cfgmgr_set_status(9r) cfgmgr_get_state(9r)
Check Out this Related Man Page
power(9E) Driver Entry Points power(9E) NAME
power - power a device attached to the system SYNOPSIS
#include <sys/ddi.h> #include <sys/sunddi.h> int prefixpower(dev_info_t *dip, int component, int level); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI). This entry point is required. If the driver writer does not supply this entry point, the value NULL must be used in the cb_ops(9S) structure instead. PARAMETERS
dip Pointer to the device's dev_info structure. component Component of the driver to be managed. level Desired component power level. DESCRIPTION
The power(9E) function is the device-specific Power Management entry point. This function is called when the system wants the driver to set the power level of component to level. The level argument is the driver-defined power level to which the component needs to be set. Except for power level 0, which is inter- preted by the framework to mean "powered off," the interpretation of level is entirely up to the driver. The component argument is the component of the device to be power-managed. The interpretation of component is entirely up to the driver. When a requested power transition would cause the device to lose state, the driver must save the state of the device in memory. When a requested power transition requires state to be restored, the driver must restore that state. If a requested power transition for one component requires another component to change power state before it can be completed, the driver must call pm_raise_power(9F) to get the other component changed, and the power(9E) entry point must support being re-entered. If the system requests an inappropriate power transition for the device (for example, a request to power down a device which has just become busy), then the power level should not be changed and power should return DDI_FAILURE. RETURN VALUES
The power() function returns: DDI_SUCCESS Successfully set the power to the requested level. DDI_FAILURE Failed to set the power to the requested level. CONTEXT
The power() function is called from user or kernel context only. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Interface stability |Evolving | +-----------------------------+-----------------------------+ SEE ALSO
attach(9E), detach(9E), pm_busy_component(9F), pm_idle_component(9F), pm_raise_power(9F), cb_ops(9S) Writing Device Drivers Using Power Management SunOS 5.10 12 Dec 2003 power(9E)