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
ddi_dev_report_fault(9F) Kernel Functions for Drivers ddi_dev_report_fault(9F) NAME
ddi_dev_report_fault - Report a hardware failure SYNOPSIS
#include <sys/ddi.h> #include <sys/sunddi.h> void ddi_dev_report_fault (dev_info_t *dip, ddi_fault_impact_t impact, ddi_fault_location_t location, const char *message ); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI) PARAMETERS
dip Pointer to the driver's dev_info structure to which the fault report relates. (Normally the caller's own dev_info pointer). impact One of a set of enumerated values indicating the impact of the fault on the device's ability to provide normal service. location One of a set of enumerated values indicating the location of the fault, relative to the hardware controlled by the driver specified by dip. message Text of the message describing the fault being reported. DESCRIPTION
This function provides a standardized mechanism through which device drivers can report hardware faults. Use of this reporting mechanism enables systems equipped with a fault management system to respond to faults discovered by a driver. On a suitably equipped system, this might include automatic failover to an alternative device and/or scheduling replacement of the faulty hardware. The driver must indicate the impact of the fault being reported on its ability to provide service by passing one of the following values for the impact parameter: "small and bold">DDI_SERVICE_LOST Indicates a total loss of service. The driver is unable to implement the normal functions of its hardware. DDI_SERVICE_DEGRADED The driver is unable to provide normal service, but can provide a partial or degraded level of service. The driver may have to make repeated attempts to perform an operation before it succeeds, or it may be running at less than its configured speed. A driver may use this value to indicate that an alternative device should be used if available, but that it can continue operation if no alternative exists. DDI_SERVICE_UNAFFECTED The service provided by the device is currently unaffected by the reported fault. This value may be used to report recovered errors for predictive failure analysis. DDI_SERVICE_RESTORED The driver has resumed normal service, following a previous report that service was lost or degraded. This message implies that any previously reported fault condition no longer exists. The location parameter should be one of the following values: DDI_DATAPATH_FAULT The fault lies in the datapath between the driver and the device. The device may be unplugged, or a problem may exist in the bus on which the device resides. This value is appropriate if the device is not responding to accesses, (for example, the device may not be present) or if a call to ddi_check_acc_handle(9F) returns DDI_FAILURE. DDI_DEVICE_FAULT The fault lies in the device controlled by the driver. This value is appropriate if the device returns an error from a selftest func- tion, or if the driver is able to determine that device is present and accessible, but is not functioning correctly. DDI_EXTERNAL_FAULT The fault is external to the device. For example, an Ethernet driver would use this value when reporting a cable fault. If a device returns detectably bad data during normal operation (an "impossible" value in a register or DMA status area, for example), the driver should check the associated handle using ddi_check_acc_handle(9F) or ddi_check_dma_handle(9F) before reporting the fault. If the fault is associated with the handle, the driver should specify DDI_DATAPATH_FAULT rather than DDI_DEVICE_FAULT. As a consequence of this call, the device's state may be updated to reflect the level of service currently available. See ddi_get_devstate(9F). Note that if a driver calls ddi_get_devstate(9F) and discovers that its device is down, a fault should not be reported- the device is down as the result of a fault that has already been reported. Additionally, a driver should avoid incurring or reporting additional faults when the device is already known to be unusable. The ddi_dev_report_fault() call should only be used to report hardware (device) problems and should not be used to report purely software problems such as memory (or other resource) exhaustion. EXAMPLES
An Ethernet driver receives an error interrupt from its device if various fault conditions occur. The driver must read an error status register to determine the nature of the fault, and report it appropriately: static int xx_error_intr(xx_soft_state *ssp) { ... error_status = ddi_get32(ssp->handle, &ssp->regs->xx_err_status); if (ddi_check_acc_handle(ssp->handle) != DDI_SUCCESS) { ddi_dev_report_fault(ssp->dip, DDI_SERVICE_LOST, DDI_DATAPATH_FAULT, "register access fault"); return DDI_INTR_UNCLAIMED; } if (ssp->error_status & XX_CABLE_FAULT) { ddi_dev_report_fault(ssp->dip, DDI_SERVICE_LOST, DDI_EXTERNAL_FAULT, "cable fault") return DDI_INTR_CLAIMED; } if (ssp->error_status & XX_JABBER) { ddi_dev_report_fault(ssp->dip, DDI_SERVICE_DEGRADED, DDI_EXTERNAL_FAULT, "jabbering detected") return DDI_INTR_CLAIMED; } ... } CONTEXT
The ddi_dev_report_fault() function may be called from user, kernel, or interrupt context. SEE ALSO
ddi_check_acc_handle(9F), ddi_check_dma_handle(9F), ddi_get_devstate(9F) SunOS 5.10 13 August 1999 ddi_dev_report_fault(9F)