All of lore.kernel.org
 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 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.