1.\" $OpenBSD: autoconf.9,v 1.10 2008/06/26 05:42:08 ray Exp $ 2.\" $NetBSD: autoconf.9,v 1.9 2002/02/13 08:18:35 ross Exp $ 3.\" 4.\" Copyright (c) 2001 The NetBSD Foundation, Inc. 5.\" All rights reserved. 6.\" 7.\" This code is derived from software contributed to The NetBSD Foundation 8.\" by Gregory McGarry. 9.\" 10.\" Redistribution and use in source and binary forms, with or without 11.\" modification, are permitted provided that the following conditions 12.\" are met: 13.\" 1. Redistributions of source code must retain the above copyright 14.\" notice, this list of conditions and the following disclaimer. 15.\" 2. Redistributions in binary form must reproduce the above copyright 16.\" notice, this list of conditions and the following disclaimer in the 17.\" documentation and/or other materials provided with the distribution. 18.\" 19.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS 20.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 21.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 22.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 23.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 24.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 25.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 26.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 27.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 28.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 29.\" POSSIBILITY OF SUCH DAMAGE. 30.\" 31.Dd $Mdocdate: June 26 2008 $ 32.Dt AUTOCONF 9 33.Os 34.Sh NAME 35.Nm autoconf 36.Nd autoconfiguration framework 37.Sh SYNOPSIS 38.Fd #include <sys/param.h> 39.Fd #include <sys/device.h> 40.Sh DESCRIPTION 41Autoconfiguration is the process of matching hardware devices with an 42appropriate device driver. 43In its most basic form, autoconfiguration consists of the recursive 44process of finding and attaching all devices on a bus, including other buses. 45.Pp 46The autoconfiguration framework supports 47.Em direct configuration 48where the bus driver can determine the devices present. 49.Pp 50The autoconfiguration framework also supports 51.Em indirect configuration 52where the drivers must probe the bus looking for the presence of a device. 53Direct configuration is preferred since it can find hardware regardless of 54the presence of proper drivers. 55.Pp 56The autoconfiguration process occurs at system bootstrap and is driven by a 57table generated from a 58.Do 59machine description 60.Dc 61file by 62.Xr config 8 . 63For a description of the 64.Xr config 8 65.Do 66device definition 67.Dc 68language, see 69.Xr files.conf 5 . 70.Pp 71Each device must have a name consisting of an alphanumeric string that 72ends with a unit number. 73The unit number identifies an instance of the driver. 74Device data structures are allocated dynamically during autoconfiguration, 75giving a unique address for each instance. 76.Sh INITIALIZATION 77.nr nS 1 78.Ft "void" 79.Fn config_init "void" 80.nr nS 0 81.Pp 82The 83.Fn config_init 84function initializes the autoconfiguration data structures. 85.Sh INDIRECT CONFIGURATION 86.nr nS 1 87.Ft "void *" 88.Fn config_search "cfmatch_t func" "struct device *parent" "void *aux" 89.Ft "void *" 90.Fn config_rootsearch "cfmatch_t func" "char *rootname" "void *aux" 91.nr nS 0 92.Pp 93The 94.Fn config_search 95function performs indirect configuration of physical devices by iterating 96over all potential children, calling the given function 97.Fa func 98for each one. 99.Pp 100The 101.Fn config_rootsearch 102function finds the root device identified by the string 103.Fa rootname , 104in a manner similar to 105.Fn config_search , 106except that there is no parent device. 107If 108.Fa func 109is 110.Dv NULL , 111.Fn config_search 112applies each child's match function instead. 113The argument 114.Fa parent 115is the pointer to the parent's device structure. 116The given 117.Fa aux 118argument describes the device that has been found and is simply passed 119on through 120.Fa func 121to the child. 122.Fn config_search 123returns a pointer to the best-matched child or 124.Dv NULL 125otherwise. 126.Pp 127The role of 128.Fa func 129is to call 130the match function for each device and call 131.Fn config_attach 132for any positive matches. 133.Bd -literal 134typedef int (*cfmatch_t)(struct device *parent, void *child, void *aux); 135.Ed 136.Pp 137If 138.Fa func 139is 140.Dv NULL , 141then the parent should record the return value from 142.Fn config_search 143and call 144.Fn config_attach 145itself. 146.Pp 147Note that this function is designed so that it can be used to apply an 148arbitrary function to all potential children. 149In this case callers may choose to ignore the return value. 150.Sh DIRECT CONFIGURATION 151.nr nS 1 152.Ft "struct device *" 153.Fn config_found_sm "struct device *parent" "void *aux" "cfprint_t print" \ 154 "cfmatch_t submatch" 155.Ft "struct device *" 156.Fn config_found "struct device *parent" "void *aux" "cfprint_t print" 157.Ft "struct device *" 158.Fn config_rootfound "char *rootname" "void *aux" 159.nr nS 0 160.Pp 161The 162.Fn config_found_sm 163function performs direct configuration on a physical device. 164.Fn config_found_sm 165is called by the parent and in turn calls the 166.Fa submatch 167function to call the match function as determined by the configuration table. 168If 169.Fa submatch 170is 171.Dv NULL , 172the driver match functions are called directly. 173The argument 174.Fa parent 175is the pointer to the parent's device structure. 176The given 177.Fa aux 178argument describes the device that has been found. 179The 180.Em softc 181structure for the matched device will be allocated, and the appropriate 182driver attach function will be called. 183.Pp 184If the device is matched, the system prints the name of the child and 185parent devices, and then calls the 186.Fa print 187function to produce additional information if desired. 188If no driver takes a match, the same 189.Fa print 190function is called to complain. 191The print function is called with the 192.Fa aux 193argument and, if the matches failed, the full name (including unit 194number) of the parent device, otherwise 195.Dv NULL . 196.Bd -literal 197typedef int (*cfprint_t)(void *aux, const char *parentname); 198#define QUIET 0 /* print nothing */ 199#define UNCONF 1 /* print " not configured" */ 200#define UNSUPP 2 /* print " not supported" */ 201.Ed 202.Pp 203Two special strings, 204.Do 205not configured 206.Dc 207and 208.Do 209unsupported 210.Dc 211will be appended automatically to non-driver reports if the return 212value is 213.Dv UNCONF 214or 215.Dv UNSUPP 216respectively, otherwise the function should return the value 217.Dv QUIET . 218.Pp 219The 220.Fn config_found_sm 221function returns a pointer to the attached device's 222.Em softc 223structure if the device is attached, 224.Dv NULL 225otherwise. 226Most callers can ignore this value, since the system will already have 227printed a diagnostic. 228.Pp 229The 230.Fn config_found 231macro expands to 232.Fn config_found_sm "parent" "aux" "print" "submatch" 233with 234.Fa submatch 235set to 236.Dv NULL 237and is provided for compatibility with older drivers. 238.Pp 239The 240.Fn config_rootfound 241function performs the same operation on the root device identified 242by the 243.Fa rootname 244string. 245.Sh ATTACHING AND DETACHING DEVICES 246.nr nS 1 247.Ft "struct device *" 248.Fn config_attach "struct device *parent" "void *cf" "void *aux" \ 249 "cfprint_t print" 250.Ft "int" 251.Fn config_detach "struct device *dev" "int flags" 252.nr nS 0 253.Pp 254The 255.Fn config_attach 256function attaches a found device. 257Memory is allocated for the 258.Em softc 259structure and the driver's attach function is called according to the 260configuration table. 261If successful, 262.Fn config_attach 263returns the 264.Em softc . 265If unsuccessful, it returns 266.Dv NULL . 267.Pp 268The 269.Fn config_detach 270function is called by the parent to detach the child device. 271The second argument 272.Fa flags 273contains detachment flags: 274.Bd -literal 275#define DETACH_FORCE 0x01 /* Force detachment; hardware gone */ 276#define DETACH_QUIET 0x02 /* Don't print a notice */ 277.Ed 278.Pp 279The 280.Fn config_detach 281function returns zero if successful and an error code otherwise. 282.Fn config_detach 283is always called from process context, allowing 284.Xr tsleep 9 285to be called while the device detaches itself (to deal with processes 286which have a device open). 287.Sh DEVICE ACTIVATION/DEACTIVATION 288.nr nS 1 289.Ft "int" 290.Fn config_activate "struct device *dev" 291.Ft "int" 292.Fn config_deactivate "struct device *dev" 293.nr nS 0 294.Pp 295The 296.Fn config_activate 297function is called by the parent to activate the child device 298.Fa dev . 299It is called to activate resources and initialise other kernel 300subsystems (such as the network subsystem). 301.Fn config_activate 302is called from interrupt context after the device has been attached. 303.Pp 304The 305.Fn config_deactivate 306function is called by the parent to deactivate the child device 307.Fa dev . 308.Fn config_deactivate 309is called from interrupt context to immediately relinquish resources 310and notify dependent kernel subsystems that the device is about to be 311detached. 312At some later point, 313.Fn config_detach 314will be called to finalise the removal of the device. 315.Sh DEFERRED CONFIGURATION 316.nr nS 1 317.Ft "void" 318.Fn config_defer "struct device *dev" "void (*func)(struct device *)" 319.nr nS 0 320.Pp 321The 322.Fn config_defer 323function is called by the child to defer the remainder of its configuration 324until all its parent's devices have been attached. 325At this point, the function 326.Fa func 327is called with the argument 328.Fa dev . 329.Sh CODE REFERENCES 330The autoconfiguration framework itself is implemented within the file 331.Pa sys/kern/subr_autoconf.c . 332Data structures and function prototypes for the framework are located in 333.Pa sys/sys/device.h . 334.Sh SEE ALSO 335.Xr autoconf 4 , 336.Xr files.conf 5 , 337.Xr config 8 338.Sh HISTORY 339Autoconfiguration first appeared in 340.Bx 4.1 . 341The autoconfiguration framework was completely revised in 342.Bx 4.4 . 343The detach and activate/deactivate interfaces appeared in 344.Nx 1.5 . 345