On Tue, Apr 02, 2002 at 10:40:08AM -0800, David Brownell wrote: > > - do you want me to add this to the main kernel tree? It should > > probably go somewhere like drivers/usb/device. > > Well, parts of it. I had half thought about drivers/usb/dcd > for the Device Controller Driver parts (matching 'hcd' for > the Host Controller Drivers :), but some of those would > best belong in the architecture-specific trees (SA-1110 > as one example).
The arm port has a USB host and client driver (or so I've been told, the client might be this one for all I know :) I've seen the host driver, and it will probably end up in the drivers/usb/ directory soon. Same thing goes for a embedded PPC USB host controller driver that is based off of usb-ohci.c, it too will end up in the drivers/usb directory soon. drivers/usb/dcd sounds ok, I don't mind too much, but don't like the "usbd" directory name, as it sounds too much like "USB Deamon" to me (but I might have been staring at all of the different kernel deamon names too long...) > Might be worth thinking about whether more rework of > the USB tree layout would be a good thing. Assuming > we keep getting more drivers, I think adding subdirs > would help make things more manageable. Ones for > network and webcame (host side) drivers would seem > like a good start. And "device side drivers" might live > in their own directories ... for all that I've suggested the > network stack as the preferred interop solution for smart > Linux devices and their hosts (any kind). I think the network and video drivers now have a critical mass to move them to their own directory if no one objects. Nice thing about bitkeeper, file moves are very simple to do :) > Before it goes there, I thought I'd request some discussion > and convergence of the API with what's already there. > Easier to achieve that before integration than after. Actually, if the code is in the kernel, I think it is easier to provide better discussion, as we can all share patches against a common view. Just because the code ends up in the tree, does not mean at all that the API can't change, or be radically altered. It just makes it easier :) > Different terminology for the same thing would just be > confusing, for example... a USB "interface" should be > called the same thing everywhere, but seems like it's > become a "function" in this USBD code, while the > word "interface" is used to describe controllers > (host and device). I agree, the terminology should be the same. > > - it looks like your usbd api is close to the same as the > > existing usb api. Why not make it even closer to help provide > > some "familiarity" when writing drivers for both sides of the > > wire? For example, usbd_alloc_urb() takes 4 parameters, while > > usb_alloc_urb() takes 2. > > Exactly: API convergence. Constants and structure defs > (for descriptors etc) should be the same (common header?), > there should NOT be two conflicting definitions of "URB", > and so on. > > Maybe we can use this API to finally shrink and simplify the > URB model in the host side drivers ... convergence would > more naturally involve changes on _both_ sides. That would be great. > Plus think that if, as Stuart said, he thinks it's a bit "over elaborated", > incremental integration (in simpler chunks) would be a good way > way to address some of those issues. If Stuart wants to cut it up into smaller chunks for me to apply, please do, it doesn't bother me either way (remember it's going into 2.5, not 2.4 :) thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
