On Tue, 9 Mar 2004, David Brownell wrote:
I didn't notice a followup to my post of yesterday talking about needing better bcdDevice conventions. The current one only allocates 9 numbers for controller numbers ... almost kaput.
I meant to comment on that...
When I started using that VV.KC convention, where VV is a two-digit version number, K indicates the kernel version, and C the controller chip, I realized that 9 or 10 different values for C wouldn't be enough. There were two possible ways to deal with the problem:
...
Ultimately neither of these is really satisfactory. The fact is, we shouldn't be trying to encode all this information in the bcdDevice field in the first place.
Actually I don't see any problem with any individual product choosing to do that, since version numbering is product-specific. The problem is trying to generalize that behavior, given such a miniscule range of product version codes (1000 max) and a software model that's not predicated on everything being a full custom design.
There are other parts of autoconfig that don't relate to endpoints, and the "epautoconf.h" you saw should vanish ... the two declarations belong in <linux/usb_gadget.h>, nothing else is endpoint-specific.
Endpoint selection is the most critical, though, and perhaps also the most amenable to an automated solution.
That's why we've been talking about it off and on for several months now! Though I think the other stuff is likewise amenable. You were talking about the "ID allocator" role for strings, interfaces, and configurations at one point ... I chucked as I noticed needing to do the same thing for endpoints.
Here's something else to consider for composite gadget drivers. The main program will need to know at all times which function driver has allocated which endpoint. That information is needed to dispatch control messages with RECIP_ENDPOINT. The simplest way to do this may be for the main program to set up a hook intercepting calls to usb_ep_enable() and usb_ep_disable().
Not just allocated, but how they've configured it (bEndpointAddress); though not all hardware is flexible that way (like net2280 is). I'd not much thought about that, but you're right. I suppose I'd thought that each function instance would have a list of endpoints it uses.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
