From: David Brownell <david-b@pacbell.net>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net,
Matthew Dharm <mdharm@one-eyed-alien.net>,
Greg KH <greg@kroah.com>
Subject: Re: [linux-usb-devel] Re: highmem and usb [was "sr: unaligned transfer" in 2.5.2-pre1]
Date: Wed, 02 Jan 2002 10:55:42 -0800 [thread overview]
Message-ID: <07e501c193bf$14cb7800$6800000a@brownell.org> (raw)
In-Reply-To: <m23d1trr4w.fsf@pengo.localdomain> <20011230122756.L1821@suse.de> <20011230212700.B652@one-eyed-alien.net> <20011231125157.D1246@suse.de> <20011231145455.C6465@one-eyed-alien.net> <065e01c192fd$fe066e20$6800000a@brownell.org> <20020101233423.I16092@suse.de> <06c801c1934e$1fc01a20$6800000a@brownell.org> <20020102103252.B28530@suse.de> <07c401c193bc$90ad5d60$6800000a@brownell.org> <20020102194404.A482@suse.de>
> > OK, I think I'm clear on this much then: in 2.5, to support block drivers
> > over USB (usb-storage only, for now) there needs to be an addition to
> > the buffer addressing model in usbcore, as exposed by URBs.
> >
> > - Current "transfer_buffer" + "transfer_buffer_length" mode needs to
> > stay, since most drivers aren't block drivers.
>
> Why? Surely USB block drivers are not the only ones that want to support
> highmem.
Once the capability is there, it'll find other uses. But allowing them is not
the same as requiring them. Getting rid of the current model would break
every USB driver, rather than just ones that want to support highmem.
> > - Add some kind of "page + offset" addressing model.
>
> Yes
>
> > Discussion of details can be taken off LKML, it'd seem. Though I'm
> > curious when the scatterlist->address field will vanish, making these
> > changes a requirement. Is that a 2.5.2 thing?
>
> Maybe 2.5.3, dunno for sure.
A bit of a delay would make things a bit easier ... :)
Of course, if scatterlist->address doesn't work any more,
it won't matter much.
- Dave
> > Also, I noticed that include/asm-sparc/pci.h doesn't include the
> > standard pci_map_page() call ... what's up with that? That surely
> > causes portability problems.
>
> It probably isn't up to snuff yet.
>
> --
> Jens Axboe
>
next prev parent reply other threads:[~2002-01-02 18:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-23 17:44 "sr: unaligned transfer" in 2.5.2-pre1 Peter Osterlund
2001-12-23 19:22 ` Greg KH
2001-12-30 9:31 ` Peter Osterlund
2001-12-30 11:27 ` Jens Axboe
2001-12-31 5:27 ` Matthew Dharm
2001-12-31 11:51 ` Jens Axboe
2001-12-31 22:54 ` [linux-usb-devel] " Matthew Dharm
2001-12-31 23:59 ` Andre Hedrick
2002-01-01 17:39 ` Jens Axboe
2002-01-01 17:40 ` Jens Axboe
2002-01-01 19:53 ` David Brownell
2002-01-01 22:34 ` Jens Axboe
2002-01-01 23:28 ` Matthew Dharm
2002-01-02 5:40 ` [linux-usb-devel] Re: highmem and usb [was: "sr: unaligned transfer" in 2.5.2-pre1] David Brownell
2002-01-02 9:27 ` [linux-usb-devel] Re: highmem and usb [was:"sr: unalignedtransfer" " Oliver.Neukum
2002-01-02 18:43 ` David Brownell
2002-01-02 9:31 ` [linux-usb-devel] Re: highmem and usb [was: "sr: unaligned transfer" " Jens Axboe
2002-01-02 9:30 ` [linux-usb-devel] Re: "sr: unaligned transfer" in 2.5.2-pre1 Jens Axboe
2002-01-02 5:27 ` [linux-usb-devel] Re: highmem and usb [was "sr: unaligned transfer" in 2.5.2-pre1] David Brownell
2002-01-02 9:32 ` Jens Axboe
2002-01-02 18:37 ` David Brownell
2002-01-02 18:44 ` Jens Axboe
2002-01-02 18:55 ` David Brownell [this message]
2002-01-02 20:23 ` Jens Axboe
2002-01-02 22:32 ` [linux-usb-devel] Re: highmem and usb [was "sr: unalignedtransfer" " Oliver.Neukum
2001-12-24 4:05 ` "sr: unaligned transfer" in 2.5.2-pre1 Bob_Tracy
2001-12-24 7:24 ` Peter Osterlund
2001-12-24 14:13 ` WHICH MACHINE????? Astinus
2001-12-24 15:37 ` Erik Mouw
2001-12-25 15:41 ` Svein Ove Aas
2001-12-26 13:56 ` Erik Mouw
2001-12-24 16:19 ` J.A. Magallon
2001-12-24 22:48 ` "sr: unaligned transfer" in 2.5.2-pre1 Peter Osterlund
2001-12-27 7:13 ` Petr Titera
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='07e501c193bf$14cb7800$6800000a@brownell.org' \
--to=david-b@pacbell.net \
--cc=axboe@suse.de \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mdharm@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