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 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.