9842 man page typos and spelling

          --- old/usr/src/man/man4/driver.conf.4
          +++ new/usr/src/man/man4/driver.conf.4
   1    1  '\" te
   2    2  .\"  Copyright (c) 2005, Sun Microsystems, Inc. All Rights Reserved
   3    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    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    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"
        6 +.TH DRIVER.CONF 4 "Sep 16, 2018"
   7    7  .SH NAME
   8    8  driver.conf \- driver configuration files
   9    9  .SH SYNOPSIS
  10   10  .LP
  11   11  .nf
  12   12  \fBdriver.conf\fR
  13   13  .fi
  14   14  
  15   15  .SH DESCRIPTION
  16      -.sp
  17   16  .LP
  18   17  Driver configuration files provide values for device properties. The values
  19   18  override values provided by the devices themselves. Most modern devices provide
  20   19  enough property values to make a driver configuration file unnecessary.
  21   20  .sp
  22   21  .LP
  23   22  The system associates a driver with its configuration file by name. For
  24   23  example, a driver in \fB/usr/kernel/drv\fR called \fBwombat\fR has the driver
  25   24  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
       25 +associated with it. On systems that support 64-bit drivers, the driver
  27   26  configuration file should be placed in the directory in which the 32-bit driver
  28   27  is (or would be) located, even if only a 64-bit version is provided. For
  29   28  example, a 64-bit driver stored in \fB/usr/kernel/drv/sparcv9\fR stores its
  30   29  driver configuration file in \fB/usr/kernel/drv\fR.
  31   30  .sp
  32   31  .LP
  33   32  The value of the \fBname\fR property is the node name. In a \fBdriver.conf\fR
  34   33  file, where the generic node name and \fBcompatible\fR property associated with
  35   34  a self-identifying devices are typically not used, the node name must be a
  36   35  binding name. The binding name is the name chosen by the system to bind a

  37   36  driver to the device. The binding name is either an alias associated with the
  38   37  driver established by \fBadd_drv\fR(1M) or the driver name itself.
  39   38  .sp
  40   39  .LP
  41   40  The syntax of a single entry in a driver configuration file takes one of three
  42   41  forms:
  43   42  .sp
  44   43  .in +2
  45   44  .nf
  46   45  \fBname\fR="\fInode name\fR" \fBparent\fR="\fIparent name\fR" [\fIproperty-name=value\fR ...]\fB;\fR
  47   46  .fi
  48   47  .in -2
  49   48  
  50   49  .sp
  51   50  .LP
  52   51  In this form, the parent name can be either the binding name of the parent
  53   52  nexus driver or a specific full pathname, beginning with a slash (\fB/\fR)
  54   53  character, identifying a specific instance of a parent bus. If a binding name
  55   54  is used then all parent nodes bound to that driver match. A generic name (for
  56   55  example, \fBpci\fR) is not a valid binding name even though it can appear in
  57   56  the full pathname of all intended parents.
  58   57  .sp
  59   58  .LP
  60   59  Alternatively, the parent can be specified by the type of interface it presents
  61   60  to its children.
  62   61  .sp
  63   62  .in +2
  64   63  .nf
  65   64  \fBname\fR="\fInode name\fR" \fBclass\fR="\fIclass name\fR" [\fIproperty-name=value\fR ...]\fB;\fR
  66   65  .fi
  67   66  .in -2
  68   67  
  69   68  .sp
  70   69  .LP
  71   70  For example, the driver for the \fBSCSI\fR host adapter can have different
  72   71  names on different platforms, but the target drivers can use class \fBscsi\fR
  73   72  to insulate themselves from these differences.
  74   73  .sp
  75   74  .LP
  76   75  Entries of either form above correspond to a device information (\fBdevinfo\fR)
  77   76  node in the kernel device tree. Each node has a \fIname\fR which is usually the
  78   77  name of the driver, and a \fIparent\fR name which is the name of the parent
  79   78  \fBdevinfo\fR node to which it will be connected. Any number of name-value
  80   79  pairs can be specified to create properties on the prototype \fBdevinfo\fR
  81   80  node. These properties can be retrieved using the DDI property interfaces (for
  82   81  example, \fBddi_prop_get_int\fR(9F) and \fBddi_prop_lookup\fR(9F)). The
  83   82  prototype \fBdevinfo\fR node specification must be terminated with a semicolon
  84   83  (\fB;\fR).
  85   84  .sp
  86   85  .LP
  87   86  The third form of an entry is simply a list of properties.
  88   87  .sp
  89   88  .in +2
  90   89  .nf
  91   90  [\fIproperty-name=value\fR ...]\fB;\fR
  92   91  .fi
  93   92  .in -2
  94   93  .sp
  95   94  
  96   95  .sp
  97   96  .LP
  98   97  A property created in this way is treated as global to the driver. It can be
  99   98  overridden by a property with the same name on a particular \fBdevinfo\fR node,
 100   99  either by creating one explicitly on the prototype node in the driver.conf file
 101  100  or by the driver.
 102  101  .sp
 103  102  .LP
 104  103  Items are separated by any number of newlines, \fBSPACE\fR or \fBTAB\fR
 105  104  characters.
 106  105  .sp
 107  106  .LP
 108  107  The configuration file can contain several entries to specify different device
 109  108  configurations and parent nodes. The system can call the driver for each
 110  109  possible prototype \fBdevinfo\fR node, and it is generally the responsibility
 111  110  of the drivers \fBprobe\fR(9E) routine to determine if the hardware described
 112  111  by the prototype \fBdevinfo\fR node is really present.
 113  112  .sp
 114  113  .LP
 115  114  Property names must not violate the naming conventions for Open Boot PROM
 116  115  properties or for IEEE 1275 names. In particular, property names should contain
 117  116  only printable characters, and should not contain at-sign (\fB@\fR), slash
 118  117  (\fB/\fR), backslash (\fB\e\fR), colon (\fB:\fR), or square brackets
 119  118  (\fB[]\fR). Property values can be decimal integers or strings delimited by
 120  119  double quotes (\fB"\fR). Hexadecimal integers can be constructed by prefixing
 121  120  the digits with \fB0x\fR.
 122  121  .sp
 123  122  .LP
 124  123  A comma separated list of integers can be used to construct properties whose
 125  124  value is an integer array. The value of such properties can be retrieved inside
 126  125  the driver using \fBddi_prop_lookup_int_array\fR(9F).
 127  126  .sp
 128  127  .LP
 129  128  Comments are specified by placing a \fB#\fR character at the beginning of the
 130  129  comment string, the comment string extends for the rest of the line.
 131  130  .SH EXAMPLES
 132  131  .LP
 133  132  \fBExample 1 \fRConfiguration File for a PCI Bus Frame Buffer
 134  133  .sp
 135  134  .LP
 136  135  The following is an example of a configuration file called
 137  136  \fBACME,simple.conf\fR for a \fBPCI\fR bus frame buffer called
 138  137  \fBACME,simple\fR.
 139  138  
 140  139  .sp
 141  140  .in +2
 142  141  .nf
 143  142  #
 144  143  # Copyright (c) 1993, by ACME Fictitious Devices, Inc.
 145  144  #
 146  145  #ident  "@(#)ACME,simple.conf   1.3     1999/09/09"
 147  146  
 148  147  name="ACME,simple" class="pci" unit-address="3,1"
 149  148          debug-mode=12;
 150  149  .fi
 151  150  .in -2
 152  151  
 153  152  .sp
 154  153  .LP
 155  154  This example creates a prototype \fBdevinfo\fR node called \fBACME,simple\fR
 156  155  under all parent nodes of class \fBpci\fR. The node has device and function
 157  156  numbers of 3 and 1, respectively; the property \fBdebug-mode\fR is provided for
 158  157  all instances of the driver.
 159  158  
 160  159  .LP
 161  160  \fBExample 2 \fRConfiguration File for a Pseudo Device Driver
 162  161  .sp
 163  162  .LP
 164  163  The following is an example of a configuration file called
 165  164  \fBACME,example.conf\fR for a pseudo device driver called \fBACME,example\fR.
 166  165  
 167  166  .sp
 168  167  .in +2
 169  168  .nf
 170  169  #
 171  170  # Copyright (c) 1993, ACME Fictitious Devices, Inc.
 172  171  #
 173  172  #ident  "@(#)ACME,example.conf  1.2   93/09/09"
 174  173  name="ACME,example" parent="pseudo" instance=0
 175  174      debug-level=1;
 176  175  
 177  176  name="ACME,example" parent="pseudo" instance=1;
 178  177  
 179  178  whizzy-mode="on";
 180  179  debug-level=3;
 181  180  .fi
 182  181  .in -2
 183  182  
 184  183  .sp
 185  184  .LP
 186  185  This creates two \fBdevinfo\fR nodes called \fBACME,example\fR which attaches
 187  186  below the \fBpseudo\fR node in the kernel device tree. The \fBinstance\fR
 188  187  property is only interpreted by the \fBpseudo\fR node, see \fBpseudo\fR(4) for
 189  188  further details. A property called \fBdebug-level\fR is created on the first
 190  189  \fBdevinfo\fR node which has the value 1. The \fBexample\fR driver is able to
 191  190  fetch the value of this property using \fBddi_prop_get_int\fR(9F).
 192  191  
 193  192  .sp
 194  193  .LP

 195  194  Two global driver properties are created, \fBwhizzy-mode\fR (which has the
 196  195  string value "on") and \fBdebug-level\fR (which has the value 3). If the driver
 197  196  looks up the property \fBwhizzy-mode\fR on either node, it retrieves the value
 198  197  of the global \fBwhizzy-mode\fR property ("on"). If the driver looks up the
 199  198  \fBdebug-level\fR property on the first node, it retrieves the value of the
 200  199  \fBdebug-level\fR property on that node (1). Looking up the same property on
 201  200  the second node retrieves the value of the global \fBdebug-level\fR property
 202  201  (3).
 203  202  
 204  203  .SH SEE ALSO
 205      -.sp
 206  204  .LP
 207  205  \fBadd_drv\fR(1M), \fBpci\fR(4), \fBpseudo\fR(4), \fBsbus\fR(4), \fBscsi\fR(4),
 208  206  \fBprobe\fR(9E), \fBddi_getlongprop\fR(9F), \fBddi_getprop\fR(9F),
 209  207  \fBddi_getproplen\fR(9F), \fBddi_prop_get_int\fR(9F),
 210  208  \fBddi_prop_lookup\fR(9F), \fBddi_prop_op\fR(9F)
 211  209  .sp
 212  210  .LP
 213  211  \fIWriting Device Drivers\fR
 214  212  .SH WARNINGS
 215      -.sp
 216  213  .LP
 217  214  To avoid namespace collisions between multiple driver vendors, it is strongly
 218  215  recommended that the \fIname\fR property of the driver should begin with a
 219  216  vendor-unique string. A reasonably compact and unique choice is the vendor
 220  217  over-the-counter stock symbol.
 221  218  .SH NOTES
 222      -.sp
 223  219  .LP
 224  220  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.
      221 +\fBdriver.conf\fR files.
    

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX