All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andries Brouwer <aebr@win.tue.nl>
To: davej@codemonkey.org.uk
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org, gregkh@kroah.com
Subject: Re: mysterious shifts in USB storage drivers.
Date: Thu, 15 May 2003 16:31:21 +0200	[thread overview]
Message-ID: <20030515143121.GA29658@win.tue.nl> (raw)
In-Reply-To: <200305150331.h4F3VHID000770@deviant.impure.org.uk>

On Thu, May 15, 2003 at 04:31:17AM +0100, davej@codemonkey.org.uk wrote:

> These went into 2.4 over a year ago. Unfortunatly,
> with no comments in the logs.
> 
> 
> diff -urpN --exclude-from=/home/davej/.exclude bk-linus/drivers/usb/storage/datafab.c linux-2.5/drivers/usb/storage/datafab.c
> --- bk-linus/drivers/usb/storage/datafab.c	2003-04-10 06:01:25.000000000 +0100
> +++ linux-2.5/drivers/usb/storage/datafab.c	2003-03-17 23:42:38.000000000 +0000
> @@ -670,7 +670,7 @@ int datafab_transport(Scsi_Cmnd * srb, s
>  			srb->result = SUCCESS;
>  		} else {
>  			info->sense_key = UNIT_ATTENTION;
> -			srb->result = CHECK_CONDITION << 1;
> +			srb->result = CHECK_CONDITION;
>  		}
>  		return rc;
>  	}

And then you say: I have no idea what they do, let us also put them in 2.5?

Very long ago someone noticed that all status codes were even
and decided to save some space in arrays by shifting them right one.

Thus, we find in drivers/scsi/scsi.h:
#define status_byte(result) (((result) >> 1) & 0x1f)

Usually the status byte is returned by the device, but everywhere
where we invent a status ourselves we need the <<1.
This is annoying, and the kernl, both 2.4 and 2.5, is full of
mistakes here - may submit some patches against 2.5.70 in case
that appears soon. These days we also have the explicit codes
that have been shifted already:

/*
 *  SCSI Architecture Model (SAM) Status codes. Taken from SAM-3 draft
 *  T10/1561-D Revision 4 Draft dated 7th November 2002.
 */
#define SAM_STAT_GOOD            0x00
#define SAM_STAT_CHECK_CONDITION 0x02
#define SAM_STAT_CONDITION_MET   0x04
#define SAM_STAT_BUSY            0x08
...
/*
 *  Status codes. These are deprecated as they are shifted 1 bit right
 *  from those found in the SCSI standards. This causes confusion for
 *  applications that are ported to several OSes. Prefer SAM Status codes
 *  above.
 */

#define GOOD                 0x00
#define CHECK_CONDITION      0x01
#define CONDITION_GOOD       0x02
#define BUSY                 0x04

Andries


      parent reply	other threads:[~2003-05-15 14:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15  3:31 mysterious shifts in USB storage drivers davej
2003-05-15  3:37 ` Linus Torvalds
2003-05-15  4:56 ` Greg KH
2003-05-15  7:14   ` Matthew Dharm
2003-05-15  8:07     ` Greg KH
2003-05-15 14:31 ` Andries Brouwer [this message]

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=20030515143121.GA29658@win.tue.nl \
    --to=aebr@win.tue.nl \
    --cc=davej@codemonkey.org.uk \
    --cc=gregkh@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.