Re: [linux-usb-devel] Re: [BK PATCH] USB update for 2.6.3

[Benjamin Herrenschmidt]

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.
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/