The Design and Implementation of the FreeBSD Operating System, Second Edition
Now available: The Design and Implementation of the FreeBSD Operating System (Second Edition)


[ source navigation ] [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] [ list types ] [ track identifier ]

FreeBSD/Linux Kernel Cross Reference
sys/kern/device_if.m

Version: -  FREEBSD  -  FREEBSD-13-STABLE  -  FREEBSD-13-0  -  FREEBSD-12-STABLE  -  FREEBSD-12-0  -  FREEBSD-11-STABLE  -  FREEBSD-11-0  -  FREEBSD-10-STABLE  -  FREEBSD-10-0  -  FREEBSD-9-STABLE  -  FREEBSD-9-0  -  FREEBSD-8-STABLE  -  FREEBSD-8-0  -  FREEBSD-7-STABLE  -  FREEBSD-7-0  -  FREEBSD-6-STABLE  -  FREEBSD-6-0  -  FREEBSD-5-STABLE  -  FREEBSD-5-0  -  FREEBSD-4-STABLE  -  FREEBSD-3-STABLE  -  FREEBSD22  -  l41  -  OPENBSD  -  linux-2.6  -  MK84  -  PLAN9  -  xnu-8792 
SearchContext: -  none  -  3  -  10 

    1 #
    2 # Copyright (c) 1998 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
   11 #    notice, this list of conditions and the following disclaimer in the
   12 #    documentation and/or other materials provided with the distribution.
   13 #
   14 # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
   15 # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
   16 # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
   17 # ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
   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: src/sys/kern/device_if.m,v 1.7.2.1 2001/07/24 09:49:41 dd Exp $
   27 # $DragonFly: src/sys/kern/device_if.m,v 1.4 2005/10/28 03:25:57 dillon Exp $
   28 #
   29 
   30 #include <sys/bus.h>
   31 
   32 INTERFACE device;
   33 
   34 #
   35 # Default implementations of some methods.
   36 #
   37 CODE {
   38         static int null_shutdown(device_t dev)
   39         {
   40             return 0;
   41         }
   42 
   43         static int null_suspend(device_t dev)
   44         {
   45             return 0;
   46         }
   47 
   48         static int null_resume(device_t dev)
   49         {
   50             return 0;
   51         }
   52 };
   53 
   54 #
   55 # Probe to see if the device is present.  Return 0 if the device exists,
   56 # ENXIO if it cannot be found. If some other error happens during the
   57 # probe (such as a memory allocation failure), an appropriate error code
   58 # should be returned. For cases where more than one driver matches a
   59 # device, a priority value can be returned.  In this case, success codes
   60 # are values less than or equal to zero with the highest value representing
   61 # the best match.  Failure codes are represented by positive values and
   62 # the regular unix error codes should be used for the purpose.
   63 
   64 # If a driver returns a success code which is less than zero, it must
   65 # not assume that it will be the same driver which is attached to the
   66 # device. In particular, it must not assume that any values stored in
   67 # the softc structure will be available for its attach method and any
   68 # resources allocated during probe must be released and re-allocated
   69 # if the attach method is called.  If a success code of zero is
   70 # returned, the driver can assume that it will be the one attached.
   71 # 
   72 # Devices which implement busses should use this method to probe for
   73 # the existence of devices attached to the bus and add them as
   74 # children.  If this is combined with the use of bus_generic_attach,
   75 # the child devices will be automatically probed and attached.
   76 #
   77 METHOD int probe {
   78         device_t dev;
   79 };
   80 
   81 #
   82 # Called by a parent bus to add new devices to the bus.  The driver
   83 # should check parent->state to determine whether this is an initial
   84 # identification scan on the bus, or whether it is a rescan.  If
   85 # parent->state == DS_ATTACHED then the identify call is a re-scan.
   86 #
   87 # Return 0 on success, 0 on rescan, or an error on the initial scan if no
   88 # devices were added to the bus.  Using generic_bus_identify() will
   89 # simply call BUS_ADD_CHILD using the driver name.
   90 #
   91 # Standard matching devices do not usually have an identify function, whereas
   92 # busses or any entity which needs to create static device entries under
   93 # the bus will.
   94 #
   95 STATICMETHOD int identify {
   96         driver_t *driver;
   97         device_t parent;
   98 };
   99 
  100 #
  101 # Attach a device to the system.  The probe method will have been
  102 # called and will have indicated that the device exists.  This routine
  103 # should initialise the hardware and allocate other system resources.
  104 # Returns 0 on success.
  105 #
  106 METHOD int attach {
  107         device_t dev;
  108 };
  109 
  110 #
  111 # Detach a device.  This can be called if the user is replacing the
  112 # driver software or if a device is about to be physically removed
  113 # from the system (e.g. for pccard devices).  Returns 0 on success.
  114 #
  115 METHOD int detach {
  116         device_t dev;
  117 };
  118 
  119 #
  120 # This is called during system shutdown to allow the driver to put the 
  121 # hardware into a consistent state for rebooting the computer.
  122 #
  123 METHOD int shutdown {
  124         device_t dev;
  125 } DEFAULT null_shutdown;
  126 
  127 #
  128 # This is called by the power-management subsystem when a suspend has been
  129 # requested by the user or by some automatic mechanism.  This gives
  130 # drivers a chance to veto the suspend or save their configuration before
  131 # power is removed.
  132 #
  133 METHOD int suspend {
  134         device_t dev;
  135 } DEFAULT null_suspend;
  136 
  137 METHOD int resume {
  138         device_t dev;
  139 } DEFAULT null_resume;

Cache object: a5973b9b4ccc61b0018829b85aab6187


[ source navigation ] [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] [ list types ] [ track identifier ]


This page is part of the FreeBSD/Linux Linux Kernel Cross-Reference, and was automatically generated using a modified version of the LXR engine.