From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Hans de Goede <j.w.r.degoede@hhs.nl>
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 14:20:46 -0600 [thread overview]
Message-ID: <1200342046.3159.64.camel@localhost.localdomain> (raw)
In-Reply-To: <478BB795.4040305@hhs.nl>
On Mon, 2008-01-14 at 20:27 +0100, Hans de Goede wrote:
> James Bottomley wrote:
> >>> 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.
> >
> > Yes, I know that. What I mean is the block subsystem sends reads and
> > writes down in increments of the sector size. Checking if the current
> > number of pending sectors is greater than the current block size is
> > checking that guarantee. The current code already has a check in it to
> > see if this guarantee is observed ... you don't need to check it again.
> >
>
> I'm not checking for the guarantee, I'm checking that the read > 1
> realsize_sector, before decrementing the number of _512_bytes_sectors by
> realsize_sector, this check must be there, as after reading all but the last
> sector, another request will be send with 1 realsize_sector size, for which
> (block + rq->nr_sectors) == get_capacity(disk) will still hold true, in this
> case this_count must not be lowered, otherwise this_count will become 0 in this
> case and the last sector will never get read.
>
> I hope that clarifies why that code is there, if not can you tell how you would
> want the code to look by just giving the full if statement as it should be, I
> think we are somehow misunderstanding each other.
Oh, right; it's > rather than >= ... sorry, yes that's fine.
James
next prev parent reply other threads:[~2008-01-14 20:20 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
2008-01-14 19:09 ` James Bottomley
2008-01-14 19:27 ` Hans de Goede
2008-01-14 20:20 ` James Bottomley [this message]
[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=1200342046.3159.64.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=bharrosh@panasas.com \
--cc=fedora-kernel-list@redhat.com \
--cc=j.w.r.degoede@hhs.nl \
--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 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).