device_if.m (59093) | device_if.m (131988) |
---|---|
1# | 1# |
2# Copyright (c) 1998 Doug Rabson | 2# Copyright (c) 1998,2004 Doug Rabson |
3# All rights reserved. 4# 5# Redistribution and use in source and binary forms, with or without 6# modification, are permitted provided that the following conditions 7# are met: 8# 1. Redistributions of source code must retain the above copyright 9# notice, this list of conditions and the following disclaimer. 10# 2. Redistributions in binary form must reproduce the above copyright --- 7 unchanged lines hidden (view full) --- 18# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 19# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 20# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 21# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 22# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 23# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 24# SUCH DAMAGE. 25# | 3# All rights reserved. 4# 5# Redistribution and use in source and binary forms, with or without 6# modification, are permitted provided that the following conditions 7# are met: 8# 1. Redistributions of source code must retain the above copyright 9# notice, this list of conditions and the following disclaimer. 10# 2. Redistributions in binary form must reproduce the above copyright --- 7 unchanged lines hidden (view full) --- 18# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 19# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 20# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 21# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 22# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 23# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 24# SUCH DAMAGE. 25# |
26# $FreeBSD: head/sys/kern/device_if.m 59093 2000-04-08 14:17:18Z dfr $ | 26# $FreeBSD: head/sys/kern/device_if.m 131988 2004-07-11 16:17:42Z dfr $ |
27# 28 29#include <sys/bus.h> 30 | 27# 28 29#include <sys/bus.h> 30 |
31/** 32 * @defgroup DEVICE device - KObj methods for all device drivers 33 * @brief A basic set of methods required for all device drivers. 34 * 35 * The device interface is used to match devices to drivers during 36 * autoconfiguration and provides methods to allow drivers to handle 37 * system-wide events such as suspend, resume or shutdown. 38 * @{ 39 */ |
|
31INTERFACE device; 32 33# 34# Default implementations of some methods. 35# 36CODE { 37 static int null_shutdown(device_t dev) 38 { --- 5 unchanged lines hidden (view full) --- 44 return 0; 45 } 46 47 static int null_resume(device_t dev) 48 { 49 return 0; 50 } 51}; | 40INTERFACE device; 41 42# 43# Default implementations of some methods. 44# 45CODE { 46 static int null_shutdown(device_t dev) 47 { --- 5 unchanged lines hidden (view full) --- 53 return 0; 54 } 55 56 static int null_resume(device_t dev) 57 { 58 return 0; 59 } 60}; |
52 53# 54# Probe to see if the device is present. Return 0 if the device exists, 55# ENXIO if it cannot be found. If some other error happens during the 56# probe (such as a memory allocation failure), an appropriate error code 57# should be returned. For cases where more than one driver matches a 58# device, a priority value can be returned. In this case, success codes 59# are values less than or equal to zero with the highest value representing 60# the best match. Failure codes are represented by positive values and 61# the regular unix error codes should be used for the purpose. 62 63# If a driver returns a success code which is less than zero, it must 64# not assume that it will be the same driver which is attached to the 65# device. In particular, it must not assume that any values stored in 66# the softc structure will be available for its attach method and any 67# resources allocated during probe must be released and re-allocated 68# if the attach method is called. If a success code of zero is 69# returned, the driver can assume that it will be the one attached. 70# 71# Devices which implement busses should use this method to probe for 72# the existence of devices attached to the bus and add them as 73# children. If this is combined with the use of bus_generic_attach, 74# the child devices will be automatically probed and attached. 75# | 61 62/** 63 * @brief Probe to see if a device matches a driver. 64 * 65 * Users should not call this method directly. Normally, this 66 * is called via device_probe_and_attach() to select a driver 67 * calling the DEVICE_PROBE() of all candidate drivers and attach 68 * the winning driver (if any) to the device. 69 * 70 * This function is used to match devices to device drivers. 71 * Typically, the driver will examine the device to see if 72 * it is suitable for this driver. This might include checking 73 * the values of various device instance variables or reading 74 * hardware registers. 75 * 76 * In some cases, there may be more than one driver available 77 * which can be used for a device (for instance there might 78 * be a generic driver which works for a set of many types of 79 * device and a more specific driver which works for a subset 80 * of devices). Because of this, a driver should not assume 81 * that it will be the driver that attaches to the device even 82 * if it returns a success status from DEVICE_PROBE(). In particular, 83 * a driver must free any resources which it allocated during 84 * the probe before returning. The return value of DEVICE_PROBE() 85 * is used to elect which driver is used - the driver which returns 86 * the largest non-error value wins the election and attaches to 87 * the device. 88 * 89 * If a driver matches the hardware, it should set the device 90 * description string using device_set_desc() or 91 * device_set_desc_copy(). This string is 92 * used to generate an informative message when DEVICE_ATTACH() 93 * is called. 94 * 95 * As a special case, if a driver returns zero, the driver election 96 * is cut short and that driver will attach to the device 97 * immediately. 98 * 99 * For example, a probe method for a pci device driver might look 100 * like this: 101 * 102 * @code 103 * int foo_probe(device_t dev) 104 * { 105 * if (pci_get_vendor(dev) == FOOVENDOR && 106 * pci_get_device(dev) == FOODEVICE) { 107 * device_set_desc(dev, "Foo device"); 108 * return (0); 109 * } 110 * return (ENXIO); 111 * } 112 * @endcode 113 * 114 * To include this method in a device driver, use a line like this 115 * in the driver's method list: 116 * 117 * @code 118 * KOBJMETHOD(device_probe, foo_probe) 119 * @endcode 120 * 121 * @param dev the device to probe 122 * 123 * @retval 0 if the driver strongly matches this device 124 * @retval negative if the driver can match this device - the 125 * least negative value is used to select the 126 * driver 127 * @retval ENXIO if the driver does not match the device 128 * @retval positive if some kind of error was detected during 129 * the probe, a regular unix error code should 130 * be returned to indicate the type of error 131 * @see DEVICE_ATTACH(), pci_get_vendor(), pci_get_device() 132 */ |
76METHOD int probe { 77 device_t dev; 78}; 79 | 133METHOD int probe { 134 device_t dev; 135}; 136 |
80# 81# Called by a parent bus to add new devices to the bus. 82# | 137/** 138 * @brief Called by a parent device to allow drivers to add new devices to the parent. 139 * 140 * The DEVICE_IDENTIFY() method is used by some drivers (e.g. the ISA bus driver) 141 * to help populate the bus device with a useful set of child devices, normally by 142 * calling the BUS_ADD_CHILD() method of the parent device. For instance, 143 * the ISA bus driver uses several special drivers, including the isahint driver and 144 * the pnp driver to create child devices based on configuration hints and PnP bus 145 * probes respectively. 146 * 147 * Many bus drivers which support true plug-and-play do not need to use this method 148 * at all since child devices can be discovered automatically without help from 149 * child drivers. 150 * 151 * To include this method in a device driver, use a line like this 152 * in the driver's method list: 153 * 154 * @code 155 * KOBJMETHOD(device_identify, foo_identify) 156 * @endcode 157 * 158 * @param driver the driver whose identify method is being called 159 * @param parent the parent device to use when adding new children 160 */ |
83STATICMETHOD void identify { 84 driver_t *driver; 85 device_t parent; 86}; 87 | 161STATICMETHOD void identify { 162 driver_t *driver; 163 device_t parent; 164}; 165 |
88# 89# Attach a device to the system. The probe method will have been 90# called and will have indicated that the device exists. This routine 91# should initialise the hardware and allocate other system resources 92# (such as devfs entries). Returns 0 on success. 93# | 166/** 167 * @brief Attach a device to a device driver 168 * 169 * Normally only called via device_probe_and_attach(), this is called 170 * when a driver has succeeded in probing against a device. 171 * This method should initialise the hardware and allocate other 172 * system resources (e.g. devfs entries) as required. 173 * 174 * To include this method in a device driver, use a line like this 175 * in the driver's method list: 176 * 177 * @code 178 * KOBJMETHOD(device_attach, foo_attach) 179 * @endcode 180 * 181 * @param dev the device to probe 182 * 183 * @retval 0 success 184 * @retval non-zero if some kind of error was detected during 185 * the attach, a regular unix error code should 186 * be returned to indicate the type of error 187 * @see DEVICE_PROBE() 188 */ |
94METHOD int attach { 95 device_t dev; 96}; 97 | 189METHOD int attach { 190 device_t dev; 191}; 192 |
98# 99# Detach a device. This can be called if the user is replacing the 100# driver software or if a device is about to be physically removed 101# from the system (e.g. for pccard devices). Returns 0 on success. 102# | 193/** 194 * @brief Detach a driver from a device. 195 * 196 * This can be called if the user is replacing the 197 * driver software or if a device is about to be physically removed 198 * from the system (e.g. for removable hardware such as USB or PCCARD). 199 * 200 * To include this method in a device driver, use a line like this 201 * in the driver's method list: 202 * 203 * @code 204 * KOBJMETHOD(device_detach, foo_detach) 205 * @endcode 206 * 207 * @param dev the device to detach 208 * 209 * @retval 0 success 210 * @retval non-zero the detach could not be performed, e.g. if the 211 * driver does not support detaching. 212 * 213 * @see DEVICE_ATTACH() 214 */ |
103METHOD int detach { 104 device_t dev; 105}; 106 | 215METHOD int detach { 216 device_t dev; 217}; 218 |
107# 108# This is called during system shutdown to allow the driver to put the 109# hardware into a consistent state for rebooting the computer. 110# | 219/** 220 * @brief Called during system shutdown. 221 * 222 * This method allows drivers to detect when the system is being shut down. 223 * Some drivers need to use this to place their hardware in a consistent 224 * state before rebooting the computer. 225 * 226 * To include this method in a device driver, use a line like this 227 * in the driver's method list: 228 * 229 * @code 230 * KOBJMETHOD(device_shutdown, foo_shutdown) 231 * @endcode 232 */ |
111METHOD int shutdown { 112 device_t dev; 113} DEFAULT null_shutdown; 114 | 233METHOD int shutdown { 234 device_t dev; 235} DEFAULT null_shutdown; 236 |
115# 116# This is called by the power-management subsystem when a suspend has been 117# requested by the user or by some automatic mechanism. This gives 118# drivers a chance to veto the suspend or save their configuration before 119# power is removed. 120# | 237/** 238 * @brief This is called by the power-management subsystem when a suspend has been 239 * requested by the user or by some automatic mechanism. 240 * 241 * This gives 242 * drivers a chance to veto the suspend or save their configuration before 243 * power is removed. 244 * 245 * To include this method in a device driver, use a line like this 246 * in the driver's method list: 247 * 248 * @code 249 * KOBJMETHOD(device_suspend, foo_suspend) 250 * @endcode 251 * 252 * @param dev the device being suspended 253 * 254 * @retval 0 success 255 * @retval non-zero an error occurred while attempting to prepare the device 256 * for suspension 257 * 258 * @see DEVICE_RESUME() 259 */ |
121METHOD int suspend { 122 device_t dev; 123} DEFAULT null_suspend; 124 | 260METHOD int suspend { 261 device_t dev; 262} DEFAULT null_suspend; 263 |
264/** 265 * @brief This is called when the system resumes after a suspend. 266 * 267 * To include this method in a device driver, use a line like this 268 * in the driver's method list: 269 * 270 * @code 271 * KOBJMETHOD(device_resume, foo_resume) 272 * @endcode 273 * 274 * @param dev the device being resumed 275 * 276 * @retval 0 success 277 * @retval non-zero an error occurred while attempting to restore the device 278 * from suspension 279 * 280 * @see DEVICE_SUSPEND() 281 */ |
|
125METHOD int resume { 126 device_t dev; 127} DEFAULT null_resume; | 282METHOD int resume { 283 device_t dev; 284} DEFAULT null_resume; |