ddi_get_devstate(9f)

1ddi_get_devstate(9F)     Kernel Functions for Drivers     ddi_get_devstate(9F)
2
3
4

NAME

6       ddi_get_devstate - Check device state
7

SYNOPSIS

9       #include <sys/ddi.h>
10       #include <sys/sunddi.h>
11
12       ddi_devstate_t ddi_get_devstate(dev_info_t *dip);
13
14

INTERFACE LEVEL

16       Solaris DDI specific (Solaris DDI)
17

PARAMETERS

19       dip     Pointer to the device's dev_info structure
20
21

DESCRIPTION

23       The ddi_get_devstate() function returns a value indicating the state of
24       the device specified by  dip, as derived from the configuration  opera‐
25       tions  that  have  been  performed  on  it  (or  on the bus on which it
26       resides) and any fault reports relating to it.
27

RETURN VALUES

29       DDI_DEVSTATE_OFFLINE     The device is offline.   In  this  state,  the
30                                device  driver is not attached, nor will it be
31                                attached automatically. The device  cannot  be
32                                used until it is brought online.
33
34
35       DDI_DEVSTATE_DOWN         The  device  is  online but unusable due to a
36                                fault.
37
38
39       DDI_DEVSTATE_QUIESCED     The bus on which the device resides has  been
40                                quiesced.  This  is not a fault, but no opera‐
41                                tions on the device should be performed  while
42                                the bus remains quiesced.
43
44
45       DDI_DEVSTATE_DEGRADED     The device is online but only able to provide
46                                a partial or degraded service, due to a fault.
47
48
49       DDI_DEVSTATE_UP           The device is online and fully operational.
50
51

CONTEXT

53       The ddi_get_devstate() function may be called  from  user,  kernel,  or
54       interrupt context.
55

NOTES

57       A  device  driver  should  call this function to check its own state at
58       each major entry point, and before committing resources to a  requested
59       operation.   If  a driver discovers that its device is already down, it
60       should perform required cleanup actions and return as soon as possible.
61       If  appropriate,  it  should  return an error to its caller, indicating
62       that the device has failed (for example, a  driver's  read(9E)  routine
63       would return EIO).
64
65
66       Depending on the driver, some non-I/O operations (for example, calls to
67       the driver's ioctl(9E) routine) may still succeed; only functions which
68       would  require fully accessible and operational hardware will necessar‐
69       ily fail. If the bus on which  the  device  resides  is  quiesced,  the
70       driver  may  return  a value indicating the operation should be retried
71       later (for  example,  EAGAIN).   Alternatively,  for  some  classes  of
72       device,  it  may be appropriate for the driver to enqueue the operation
73       and service it once the bus has been unquiesced.   Note  that  not  all
74       busses  support  the  quiesce/unquiesce  operations,  so this value may
75       never be seen by some drivers.
76