Hi, On Thu, Oct 18, 2012 at 05:12:48PM +0200, Andrzej Pietrasiewicz wrote: > Hello Felipe, > > On Wednesday, October 17, 2012 3:56 PM Felipe Balbi wrote: > > <snip> > > > On Wed, Oct 17, 2012 at 11:43:11AM +0200, Andrzej Pietrasiewicz wrote: > > > Demonstrate a USB gadget configured entirely through configfs. > > > This is a work in progress. > > > > > <snip> > > > > > this is wrong. we don't want *another* gadget driver. We want to get rid > > of the ones we have. The end goal is to keep only f_* files in kernel. > > > > I definitely agree about f_* files. However, I think we need... something? > While Sebastian's recent patch series shows how to remove #include .c > lines from gadget code, it does not do anything about the gadgets in > the meaning that if we had e.g. g_zero module before, we _still_ have > the g_zero, _plus_ we have f_sourcesink and f_loopback modules. that's one step. We can't get to configfs-based gadget binding if we don't cleanup the problems we have now. > In other words, one must still insmod g_zero (f_sourcesink and f_loopback > being automatically requested), possibly setting some parameters like > vendor id, product id and so on. The g_zero here contains > a usb_composite_driver which, after it gets probed, takes one udc. > > I think what we want here is a possibility to configure multiple functions > in one gadget (under one udc, in other words). eventually, but not until we do the ground work/housekeeping to get there. We definitely don't want to hack something together which nobody will in the future. > So the "something" I mentioned earlier should be the place where the > usb_composite_driver is defined and probed. And I called this kind of > entity a "gadget". Any better name? > > Does this sound reasonable to you? Or do you think about something > completely different? Sorry but you seem to be way off :-s. I continue to say that we don't want any "temporary" solutions, we want to take all steps necessary towards our goal of deleting all g_* files and keeping only the functions in kernel. This means that will not accept a gadget driver which is built based on configfs, while that does the whole "configfs-based binding" it does it in the wrong way and I will not let that go into the kernel. If it takes two more merge windows to get to the end goal, so be it, but no temporary solutions meanwhile because "temporary" tends to last for at least 10 years in real life. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
