On Thu, 9 Jun 2011, Felipe Balbi wrote: > > Wait a minute. There are some venerable standalone gadget drivers, and > > I don't see any good reason for forcing them to use the composite > > framework. In fact, didn't David specifically avoid doing that, in > > order to save the unnecessary overhead? > > I don't really remember that, so I might have missed. OTOH, composite.c > is fairly simple and the only gadget driver not using it is > file_storage.c, but having a f_msc.c wouldn't hurt. We already have f_mass_storage.c. There are two different versions of the storage gadget: my original standalone driver and Michal's adaptation to the composite framework. Are you suggesting that I bite the bullet and withdraw g_file_storage? > > > 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, > > > > Why? What's wrong with leaving the operations inline? Most of them > > are function calls anyway. > > keep reading. The idea is to move the otg notifier to be a UDC notifier. > Most of the notifications are from the gadget anyway: Suspend, Resume, > Enumerated with xxx mA configuration, etc. But what does this have to do with all the inline operations in gadget.h? For example, what is the connection between otg notifiers and usb_ep_enable()? > > > in case of mass storage, if > > > removable == 1, it can activate on bind() time, else it needs to wait > > > until a file is echoed to "file" sysfs attribute and so on. > > > > That's not how the mass storage drivers work. If the "removable" flag > > isn't set, they _require_ a backing file to be specified at load time > > and the "file" attribute is read-only. > > exactly... if removable == 1, it means we're a card-reader (or CDROM) so > we can connect to host even without a backing file ;-) No, no -- consider what happens when removable == 0. If you wait until a filename is echoed to the "file" sysfs attribute, you'll be waiting a long time because the attribute will be read-only. > > > After all this is done, we need to make gadget framework handle the > > > start of the enumeration too. Today every gadget driver starts a > > > transfer on probe() time to wait for the SetAddress command so ep0 > > > handling is always "special" and separate from all other endpoints, I > > > > But ep0 _is_ special, for several reasons. Furthermore, the initial > > transfer doesn't wait for the Set-Address request; it handles any > > control request. For example, the first request sent by a Linux host > > to a new device is Get-Device-Descriptor, not Set-Address. > > well, I though you would have gotten the point. The thing is that there > is a duplication there. All controllers have to "bypass" usb_ep_queue() > and that's always a bit tricky to get right. So, if we know every > controller will _have_ to start a ep0-out transfer to receive the first > USB Setup Packet, then we can combine that on an upper layer and free > all controllers from having to do that. The gadget framework doesn't use usb_ep_queue() to start a control transfer on ep0. It is used only for the data and status stages, not the setup stage. Which means that _no_ controller has to start an ep0-out transfer to receive the first Setup packet. > > Does anybody have any experience with how the Linux gadgets are being > > used in commercial devices? It might be good to get some feedback from > > the people who actually need to make this stuff work in real life. > > Well, at least I've put 3 products on the market, all of them got USB > certification. Does that count ;-) ? Hmmm... I have a Mobile Internet Device made by some Chinese company that runs g_file_storage by default. The backing file is a partition on an SD card -- and that partition is also mounted at the same time, which is strictly against the rules. This suggests that many of the people using the gadget software don't have a very good idea of what they're doing. Alan Stern -- 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
