Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

enum_wimax_st(9) [suse man page]

ENUM 
WIMAX_ST(9) Linux Networking ENUM WIMAX_ST(9) NAME
enum_wimax_st - The different states of a WiMAX device SYNOPSIS
enum wimax_st { __WIMAX_ST_NULL, WIMAX_ST_DOWN, __WIMAX_ST_QUIESCING, WIMAX_ST_UNINITIALIZED, WIMAX_ST_RADIO_OFF, WIMAX_ST_READY, WIMAX_ST_SCANNING, WIMAX_ST_CONNECTING, WIMAX_ST_CONNECTED, __WIMAX_ST_INVALID }; CONSTANTS
__WIMAX_ST_NULL The device structure has been allocated and zeroed, but still wimax_dev_add hasn't been called. There is no state. WIMAX_ST_DOWN The device has been registered with the WiMAX and networking stacks, but it is not initialized (normally that is done with 'ifconfig DEV up' [or equivalent], which can upload firmware and enable communications with the device). In this state, the device is powered down and using as less power as possible. This state is the default after a call to wimax_dev_add. It is ok to have drivers move directly to WIMAX_ST_UNINITIALIZED or WIMAX_ST_RADIO_OFF in _probe after the call to wimax_dev_add. It is recommended that the driver leaves this state when calling 'ifconfig DEV up' and enters it back on 'ifconfig DEV down'. __WIMAX_ST_QUIESCING The device is being torn down, so no API operations are allowed to proceed except the ones needed to complete the device clean up process. WIMAX_ST_UNINITIALIZED [optional] Communication with the device is setup, but the device still requires some configuration before being operational. Some WiMAX API calls might work. WIMAX_ST_RADIO_OFF The device is fully up; radio is off (wether by hardware or software switches). It is recommended to always leave the device in this state after initialization. WIMAX_ST_READY The device is fully up and radio is on. WIMAX_ST_SCANNING [optional] The device has been instructed to scan. In this state, the device cannot be actively connected to a network. WIMAX_ST_CONNECTING The device is connecting to a network. This state exists because in some devices, the connect process can include a number of negotiations between user space, kernel space and the device. User space needs to know what the device is doing. If the connect sequence in a device is atomic and fast, the device can transition directly to CONNECTED WIMAX_ST_CONNECTED The device is connected to a network. __WIMAX_ST_INVALID This is an invalid state used to mark the maximum numeric value of states. DESCRIPTION
Transitions from one state to another one are atomic and can only be caused in kernel space with wimax_state_change. To read the state, use wimax_state_get. States starting with __ are internal and shall not be used or referred to by drivers or userspace. They look ugly, but that's the point -- if any use is made non-internal to the stack, it is easier to catch on review. All API operations [with well defined exceptions] will take the device mutex before starting and then check the state. If the state is __WIMAX_ST_NULL, WIMAX_ST_DOWN, WIMAX_ST_UNINITIALIZED or __WIMAX_ST_QUIESCING, it will drop the lock and quit with -EINVAL, -ENOMEDIUM, -ENOTCONN or -ESHUTDOWN. The order of the definitions is important, so we can do numerical comparisons (eg: < WIMAX_ST_RADIO_OFF means the device is not ready to operate). COPYRIGHT
Kernel Hackers Manual 2.6. July 2010 ENUM WIMAX_ST(9)

Check Out this Related 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)
Man Page