Hello Felipe, Hello Sebastian, On Tuesday, October 23, 2012 8:55 AM Felipe Balbi wrote: <snip> > Hi, > > On Mon, Oct 22, 2012 at 04:26:35PM +0200, Sebastian Andrzej Siewior wrote: > > after a mkdir config0 you should allocate a struct usb_configuration for > this. > > > > | +->function0 > > | + name (=> ether) > > > > Here I am not sure if we should name it function0 and have name > > property or just put the name of the the directory into > > usb_get_function() and request that functions. > > I am also not sure if the order of the functions is important. *I* > > think that it does not matter if we first expose the serial function > > and then the mass storage and next time the other way around. Other > opinions? > > I don't it should matter, what matters though is which configuration we > expose first. > > > >1) What kind of ground work/housekeeping are required before configfs > > >works can be considered? > > > > on top of my head: > > - the serial gadget family that is acm, obex and the "simple serial" > > require to know in advance the number of available ports. This limit > > is shared among all users of u_serial. One should look and see if this > > limitation could be hidden somewhere in u_serial or removed > > completely. > > > > - if the function API is consider "okay" convert the remaining functions > > to it. > > > > - descriptor allocation / creation rework. > > Each functions brings a few of their own descriptors. The user might > > want to change them. Besides the "obvious" VID/PID thingy there are > > the string descriptors. Currently a bunch of functions allocate the > > descriptors "once" and check if the of the first id is 0 and if not, > > they skip the allocation. This is done in order to share the string > > (and descriptor which contains iSerial for instance) across multiple > > configurations. This sharing does not work if we plan to use the same > > function twice on two UDCs where we could have diffent IDs. > > correct > > > What I had in mind was: > > - create a copy of each descriptor. Each descriptor should have a name > > or something different that can be used as an unique identifier. > > - after the copy has been done, the function can request the copy by > > the name and update some fields like the endpoint number in case of > > an endpoint descriptor. > > - configfs could also allow to edit some fields here like the string. > > note that the string is a separate descriptor :-) configfs should allow > for a string descriptor to be linked to e.g. the iManufacturer field of a > device descriptor. Maybe a symlink is enough ? > > > - each gadget provides now two sometimes three copies of those > > descriptors. To make things simpler the gadget could provide only > > set of descriptors (for instance only SS) and composite would create > > HS and FS from it if desired. > > I don't think that will work. Think about isochronous and interrupt > endpoints where wMaxPacketSize can be whatever we want. I'd rather > allocate 3 sets of descriptors :-s > > > - after attaching all functions within a config, the code resets the > > allocated endpoints. This is done because only one config can be > > active at a time and therefore the endpoints are shared. > > Not only the endpoints can be shared among configs but also among > > alternate interfaces. If you look at the tcm gadget I share the same > > endpoints between UAS and BOT. Maybe this could be done in a better > > way. Also I hate that we allocate HS descriptors and fill the blanks > > in FS descriptors. > > > > Each point here is just one of my thought. I currently try hard not to > > mix everything in one series and get everything NAKed due to one bad > > thought :) Right now it works. I am not sure how "well" they are. > > > > >Can configfs works be done in parallel? > > You can take what you have and rebase on top of recent code. The > > problem is that we can't merge incomplete code and stuff that is > > missing something because we can't change an interface. The rulles are > > for now that we want a generic interface and it should be possible to > > attach it to more than just one UDC at a time and we don't want break > anything. > > > > >2) If only f_* files remain, where will they be used? Now they are > > >used by their gadget counterparts, e.g. f_sourcesink and f_loopback > > >are used by zero.c. In other words, if f_* files deal with the usb > > >functions level and only they remain, then what takes care of usb > > >configurations and usb devices? > > > > The configfs interface. Let me tell you more what I dreaming about > > while I fall asleep: Now I try to ease the entry pain for configfs. > > The new code should be used by configfs and by the g_* code and the > > g_* code shouldn't notice a thing while using it. Once the configfs is > > stable and working well and people don't complain that it is hard to > > handle, we can ask all users to switch to it instead of using modprobe > > g_*. Any why should they use it? Because it is so much more flexible. > > Then we could provide a script/tool which is named g_zero.sh and does > > what "modprobe g_zero" would do but via configfs. And then, if nobody > > is using "modprobe g_*" anymore, we could remove them. > > right. > > -- Thanks guys! I only skimmed through your responses but it looks like a plan. I will get back to you after I exactly understand what you have proposed. Thanks, AP -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
