On Feb 20 2004, at 17:03, Benjamin Herrenschmidt was caught saying: > 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).
Why can't you just do the following to get to the PCI device? if (dev->bus_type == &pci_bus_type) { struct pci_dev pci_usb_dev = to_pci_dev(dev); ... } If you mean the USB target device itself, can't you walk the tree until you find a device that is no longer on bus_type usb to determine your root? > 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 ;) You could stuff that into platform_data on PCI devices on your platforms. > 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... I think we're not quite there yet, but once you have the device struct, in theory, you can walk up the tree to grab the platform_data for say the device's parent and do any tweaks based on platform-specific bus parameters. With PCI, you could even stuff this into pci_bus->sysdata. I think having a function pointer table for things like dma mapping and ioremap on all devices would be a very good thing, but not sure if the powers that be would allow that in 2.6. ~Deepak -- Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/ ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel