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.
Yes, but the are out of the naming scheme you proposed: we can't rely anymore the characters 3 (and possibly 4) are endpoint number. This makes string analysis a little more complex.
A little, but on the other hand the pseudocode I sent before would handle that just fine ... :)
(besides, when I was looking at endpoint names through UDC drivers (before you explained me the naming scheme) I had the impression they are free-format strings because of ep-a and such).
Well, it's worth documenting the naming convention for sure.
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.
The answer is simple: since we're going anyway to change things, why not change them in such a way that will be useful in future? Your approach is more conservative, it will retain 100% compatibilty with existing gadget drivers (is there such a large number of them? I've seen only three).
There are four in my gadget-2.4 tree (superh_udc is SH3, not SH4, and won't do 2.6 yet), and enough being developed in not-yet-public trees that I don't want to put backwards-incompatible changes into the API. Like your suggestion of removing ep->name.
If you want to retain backward compatibility, you can just leave the endpoint names and add the capabilities bitfield. Then an advisory comment may be added telling to prefer bitfield analysis rather than using the endpoint name. This way, new drivers will use the more precise endpoint choosing scheme while old drivers will still work.
That's what I suggested, modulo your doc proposal! :)
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?
I don't quite understand the statement. If we would have a bitfield, and there would appear a new controller that would have some new feature which has to be taken into account during autoconfigure, the only things that will have to be changed are the new UDC driver (to provide the feature bit), and the autoconf() utility (to take that bit into
That presumes the autoconfig() call is already deployed. I was focusing on making that happen, without changing any controller drivers.
Yes, a new UDC driver will often mean tweaks to some other parts of the stack ... and just by having an autoconfig() call to manage endpoints, we'll already be reducing the number of tweaks by a lot.
account). The default policy for coping with gadgets unaware of that bit should be determined by the nature of the feature. If this is a restrictive feature, and unaware gadget drivers could fail if they get such a restricted endpoint, the policy should be "don't use the endpoint if gadget driver haven't explicitly allowed it". Further, some bitfields
No endpoint is usable until it's explicitly enabled by the gadget driver ... that's no API change!
I think I left the spec a bit fuzzy about trying to enable endpoint configs the hardware disallows, placing the onus on the gadget drivers (not to try broken things) not on the controller drivers (catch all possile gadget driver errors).
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 #endif 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.
Agree. This cold be added to some global header file that every gadget will include, and every gadget will have a way to check for quirks specific to just one UDC.
Actually I was thinking that support for hardware-specific stuff should only be visible to drivers that explicitly buy into this little framework. By including "autoconfig.h" or something similar.
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.
Well, when the autoconf() will be written using char* names, it will be too late to change anything, that's why I want this clarified now.
I think that's an orthogonal issue. You may be making assumptions about the API to the endpoint autoconfig routine, like whether it takes anything more than an endpoint descriptor to modify. (Which is the API I'd been thinking of ... :)
I think it'd make more sense for all of that to be handled by module parameters though.
Yes, I have thought of module parameters too but I don't know a easy way to pass UCS-2 strings as a module parameter. We can limit to ISO8859-1 strings though.
8859-1 could be the starting point -- it's almost trivial.
On the other hand, how about this: start with US-ASCII, 7 bits and all. Then later roll in a patch to interpret the 8th bit as starting a UTF-8 character ... giving UCS-2 support for free, from module parameters, with precious little new code.
In fact, maybe the usbstring.c code should change its default assumption in that way: the strings are UTF-8, not ISO-8859-1. That'd solve that issue pretty pervasively in the gadget stack.
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 the
same module_param names.
Perhaps on 2.4.x we can use module parameters, and on 2.6.x include additional sysfs support (enabled by a bool in menuconfig) for those Advanced Guys{tm} needing UCS-2.
Or always support the module params.
- Dave
-- Greetings, Andrew
------------------------------------------------------- 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
------------------------------------------------------- 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
