Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

ddi_get_devstate(9f) [sunos man page]

ddi_get_devstate(9F)					   Kernel Functions for Drivers 				      ddi_get_devstate(9F)

NAME
ddi_get_devstate - Check device state SYNOPSIS
#include <sys/ddi.h> #include <sys/sunddi.h> ddi_devstate_t ddi_get_devstate(dev_info_t *dip); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI) PARAMETERS
dip Pointer to the device's dev_info structure DESCRIPTION
The ddi_get_devstate() function returns a value indicating the state of the device specified by dip, as derived from the configuration operations that have been performed on it (or on the bus on which it resides) and any fault reports relating to it. RETURN VALUES
DDI_DEVSTATE_OFFLINE The device is offline. In this state, the device driver is not attached, nor will it be attached automatically. The device cannot be used until it is brought online. DDI_DEVSTATE_DOWN The device is online but unusable due to a fault. DDI_DEVSTATE_QUIESCED The bus on which the device resides has been quiesced. This is not a fault, but no operations on the device should be performed while the bus remains quiesced. DDI_DEVSTATE_DEGRADED The device is online but only able to provide a partial or degraded service, due to a fault. DDI_DEVSTATE_UP The device is online and fully operational. CONTEXT
The ddi_get_devstate() function may be called from user, kernel, or interrupt context. NOTES
A device driver should call this function to check its own state at each major entry point, and before committing resources to a requested operation. If a driver discovers that its device is already down, it should perform required cleanup actions and return as soon as possi- ble. If appropriate, it should return an error to its caller, indicating that the device has failed (for example, a driver's read(9E) rou- tine would return EIO). Depending on the driver, some non-I/O operations (for example, calls to the driver's ioctl(9E) routine) may still succeed; only functions which would require fully accessible and operational hardware will necessarily fail. If the bus on which the device resides is quiesced, the driver may return a value indicating the operation should be retried later (for example, EAGAIN). Alternatively, for some classes of device, it may be appropriate for the driver to enqueue the operation and service it once the bus has been unquiesced. Note that not all busses support the quiesce/unquiesce operations, so this value may never be seen by some drivers. SEE ALSO
attach(9E), ioctl(9E), open(9E), read(9E), strategy(9E), write(9E), ddi_dev_report_fault(9F) SunOS 5.10 13 August 1999 ddi_get_devstate(9F)

Check Out this Related Man Page

quiesce(9E)							Driver Entry Points						       quiesce(9E)

NAME
quiesce - quiesce a device SYNOPSIS
#include <sys/ddi.h> #include <sys/sunddi.h> int prefixquiesce(dev_info_t *dip); int ddi_quiesce_not_needed(dev_info_t *dip); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI) PARAMETERS
dip A pointer to the device's dev_info structure. DESCRIPTION
The quiesce() function quiesces a device so that the device no longer generates interrupts, modifies or accesses memory. The driver should reset the device to a hardware state from which the device can be correctly configured by the driver's attach() routine without a system power cycle or being configured by the firmware. For devices with a defined reset state configuration, the driver should return that device to that state as part of the quiesce operation. Fast Reboot, where firmware is bypassed when booting to a new OS image, is such a case. quiesce() is only called for an attached device instance as one of the final operations of a reboot sequence, and no other thread can be active for this device. The system guarantees that no other driver entry point is active or invoked while quiesce() is invoked. The system also guarantees that no timeout or taskq is invoked. The system is single-threaded and can not be interrupted. Therefore, the driver's qui- esce() implementation must not use locks or timeouts, or rely on them being called. The driver must discard all outstanding I/O instead of waiting for completion. At the conclusion of the quiesce() operation, the driver must guarantee that the device no longer has access to memory or interrupts. The only DDI interfaces that can be called by the quiesce() implementation are non-blocking functions, such as the ddi_get*() and ddi_put*() functions. If quiesce() determines a particular instance of the device cannot be quiesced when requested because of some exceptional condition, qui- esce() returns DDI_FAILURE. This rarely happens. If a driver has previously implemented the obsolete reset() interface, its functionality must be merged into quiesce(). The driver's reset() routine is no longer called if an implementation of quiesce() is present. ddi_quiesce_not_needed() always returns DDI_SUCCESS. A driver can set its devo_quiesce device function to ddi_quiesce_not_needed() to indi- cate that the device it manages does not need to be quiesced. RETURN VALUES
quiesce() returns the following: DDI_SUCCESS The device has been successfully quiesced. DDI_FAILURE The operation failed. CONTEXT
This function is called from kernel context only. SEE ALSO
reboot(1M), uadmin(1M), uadmin(2), attach(9E), detach(9E), ddi_add_intr(9F), ddi_map_regs(9F), pci_config_setup(9F), timeout(9F), dev_ops(9S) NOTES
When quiesce() is called, the system is single-threaded, therefore the driver's quiesce() implementation must not be blocked. For example, the implementation must not create or tear down mappings, call FMA functions, or create or cancel callbacks. SunOS 5.11 16 Sep 2008 quiesce(9E)
Man Page