linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: linux-scsi@vger.kernel.org, stern@rowland.harvard.edu
Subject: Re: HP PSC 1350 cardreader problem + fix, needs new unusal_dev FLAG
Date: Sun, 10 Jun 2007 20:56:59 +0200	[thread overview]
Message-ID: <466C497B.4010407@hhs.nl> (raw)
In-Reply-To: <1181495929.6112.6.camel@mulgrave.il.steeleye.com>

James Bottomley wrote:
> On Sun, 2007-06-10 at 18:43 +0200, Hans de Goede wrote:
>> 1) currently I have decided to add quirk code for this to the usb-storage
>>     driver, as I don't want to polute the generic scsi code with this, but maybe
>>     it would be better to add a quirk for this to the scsi layer?
>> 2) What on earth should I name the flag for this?
> 
> It probably makes the most sense to keep this at the USB layer.  I can't
> see any properly conforming SCSI device having this problem.  Plus the
> command construction is currently a submit hot path for SCSI ... this
> would add an extra check to that path.
> 
>> 3) Currently I just shorten the read / write by one sector. The scsi layer then
>>     notices the 1 sector to short read/write and sends a new command for the
>>     last sector. This works well, but is it ok to depend on the scsi layer
>>     behaving this way?
> 
> Yes, that's behaviour by design.
> 
>> 4) Should I be checking for other READ_X and WRITE_x commands too?
> 
> That depends on USB storage, but I think it currently sets the
> use_10_for_rw flag which forces us only to use READ_10/WRITE_10
> 
> James
> 

Thanks for the quick and thorough answer! I've submitted a pathc for this to 
the usb-storage list.

Regards,

Hans


      reply	other threads:[~2007-06-10 18:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-10 16:43 HP PSC 1350 cardreader problem + fix, needs new unusal_dev FLAG Hans de Goede
2007-06-10 17:18 ` James Bottomley
2007-06-10 18:56   ` Hans de Goede [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=466C497B.4010407@hhs.nl \
    --to=j.w.r.degoede@hhs.nl \
    --cc=James.Bottomley@SteelEye.com \
    --cc=linux-scsi@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).