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: Hollis Blanchard <hollisb@us.ibm.com>,
	"David S. Miller" <davem@redhat.com>,
	Andrew Morton <akpm@osdl.org>, Greg KH <greg@kroah.com>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Linux-USB <linux-usb-devel@lists.sourceforge.net>
Subject: Re: [linux-usb-devel] Re: [BK PATCH] USB update for 2.6.3
Date: Sat, 21 Feb 2004 09:40:23 +1100	[thread overview]
Message-ID: <1077316822.9625.4.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0402201128240.1101@ppc970.osdl.org>

On Sat, 2004-02-21 at 06:32, Linus Torvalds wrote:
> On Fri, 20 Feb 2004, Hollis Blanchard wrote:
> > 
> > Well, I was picturing all those *_dma_supported() functions as being 
> > plugged into (new) fields in struct bus_type:
> > 	struct bus_type {
> > 		...
> > 		int (*dma_supported)(struct device *dev, u64 mask);
> > 	}
> 
> Ok, that would work. It might even be a good idea (not just DMA-related) 
> to make sure that everything you can portably "do" with a device would 
> show up as device operations. Right now it's not very well specified, and 
> there's obviously a lot of confusion.

Yes, which is why I don't agree with Hollis about having that in
bus_type, but rather in the device itself and inherit from the
parents by default ;) (Hrm... did I repeat myself ?)

The bus_type was is pretty useless for things like USB, and we
may have several controllers of the same bus with different
caracteristics (an on-chip OHCI and a PCI EHCI comes to mind)

Hrm... reading your last sentence, it seems you don't want people
to pass the struct device of the USB device but the host one instead,
fair enough...

> > If your *_dma_supported functions only take usb_dev, pci_dev, etc, then 
> > you end up with code like asm-generic/dma-mapping.h:
> 
> I agree, that is horrible. On the other hand, some architectures don't 
> need any indirection or any conditionals at all, since they know that they 
> only have one type of DMA. 
> 
> Making the device operations explicit would be good, though, and would 
> match how we do things in general. It's a fairly big change at this point, 
> but if somebody is willing to put the effort into the cleanup, then I'm 
> all for it.
> 
> I'd still ask that people don't do DMA on non-host devices. I'd rather 
> have a USB "struct device" just return "DMA not supported", to make sure 
> that everybody asks the right chip.
> 



  reply	other threads:[~2004-02-20 22:48 UTC|newest]

Thread overview: 32+ 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
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                               ` Benjamin Herrenschmidt [this message]
2004-02-20 19:30                       ` [linux-usb-devel] " 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
2004-02-20 15:31   ` [linux-usb-devel] " Paulo Marques
     [not found] <fa.ck6rcsq.nl8r18@ifi.uio.no>
     [not found] ` <fa.eul0v67.1p62arn@ifi.uio.no>
2004-03-04 18:05   ` 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=1077316822.9625.4.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=davem@redhat.com \
    --cc=greg@kroah.com \
    --cc=hollisb@us.ibm.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