public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Greg KH <greg@kroah.com>, Andrew Morton <akpm@osdl.org>,
	Linux-USB <linux-usb-devel@lists.sourceforge.net>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BK PATCH] USB update for 2.6.3
Date: Fri, 20 Feb 2004 17:03:16 +1100	[thread overview]
Message-ID: <1077256996.20789.1091.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0402192156240.2244@ppc970.osdl.org>

On Fri, 2004-02-20 at 16:58, Linus Torvalds wrote:
> On Thu, 19 Feb 2004, Greg KH wrote:
> > 
> > Here are some USB patches for 2.6.3.  Here are the main types of changes:
> > 	- switch usb code to use dmapools instead of pcipools which
> > 	  makes the embedded people happy.
> 
> However, this makes the ppc64 people very unhappy.
> 
> I've just yesterday and today switched my main home machine to be ppc64, 
> and this will not compile for me. Bad boy!
> 
> (And I haven't used ppc64 enough to be able to make sense of the DMA 
> setup, so I can't even fix it myself yet. Aaarghh!)

Hehe ;)

Well, last I heard, people here were trying to make that work, but
still, our dma mapping API will probably want the device passed in
to be a pci_dev...

The problem with the generic API is that it makes it difficult
for us to actually go back to the PCI device hosting the USB
device we get passed in... Which we what we want (our IO MMU
setup is based on what PCI device is there, for PCI at least,
for VIO, it's a bit different, but the idea is the same).

A while ago, I've advertised making this API a set of function
pointers attached to the struct device inherited from the bus
parent, so the core code just set one for the root PCIs and
everybody inherits them.... But of course, since x86 isn't
affected, nobody cared ;)

I think the "generic" DMA API is just not suitable at the moment
to be really used. It gets passed "generic" struct device, which,
due to the way Pat designed it, are almost useless alone (we
can't quite match them to anything and don't have any kind of
"inheritance" of methods via function pointers). There is no
simple hook for archs to carry informations attached to struct
devices neither, etc...

Ben



  reply	other threads:[~2004-02-20  6:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-20  1:28 [BK PATCH] USB update for 2.6.3 Greg KH
2004-02-20  5:58 ` Linus Torvalds
2004-02-20  6:03   ` Benjamin Herrenschmidt [this message]
2004-02-20  6:30     ` Linus Torvalds
2004-02-20  6:28       ` Benjamin Herrenschmidt
2004-02-20  6:47         ` Linus Torvalds
2004-02-20  6:42           ` Benjamin Herrenschmidt
2004-02-20  7:00             ` Greg KH
2004-02-20  7:06               ` Benjamin Herrenschmidt
2004-02-20  7:58               ` [linux-usb-devel] " David Brownell
2004-02-20  7:03             ` Linus Torvalds
2004-02-20  7:04               ` David S. Miller
2004-02-20  7:10                 ` Benjamin Herrenschmidt
2004-02-20  7:32                   ` David S. Miller
2004-02-20 15:15                     ` Linus Torvalds
2004-02-20 18:15                       ` Hollis Blanchard
2004-02-20 18:39                         ` Linus Torvalds
2004-02-20 19:20                           ` Hollis Blanchard
2004-02-20 19:32                             ` Linus Torvalds
2004-02-20 22:40                               ` [linux-usb-devel] " Benjamin Herrenschmidt
2004-02-20 19:30                       ` Alan Stern
2004-02-20  7:08               ` Benjamin Herrenschmidt
2004-02-20  8:08         ` David Brownell
2004-02-20  9:26           ` Russell King
2004-02-20  7:40     ` Deepak Saxena
2004-02-20  7:47       ` [linux-usb-devel] " Benjamin Herrenschmidt
2004-02-20  8:08         ` Deepak Saxena
2004-02-20  8:43           ` David Brownell
2004-02-20  8:48             ` Benjamin Herrenschmidt
2004-02-20  9:27               ` Russell King
     [not found] <fa.d7mjamc.1l40pri@ifi.uio.no>
2004-02-20  6:34 ` Andy Lutomirski

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=1077256996.20789.1091.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=torvalds@osdl.org \
    /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