Merge by hand (conflicts between pending drivers and kfree cleanups)

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

5 files changed, 34 insertions, 38 deletions

diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt
index 68a711fb82c..15378422fc4 100644
--- a/Documentation/cciss.txt
+++ b/Documentation/cciss.txt
@@ -133,3 +133,32 @@ hardware and it is important to prevent the kernel from attempting to directly
 access these devices too, as if the array controller were merely a SCSI 
 controller in the same way that we are allowing it to access SCSI tape drives.
 
+SCSI error handling for tape drives and medium changers
+-------------------------------------------------------
+
+The linux SCSI mid layer provides an error handling protocol which
+kicks into gear whenever a SCSI command fails to complete within a
+certain amount of time (which can vary depending on the command).
+The cciss driver participates in this protocol to some extent.  The
+normal protocol is a four step process.  First the device is told
+to abort the command.  If that doesn't work, the device is reset.
+If that doesn't work, the SCSI bus is reset.  If that doesn't work
+the host bus adapter is reset.  Because the cciss driver is a block
+driver as well as a SCSI driver and only the tape drives and medium
+changers are presented to the SCSI mid layer, and unlike more 
+straightforward SCSI drivers, disk i/o continues through the block
+side during the SCSI error recovery process, the cciss driver only
+implements the first two of these actions, aborting the command, and
+resetting the device.  Additionally, most tape drives will not oblige 
+in aborting commands, and sometimes it appears they will not even 
+obey a reset coommand, though in most circumstances they will.  In
+the case that the command cannot be aborted and the device cannot be 
+reset, the device will be set offline.
+
+In the event the error handling code is triggered and a tape drive is
+successfully reset or the tardy command is successfully aborted, the 
+tape drive may still not allow i/o to continue until some command
+is issued which positions the tape to a known position.  Typically you
+must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example)
+before i/o can proceed again to a tape drive which was reset.
+
diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX
index fef92ebf266..e7da8c3a255 100644
--- a/Documentation/scsi/00-INDEX
+++ b/Documentation/scsi/00-INDEX
@@ -52,8 +52,6 @@ ppa.txt
 	- info on driver for IOmega zip drive
 qlogicfas.txt
 	- info on driver for QLogic FASxxx based adapters
-qlogicisp.txt
-	- info on driver for QLogic ISP 1020 based adapters
 scsi-generic.txt
 	- info on the sg driver for generic (non-disk/CD/tape) SCSI devices.
 scsi.txt
diff --git a/Documentation/scsi/qlogicfas.txt b/Documentation/scsi/qlogicfas.txt
index 398f9916807..c211d827fef 100644
--- a/Documentation/scsi/qlogicfas.txt
+++ b/Documentation/scsi/qlogicfas.txt
@@ -11,8 +11,7 @@ Qlogic boards:
 	* IQ-PCI-10
 	* IQ-PCI-D
 
-is provided by the qlogicisp.c driver.  Check README.qlogicisp for
-details.
+is provided by the qla1280 driver.
 
 Nor does it support the PCI-Basic, which is supported by the
 'am53c974' driver.
diff --git a/Documentation/scsi/qlogicisp.txt b/Documentation/scsi/qlogicisp.txt
deleted file mode 100644
index 6920f6c76a9..00000000000
--- a/Documentation/scsi/qlogicisp.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Notes for the QLogic ISP1020 PCI SCSI Driver:
-
-This driver works well in practice, but does not support disconnect/
-reconnect, which makes using it with tape drives impractical.
-
-It should work for most host adaptors with the ISP1020 chip.  The
-QLogic Corporation produces several PCI SCSI adapters which should
-work:
-
-	* IQ-PCI
-	* IQ-PCI-10
-	* IQ-PCI-D
-
-This driver may work with boards containing the ISP1020A or ISP1040A
-chips, but that has not been tested.
-
-This driver will NOT work with:
-
-	* ISA or VL Bus Qlogic cards (they use the 'qlogicfas' driver)
-	* PCI-basic (it uses the 'am53c974' driver)
-
-Much thanks to QLogic's tech support for providing the latest ISP1020
-firmware, and for taking the time to review my code.
-
-Erik Moe
-ehm@cris.com
-
-Revised:
-Michael A. Griffith
-grif@cs.ucr.edu
diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt
index 534a50922a7..331afd791cb 100644
--- a/Documentation/scsi/scsi_eh.txt
+++ b/Documentation/scsi/scsi_eh.txt
@@ -83,11 +83,11 @@ with the command.
  The timeout handler is scsi_times_out().  When a timeout occurs, this
 function
 
- 1. invokes optional hostt->eh_timedout() callback.  Return value can
+ 1. invokes optional hostt->eh_timed_out() callback.  Return value can
     be one of
 
     - EH_HANDLED
-	This indicates that eh_timedout() dealt with the timeout.  The
+	This indicates that eh_timed_out() dealt with the timeout.  The
 	scmd is passed to __scsi_done() and thus linked into per-cpu
 	scsi_done_q.  Normal command completion described in [1-2-1]
 	follows.
@@ -105,7 +105,7 @@ function
 	command will time out again.
 
     - EH_NOT_HANDLED
-	This is the same as when eh_timedout() callback doesn't exist.
+	This is the same as when eh_timed_out() callback doesn't exist.
 	Step #2 is taken.
 
  2. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the
@@ -142,7 +142,7 @@ are linked on shost->eh_cmd_q.
  Note that this does not mean lower layers are quiescent.  If a LLDD
 completed a scmd with error status, the LLDD and lower layers are
 assumed to forget about the scmd at that point.  However, if a scmd
-has timed out, unless hostt->eh_timedout() made lower layers forget
+has timed out, unless hostt->eh_timed_out() made lower layers forget
 about the scmd, which currently no LLDD does, the command is still
 active as long as lower layers are concerned and completion could
 occur at any time.  Of course, all such completions are ignored as the