The code that could set sc_data_direction to DMA_BIDIRECTIONAL has
been removed eight years ago. Hence remove the code that handles
this case. See also patch "unify SCSI_IOCTL_SEND_COMMAND implementations"
(commit 21b2f0c803ad).
Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
Cc: Don Brace <don.br...@pmcs.com>
---
drivers/block/cciss_scsi.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
index ecd845c..8f60a64 100644
--- a/drivers/block/cciss_scsi.c
+++ b/drivers/block/cciss_scsi.c
@@ -1478,21 +1478,6 @@ cciss_scsi_queue_command_lck(struct scsi_cmnd *cmd, void
(*done)(struct scsi_cmn
case DMA_NONE:
c->Request.Type.Direction = XFER_NONE;
break;
- case DMA_BIDIRECTIONAL:
- // This can happen if a buggy application does a scsi passthru
- // and sets both inlen and outlen to non-zero. ( see
- // ../scsi/scsi_ioctl.c:scsi_ioctl_send_command() )
-
- c->Request.Type.Direction = XFER_RSVD;
- // This is technically wrong, and cciss controllers should
- // reject it with CMD_INVALID, which is the most correct
- // response, but non-fibre backends appear to let it
- // slide by, and give the same results as if this field
- // were set correctly. Either way is acceptable for
- // our purposes here.
-
- break;
-
default:
dev_warn(&h->pdev->dev, "unknown data direction: %d\n",
cmd->sc_data_direction);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
