xref: /openbsd-src/share/man/man9/autoconf.9 (revision d13be5d47e4149db2549a9828e244d59dbc43f15)
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