Status_byte() in drivers/scsi/scsi.h

There seems to be some problem with the status_byte( ) in scsi.h

A SAM status code SAM_STAT_TASK_ABORTED is ignored by status_byte() - it returns a status GOOD. If SAM status code SAM_STAT_TASK_ABORTED is set status_byte() must return 0x20.

In kernel file include/scsi/scsi.h new SCSI Architecture Model (SAM) Status Codes were presented as following:
#define SAM_STAT_GOOD 0x00
#define SAM_STAT_CHECK_CONDITION 0x02

#define SAM_STAT_CONDITION_MET   0x04
#define SAM_STAT_BUSY            0x08
#define SAM_STAT_INTERMEDIATE    0x10
#define SAM_STAT_INTERMEDIATE_CONDITION_MET 0x14
#define SAM_STAT_RESERVATION_CONFLICT 0x18
#define SAM_STAT_COMMAND_TERMINATED 0x22        /* obsolete in SAM-3 */
#define SAM_STAT_TASK_SET_FULL   0x28
#define SAM_STAT_ACA_ACTIVE      0x30
#define SAM_STAT_TASK_ABORTED    0x40

This means that an implementation of a status_byte() function in drivers/scsi/scsi.h has to be changed from:

#define status_byte(result) (((result) >> 1) & 0x1f)
to:
#define status_byte(result) (((result) >> 1) & 0x3f)

Otherwise it would ignore a status code SAM_STAT_TASK_ABORTED and return GOOD.

Please let me know your thoughts.

Thanks
-Sachin

Sachin,
The status_byte() macro is for SCSI-2 and earlier and matches a Linux-specific set of defines that are shifted from the "standard" values (e.g. CHECK_CONDITION). In those days bit 6 was not in use.

We are still arguing about the exact form of the macro to use that matches the SAM_STAT_ defines show above. In the meantime you could use:
#define sam_status_value(scmd_result) ((scmd_result) & 0x7e)
and compare the result with the SAM_STAT_ defines above.

Doug Gilbert

According to Dougs comments , here is the patch to include new macros for SAM status codes . Patch is in drivers/scsi/scsi.h

@@ -95,6 +95,13 @@
  *      host_byte   = set by low-level driver to indicate status.
  *      driver_byte = set by mid-level.
  */
+
+/* 
+ * Define a new macro sam_status_value for the status codes
+ * defined for new SCSI Architecture Model SAM 
+ */
+#define sam_status_value(scmd_result) ((scmd_result) & 0x7e)
+
 #define status_byte(result) (((result) >> 1) & 0x1f)
 #define msg_byte(result)    (((result) >> 8) & 0xff)
 

Any comments are welcome.

Thanks
-Sachin
-----------------------------------------------------------------------------------

This is not the correct thing to do. Our problems with the status byte stem from its evolving meaning. In SCSI-1, it was a bitmap, in SCSI-2 a value in a bitrange of reserved bits and in SCSI-3 it covers an entire byte. In SAM-3 all the defined codes have bit zero set to zero, so your current patch would do no harm for now, but bit zero is no-longer a reserved bit.

James

SAM-3 (rev 7) doesn't say status is a byte either. However since it doesn't define the endianess of status then it is probably safe to assume it is. If we choose a mask of 0xff we could only upset SCSI-1 (and perhaps CCS) devices. Many of those around?

On a related subject, SPC-3 defines a new "descriptor" sense data format (see section 4.5). It is a lot cleaner and more compact than the original one and is controlled by the D_SENSE bit in the control mode page. Has anybody seen a target that supports these?

Doug Gilbert

If it's in the spec, I'm sure I could create one... <evil grin>

Jeff