public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] scsi_status() macro
Date: Fri, 16 May 2003 15:32:13 +1000	[thread overview]
Message-ID: <3EC477DD.7080409@torque.net> (raw)
In-Reply-To: <1053047480.3998.120.camel@mulgrave>

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

James Bottomley wrote:
> If you're doing this:
> 
> On Thu, 2003-05-15 at 18:50, Douglas Gilbert wrote:
> 
>>+#define scsi_status(result) ((result) & 0x7e)
> 
> 
> because bit0 is reserved in SCSI-2, then it should be 0x3e because bits
> 6 and 7 are also reserved.  Of course, this would clash with the SCSI-3
> definition of TASK ABORTED, sigh.
> 
> Perhaps it's better just not to bother with the mask?

James,
The macro still gets rid of the upper bytes in
scsi_cmnd::result so in needs to be at least
a mask of 0xff.

With a mask of 0x7e it is correct for SCSI-3,
bit 6 is reserved ** in SCSI-2  and "vendor unique"
in SCSI-1 and SCSI_1_CCS. I dug up a SCSI 1 draft and
the Status byte table is attached. So as far as I
can see our only exposure is to SCSI 1 and CCS
devices.

A possible source of confusion with this proposed
patch is that 'scsi_status' is probably one of the
most common variable names in the SCSI subsystem.
As a macro it shouldn't clash but it may confuse.
Alternate patch using get_scsi_status() attached.


** SCSI-2 defines reserved as "set aside for future
standardization" but SPC-3 (spc3r12) nails it down:
"A reserved bit, byte, word or field shall be set to
zero, ...".

Doug Gilbert


[-- Attachment #2: scsi1_stat.txt --]
[-- Type: text/plain, Size: 855 bytes --]

14. Status 

A status byte shall be sent from the target to the initiator during the STATUS 
phase at the termination of each command as specified in Tables 14-1 and 14-2 
unless the command is cleared by an ABORT message, by a BUS DEVICE RESET 
message, or by a "hard" RESET condition.

                                  Table 14-1
                                 Status Byte 

==============================================================================
  Bit|   7    |   6    |   5    |   4    |   3    |   2    |   1    |   0    |
Byte |        |        |        |        |        |        |        |        |
==============================================================================
 0   |Reserved|  Vendor Unique  |        Status Byte Code           |   V    |
==============================================================================


[-- Attachment #3: scsi_h2569bk8cc2.diff --]
[-- Type: text/plain, Size: 1113 bytes --]

--- linux/drivers/scsi/scsi.h	2003-05-14 18:09:21.000000000 +1000
+++ linux/drivers/scsi/scsi.h2569bk8cc	2003-05-16 14:50:11.046698960 +1000
@@ -90,12 +90,19 @@
  *
  *  These are set by:
  *
- *      status byte = set from target device
+ *      status byte = set from target device (SCSI status value)
  *      msg_byte    = return status from host adapter itself.
  *      host_byte   = set by low-level driver to indicate status.
  *      driver_byte = set by mid-level.
+ *
+ *  Notes about following macros:
+ *	get_scsi_status() returns a standard SCSI status value that
+ *	may be compared with the SAM_STAT_... series of defines.
+ *	status_byte() returns a shifted SCSI status value that matches
+ *	CHECK_CONDITION and friends. status_byte() is deprecated.
  */
-#define status_byte(result) (((result) >> 1) & 0x1f)
+#define get_scsi_status(result) ((result) & 0x7e)
+#define status_byte(result) (((result) >> 1) & 0x1f)	/* deprecated */
 #define msg_byte(result)    (((result) >> 8) & 0xff)
 #define host_byte(result)   (((result) >> 16) & 0xff)
 #define driver_byte(result) (((result) >> 24) & 0xff)

  reply	other threads:[~2003-05-16  5:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15 23:50 [PATCH] scsi_status() macro Douglas Gilbert
2003-05-16  1:11 ` James Bottomley
2003-05-16  5:32   ` Douglas Gilbert [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-16 12:12 Andries.Brouwer
2003-05-17  4:38 ` Douglas Gilbert
2003-05-17  4:59 Andries.Brouwer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EC477DD.7080409@torque.net \
    --to=dougg@torque.net \
    --cc=James.Bottomley@SteelEye.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox