Attachment 51155 Details for Bug 77774 – cont_arch.diff

[patch] cont_arch.diff

cont_arch.diff (text/plain), 8.31 KB, created by Joel Dahl on 2005-02-20 13:20:00 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Joel Dahl

Created: 2005-02-20 13:20:00 UTC

Size: 8.31 KB

patch

obsolete

>Index: pccard/chapter.sgml
>===================================================================
>RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.sgml,v
>retrieving revision 1.9
>diff -u -r1.9 chapter.sgml
>--- pccard/chapter.sgml	11 Apr 2004 08:38:42 -0000	1.9
>+++ pccard/chapter.sgml	20 Feb 2005 12:51:09 -0000
>@@ -70,7 +70,7 @@
>       <para>Finally, some really low end devices do not contain
>         manufacturer identification at all.  These devices require
>         that one matches them using the human readable CIS strings.
>-        While it would be nice if we didn't need this method as a
>+        While it would be nice if we did not need this method as a
>         fallback, it is necessary for some very low end CD-ROM players
>         that are quite popular.  This method should generally be
>         avoided, but a number of devices are listed in this section
>@@ -89,7 +89,7 @@
>         them.  This section is sorted in numerical order.  The next
>         section has all of the products that are used by these
>         vendors, along with their product ID numbers and a description
>-        string.  The description string typically isn't used (instead
>+        string.  The description string typically is not used (instead
>         we set the device's description based on the human readable
>         CIS, even if we match on the numeric version).  These two
>         sections are then repeated for those devices that use the
>@@ -112,16 +112,16 @@
>         that NETGEAR purchased cards from and the author of support
>         for those cards was unaware at the time that Netgear was using
>         someone else's id.  These entries are fairly straightforward.
>-        There's the vendor keyword used to denote the kind of line
>-        that this is.  There's the name of the vendor.  This name will
>+        There is the vendor keyword used to denote the kind of line
>+        that this is.  There is the name of the vendor.  This name will
>         be repeated later in the pccarddevs file, as well as used in
>         the driver's match tables, so keep it short and a valid C
>-        identifier.  There's a numeric ID, in hex, for the
>+        identifier.  There is a numeric ID, in hex, for the
>         manufacturer.  Do not add IDs of the form
>         <literal>0xffffffff</literal> or <literal>0xffff</literal>
>         because these are reserved ids (the former is 'no id set'
>         while the latter is sometimes seen in extremely poor quality
>-        cards to try to indicate 'none).  Finally there's a string
>+        cards to try to indicate 'none).  Finally there is a string
>         description of the company that makes the card.  This string
>         is not used in FreeBSD for anything but commentary
>         purposes.</para>
>@@ -139,10 +139,10 @@
>         product keyword.  Then there is the vendor name, repeated from
>         above.  This is followed by the product name, which is used by
>         the driver and should be a valid C identifier, but may also
>-        start with a number.  There's then the product id for this
>-        card, in hex.  As with the vendors, there's the same
>+        start with a number.  There is then the product id for this
>+        card, in hex.  As with the vendors, there is the same
>         convention for <literal>0xffffffff</literal> and
>-        <literal>0xffff</literal>.  Finally, there's a string
>+        <literal>0xffff</literal>.  Finally, there is a string
>         description of the device itself.  This string typically is
>         not used in FreeBSD, since FreeBSD's pccard bus driver will
>         construct a string from the human readable CIS entries, but it
>@@ -176,9 +176,9 @@
>         strings are filtered by the program that generates
>         <filename>pccarddevs.h</filename> to replace &amp;sp with a
>         real space.  NULL entries mean that that part of the entry
>-        should be ignored.  In the example I've picked, there's a bad
>-        entry.  It shouldn't contain the version number in it unless
>-        that's critical for the operation of the card.  Sometimes
>+        should be ignored.  In the example I have picked, there is a bad
>+        entry.  It should not contain the version number in it unless
>+        that is critical for the operation of the card.  Sometimes
>         vendors will have many different versions of the card in the
>         field that all work, in which case that information only makes
>         it harder for someone with a similar card to use it with
>@@ -226,7 +226,7 @@
> }</programlisting>
> 
>       <para>Here we have a simple pccard probe routine that matches a
>-        few devices.  As stated above, the name may vary (if it isn't
>+        few devices.  As stated above, the name may vary (if it is not
>         <function>foo_pccard_probe()</function> it will be
>         <function>foo_pccard_match()</function>).  The function
>         <function>pccard_product_lookup()</function> is a generalized
>@@ -268,7 +268,7 @@
>         First, one must obtain the identification information from the
>         device.  The easiest way to do this is to insert the device
>         into a PC Card or CF slot and issue <command>devinfo
>-        -v</command>.  You'll likely see something like:</para>
>+        -v</command>.  You will likely see something like:</para>
> 
> <programlisting>        cbb1 pnpinfo vendor=0x104c device=0xac51 subvendor=0x1265 subdevice=0x0300 class=0x060700 at slot=10 function=1
>           cardbus1
>@@ -288,7 +288,7 @@
> 
> <programlisting>vendor BUFFALO			0x026f	BUFFALO (Melco Corporation)</programlisting>
> 
>-      <para>so we're good there.  Looking for an entry for this card,
>+      <para>so we are good there.  Looking for an entry for this card,
>         we do not find one.  Instead we find:</para>
> 
> <programlisting>/* BUFFALO */
>@@ -323,14 +323,14 @@
> 	{ NULL }
> };</programlisting>
> 
>-      <para>Note that I've included a '<literal>+</literal>' in the
>+      <para>Note that I have included a '<literal>+</literal>' in the
>         line before the line that I added, but that is simply to
>         highlight the line.  Do not add it to the actual driver.  Once
>-        you've added the line, you can recompile your kernel or module
>+        you have added the line, you can recompile your kernel or module
>         and try to see if it recognizes the device.  If it does and
>-        works, please submit a patch.  If it doesn't work, please
>+        works, please submit a patch.  If it does not work, please
>         figure out what is needed to make it work and submit a patch.
>-        If it didn't recognize it at all, you have done something
>+        If it did not recognize it at all, you have done something
>         wrong and should recheck each step.</para>
> 
>       <para>If you are a FreeBSD src committer, and everything appears
>@@ -352,11 +352,11 @@
>       <para>Many people send entries for new devices to the author
>         directly.  Please do not do this.  Please submit them as a PR
>         and send the author the PR number for his records.  This makes
>-        sure that entries aren't lost.  When submitting a PR, it is
>+        sure that entries are not lost.  When submitting a PR, it is
>         unnecessary to include the <filename>pccardevs.h</filename>
>         diffs in the patch, since those will be regenerated.  It is
>         necessary to include a description of the device, as well as
>-        the patches to the client driver.  If you don't know the name,
>+        the patches to the client driver.  If you do not know the name,
>         use OEM99 as the name, and the author will adjust OEM99
>         accordingly after investigation.  Committers should not commit
>         OEM99, but instead find the highest OEM entry and commit one
>Index: sound/chapter.sgml
>===================================================================
>RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/arch-handbook/sound/chapter.sgml,v
>retrieving revision 1.7
>diff -u -r1.7 chapter.sgml
>--- sound/chapter.sgml	6 Aug 2003 23:48:03 -0000	1.7
>+++ sound/chapter.sgml	20 Feb 2005 12:58:52 -0000
>@@ -594,7 +594,7 @@
>           </callout>
> 
>           <callout arearefs="co-mxset-return">
>-            <para>As the hardware levels probably won't match the
>+            <para>As the hardware levels probably will not match the
>               input scale, and some rounding will occur, the routine
>               returns the actual level values (in range 0-100) as
>               shown.</para>

Actions: View | Diff

Attachments on bug 77774: 51155