sbp2: proper treatment of DID_OK
Sbp2 relied on DID_OK to be defined as 0. Always shift DID_OK into the right
position anyway, and explicitly return DID_OK together with CHECK_CONDITION.
Also comment on some #if 0 code. The patch does not change current behaviour.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c
index ce3b43d..eb7106b 100644
--- a/drivers/ieee1394/sbp2.c
+++ b/drivers/ieee1394/sbp2.c
@@ -2410,7 +2410,7 @@
*/
switch (scsi_status) {
case SBP2_SCSI_STATUS_GOOD:
- SCpnt->result = DID_OK;
+ SCpnt->result = DID_OK << 16;
break;
case SBP2_SCSI_STATUS_BUSY:
@@ -2420,7 +2420,7 @@
case SBP2_SCSI_STATUS_CHECK_CONDITION:
SBP2_DEBUG("SBP2_SCSI_STATUS_CHECK_CONDITION");
- SCpnt->result = CHECK_CONDITION << 1;
+ SCpnt->result = CHECK_CONDITION << 1 | DID_OK << 16;
/*
* Debug stuff
@@ -2454,7 +2454,7 @@
/*
* Take care of any sbp2 response data mucking here (RBC stuff, etc.)
*/
- if (SCpnt->result == DID_OK) {
+ if (SCpnt->result == DID_OK << 16) {
sbp2_check_sbp2_response(scsi_id, SCpnt);
}
@@ -2472,6 +2472,8 @@
* If a unit attention occurs, return busy status so it gets
* retried... it could have happened because of a 1394 bus reset
* or hot-plug...
+ * XXX DID_BUS_BUSY is actually a bad idea because it will defy
+ * the scsi layer's retry logic.
*/
#if 0
if ((scsi_status == SBP2_SCSI_STATUS_CHECK_CONDITION) &&