Hi, On Mon, Jun 13, 2011 at 12:30:09PM -0400, Alan Stern wrote: > > > It essentially _was_ done; the result was g_mass_storage. The two > > > drivers are almost but not quite entirely the same (apart from use of > > > the composite framework). > > > > I see, the problem now is that we have two drivers doing somewhat the > > same thing and while the ARM people already got bashed because of "not > > sharing enough code" we have duplicate drivers on the gadget framework > > :-) > > Yeah, it's a mess. I don't know what would be best. soon enough Linus will start targetting the drivers/ tree :-) > > We also need to a find a better way to get rid of the inclusion of C > > source files. I understand why Dave did it, but it's been quite some > > time since those patches were committed - e.g. > > 7e75bc0f9006e995a0fa25f0a285addc3d5fd5cb - and no progress has been made > > to fix that up. Probably Clang's link-time optimization would help a lot > > on that, but Clang still needs quite some work to be usable for us, so > > we need something else. Any ideas ? > > Could these routines go into the UDC core? it's related to composite.c, only if we move the entire composite.c into udc-core :-) It's too much code we need to change, see any of the gadget drivers, for instance take zero.c: /* * Kbuild is not very cooperative with respect to linking separately * compiled library objects into one module. So for now we won't use * separate compilation ... ensuring init/exit sections work to shrink * the runtime footprint, and giving us at least some parts of what * a "gcc --combine ... part1.c part2.c part3.c ... " build would. */ #include "composite.c" #include "usbstring.c" #include "config.c" #include "epautoconf.c" #include "f_sourcesink.c" #include "f_loopback.c" > > On another matter, do you think it's worth moving g_(mass|file)_storage > > to target ? We asked Tatyana to make UAS use target, but what about the > > legacy MSC gadgets ? (I have to say I didn't even look into target's > > code) > > It would be a big change, a lot bigger than adding in the composite > framework. In fact, at this point I still don't know exactly what > would be involved -- but I suspect it would cause a noticeable increase > in the kernel code size which would not be good for embedded platforms. I see... We will probably need to clean up a few things, but maybe it's lower proirity since g_file_storage is working and we have quite a few USB Certified devices using it ? > > > Okay, now I get it. You can understand why I was confused, seeing as > > > how your original message said: > > > > > > We also need to cleanup all the ->start()/->stop() calls from > > > all udc controllers, then we need to uninline all the > > > operations we have on gadget.h ... > > > > > > Evidently you didn't really mean "all". > > > > the keyword was "operations", now that I read it again it's not clear > > enough, but it was supposed to refer to struct usb_gadget_ops :-) > > Ah. But why uninline these things? The inline function merely checks > that the function pointer is non-NULL before invoking it. Would you > want to send a notification even when an unimplemented gadget_ops is > called? not for all, I guess. Some of those we want to use to let a charger chip know how to configure the charging profile. For example, even if the UDC driver (musb, omap_udc, ci13xx, etc) don't implement vbus_draw() we want to let a charger chip know about the selected configuration so that we can connect load between VBUS and GND pins to start USB battery charging. But some of them, only make sense if the pointer is implemented, for sure :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
