Only for bulk-only drivers? In this case, g_ether and g_storage don't qualify as they need an int endpoint. This is half of the drivers I have in my CVS - and the most useful drivers. Yes, g_serial and g_zero are bulk-only, so they could use the generic autoconfigure() routine.
Those "status" channels are logically just another bulk endpoint; as I said, _all_ the current drivers (except gadgetfs!), and most of the non-isochronous class specs, can be done with only support for autoconfiguring three bulk/interrrupt endpoints.
Why not extend the autoconfigure() to isochronous and interrupt endpoints? Is it that complex? My current limited USB knowledge doesn't allow me to understand what's complex in choosing between iso/int/bulk endpoints.
Call it creeping complexity ... plus, none of the current drivers needs ISO (or high bandwidth interrupt) transfers. They add a lot more variables, and aren't widely used in any products.
I've observed, far too many times, that designing APIs in absence of multiple (at _least_ three) users for the API is a losing game. There's no way to get such APIs right. That's exactly the task you're suggesting for autoconfiguring ISO support.
I'm trying to say that it would be a lot easier to write UDC-independent autoconfigure code if there would be some capabilities bitfield rather than having to analyze a free-format character string. In general, the char *name field can be removed altogether; in this case you will actually gain some RAM because a 32-bit field is smaller than a 32-bit pointer plus 4-99 characters (if you're worried about RAM size).
It's not a "free-format" string, as I've explaned to you before. After the initial "ep", hardware restrictions show up like:
* "N" for address-restricted endpoints * Then "in" or "out" for direction-restricted endpoints * Then "-bulk" or "-iso" (or rarely "-int") for type-restricted ones
If "name" were removed, then you'd encourage every different driver and controller (and gadgetfs) to come up with a different naming convention. That's confusing and error prone; bad diagnostics have a bigger cost than may immediately be apparent.
If we ever come up with a real _need_ for a capabilities bitfield, we can add one. But at this point it's not needed, and there's no point in talking about removing a "name" field that's simple, easy to use, multi-purpose, and hasn't caused any problems.
Given how different the UDCs are, there MUST be a place to fit heuristics in any autoconfiguration scheme.
I agree there can be some totally wild limitations in some UDCs that are hard to encode into the autoconfigure() code. These cases could result in ugly if()'s (which could be #ifdef'ed though for those who don't use that UDC). But I still believe the most autoconfigure part may be done in a generic way.
Which was exactly what I described ... except for the #ifdefs, where I suggested macros like the mach_is_xxx() family on ARM, which would be optimized away by the compiler.
By virtue of the endpoint naming policy, and by restricting that logic to "bulk-only" configurations, it's actually possible to automate most bulk autoconfig() logic. Something roughly like this:
I still don't like the "virtue of endpoint naming policy". See, mq11xx_udc has endpoints that support either bulk or iso mode. I named them "ep1in-bulk!iso", you told me to name them just "ep1in". In this case the information whether the endpoint supports bulk or isochronous mode is not available at all. So it will have to be a separate case,
It's completely available. See above: the name "ep1in" means an endpoint with two restrictions: address (1) and direction (in). But no type-based restrictions. (If it can do bulk, it can also do interrupt ... modulo high speed PING protocol, which isn't an issue with full speed devices.)
again a lot of code to analyze the string ...
Not a "lot" ... especially for run-once logic living in an init section and gets discarded.
The endpoint naming convention suffices to report almost all of those issues. (Except for the rather arbitrary ones where it's better to have simple heuristics.)
Well, it didn't suffice to report the max packet size so you had to add a separate field for that.
No, that was already needed for other purposes. Since drivers may specify endpoint sizes smaller than the maximum (that's common with interrupt and isochronous transfers), all that did was define the meaning of a field during a period when it was previously undefined: before the endpoint gets enabled.
Plus speed-specific issues, and interdependencies between endpoint configurations, and quirks that require driver level workarounds (like superh_udc endpoint halt processing), and probably even some things that pack into nice small non-algorithmic bit patterns... :)
So what? Are you going to encode these particular features into the endpoint naming convention? "ep1in-bulk|iso-hs-haltquirk"? ;-)
Nope, don't need to. Just check if gadget->name is "sh_udc". (ISO endpoints by definition don't halt, by the way.) Then it's known that the quirk applies.
Now regarding other things composite gadget drivers will have to share: since there is just one string table/vendor+product id per UDC, I think these things should be better moved to the UDC driver (again all UDCs could share some common code which would handle some of the ep0
Erm, no. Controller drivers should be policy free. All of those identifers are policies. Different gadget (and eventually, function) drivers implement different policies.
Controller drivers _do_ handle some EP0 requests -- the ones that involve no device-side policy decisions, like features for endpoints (halt) and devices (power source, remote wakeup, OTG HNP modes), and maybe a few more (SET_ADDRESS if the hardware needs help) But that stuff is hardware-specific, so it belongs at that level; and it can't be shared.
You seem to be assuming that the only way to share code is to have it live in a UDC. That's not at all true. And it's why I phrased the question as what "utilities" (shared code) to build over the core (UDC) APIs ... and then gave several examples of ways to build such shared code on top of the core APIs.
- Dave
------------------------------------------------------- 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
