Skip to contentSkip to conversation

sym2: remove code to handle DMA_BIDIRECTION requests

PATCH In review Christoph Hellwig 3 participants 3 messages Sep 14, 2005 – Sep 15, 2005

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sym2: remove code to handle DMA_BIDIRECTION requests

The upper layer doesn't send these down since 2.4.x (or 2.6 in practice), so no need to handle it. Inline sym_setup_data_pointers into it's only caller so we can fail gracefully in the case we'd get one neverless.

drivers/scsi/sym53c8xx_2/sym_fw.c +0 -6
Index: scsi-misc-2.6/drivers/scsi/sym53c8xx_2/sym_fw.c
===================================================================
@@ -70,9 +70,6 @@
 };
 static struct sym_fwb_ofs sym_fw1b_ofs = {
 	SYM_GEN_FW_B(struct SYM_FWB_SCR)
-#ifdef SYM_OPT_HANDLE_DIR_UNKNOWN
-	SYM_GEN_B(struct SYM_FWB_SCR, data_io)
-#endif
 };
 static struct sym_fwz_ofs sym_fw1z_ofs = {
 	SYM_GEN_FW_Z(struct SYM_FWZ_SCR)
@@ -98,9 +95,6 @@
 };
 static struct sym_fwb_ofs sym_fw2b_ofs = {
 	SYM_GEN_FW_B(struct SYM_FWB_SCR)
-#ifdef SYM_OPT_HANDLE_DIR_UNKNOWN
-	SYM_GEN_B(struct SYM_FWB_SCR, data_io)
-#endif
 	SYM_GEN_B(struct SYM_FWB_SCR, start64)
 	SYM_GEN_B(struct SYM_FWB_SCR, pm_handle)
 };
drivers/scsi/sym53c8xx_2/sym_fw.h +0 -6
Index: scsi-misc-2.6/drivers/scsi/sym53c8xx_2/sym_fw.h
===================================================================
@@ -92,9 +92,6 @@
 };
 struct sym_fwb_ofs {
 	SYM_GEN_FW_B(u_short)
-#ifdef SYM_OPT_HANDLE_DIR_UNKNOWN
-	SYM_GEN_B(u_short, data_io)
-#endif
 	SYM_GEN_B(u_short, start64)
 	SYM_GEN_B(u_short, pm_handle)
 };
@@ -111,9 +108,6 @@
 };
 struct sym_fwb_ba {
 	SYM_GEN_FW_B(u32)
-#ifdef SYM_OPT_HANDLE_DIR_UNKNOWN
-	SYM_GEN_B(u32, data_io)
-#endif
 	SYM_GEN_B(u32, start64);
 	SYM_GEN_B(u32, pm_handle);
 };
drivers/scsi/sym53c8xx_2/sym_fw1.h +0 -48

60 lines not on this page · raw message

drivers/scsi/sym53c8xx_2/sym_fw2.h +0 -52

64 lines not on this page · raw message

drivers/scsi/sym53c8xx_2/sym_glue.h +0 -1
Index: scsi-misc-2.6/drivers/scsi/sym53c8xx_2/sym_glue.h
===================================================================
@@ -68,7 +68,6 @@
  */
 #define	SYM_CONF_TIMER_INTERVAL		((HZ+1)/2)
 
-#define SYM_OPT_HANDLE_DIR_UNKNOWN
 #define SYM_OPT_HANDLE_DEVICE_QUEUEING
 #define SYM_OPT_LIMIT_COMMAND_REORDERING
 
drivers/scsi/sym53c8xx_2/sym_hipd.c +4 -4
Index: scsi-misc-2.6/drivers/scsi/sym53c8xx_2/sym_hipd.c
===================================================================
@@ -3650,7 +3650,7 @@
 	 *  If result is dp_sg = SYM_CONF_MAX_SG, then we are at the 
 	 *  end of the data.
 	 */
-	tmp = scr_to_cpu(sym_goalp(cp));
+	tmp = scr_to_cpu(cp->goalp);
 	dp_sg = SYM_CONF_MAX_SG;
 	if (dp_scr != tmp)
 		dp_sg -= (tmp - 8 - (int)dp_scr) / (2*4);
@@ -3757,7 +3757,7 @@
 	 *  And our alchemy:) allows to easily calculate the data 
 	 *  script address we want to return for the next data phase.
 	 */
-	dp_ret = cpu_to_scr(sym_goalp(cp));
+	dp_ret = cpu_to_scr(cp->goalp);
 	dp_ret = dp_ret - 8 - (SYM_CONF_MAX_SG - dp_sg) * (2*4);
 
 	/*
@@ -3853,7 +3853,7 @@
 	 *  If all data has been transferred,
 	 *  there is no residual.
 	 */
-	if (cp->phys.head.lastp == sym_goalp(cp))
+	if (cp->phys.head.lastp == cp->goalp)
 		return resid;
 
 	/*
@@ -5527,7 +5527,7 @@
 	 *  extended error did occur, there is no residual.
 	 */
 	resid = 0;
-	if (cp->phys.head.lastp != sym_goalp(cp))
+	if (cp->phys.head.lastp != cp->goalp)
 		resid = sym_compute_residual(np, cp);
 
 	/*
drivers/scsi/sym53c8xx_2/sym_hipd.h +0 -84

120 lines not on this page · raw message

drivers/scsi/sym53c8xx_2/sym_glue.c +36 -3
Index: scsi-misc-2.6/drivers/scsi/sym53c8xx_2/sym_glue.c
===================================================================
@@ -514,9 +514,10 @@
  */
 int sym_setup_data_and_start(struct sym_hcb *np, struct scsi_cmnd *cmd, struct sym_ccb *cp)
 {
-	int dir;
 	struct sym_tcb *tp = &np->target[cp->target];
 	struct sym_lcb *lp = sym_lp(tp, cp->lun);
+	u32 lastp, goalp;
+	int dir;
 
 	/*
 	 *  Build the CDB.
@@ -534,15 +535,47 @@
 			sym_set_cam_status(cmd, DID_ERROR);
 			goto out_abort;
 		}
+
+		/*
+		 *  No segments means no data.
+		 */
+		if (!cp->segments)
+			dir = DMA_NONE;
 	} else {
 		cp->data_len = 0;
 		cp->segments = 0;
 	}
 
 	/*
-	 *  Set data pointers.
+	 *  Set the data pointer.
+	 */
+	switch (dir) {
+	case DMA_BIDIRECTIONAL:
+		printk("%s: got DMA_BIDIRECTIONAL command", sym_name(np));
+		sym_set_cam_status(cmd, DID_ERROR);
+		goto out_abort;
+	case DMA_TO_DEVICE:
+		goalp = SCRIPTA_BA(np, data_out2) + 8;
+		lastp = goalp - 8 - (cp->segments * (2*4));
+		break;
+	case DMA_FROM_DEVICE:
+		cp->host_flags |= HF_DATA_IN;
+		goalp = SCRIPTA_BA(np, data_in2) + 8;
+		lastp = goalp - 8 - (cp->segments * (2*4));
+		break;
+	case DMA_NONE:
+	default:
+		lastp = goalp = SCRIPTB_BA(np, no_data);
+		break;
+	}
+
+	/*
+	 *  Set all pointers values needed by SCRIPTS.
 	 */
-	sym_setup_data_pointers(np, cp, dir);
+	cp->phys.head.lastp = cpu_to_scr(lastp);
+	cp->phys.head.savep = cpu_to_scr(lastp);
+	cp->startp	    = cp->phys.head.savep;
+	cp->goalp	    = cpu_to_scr(goalp);
 
 	/*
 	 *  When `#ifed 1', the code below makes the driver 
#1 lore raw
Quoted 4 lines · Christoph Hellwig

The upper layer doesn't send these down since 2.4.x (or 2.6 in practice), so no need to handle it. Inline sym_setup_data_pointers into it's only caller so we can fail gracefully in the case we'd get one neverless.

Christoph,
I have no objection to this patch.

I would like to flag that at some stage in the future the SCSI (or whatever it may be called) subsystem will need to support true bidirectional commands (there are a few of these in SBC-2 and lots of them in OSD). To do it properly I think we need two scatter gather lists, one for data out (to the device) and one for data in (from the device). The SBC-2 XDWRITEREAD command indicates that the data out is done before the data in (from the device); I'm not sure whether that ordering is always the case.

Doug Gilbert

#2 lore raw
Quoted 9 lines · Douglas Gilbert
Quoted 4 lines · Christoph Hellwig

The upper layer doesn't send these down since 2.4.x (or 2.6 in practice), so no need to handle it. Inline sym_setup_data_pointers into it's only caller so we can fail gracefully in the case we'd get one neverless.

Christoph,
I have no objection to this patch.

Quoted 10 lines

I would like to flag that at some stage in the future the SCSI (or whatever it may be called) subsystem will need to support true bidirectional commands (there are a few of these in SBC-2 and lots of them in OSD). To do it properly I think we need two scatter gather lists, one for data out (to the device) and one for data in (from the device). The SBC-2 XDWRITEREAD command indicates that the data out is done before the data in (from the device); I'm not sure whether that ordering is always the case.

Yes, we will need to support truely bidirectional commands one day, but hopefully never on SPI HBAs ;-)

At the same point we'll probably need to support > 16 byte CDBs aswell, and we'll need to switch to dynamically allocating the actual ->cmnd buffer (maybe only if it's > 12 bytes?).

Sounds like a nice research projects for someone's Bacchelors thesis if anyone out there is looking for something like that ;-)