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
prev parent 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).