7 files changed, 19 insertions, 19 deletions

diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt
index ee03678c8029..3367130e64f6 100644
--- a/Documentation/scsi/aacraid.txt
+++ b/Documentation/scsi/aacraid.txt
@@ -4,7 +4,7 @@ Introduction
 -------------------------
 The aacraid driver adds support for Adaptec (http://www.adaptec.com)
 RAID controllers. This is a major rewrite from the original
-Adaptec supplied driver. It has signficantly cleaned up both the code
+Adaptec supplied driver. It has significantly cleaned up both the code
 and the running binary size (the module is less than half the size of
 the original).
 
diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt
index 2084ad5efb94..904d49e90ef2 100644
--- a/Documentation/scsi/aic79xx.txt
+++ b/Documentation/scsi/aic79xx.txt
@@ -81,7 +81,7 @@ The following information is available in this file:
           an SDTR with an offset of 0 to be sure the target
           knows we are async.  This works around a firmware defect
           in the Quantum Atlas 10K.
-        - Implement controller susupend and resume.
+        - Implement controller suspend and resume.
         - Clear PCI error state during driver attach so that we
           don't disable memory mapped I/O due to a stray write
           by some other driver probe that occurred before we
diff --git a/Documentation/scsi/aic7xxx_old.txt b/Documentation/scsi/aic7xxx_old.txt
index 1c8c69b8c465..c92f4473193b 100644
--- a/Documentation/scsi/aic7xxx_old.txt
+++ b/Documentation/scsi/aic7xxx_old.txt
@@ -241,7 +241,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
         that instead of dumping the register contents on the card, this
         option dumps the contents of the sequencer program RAM.  This gives
         the ability to verify that the instructions downloaded to the
-        card's sequencer are indeed what they are suppossed to be.  Again,
+        card's sequencer are indeed what they are supposed to be.  Again,
         unless you have documentation to tell you how to interpret these
         numbers, then it is totally useless.
         
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt
index 9b9516364ec1..35f6b8ed2295 100644
--- a/Documentation/scsi/ibmmca.txt
+++ b/Documentation/scsi/ibmmca.txt
@@ -309,9 +309,9 @@
    2.6 Abort & Reset Commands
    --------------------------
    These are implemented with busy waiting for interrupt to arrive.
-   ibmmca_reset() and ibmmca_abort() do not work sufficently well
-   up to now and need still a lot of development work. But, this seems
-   to be even a problem with other SCSI-low level drivers, too. However,
+   ibmmca_reset() and ibmmca_abort() do not work sufficiently well
+   up to now and need still a lot of development work. This seems
+   to be a problem with other low-level SCSI drivers too, however
    this should be no excuse.
 
    2.7 Disk Geometry
@@ -684,8 +684,8 @@
       not like sending commands to non-existing SCSI-devices and will react
       with a command error as a sign of protest. While this error is not
       present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI
-      Adapters. Therefore, I implemented a workarround to forgive those 
-      adapters their protests, but it is marked up in the statisctis, so
+      Adapters. Therefore, I implemented a workaround to forgive those 
+      adapters their protests, but it is marked up in the statistics, so
       after a successful boot, you can see in /proc/scsi/ibmmca/<host_number>
       how often the command errors have been forgiven to the SCSI-subsystem.
       If the number is bigger than 0, you have a SCSI subsystem of older
@@ -778,15 +778,15 @@
          not accept this, as they stick quite near to ANSI-SCSI and report
          a COMMAND_ERROR message which causes the driver to panic. The main
          problem was located around the INQUIRY command. Now, for all the
-         mentioned commands, the buffersize, sent to the adapter is at 
+         mentioned commands, the buffersize sent to the adapter is at 
          maximum 255 which seems to be a quite reasonable solution. 
-         TEST_UNIT_READY gets a buffersize of 0 to make sure, that no 
+         TEST_UNIT_READY gets a buffersize of 0 to make sure that no 
          data is transferred in order to avoid any possible command failure.
-      2) On unsuccessful TEST_UNIT_READY, the midlevel-driver has to send
-         a REQUEST_SENSE in order to see, where the problem is located. This
+      2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send
+         a REQUEST_SENSE in order to see where the problem is located. This
          REQUEST_SENSE may have various length in its answer-buffer. IBM
-         SCSI-subsystems report a command failure, if the returned buffersize
-         is different from the sent buffersize, but this can be supressed by
+         SCSI-subsystems report a command failure if the returned buffersize
+         is different from the sent buffersize, but this can be suppressed by
          a special bit, which is now done and problems seem to be solved.
    2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on 
       2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes.
@@ -1156,7 +1156,7 @@
         Guide) what has to be done for reset, we still share the bad shape of
         the reset functions with all other low level SCSI-drivers. 
         Astonishingly, reset works in most cases quite ok, but the harddisks
-        won't run in synchonous mode anymore after a reset, until you reboot.
+        won't run in synchronous mode anymore after a reset, until you reboot.
      Q: Why does my XXX w/Cache adapter not use read-prefetch?
      A: Ok, that is not completely possible. If a cache is present, the 
         adapter tries to use it internally. Explicitly, one can use the cache
diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt
index ea8e98fad2bb..58ad8db333d9 100644
--- a/Documentation/scsi/ncr53c8xx.txt
+++ b/Documentation/scsi/ncr53c8xx.txt
@@ -70,7 +70,7 @@ Written by Gerard Roudier <groudier@free.fr>
 15. SCSI problem troubleshooting
       15.1 Problem tracking
       15.2 Understanding hardware error reports
-16. Synchonous transfer negotiation tables
+16. Synchronous transfer negotiation tables
       16.1 Synchronous timings for 53C875 and 53C860 Ultra-SCSI controllers
       16.2 Synchronous timings for fast SCSI-2 53C8XX controllers
 17. Serial NVRAM support (by Richard Waltham)
@@ -1382,7 +1382,7 @@ SCSI standards, chip cores functionnals and internal driver data structures.
 You are not required to decode and understand them, unless you want to help 
 maintain the driver code.
 
-16. Synchonous transfer negotiation tables
+16. Synchronous transfer negotiation tables
 
 Tables below have been created by calling the routine the driver uses
 for synchronisation negotiation timing calculation and chip setting.
diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt
index 20e30cf31877..66ba3ad0ce06 100644
--- a/Documentation/scsi/st.txt
+++ b/Documentation/scsi/st.txt
@@ -369,7 +369,7 @@ MTSETDRVBUFFER
                 the device dependent address. It is recommended to set
                 this flag unless there are tapes using the device
                 dependent (from the old times) (global)
-             MT_ST_SYSV sets the SYSV sematics (mode)
+             MT_ST_SYSV sets the SYSV semantics (mode)
              MT_ST_NOWAIT enables immediate mode (i.e., don't wait for
                 the command to finish) for some commands (e.g., rewind)
              MT_ST_DEBUGGING debugging (global; debugging must be
diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt
index 98d5f1ec124f..26c8a08ca3ea 100644
--- a/Documentation/scsi/sym53c8xx_2.txt
+++ b/Documentation/scsi/sym53c8xx_2.txt
@@ -67,7 +67,7 @@ under Linux is contained in 2 files named sym_glue.h and sym_glue.c.
 Other drivers files are intended not to depend on the Operating System 
 on which the driver is used.
 
-The history of this driver can be summerized as follows:
+The history of this driver can be summarized as follows:
 
 1993: ncr driver written for 386bsd and FreeBSD by:
           Wolfgang Stanglmeier        <wolf@cologne.de>