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:42:56 +1100 [thread overview]
Message-ID: <1077259375.20787.1141.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0402192243170.14296@ppc970.osdl.org>
> Well, we do. The pcibios_xxx routines get called for all PCI devices
> during discovery, and that's when you'd fill them in.
But what about USB or FireWire devices ? In theory, I'd like to see
the driver for those not have to bother about beeing hosted by a PCI
device or whatever else (there are typically non-PCI OHCI USBs on
embedded platform, faking a pci_dev is becoming painful).
So it would actually make sense to be able to pass whatever struct
device we are on, and have a real inheritance of the DMA functions
going down the bus, don't you think ?
> Anyway, I found the bug - the "asm-generic/dma-mapping.h" compatibility
> macros _do_ work, but the EHCI controller driver doesn't actually include
> that header file. Oops.
Heh.
> > We should have a way, when creating a device, to fill it properly, like
> >
> > platform_device_setup(struct device *new_dev, struct device *parent)
>
> No no. That wouldn't work AT ALL, since the whole point is that you need
> to know what the device is - ie you need to fill in the information when
> you get the "struct pci_dev *" (because different buses would most likely
> have different behaviour, and could have different requirements for DMA
> mapping etc).
And ? Where is the problem ? By default, you inherit from the parent
and that's just fine. The platform sets the ops for the root PCIs and
everybody below that inherit from them, same goes for VIO. If at one
level in the hierarchy, there is a "brake" (a bridge to a different
kind of bus that has additional restrictions), then the above routine
can "know" this via the new_dev bus type and setup appropriate mapping
functions.
> So the platform code that actually knows what the device is (pcibios_xxx
> for PCI devices) would fill in the platform pointer.
Hrm... and we keep it empty for USB, FireWire, etc... or we add
platform_usb_xxxx, platform_ieee1394_* etc... for all those cases ?
> Anyway, I got it all working with the trivial patch..
>
> ===== drivers/usb/host/ehci-hcd.c 1.67 vs edited =====
> --- 1.67/drivers/usb/host/ehci-hcd.c Wed Feb 11 03:42:39 2004
> +++ edited/drivers/usb/host/ehci-hcd.c Thu Feb 19 22:42:53 2004
> @@ -41,6 +41,7 @@
> #include <linux/reboot.h>
> #include <linux/usb.h>
> #include <linux/moduleparam.h>
> +#include <linux/dma-mapping.h>
>
> #include "../core/hcd.h"
>
>
> so this works for now, even though it's really really ugly (and it _will_
> BUG() out if anybody ever passes a non-PCI-related "struct device" to the
> thing).
>
> Let's see if it boots too. So far it's only compiled successfully ;)
>
> Linus
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
next prev parent reply other threads:[~2004-02-20 6:48 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
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 [this message]
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=1077259375.20787.1141.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