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.
Ok, then we may leave ISO out of parenthesis. In general, what we are discussing here are just helper routines, so if some gadget doesn't like them it could examine the available UDC driver itself.
Yes: utilities. Which should make it easier to handle "simple" cases (most of today's gadget drivers), but will never replace direct access to the "struct usb_gadget" as needed by the more complex cases.
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
hmm, well, the datasheet for MediaQ 1132 says endpoint 1 is restricted to interrupt transfers, endpoints 2 and 3 are just bulk/isochronous. Not a single word about interrupt transfers, although maybe it still can be used for that, just not *designed* for that.
To a first approximation, "interrupt" endpoint hardware is the same as "bulk" endpoint hardware except some transistors have been shaved. Double buffering not needed (except for high bandwidth, hence never at full speed). Often only small packets are needed, so the FIFO is small. Not many drivers need a second approximation.
If it's "restricted", that might be a kind of second-approx issue. There's a data toggle option, for iso synchronization; bulk uses one of the two modes. At high speed there are a few other issues. Or it might just be for marketing, to make it sound more featureful.
By the way, how net2280 driver fits into this naming scheme? It has"ep-a", "ep-b" and so on until "ep-f".
In that case the names are from the chip vendor. There are no hardware restrictions on endpoint role, beyond FIFO size and DMA support. They fit in as "no restrictions" cases; they'll handle pretty much everything you throw at them.
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.
Sure it haven't caused because they weren't analyzed in general until now. I don't say its impossible to analyze them, my point is that bitfields are easier to use (and produce less code). Am I wrong?
Then we're not really disagreeing. I'm saying the current API suffices for now; you're saying that in the future autoconfig code may benefit from some new endpoint bitfields conveying the most common hardware restrictions.
If I submitted an autoconfig() patch along the lines of what I sketched, and updated all the gadget drivers, then you'd want to change how it looks at the controllers (to use bitfields).
Changing that would mean tweaking the autoconfig() logic to use such bitfields (in controllers that provide them), then changing all the in-tree device controller drivers to provide them. Yes?
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.
It's not a matter of mach_is_xxx, it's a matter of #ifdef CONFIG_USB_GOKU, #ifdef CONFIG_USB_PXA2XX and so on. If the driver haven't been compiled even as a module, we can ommit support for it altogether.
Solved by {who,what}ever creates the header with entries (newer kernels changed these symbols...) like the mach_is_xxx() ones:
#ifdef CONFIG_USB_GADGET_GOKU
# define gadget_is_goku(g) (strcmp("goku_udc", (g)->name) == 0)
#else
# define gadget_is_goku(g) 0
#endifSo the compiler removes dead code ... without lots of in-line #ifdefs. It could live in an "autoconfig.h", at least for starters.
Or it could look a lot more like the mach_is_xxx stuff and include a bunch of #defined symbols for each controller. That might be nice for quirk handling that affects "normal operations", for drivers too lazy to check once during init time and set a local flag.
Ok, I agree for such very specific quirks that applies to a single UDC (and this would be protected by #ifdef CONFIG_USB_SH). But I still like bitfields a lot more for features found in more than one UDC. You can't encode everything in the endpoint name string (and I don't like analyzing strings for such simple checks, I already said that).
Sure, I understand that. I just want to see the utilities in place and working before anything starts to change the controller drivers to add a mechanism that we both agreed isn't currently necessary, or even beneficial until drivers start autoconfiguring endpoints.
Erm, no. Controller drivers should be policy free. All of those identifers are policies. Different gadget (and eventually, function) drivers implement different policies.
What you mean a policy? I mean the following: there are a lot of usb-storage devices, and they all have different strings, different vendor/product IDs. Someone may want to produce a Linux-based, say, camera which would be a usb-storage device. It will need to set its own USB strings and IDs.
Right, that's all policy. The product marketing team would want to handle some of it ... certainly each vendor would use its own vendor and product IDs, and often strings for at least manufacturer and product. (But probably few other strings.) So far, such folk have seemed happy to just modify the source code #defines; they don't have the "one distro, many different devices" problem you're looking at, it's "dedicated board, dedicated firmware".
I think it'd make more sense for all of that to be handled by module parameters though. That'd be cheaper than sysfs support, and would work easily on 2.4 kernels too. No need to grow any specialized infrastructure for module params, though it'd be nice to have all the drivers use thesame module_param names.
Your example of a PDA wanting to identify itself as "Axim" versus "iPaq" (vs "Zaurus", vs ...) is a good one, by the way.
- 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
