public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Andries.Brouwer@cwi.nl, luben@splentec.com,
	stern@rowland.harvard.edu, linux-scsi@vger.kernel.org,
	linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] Re: inquiry in scsi_scan.c
Date: Mon, 6 Jan 2003 17:23:22 -0500	[thread overview]
Message-ID: <20030106222322.GC29126@redhat.com> (raw)
In-Reply-To: <20030106112259.B13916@one-eyed-alien.net>

On Mon, Jan 06, 2003 at 11:22:59AM -0800, Matthew Dharm wrote:
> 
> The first case:  If the additional length indicates < 36 bytes, we should
> never issue the second request (which is where this device choked).  This
> should be a sanity check in scsi_scan.c, and it works for reasons I've
> previously outlined.

No, this should be fixed in usb code.  It's a hack, I know, but it's a 
hack to work around the fact that usb devices are broken by and large much 
more so than non-usb scsi devices.  Basically, the usb code has the 
ability to tell that 36 bytes were actually transferred, so the usb code 
should set the length byte in the return to max(actual_transfer - 5, 
current_length_byte);  In actuality, other scsi HBAs that know how many 
bytes were transferred by devices could do this as well, but they don't 
need to because their SCSI devices aren't so braindead....

> The second case:  This is a bad device.  A classic off-by-one error.  But
> what can usb-storage do?  We don't know that the device is bad.  But,
> focusing on this case, what happens?  Short data is returned... if the
> resid field is set to indicate this, then scsi_scan.c should be able to do
> something sane here.

Yep, as my previous email, scsi_scan.c should simply ignore the extra byte 
because we don't care about it in the least.

> Perhaps the "best" fix here is to simply make scsi_scan.c only send 36 byte
> inquiry requests if the bus is 'emulated'.  That would solve a world of
> problems....

Except that if a device *does* transfer 36 bytes and then lies and says it 
only transferred 5 then we are missing information that might actually be 
usefull, hence the reason to set the transfer length up to the real amount 
transferred (and BTW, I would only do this for INQUIRY responses, for 
anything else the device is simply too buggy to live if it lies about the 
transfer length).


-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

  parent reply	other threads:[~2003-01-06 22:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-06 19:18 Re: inquiry in scsi_scan.c Andries.Brouwer
2003-01-06 19:22 ` Matthew Dharm
2003-01-06 20:49   ` [linux-usb-devel] " Luben Tuikov
2003-01-06 21:03     ` James Bottomley
2003-01-06 21:05     ` Matthew Dharm
2003-01-06 21:16       ` [linux-usb-devel] " Luben Tuikov
2003-01-06 22:07         ` Doug Ledford
2003-01-06 22:10     ` Doug Ledford
2003-01-06 22:23   ` Doug Ledford [this message]
2003-01-07  0:46     ` Matthew Dharm
2003-01-07  3:42       ` Doug Ledford
2003-01-07 15:15         ` Alan Stern
  -- strict thread matches above, loose matches on Subject: below --
2003-01-05 13:07 Andries.Brouwer
2003-01-06 15:03 ` [linux-usb-devel] " Alan Stern
2003-01-06 16:43   ` Luben Tuikov
2003-01-06 18:54     ` Alan Stern

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=20030106222322.GC29126@redhat.com \
    --to=dledford@redhat.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=luben@splentec.com \
    --cc=stern@rowland.harvard.edu \
    /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