o Merge with Linux 2.1.99.

 o Fix ancient bug in the ELF loader making ldd crash.
 o Fix ancient bug in the keyboard code for SGI, SNI and Jazz.

11 files changed, 86 insertions, 86 deletions

diff --git a/Documentation/cdrom/aztcd b/Documentation/cdrom/aztcd
index 0056ce914..fa3081cfb 100644
--- a/Documentation/cdrom/aztcd
+++ b/Documentation/cdrom/aztcd
@@ -202,7 +202,7 @@ configured and mail me (see 6.) the appropriate information.
 5.1 MULTISESSION SUPPORT
 Multisession support for CD's still is a myth. I implemented and tested a basic
 support for multisession and XA CDs, but I still have not enough CDs and appli-
-cations to test it rigourously. So if you'd like to help me, please contact me
+cations to test it rigorously. So if you'd like to help me, please contact me
 (Email address see below). As of version 1.4 and newer you can enable the 
 multisession support in aztcd.h by setting AZT_MULTISESSION to 1. Doing so 
 will cause the ISO9660-filesystem to deal with multisession CDs, ie. redirect 
@@ -375,7 +375,7 @@ If this still does not help,
  the finite state machine in azt_poll(). The most important are the status
  messages, look how they are defined and try to understand, if they make
  sense in the context where they appear. With a CD-ROM inserted the status 
- should always be 8, except in aztcd_open(). Try to open the tray, insert a
+ should always be 8, except in aztcd_open(). Try to open the tray, insert an
  audio disk, insert no disk or reinsert the CD-ROM and check, if the status
  bits change accordingly. The status bits are the most likely point, where 
  the drive manufacturers may implement changes.
@@ -400,7 +400,7 @@ following:
  that the ACMD_SOFT_RESET is issued in any case, by substituting the
  if-statement 'if ( ...=AFL_OP_OK)' by 'if (1)'.
 
-If you succeed, please mail may the exact version string of your drive and
+If you succeed, please mail me the exact version string of your drive and
 the code modifications, you have made together with a short explanation.
 If you don't succeed, you may mail me the output of the debugging messages.
 But remember, they are only useful, if they are exact and complete and you
@@ -439,13 +439,13 @@ d) I did not get information about changing drive mode. So I doubt, that the
 code around function azt_poll() case AZT_S_MODE does work. In my test I have
 not been able to switch to reading in raw mode. For reading raw mode, Aztech
 uses a different command than for cooked mode, which I only have implemen-
-ted in the ioctl-section but not in the section which is used by the ISO9660- 
+ted in the ioctl-section but not in the section which is used by the ISO9660. 
 
 The driver was developed on an AST PC with Intel 486/DX2, 8MB RAM, 340MB IDE 
 hard disk and on an AST PC with Intel Pentium 60MHz, 16MB RAM, 520MB IDE 
 running Linux kernel version 1.0.9 from the LST 1.8 Distribution. The kernel 
 was compiled with gcc.2.5.8. My CD-ROM drive is an Aztech CDA268-01A. My
-drive says, that it has Firmware Version AZT26801A1.3. It came with a ISA-bus
+drive says, that it has Firmware Version AZT26801A1.3. It came with an ISA-bus
 interface card and works with polled I/O without DMA and without interrupts.
 The code for all other drives was 'remote' tested and debugged by a number of 
 volunteers on the Internet.
@@ -508,7 +508,7 @@ You have to set the correct permissions for cdplay *and* for /dev/mcd0 or
 /dev/aztcd0 in order to use it. Remember, that you should not have /dev/cdrom 
 mounted, when you're playing audio CDs. 
 
-This program is just a hack for testing the ioctl-functions in aztcd.c, I will 
+This program is just a hack for testing the ioctl-functions in aztcd.c. I will 
 not maintain it, so if you run into problems, discard it or have a look into 
 the source code 'cdplay.c'. The program does only contain a minimum of user 
 protection and input error detection. If you use the commands in the wrong 
@@ -517,11 +517,11 @@ or even hang your machine. If you get STEN_LOW, STEN_LOW_WAIT or segment violati
 error messages when using cdplay, after that, the system might not be stable 
 any more, so you'd better reboot. As the ioctl-functions run in kernel mode,
 most normal Linux-multitasking protection features do not work. By using
-uninitialized 'wild' pointers etc., it is easy to write to other users data and
-program areas, destroy kernel tables etc.. So if you experiment with ioctls
+uninitialized 'wild' pointers etc., it is easy to write to other users' data 
+and program areas, destroy kernel tables etc.. So if you experiment with ioctls
 as always when you are doing systems programming and kernel hacking, you
 should have a backup copy of your system in a safe place (and you also
-should try before, how to restore from a backup copy)!
+should try restoring from a backup copy first)!
 
 A reworked and improved version called 'cdtester.c', which has yet more
 features for testing CDROM-drives can be found in
diff --git a/Documentation/cdrom/cdrom-standard.tex b/Documentation/cdrom/cdrom-standard.tex
index 1db560b15..6d6e74bdc 100644
--- a/Documentation/cdrom/cdrom-standard.tex
+++ b/Documentation/cdrom/cdrom-standard.tex
@@ -45,15 +45,15 @@ presumably
 \end{itemize}
 The openness of \linux, and the many different types of available
 hardware has allowed \linux\ to support many different hardware devices.
-Unfortunatly, the very openness that has allowed \linux\ to support
+Unfortunately, the very openness that has allowed \linux\ to support
 all these different devices has also allowed the behavior of each
 device driver to differ significantly from one device to another.
-This divergence of behavior has been the very significant for \cdrom\
+This divergence of behavior has been very significant for \cdrom\
 devices; the way a particular drive reacts to a `standard' $ioctl()$
 call varies greatly from one device driver to another. To avoid making
 their drivers totally inconsistent, the writers of \linux\ \cdrom\
 drivers generally created new device drivers by understanding, copying,
-and then changing an existing one. Unfortunatly, this practice did not
+and then changing an existing one. Unfortunately, this practice did not
 maintain uniform behavior across all the \linux\ \cdrom\ drivers. 
 
 This document describes an effort to establish Uniform behavior across
@@ -85,7 +85,7 @@ which was expressed through \cdromh, it appeared to be a rather wild
 set of commands and data formats.\footnote{I cannot recollect what
 kernel version I looked at, then, presumably 1.2.13 and 1.3.34---the
 latest kernel that I was indirectly involved in.} It seemed that many
-features of the software interface had been added to accomodate the
+features of the software interface had been added to accommodate the
 capabilities of a particular drive, in an {\fo ad hoc\/} manner. More
 importantly, it appeared that the behavior of the `standard' commands
 was different for most of the different drivers: \eg, some drivers
@@ -93,7 +93,7 @@ close the tray if an $open()$ call occurs when the tray is open, while
 others do not. Some drivers lock the door upon opening the device, to
 prevent an incoherent file system, but others don't, to allow software
 ejection. Undoubtedly, the capabilities of the different drives vary,
-but even when two drives have the same capability their driver's
+but even when two drives have the same capability their drivers'
 behavior was usually different.
 
 I decided to start a discussion on how to make all the \linux\ \cdrom\
@@ -109,7 +109,7 @@ hardware will allow).
 
 The goal of the \UCD\ is {\em not\/} to alienate driver developers who
 have not yet taken steps to support this effort. The goal of \UCD\ is
-simply is give people writing application programs for \cdrom\ drives
+simply to give people writing application programs for \cdrom\ drives
 {\em one\/} \linux\ \cdrom\ interface with consistent behavior for all
 \cdrom\ devices. In addition, this also provides a consistent interface
 between the low-level device driver code and the \linux\ kernel. Care
@@ -147,14 +147,14 @@ software-level, that separates the $ioctl()$ and $open()$ implementation
 from the actual hardware implementation. Note that this effort has
 made few changes which will effect a user's application programs. The
 greatest change involved moving the contents of the various low-level
-\cdrom\ driver's header files to the kernel's cdrom directory. This was
+\cdrom\ drivers' header files to the kernel's cdrom directory. This was
 done to help ensure that the user is only presented with only one cdrom
 interface, the interface defined in \cdromh.
 
 \cdrom\ drives are specific enough (\ie, different from other
 block-devices such as floppy or hard disc drives), to define a set
 of common {\em \cdrom\ device operations}, $<cdrom-device>_dops$.
-These operations are different than the classical block-device file
+These operations are different from the classical block-device file
 operations, $<block-device>_fops$.
 
 The routines for the \UCD\ interface level are implemented in the file
@@ -267,7 +267,7 @@ difficult in computer programming.
 
 Note that most functions have fewer parameters than their
 $blkdev_fops$ counterparts. This is because very little of the
-information in the structures $inode$ and $file$ are used. For most
+information in the structures $inode$ and $file$ is used. For most
 drivers, the main parameter is the $struct$ $cdrom_device_info$, from
 which the major and minor number can be extracted. (Most low-level
 \cdrom\ drivers don't even look at the major and minor number though,
@@ -291,7 +291,7 @@ struct& cdrom_device_info\ \{ \hidewidth\cr
 \noalign{\medskip}
   &int& options : 30;& options flags \cr
   &long& mc_flags : 2;& media-change buffer flags \cr
-  & int& use_count;& number of times devices is opened\cr
+  & int& use_count;& number of times device is opened\cr
 \}\cr
 }$$
 Using this $struct$, a linked list of the registered minor devices is
@@ -312,23 +312,23 @@ registration.
 A few registers contain variables local to the \cdrom\ drive. The
 flags $options$ are used to specify how the general \cdrom\ routines
 should behave. These various flags registers should provide enough
-flexibility to adapt to the different user's wishes (and {\em not\/} the
+flexibility to adapt to the different users' wishes (and {\em not\/} the
 `arbitrary' wishes of the author of the low-level device driver, as is
 the case in the old scheme). The register $mc_flags$ is used to buffer
 the information from $media_changed()$ to two separate queues. Other
-data that is specific to minor drive, can be accessed through $handle$,
+data that is specific to a minor drive, can be accessed through $handle$,
 which can point to a data structure specific to the low-level driver.
 The fields $use_count$, $next$, $options$ and $mc_flags$ need not be
 initialized.
 
-The intermediate software layer that \cdromc\ forms will performs some
+The intermediate software layer that \cdromc\ forms will perform some
 additional bookkeeping. The use count of the device (the number of
 processes that have the device opened) is registered in $use_count$. The
 function $cdrom_ioctl()$ will verify the appropriate user-memory regions
 for read and write, and in case a location on the CD is transferred,
 it will `sanitize' the format by making requests to the low-level
 drivers in a standard format, and translating all formats between the
-user-software and low level drivers. This relieves much of the drivers
+user-software and low level drivers. This relieves much of the drivers'
 memory checking and format checking and translation. Also, the necessary
 structures will be declared on the program stack.
 
@@ -469,7 +469,7 @@ addressing mode), whatever the calling software requested. But
 sanitization goes even further: the low-level implementation may
 return the requested information in $CDROM_MSF$ format if it wishes so
 (setting the $ms_info\rightarrow addr_format$ field appropriately, of
-course) and the routines in \cdromc\ will make the transform if
+course) and the routines in \cdromc\ will make the transformation if
 necessary. The return value is 0 upon success.
 
 \subsection{$Int\ get_mcn(struct\ cdrom_device_info * cdi, struct\
@@ -498,7 +498,7 @@ driver to time out.
 Some of the \cdrom-$ioctl$s defined in \cdromh\ can be
 implemented by the routines described above, and hence the function
 $cdrom_ioctl$ will use those. However, most $ioctl$s deal with
-audio-control. We have decided to leave these accessed through a
+audio-control. We have decided to leave these to be accessed through a
 single function, repeating the arguments $cmd$ and $arg$. Note that
 the latter is of type $void*{}$, rather than $unsigned\ long\
 int$. The routine $cdrom_ioctl()$ does do some useful things,
@@ -532,7 +532,7 @@ problem here could be the fact that audio-frames are 2352 bytes long,
 so either the audio-file-system should ask for 75264 bytes at once
 (the least common multiple of 512 and 2352), or the drivers should
 bend their backs to cope with this incoherence (to which I would be
-opposed).  Furthermore, it it very difficult for the hardware to find
+opposed).  Furthermore, it is very difficult for the hardware to find
 the exact frame boundaries, since there are no synchronization headers
 in audio frames.  Once these issues are resolved, this code should be
 standardized in \cdromc.
@@ -562,7 +562,7 @@ CDC_LOCK& can lock and unlock the door\cr
 CDC_SELECT_SPEED& can select speed, in units of $\sim$150\,kB/s\cr
 CDC_SELECT_DISC& drive is juke-box\cr
 CDC_MULTI_SESSION& can read sessions $>\rm1$\cr
-CDC_MCN& can read Medium Catalog Number\cr
+CDC_MCN& can read Media Catalog Number\cr
 CDC_MEDIA_CHANGED& can report if disc has changed\cr
 CDC_PLAY_AUDIO& can perform audio-functions (play, pause, etc)\cr
 CDC_RESET& hard reset device\cr
@@ -724,12 +724,12 @@ modes of operation can be set:
 \begin{description}
 \item[$CDO_AUTO_CLOSE \mathrel| CDO_USE_FFLAGS \mathrel| CDO_LOCK$] This
 is the default setting. (With $CDO_CHECK_TYPE$ it will be better, in the
-future.) If the device is not yet opened by any other process, and it
+future.) If the device is not yet opened by any other process, and if
 the device is being opened for data ($O_NONBLOCK$ is not set) and the
 tray is found to be open, an attempt to close the tray is made. Then,
 it is verified that a disc is in the drive and, if $CDO_CHECK_TYPE$ is
 set, that it contains tracks of type `data mode 1.' Only if all tests
-are passed, the return value is zero. The door is locked to prevent file
+are passed is the return value zero. The door is locked to prevent file
 system corruption. If the drive is opened for audio ($O_NONBLOCK$ is
 set), no actions are taken and a value of 0 will be returned. 
 \item[$CDO_AUTO_CLOSE \mathrel| CDO_AUTO_EJECT \mathrel| CDO_LOCK$] This
@@ -745,7 +745,7 @@ driver scheme and option flag interpretation.
 \newsection{Description of routines in \cdromc}
 
 Only a few routines in \cdromc\ are exported to the drivers. In this
-newsection we will discuss these, as well as the functions that `take
+new section we will discuss these, as well as the functions that `take
 over' the \cdrom\ interface to the kernel. The header file belonging
 to \cdromc\ is called \cdromh. Formerly, some of the contents of this
 file were placed in the file {\tt {ucdrom.h}}, but this file has now been
@@ -833,7 +833,7 @@ not masked:
 \item[CDROMEJECT_SW] If $arg\not=0$, set behavior to auto-close (close
 tray on first open) and auto-eject (eject on last release), otherwise
 set behavior to non-moving on $open()$ and $release()$ calls.
-\item[CDROM_GET_MCN or CDROM_GET_UPC] Get the Medium Catalog Number from a CD.
+\item[CDROM_GET_MCN or CDROM_GET_UPC] Get the Media Catalog Number from a CD.
 \end{description}
 
 \subsubsection{$Ioctl$s routed through $audio_ioctl()$}
@@ -878,7 +878,7 @@ the current flags.
 \item[CDROM_SELECT_SPEED] Select head-rate speed of disc specified as
   by $arg$ in units of standard cdrom speed (176\,kB/sec raw data or
   150\,kB/sec file system data). The value 0 means `auto-select', \ie,
-  play audio discs at real time and data disc at maximum speed. The value
+  play audio discs at real time and data discs at maximum speed. The value
   $arg$ is checked against the maximum head rate of the drive found in the
   $cdrom_dops$.
 \item[CDROM_SELECT_DISC] Select disc numbered $arg$ from a juke-box.
@@ -887,18 +887,18 @@ the current flags.
 \item[CDROM_MEDIA_CHANGED] Returns 1 if a disc has been changed since
   the last call. Note that calls to $cdrom_media_changed$ by the VFS
   are treated by an independent queue, so both mechanisms will detect
-  a media change once. For Juke-boxes, an extra argument $arg$
+  a media change once. For juke-boxes, an extra argument $arg$
   specifies the slot for which the information is given. The special
   value $CDSL_CURRENT$ requests that information about the currently
-  selected slot is returned.
+  selected slot be returned.
 \item[CDROM_DRIVE_STATUS] Returns the status of the drive by a call to
   $drive_status()$. Return values are defined in section~\ref{drive
    status}. Note that this call doesn't return information on the
   current playing activity of the drive; this can be polled through an
-  $ioctl$ call to $CDROMSUBCHNL$. For Juke-boxes, an extra argument
+  $ioctl$ call to $CDROMSUBCHNL$. For juke-boxes, an extra argument
   $arg$ specifies the slot for which (possibly limited) information is
   given. The special value $CDSL_CURRENT$ requests that information
-  about the currently selected slot is returned.
+  about the currently selected slot be returned.
 \item[CDROM_DISC_STATUS] Returns the type of the disc currently in the
   drive.  It should be viewed as a complement to $CDROM_DRIVE_STATUS$.
   This $ioctl$ can provide \emph {some} information about the current
@@ -996,7 +996,7 @@ $\&<your-drive>_fops$ to $\&cdrom_fops$.
 \item Change the prototypes of $<device>_open()$ and
   $<device>_release()$, and remove any strategic code (\ie, tray
   movement, door locking, etc.).
-\item Try to recompile the drivers. We advice you to use modules, both
+\item Try to recompile the drivers. We advise you to use modules, both
   for {\tt {cdrom.o}} and your driver, as debugging is much easier this
   way.
 \end{enumerate} 
@@ -1004,7 +1004,7 @@ $\&<your-drive>_fops$ to $\&cdrom_fops$.
 \newsection{Thanks}
 
 Thanks to all the people involved.  First, Erik Andersen, who has
-taken over the torch in maintaining \cdromc\ and integrating many
+taken over the torch in maintaining \cdromc\ and integrating much
 \cdrom-related code in the 2.1-kernel.  Thanks to Scott Snyder and
 Gerd Knorr, who were the first to implement this interface for SCSI
 and IDE-CD drivers and added many ideas for extension of the data
diff --git a/Documentation/cdrom/cdu31a b/Documentation/cdrom/cdu31a
index 6fa1d4b0f..c0667da09 100644
--- a/Documentation/cdrom/cdu31a
+++ b/Documentation/cdrom/cdu31a
@@ -32,7 +32,7 @@ same card).  They are not software compatible.
 Setting Up the Hardware
 -----------------------
 
-The CDU31A driver in unable to safely tell if an interface card is
+The CDU31A driver is unable to safely tell if an interface card is
 present that it can use because the interface card does not announce
 its presence in any way besides placing 4 I/O locations in memory.  It
 used to just probe memory and attempt commands, but Linus wisely asked
@@ -44,7 +44,7 @@ is, what interrupts are used, and possibly if you are on a PAS-16
 soundcard.
 
 If you have the Sony CDU31A/CDU33A drive interface card, the following
-diagram will help you set it up.  If You have another card, you are on
+diagram will help you set it up.  If you have another card, you are on
 your own.  You need to make sure that the I/O address and interrupt is
 not used by another card in the system.  You will need to know the I/O
 address and interrupt you have set.  Note that use of interrupts is
diff --git a/Documentation/cdrom/cm206 b/Documentation/cdrom/cm206
index 1aebd7e5d..bc4f9e656 100644
--- a/Documentation/cdrom/cm206
+++ b/Documentation/cdrom/cm206
@@ -14,7 +14,7 @@ Features since version 0.33
 - Full audio support, that is, both  workman, workbone and cdp work
   now reasonably. Reading TOC still takes some time. xmcd has been
   reported to run successfully. 
-- Made auto-probe code a little better, i hope
+- Made auto-probe code a little better, I hope
 
 Features since version 0.28
 ---------------------------
@@ -37,8 +37,8 @@ options:
    Further, you must decide if you are going to specify the base port
    address and the interrupt request line of the adapter card cm260 as
    boot options for (a), module parameters for (b), use automatic
-   probing of these values, or hard-wire your adaptor cards settings
-   into the source code. If you don't care, you can choose for
+   probing of these values, or hard-wire your adaptor card's settings
+   into the source code. If you don't care, you can choose 
    autoprobing, which is the default. In that case you can move on to
    the next step.
 
@@ -48,10 +48,10 @@ Compiling the kernel
 
 	make config
 
-   If you have chosen for option (a), answer yes to CONFIG_CM206 and
+   If you have chosen option (a), answer yes to CONFIG_CM206 and
    CONFIG_ISO9660_FS.
 
-   If you have chosen for option (b), answer yes to CONFIG_MODVERSIONS
+   If you have chosen option (b), answer yes to CONFIG_MODVERSIONS
    and no (!) to CONFIG_CM206 and CONFIG_ISO9660_FS. 
 
 2) then do a 
@@ -64,7 +64,7 @@ Compiling the kernel
 
 Using the driver as a module
 ----------------------------
-If you will only seldomly use the cd-rom driver, you can choose for
+If you will only occasionally use the cd-rom driver, you can choose
 option (b), install as a loadable module. You may have to re-compile
 the module when you upgrade the kernel to a new version. 
 
@@ -84,7 +84,7 @@ line to be used, e.g.
 
 	insmod /usr/src/linux/modules/cm206.o cm206=0x300,11
 
-The order of base port and irq line doesn't matter; you may specify only
+The order of base port and irq line doesn't matter; if you specify only
 one, the other will have the value of the compiled-in default.  You
 may also have to install the file-system module `iso9660.o', if you
 didn't compile that into the kernel. 
@@ -92,17 +92,17 @@ didn't compile that into the kernel.
 
 Using the driver as part of the kernel
 --------------------------------------
-If you have chosen for option a, you can specify the base-port
+If you have chosen option (a), you can specify the base-port
 address and irq on the lilo boot command line, e.g.:
 
 	LILO: linux cm206=0x340,11
 
 This assumes that your linux kernel image keyword is `linux'. 
-If you may specify either IRQ (3--11) or base port (0x300--0x370),
+If you specify either IRQ (3--11) or base port (0x300--0x370),
 auto probing is turned off for both settings, thus setting the 
 other value to the compiled-in default.
 
-Note that you can put these parameters also in the lilo configuration file:
+Note that you can also put these parameters in the lilo configuration file:
 
 # linux config
 image = /vmlinuz
@@ -122,7 +122,7 @@ the defines of CM206_IRQ and CM206_BASE.
 
 Mounting the cdrom
 ------------------
-1) Make sure that there is the right device installed in /dev.
+1) Make sure that the right device is installed in /dev.
 
   	mknod /dev/cm206cd b 32 0
 
@@ -159,7 +159,7 @@ If things don't work
 DISCLAIMER 
 ---------- 
 I cannot guarantee that this driver works, or that the hardware will
-not be harmed, although i consider it most unlikely. 
+not be harmed, although I consider it most unlikely. 
 
 I hope that you'll find this driver in some way useful. 
 
diff --git a/Documentation/cdrom/gscd b/Documentation/cdrom/gscd
index bb25a8c60..560069e2a 100644
--- a/Documentation/cdrom/gscd
+++ b/Documentation/cdrom/gscd
@@ -1,7 +1,7 @@
 	Goldstar R420 CD-Rom device driver README
 
 For all kind of other information about the GoldStar R420 CDROM
-and this Linux device driver is a WWW-URL Page installed:
+and this Linux device driver see the WWW page:
 
         http://linux.rz.fh-hannover.de/~raupach        
 
@@ -44,12 +44,12 @@ Install your new kernel as usual - maybe you do it with 'make zlilo'.
 
 Before you can use the driver, you have to
    mknod /dev/gscd0 b 16 0
-to create the appropriate device file (once for all times).
+to create the appropriate device file (you only need to do this once).
 
 If you use modules, you can try to insert the driver.
 Say: 'insmod /usr/src/linux/modules/gscd.o'
 or:  'insmod /usr/src/linux/modules/gscd.o gscd=<address>'
-The driver should report his results now.
+The driver should report its results.
 
 That's it! Mount a disk, i.e. 'mount -rt iso9660 /dev/gscd0 /cdrom'
 
diff --git a/Documentation/cdrom/ide-cd b/Documentation/cdrom/ide-cd
index ecd498158..744a81407 100644
--- a/Documentation/cdrom/ide-cd
+++ b/Documentation/cdrom/ide-cd
@@ -22,7 +22,7 @@ This driver provides the following features:
  - Reading from data tracks, and mounting iso9660 filesystems.
 
  - Playing audio tracks.  Most of the cdrom player programs floating
-   around should work; i usually use Workman.
+   around should work; I usually use Workman.
 
  - Multisession support.
 
@@ -148,7 +148,7 @@ workbone, cdplayer, etc.).  Lacking anything else, you could use the
 cdtester program in Documentation/cdrom/sbpcd.
 
 On a few drives, you can read digital audio directly using a program
-such as cdda2wav.  The only types of drive which i've heard support
+such as cdda2wav.  The only types of drive which I've heard support
 this are Sony and Toshiba drives.  You will get errors if you try to
 use this function on a drive which does not support it.
 
@@ -189,7 +189,7 @@ CDROM_NBLOCKS_BUFFER
   ioctl.  The default is 8.
 
 TEST
-  This presently enables an additional ioctl which enables a user-mode
+  This currently enables an additional ioctl which enables a user-mode
   program to execute an arbitrary packet command.  See the source for
   details.  This should be left off unless you know what you're doing.
 
@@ -271,7 +271,7 @@ b. Timeout/IRQ errors.
     and 15 for the secondary (0x1f0) interface.)  Also be sure that
     you don't have some other hardware which might be conflicting with
     the IRQ you're using.  Also check the BIOS setup for your system;
-    some have the ability to disable individual IRQ levels, and i've
+    some have the ability to disable individual IRQ levels, and I've
     had one report of a system which was shipped with IRQ 15 disabled
     by default.
 
@@ -282,7 +282,7 @@ b. Timeout/IRQ errors.
   - If you own a Pioneer DR-A24X, you _will_ get nasty error messages 
     on boot such as "irq timeout: status=0x50 { DriveReady SeekComplete }"
     The Pioneer DR-A24X cdrom drives are fairly popular these days.
-    Unfortunatly, these drives seem to become very confused when we perform
+    Unfortunately, these drives seem to become very confused when we perform
     the standard Linux ATA disk drive probe. If you own one of these drives,
     you can bypass the ATA probing which confuses these cdrom drives, by 
     adding `append="hdX=noprobe hdX=cdrom"' to your lilo.conf file and runing 
@@ -377,7 +377,7 @@ f. Data corruption.
 /*
  * cdchange.c  [-v]  <device>  [<slot>]
  *
- * This load a cdrom from a specified slot in a changer, and displays 
+ * This loads a cdrom from a specified slot in a changer, and displays 
  * information about the changer status.  The drive should be unmounted before 
  * using this program.
  *
diff --git a/Documentation/cdrom/isp16 b/Documentation/cdrom/isp16
index 7dcf6f9c9..cc86533ac 100644
--- a/Documentation/cdrom/isp16
+++ b/Documentation/cdrom/isp16
@@ -71,7 +71,7 @@ sound card configuration.
 The syntax of the command line does not allow the specification of
 irq when there's nothing specified for the base address and no
 specification of dma when there is no specification of irq.
-The value 'nosip16' for drive_type, which may be used as the first
+The value 'noisp16' for drive_type, which may be used as the first
 non-integer option value (e.g. 'isp16=noisp16'), makes sure that probing
 for and subsequent configuration of an ISP16-compatible card is skipped
 all together. This can be useful to overcome possible conflicts which
diff --git a/Documentation/cdrom/mcdx b/Documentation/cdrom/mcdx
index fd2c37321..3c0fee5e2 100644
--- a/Documentation/cdrom/mcdx
+++ b/Documentation/cdrom/mcdx
@@ -1,6 +1,6 @@
 This is a first attempt to create an `improved' driver for the Mitsumi drives.
 It is able to "live together" with mcd.c, if you have at least two Mitsumi
-drives: each driver can use his own drive.
+drives: each driver can use its own drive.
 
 To allow this "coexistence" as long as mcdx.c is not a superset of mcd.c,
 this driver has to use its own device files. We use MAJOR 20 for it. So,
diff --git a/Documentation/cdrom/sbpcd b/Documentation/cdrom/sbpcd
index 7e43d9ce4..3dc3a249d 100644
--- a/Documentation/cdrom/sbpcd
+++ b/Documentation/cdrom/sbpcd
@@ -4,7 +4,7 @@ CD-ROM driver for Linux.
 
 sbpcd really, really is NOT for ANY IDE/ATAPI drive!
 Not even if you have an "original" SoundBlaster card with an IDE interface!
-So, you better have a look into README.ide if your port address is 0x1F0,
+So, you'd better have a look into README.ide if your port address is 0x1F0,
 0x170, 0x1E8, 0x168 or similar.
 I get tons of mails from IDE/ATAPI drive users - I really can't continue
 any more to answer them all. So, if your drive/interface information sheets
@@ -18,7 +18,7 @@ LILO commands
 and get lucky.
 To make it fully clear to you: if you mail me about IDE/ATAPI drive problems,
 my answer is above, and I simply will discard your mail, hoping to stop the
-flood and to find time to lead my 12-years old son towards happy computing.
+flood and to find time to lead my 12-year old son towards happy computing.
 
 The driver is able to drive the whole family of "traditional" AT-style (that
 is NOT the new "Enhanced IDE" or "ATAPI" drive standard) Matsushita,
@@ -29,13 +29,13 @@ CR-574 is an IDE/ATAPI drive.
 The Longshine LCS-7260 is a double-speed drive which uses the "old"
 Matsushita command set. It is supported - with help by Serge Robyns.
 Vertos ("Elitegroup Computer Systems", ECS) has a similar drive - support
-has started; come in contact if you have such a "Vertos 100" or "ECS-AT"
+has started; get in contact if you have such a "Vertos 100" or "ECS-AT"
 drive.
 
 There exists an "IBM External ISA CD-ROM Drive" which in fact is a CR-563
 with a special controller board. This drive is supported (the interface is
 of the "LaserMate" type), and it is possibly the best buy today (cheaper than
-an internal drive, and you can use it as an internal, too - f.e. plug it into
+an internal drive, and you can use it as an internal, too - e.g. plug it into
 a soundcard).
 
 CreativeLabs has a new drive "CD200" and a similar drive "CD200F". The latter
@@ -51,7 +51,7 @@ speed". The data rate already reaches 500 kB/sec if you set SBP_BUFFER_FRAMES
 to 64 (it is not recommended to do that for normal "file access" usage, but it
 can speed up things a lot if you use something like "dd" to read from the
 drive; I use it for verifying self-written CDs this way).
-The drive itself is able to deliver 600 kB/sec, so this has to get a point of
+The drive itself is able to deliver 600 kB/sec, so this needs
 work; with the normal setup, the performance currently is not even as good as
 double-speed.
 
@@ -63,7 +63,7 @@ and include an original log message excerpt, and try to give all information
 a complete idiot needs to understand your hassle already with your first
 mail. And if you want to say "as I have mailed you before", be sure that I
 don't remember your "case" by such remarks; at the moment, I have some 
-hundreds open correspondences about Linux CDROM questions (hope to reduce if
+hundreds of open correspondences about Linux CDROM questions (hope to reduce if
 the IDE/ATAPI user questions disappear). 
 
 
@@ -79,7 +79,7 @@ specify the type "SBPRO 2" and the true CDROM port address with it, not the
 If you have a sound card which needs a "configuration driver" instead of
 jumpers for interface types and addresses (like Mozart cards) - those
 drivers get invoked before the DOS CDROM driver in your CONFIG.SYS, typical
-names are "cdsetup.sys" and "mztinit.sys" -, let the sound driver do the
+names are "cdsetup.sys" and "mztinit.sys" - let the sound driver do the
 CDROM port configuration (the leading comments in linux/drivers/sound/mad16.c
 are just for you!). Hannu Savolainen's mad16.c code is able to set up my
 Mozart card - I simply had to add
@@ -184,10 +184,10 @@ To install:
 
 1. Setup your hardware parameters. Though the driver does "auto-probing" at a
    lot of (not all possible!) addresses, this step is recommended for
-   every-day use. You should let sbpcd auto-probe once and use the reported
+   everyday use. You should let sbpcd auto-probe once and use the reported
    address if a drive got found. The reported type may be incorrect; it is
    correct if you can mount a data CD. There is no choice for you with the
-   type; only one is the right, the others are deadly wrong.
+   type; only one is right, the others are deadly wrong.
 
    a. Go into /usr/src/linux/drivers/cdrom/sbpcd.h and configure it for your
       hardware (near the beginning):
@@ -229,7 +229,7 @@ To install:
    second, third, or fourth controller installed, do not say "y" to the 
    secondary Matsushita CD-ROM questions.
 
-3. Then do a "make dep", then make the kernel image ("make zlilo" or else).
+3. Then do a "make dep", then make the kernel image ("make zlilo" or similar).
 
 4. Make the device file(s). This step usually already has been done by the
    MAKEDEV script.
@@ -242,7 +242,7 @@ To install:
         mknod /dev/sbpcd3 b 25 3
    to make the node(s).
 
-   The "first found" drive gets MINOR 0 (regardless to its jumpered ID), the
+   The "first found" drive gets MINOR 0 (regardless of its jumpered ID), the
    "next found" (at the same cable) gets MINOR 1, ...
    
    For a second interface board, you have to make nodes like
@@ -297,21 +297,21 @@ No DMA and no IRQ is used.
 
 To reduce or increase the amount of kernel messages, edit sbpcd.c and play
 with the "DBG_xxx" switches (initialization of the variable "sbpcd_debug").
-Don't forget to reflect what you do; enabling all DBG_xxx switches at once
+Don't forget to reflect on what you do; enabling all DBG_xxx switches at once
 may crash your system, and each message line is accompanied by a delay.
 
 The driver uses the "variable BLOCK_SIZE" feature. To use it, you have to
 specify "block=2048" as a mount option. Doing this will disable the direct
 execution of a binary from the CD; you have to copy it to a device with the
-standard BLOCK_SIZE (1024) before. So, do not use this if your system is
+standard BLOCK_SIZE (1024) first. So, do not use this if your system is
 directly "running from the CDROM" (like some of YGGDRASIL's installation
 variants). There are CDs on the market (like the german "unifix" Linux
 distribution) which MUST get handled with a block_size of 1024. Generally,
 one can say all the CDs which hold files of the name YMTRANS.TBL are defective;
 do not use block=2048 with those.
 
-Within sbpcd.h, you will find some "#define"s (f.e. EJECT and JUKEBOX). With
-that, you can configure the driver for some special things.
+Within sbpcd.h, you will find some "#define"s (e.g. EJECT and JUKEBOX). With
+these, you can configure the driver for some special things.
 You can use the appended program "cdtester" to set the auto-eject feature
 during runtime. Jeff Tranter's "eject" utility can do this, too (and more)
 for you.
@@ -344,7 +344,7 @@ o.k., but you will get I/O errors during mount). In that case, use the "kernel
 command line" feature and specify address & type at boot time to find out the
 right setup.
 
-For every-day use, address and type should get configured within sbpcd.h. That
+For everyday use, address and type should get configured within sbpcd.h. That
 will stop the auto-probing due to success with the first try.
 
 The kernel command "sbpcd=0" suppresses each auto-probing and causes
@@ -373,7 +373,7 @@ Almost all of the "SoundBlaster compatible" cards behave like the no-sound
 interfaces, i.e. need SBPRO 0! 
 
 With "original" SB Pro cards, an initial setting of CD_volume through the
-sound cards MIXER register gets done.
+sound card's MIXER register gets done.
 If you are using a "compatible" sound card of types "LaserMate" or "SPEA",
 you can set SOUND_BASE (in sbpcd.h) to get it done with your card, too...
 
@@ -385,8 +385,8 @@ Workman, WorkBone, xcdplayer, cdplayer and the nice little tool "cdplay" (see
 README.aztcd from the Aztech driver package) should work.
 
 The program CDplayer likes to talk to "/dev/mcd" only, xcdplayer wants
-"/dev/rsr0", workman loves "/dev/sr0" or "/dev/cdrom" - so, do the appropriate
-links for using them without the need of supplying parameters.
+"/dev/rsr0", workman loves "/dev/sr0" or "/dev/cdrom" - so, make the 
+appropriate links to use them without the need to supply parameters.
 
 
 Copying audio tracks:
diff --git a/Documentation/cdrom/sjcd b/Documentation/cdrom/sjcd
index 2ebaf4f4d..74a14847b 100644
--- a/Documentation/cdrom/sjcd
+++ b/Documentation/cdrom/sjcd
@@ -1,10 +1,10 @@
  -- Documentation/cdrom/sjcd
 				80% of the work takes 20% of the time,
 				20% of the work takes 80% of the time...
-						(Murphy law)
+						(Murphy's law)
 
 				Once started, training can not be stopped...
-						(StarWars)
+						(Star Wars)
 
 This is the README for the sjcd cdrom driver, version 1.6.
 
@@ -13,7 +13,7 @@ cdrom drive. It will grow as the questions arise. ;-)
 For info on configuring the ISP16 sound card look at Documentation/cdrom/isp16.
 
 The driver should work with any of the Panasonic, Sony or Mitsumi style
-CDROM interface.
+CDROM interfaces.
 The cdrom interface on Media Magic's soft configurable sound card ISP16,
 which used to be included in the driver, is now supported in a separate module.
 This initialisation module will probably also work with other interfaces
diff --git a/Documentation/cdrom/sonycd535 b/Documentation/cdrom/sonycd535
index b7bf48d8a..a931d5093 100644
--- a/Documentation/cdrom/sonycd535
+++ b/Documentation/cdrom/sonycd535
@@ -35,7 +35,7 @@ REQUIREMENTS
 	- Drive must be set up as unit 1.  Only the first unit will be 
 	  recognized
 
-	- you must enter your interface address into 
+	- You must enter your interface address into 
           /usr/src/linux/drivers/cdrom/sonycd535.h and build the
           appropriate kernel or use the "kernel command line" parameter
                 sonycd535=0x320