patch-2.4.19 linux-2.4.19/drivers/scsi/wd33c93.c

• Lines: 40
• Date: Fri Aug 2 17:39:44 2002
• Orig file: linux-2.4.18/drivers/scsi/wd33c93.c
• Orig date: Thu Oct 25 13:53:51 2001

diff -urN linux-2.4.18/drivers/scsi/wd33c93.c linux-2.4.19/drivers/scsi/wd33c93.c
@@ -1407,12 +1407,32 @@
 
 
 
-static void reset_wd33c93(struct Scsi_Host *instance)
+void reset_wd33c93(struct Scsi_Host *instance)
 {
 struct WD33C93_hostdata *hostdata = (struct WD33C93_hostdata *)instance->hostdata;
 const wd33c93_regs regs = hostdata->regs;
 uchar sr;
 
+#ifdef CONFIG_SGI_IP22
+{
+int busycount = 0;
+extern void sgiwd93_reset(unsigned long);
+   /* wait 'til the chip gets some time for us */
+   while ((READ_AUX_STAT() & ASR_BSY) && busycount++ < 100)
+	udelay (10);
+   /*
+    * there are scsi devices out there, which manage to lock up
+    * the wd33c93 in a busy condition. In this state it won't
+    * accept the reset command. The only way to solve this is to
+    * give the chip a hardware reset (if possible). The code below
+    * does this for the SGI Indy, where this is possible
+    */
+   /* still busy ? */
+   if (READ_AUX_STAT() & ASR_BSY)
+	sgiwd93_reset(instance->base); /* yeah, give it the hard one */
+}
+#endif
+
    write_wd33c93(regs, WD_OWN_ID, OWNID_EAF | OWNID_RAF |
                  instance->this_id | hostdata->clock_freq);
    write_wd33c93(regs, WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_POLLED);
@@ -2034,3 +2054,5 @@
 {
    MOD_DEC_USE_COUNT;
 }
+
+MODULE_LICENSE("GPL");