1 '\" te
   2 .\"  Copyright (c) 2005, Sun Microsystems, Inc. All Rights Reserved
   3 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
   4 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
   5 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
   6 .TH DRIVER.CONF 4 "Jan 5, 2007"
   7 .SH NAME
   8 driver.conf \- driver configuration files
   9 .SH SYNOPSIS
  10 .LP
  11 .nf
  12 \fBdriver.conf\fR
  13 .fi
  14 
  15 .SH DESCRIPTION
  16 .sp
  17 .LP
  18 Driver configuration files provide values for device properties. The values
  19 override values provided by the devices themselves. Most modern devices provide
  20 enough property values to make a driver configuration file unnecessary.
  21 .sp
  22 .LP
  23 The system associates a driver with its configuration file by name. For
  24 example, a driver in \fB/usr/kernel/drv\fR called \fBwombat\fR has the driver
  25 configuration file \fBwombat.conf\fR, also stored in \fB/usr/kernel/drv\fR,
  26 associated with it. On systems capable of support 64-bit drivers, the driver
  27 configuration file should be placed in the directory in which the 32-bit driver
  28 is (or would be) located, even if only a 64-bit version is provided. For
  29 example, a 64-bit driver stored in \fB/usr/kernel/drv/sparcv9\fR stores its
  30 driver configuration file in \fB/usr/kernel/drv\fR.
  31 .sp
  32 .LP
  33 The value of the \fBname\fR property is the node name. In a \fBdriver.conf\fR
  34 file, where the generic node name and \fBcompatible\fR property associated with
  35 a self-identifying devices are typically not used, the node name must be a
  36 binding name. The binding name is the name chosen by the system to bind a
  37 driver to the device. The binding name is either an alias associated with the
  38 driver established by \fBadd_drv\fR(1M) or the driver name itself.
  39 .sp
  40 .LP
  41 The syntax of a single entry in a driver configuration file takes one of three
  42 forms:
  43 .sp
  44 .in +2
  45 .nf
  46 \fBname\fR="\fInode name\fR" \fBparent\fR="\fIparent name\fR" [\fIproperty-name=value\fR ...]\fB;\fR

 185 .LP
 186 This creates two \fBdevinfo\fR nodes called \fBACME,example\fR which attaches
 187 below the \fBpseudo\fR node in the kernel device tree. The \fBinstance\fR
 188 property is only interpreted by the \fBpseudo\fR node, see \fBpseudo\fR(4) for
 189 further details. A property called \fBdebug-level\fR is created on the first
 190 \fBdevinfo\fR node which has the value 1. The \fBexample\fR driver is able to
 191 fetch the value of this property using \fBddi_prop_get_int\fR(9F).
 192 
 193 .sp
 194 .LP
 195 Two global driver properties are created, \fBwhizzy-mode\fR (which has the
 196 string value "on") and \fBdebug-level\fR (which has the value 3). If the driver
 197 looks up the property \fBwhizzy-mode\fR on either node, it retrieves the value
 198 of the global \fBwhizzy-mode\fR property ("on"). If the driver looks up the
 199 \fBdebug-level\fR property on the first node, it retrieves the value of the
 200 \fBdebug-level\fR property on that node (1). Looking up the same property on
 201 the second node retrieves the value of the global \fBdebug-level\fR property
 202 (3).
 203 
 204 .SH SEE ALSO
 205 .sp
 206 .LP
 207 \fBadd_drv\fR(1M), \fBpci\fR(4), \fBpseudo\fR(4), \fBsbus\fR(4), \fBscsi\fR(4),
 208 \fBprobe\fR(9E), \fBddi_getlongprop\fR(9F), \fBddi_getprop\fR(9F),
 209 \fBddi_getproplen\fR(9F), \fBddi_prop_get_int\fR(9F),
 210 \fBddi_prop_lookup\fR(9F), \fBddi_prop_op\fR(9F)
 211 .sp
 212 .LP
 213 \fIWriting Device Drivers\fR
 214 .SH WARNINGS
 215 .sp
 216 .LP
 217 To avoid namespace collisions between multiple driver vendors, it is strongly
 218 recommended that the \fIname\fR property of the driver should begin with a
 219 vendor-unique string. A reasonably compact and unique choice is the vendor
 220 over-the-counter stock symbol.
 221 .SH NOTES
 222 .sp
 223 .LP
 224 The \fBupdate_drv\fR(1M) command should be used to prompt the kernel to reread
 225 \fBdriver.conf\fR files. Using \fBmodunload\fR(1M) to update \fBdriver.conf\fR
 226 continues to work in release 9 of the Solaris operating environment, but the
 227 behavior will change in a future release.

   1 '\" te
   2 .\"  Copyright (c) 2005, Sun Microsystems, Inc. All Rights Reserved
   3 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
   4 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
   5 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
   6 .TH DRIVER.CONF 4 "Sep 16, 2018"
   7 .SH NAME
   8 driver.conf \- driver configuration files
   9 .SH SYNOPSIS
  10 .LP
  11 .nf
  12 \fBdriver.conf\fR
  13 .fi
  14 
  15 .SH DESCRIPTION

  16 .LP
  17 Driver configuration files provide values for device properties. The values
  18 override values provided by the devices themselves. Most modern devices provide
  19 enough property values to make a driver configuration file unnecessary.
  20 .sp
  21 .LP
  22 The system associates a driver with its configuration file by name. For
  23 example, a driver in \fB/usr/kernel/drv\fR called \fBwombat\fR has the driver
  24 configuration file \fBwombat.conf\fR, also stored in \fB/usr/kernel/drv\fR,
  25 associated with it. On systems that support 64-bit drivers, the driver
  26 configuration file should be placed in the directory in which the 32-bit driver
  27 is (or would be) located, even if only a 64-bit version is provided. For
  28 example, a 64-bit driver stored in \fB/usr/kernel/drv/sparcv9\fR stores its
  29 driver configuration file in \fB/usr/kernel/drv\fR.
  30 .sp
  31 .LP
  32 The value of the \fBname\fR property is the node name. In a \fBdriver.conf\fR
  33 file, where the generic node name and \fBcompatible\fR property associated with
  34 a self-identifying devices are typically not used, the node name must be a
  35 binding name. The binding name is the name chosen by the system to bind a
  36 driver to the device. The binding name is either an alias associated with the
  37 driver established by \fBadd_drv\fR(1M) or the driver name itself.
  38 .sp
  39 .LP
  40 The syntax of a single entry in a driver configuration file takes one of three
  41 forms:
  42 .sp
  43 .in +2
  44 .nf
  45 \fBname\fR="\fInode name\fR" \fBparent\fR="\fIparent name\fR" [\fIproperty-name=value\fR ...]\fB;\fR

 184 .LP
 185 This creates two \fBdevinfo\fR nodes called \fBACME,example\fR which attaches
 186 below the \fBpseudo\fR node in the kernel device tree. The \fBinstance\fR
 187 property is only interpreted by the \fBpseudo\fR node, see \fBpseudo\fR(4) for
 188 further details. A property called \fBdebug-level\fR is created on the first
 189 \fBdevinfo\fR node which has the value 1. The \fBexample\fR driver is able to
 190 fetch the value of this property using \fBddi_prop_get_int\fR(9F).
 191 
 192 .sp
 193 .LP
 194 Two global driver properties are created, \fBwhizzy-mode\fR (which has the
 195 string value "on") and \fBdebug-level\fR (which has the value 3). If the driver
 196 looks up the property \fBwhizzy-mode\fR on either node, it retrieves the value
 197 of the global \fBwhizzy-mode\fR property ("on"). If the driver looks up the
 198 \fBdebug-level\fR property on the first node, it retrieves the value of the
 199 \fBdebug-level\fR property on that node (1). Looking up the same property on
 200 the second node retrieves the value of the global \fBdebug-level\fR property
 201 (3).
 202 
 203 .SH SEE ALSO

 204 .LP
 205 \fBadd_drv\fR(1M), \fBpci\fR(4), \fBpseudo\fR(4), \fBsbus\fR(4), \fBscsi\fR(4),
 206 \fBprobe\fR(9E), \fBddi_getlongprop\fR(9F), \fBddi_getprop\fR(9F),
 207 \fBddi_getproplen\fR(9F), \fBddi_prop_get_int\fR(9F),
 208 \fBddi_prop_lookup\fR(9F), \fBddi_prop_op\fR(9F)
 209 .sp
 210 .LP
 211 \fIWriting Device Drivers\fR
 212 .SH WARNINGS

 213 .LP
 214 To avoid namespace collisions between multiple driver vendors, it is strongly
 215 recommended that the \fIname\fR property of the driver should begin with a
 216 vendor-unique string. A reasonably compact and unique choice is the vendor
 217 over-the-counter stock symbol.
 218 .SH NOTES

 219 .LP
 220 The \fBupdate_drv\fR(1M) command should be used to prompt the kernel to reread
 221 \fBdriver.conf\fR files.