aboutsummaryrefslogtreecommitdiff
path: root/Documentation/scsi
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/scsi')
-rw-r--r--Documentation/scsi/ibmmca.txt6
-rw-r--r--Documentation/scsi/lpfc.txt2
-rw-r--r--Documentation/scsi/scsi_fc_transport.txt6
3 files changed, 7 insertions, 7 deletions
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt
index a810421f1fb..3920f28710c 100644
--- a/Documentation/scsi/ibmmca.txt
+++ b/Documentation/scsi/ibmmca.txt
@@ -524,7 +524,7 @@
- Michael Lang
June 25 1997: (v1.8b)
- 1) Some cosmetical changes for the handling of SCSI-device-types.
+ 1) Some cosmetic changes for the handling of SCSI-device-types.
Now, also CD-Burners / WORMs and SCSI-scanners should work. For
MO-drives I have no experience, therefore not yet supported.
In logical_devices I changed from different type-variables to one
@@ -914,7 +914,7 @@
in version 4.0. This was never really necessary, as all troubles were
based on non-command related reasons up to now, so bypassing commands
did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
- 5) Dynamical reassignment of ldns was again verified and analyzed to be
+ 5) Dynamic reassignment of ldns was again verified and analyzed to be
completely inoperational. This is corrected and should work now.
6) All commands that get sent to the SCSI adapter were verified and
completed in such a way, that they are now completely conform to the
@@ -1386,7 +1386,7 @@
concerning the Linux-kernel in special, this SCSI-driver comes without any
warranty. Its functionality is tested as good as possible on certain
machines and combinations of computer hardware, which does not exclude,
- that dataloss or severe damage of hardware is possible while using this
+ that data loss or severe damage of hardware is possible while using this
part of software on some arbitrary computer hardware or in combination
with other software packages. It is highly recommended to make backup
copies of your data before using this software. Furthermore, personal
diff --git a/Documentation/scsi/lpfc.txt b/Documentation/scsi/lpfc.txt
index 4dbe41370a6..5741ea8aa88 100644
--- a/Documentation/scsi/lpfc.txt
+++ b/Documentation/scsi/lpfc.txt
@@ -36,7 +36,7 @@ Cable pull and temporary device Loss:
being removed, a switch rebooting, or a device reboot), the driver could
hide the disappearance of the device from the midlayer. I/O's issued to
the LLDD would simply be queued for a short duration, allowing the device
- to reappear or link come back alive, with no inadvertant side effects
+ to reappear or link come back alive, with no inadvertent side effects
to the system. If the driver did not hide these conditions, i/o would be
errored by the driver, the mid-layer would exhaust its retries, and the
device would be taken offline. Manual intervention would be required to
diff --git a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt
index d403e46d846..75143f0c23b 100644
--- a/Documentation/scsi/scsi_fc_transport.txt
+++ b/Documentation/scsi/scsi_fc_transport.txt
@@ -65,7 +65,7 @@ Overview:
discussion will concentrate on NPIV.
Note: World Wide Name assignment (and uniqueness guarantees) are left
- up to an administrative entity controling the vport. For example,
+ up to an administrative entity controlling the vport. For example,
if vports are to be associated with virtual machines, a XEN mgmt
utility would be responsible for creating wwpn/wwnn's for the vport,
using it's own naming authority and OUI. (Note: it already does this
@@ -91,7 +91,7 @@ Device Trees and Vport Objects:
Here's what to expect in the device tree :
The typical Physical Port's Scsi_Host:
/sys/devices/.../host17/
- and it has the typical decendent tree:
+ and it has the typical descendant tree:
/sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
and then the vport is created on the Physical Port:
/sys/devices/.../host17/vport-17:0-0
@@ -192,7 +192,7 @@ Vport States:
independent of the adapter's link state.
- Instantiation of the vport on the FC link via ELS traffic, etc.
This is equivalent to a "link up" and successfull link initialization.
- Futher information can be found in the interfaces section below for
+ Further information can be found in the interfaces section below for
Vport Creation.
Once a vport has been instantiated with the kernel/LLDD, a vport state