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