From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Dharm <mdharm-scsi@one-eyed-alien.net>,
Guillaume Bedot <littletux@zarb.org>,
Boaz Harrosh <bharrosh@panasas.com>,
USB Storage list <usb-storage@lists.one-eyed-alien.net>,
fedora-kernel-list@redhat.com,
USB development list <linux-usb-devel@lists.sourceforge.net>,
David Brown <usb-storage2@davidb.org>,
linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
Date: Mon, 14 Jan 2008 19:37:36 +0100 [thread overview]
Message-ID: <478BABF0.1040403@hhs.nl> (raw)
In-Reply-To: <1200328388.3159.20.camel@localhost.localdomain>
James Bottomley wrote:
> On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote:
>> On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote:
>>> Guillaume Bedot wrote:
>>>> But it fixes only two models.
>>>> Do you think other devices (hp or not) can be impacted ?
>>>> There are hundreds of models with card readers only for hp :
>>>> http://hplip.sourceforge.net/supported_devices/combined.html
>>>>
>>>> Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without
>>>> recompiling a kernel ?
>>>>
>>> This is not possible AFAIK, I've already wrote a blog post about this
>>> asking for people to test this, but got no responses.
>> Once the patches are accepted by the SCSI people, one of the things we can
>> consider doing is enabling this quirk for all USB devices. It should be
>> pretty harmless to all properly working devices, and the performance hit
>> should be pretty minimal.
>
> The SCSI patches look OK, with the stylistic points fixed below ...
> we'll need two separate patches as well (one for SCSI, one for USB).
>
Okay,
Thanks for the review! I'll do a new scsi changes only patch once I get an
answer to some questions regarding your review.
>> + /* Some devices (some sdcards for one) don't like it if the last sector
>> + gets read in a larger then 1 sector read */
>
> The comment style in sd is
>
> /*
> * comment
> */
>
Will fix,
>> + if (sdp->last_sector_bug && rq->nr_sectors > sdp->sector_size / 512 &&
>
> An unlikely() here, please to force the compiler to optimise for the
> non-buggy case.
Will do.
> Plus what is the rq->nr_sectors > sdp->sector_size /
> 512 test supposed to be doing? that being true is supposed to be a
> guarantee of the block layer (and if something goes wrong there's a
> check for this lower down).
>
It first is was just:
rq->nr_sectors > 1
Then I changed it to also do the right thing for 1024 and larger sector disks.
The whole purpose is to not read the last sector in a larger then one sector
read, so the amount of sectors gets reduced by one if (block + rq->nr_sectors
== get_capacity(disk)) but we do want still want to be able to read the last
sector by itself, so we must not reduce the no sectors to be read by one if it
is already one.
>> + block + rq->nr_sectors == get_capacity(disk)) {
>
> rq->nr_sectors should be this_count
>
Fine by me, but in this place in the code they are the same value, and the
check for a read beyond the end of disk a few lines above also uses
rq->nr_sectors, which one should be used when?
>> + this_count -= sdp->sector_size / 512;
>
> If you relocate this code to after the sector_size/this_count adjustment
> code (i.e. about line 442) you can just do --this_count;
>
I cannot move the check down as then block has been adjusted for the sector
size, so if I move the check down it becomes:
if (block * (sdp->sector_size / 512) + rq->nr_sectors == get_capacity(disk))
I would rather not have the sdp->sector_size / 512 code in the check (slow) but
rather in the not often entered if block.
Regards,
Hans
next prev parent reply other threads:[~2008-01-14 18:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-09 21:44 Linux scsi / usb-mass-storage and HP printer cardreader bug + fix Hans de Goede
2008-01-09 22:10 ` Matthew Dharm
2008-01-10 10:43 ` Boaz Harrosh
2008-01-10 10:52 ` Hans de Goede
2008-01-10 11:27 ` Boaz Harrosh
2008-01-11 12:48 ` Hans de Goede
2008-01-11 13:57 ` Guillaume Bedot
[not found] ` <47860106.3090509-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
2008-01-11 20:14 ` PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix) Hans de Goede
2008-01-11 20:34 ` [usb-storage] " Matthew Dharm
2008-01-14 9:40 ` Guillaume Bedot
2008-01-14 9:46 ` Hans de Goede
2008-01-14 16:03 ` Matthew Dharm
[not found] ` <20080114160310.GH14375-JGfshJpz5UybPZpvUQj5UqxOck334EZe@public.gmane.org>
2008-01-14 16:33 ` James Bottomley
2008-01-14 18:37 ` Hans de Goede [this message]
2008-01-14 19:09 ` James Bottomley
2008-01-14 19:27 ` Hans de Goede
2008-01-14 20:20 ` James Bottomley
[not found] ` <1200342046.3159.64.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-01-20 10:12 ` Hans de Goede
[not found] ` <1200328388.3159.20.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-01-14 18:40 ` Stefan Richter
2008-01-14 19:01 ` Matthew Dharm
2008-01-14 19:10 ` Hans de Goede
2008-04-25 5:43 ` (unknown), wangzhilei-pcEzf3JNfARxfCqBhyfcug
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=478BABF0.1040403@hhs.nl \
--to=j.w.r.degoede@hhs.nl \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bharrosh@panasas.com \
--cc=fedora-kernel-list@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=linux-usb@vger.kernel.org \
--cc=littletux@zarb.org \
--cc=mdharm-scsi@one-eyed-alien.net \
--cc=usb-storage2@davidb.org \
--cc=usb-storage@lists.one-eyed-alien.net \
/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.