Hi,
On Thu, 15 Jan 2004, David Brownell wrote:
> choice values can also be tristate symbols, so you wouldn't need the
> separate defines, unless you really always want to compile only a > single controller (even as module).
That's it precisely. USB devices have only one (upstream) link; they're not like hosts. And its link to the controller isn't re-wired on the fly any more than, say, the MMU. Kconfig just needed some persuasion before it'd dance that way.
It's still weird. Where is the problem to compile all controllers as module? At runtime you still have the possibility that only one of them can be loaded and the next one would fail to load.
The problem is something I accidently neglected to respond to in your previous note. Those controllers aren't drop-in substitutes for one another, and you seemed to be assuming they were.
> The dependency "USB_DUMMY_HCD || USB_NET2280 || USB_PXA2XX || USB_SA1100 > || USB_GOKU" can be basically reduced to "USB_GADGET".
That's where I accidentally trimmed out a response. It's wrong; those controllers are not equivalent in general. Gadget drivers that work with one controller will not automagically work with another. Two quick examples should illustrate the point:
(i) A "video" gadget driver would requires isochronous transfer support.
But only two of those controllers support that (net2280, pxa2xx_udc). So a video (or audio) class gadget driver would depend on configuring
an appropriate controller ... and even then, it'd probably compile in
more code if it's talking to a controller that supports high bandwidth
transfer modes (up to 24 MByte/sec) than one maxing ouat a 1 Mbyte/sec.(ii) Essentially every controller has endpoints that differ from the others
in capabilities like addressing, direction, supported packet sizes
transfer modes, or throughput. All of those are things that MUST be
reported to the USB host in device descriptors. The differences are currently all handled by conditional compilation.
Until a gadget driver has that support for a particular controller,
it shouldn't be possible to configure that combination.There's some work afoot to do more autoconfiguration, but it won't be able to handle all the issues for all drivers. I have hopes that at least some simple configurations -- two endpoints for bulk data (IN/OUT) and one for status (interrupt IN), for example -- will be able to autoconfigure at some point.
Reproduced it again here today, with a reasonably current 2.6.1 tree on top of RH9 (plus some updated RPMs from RH). It's there in gconfig too. The workaround is "vi .config" and delete the sticky DUMMY_HCD entry, then re-configure.
It really works fine here, are you sure you don't have any additional changes under scripts/kconfig? Did you try this on a different machine?
Absolutely certain. Yes, tried on multiple machines. Did you try it on RH9? Since it's working for you, I wonder if that's the source of the difference. Same bug in xconfig, gconfig, and menuconfig; doesn't make a lot of sense to me but then I've not looked at that code in any case.
- Dave
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
