On Wed, 14 Jun 2017, Benjamin Herrenschmidt wrote: > On Wed, 2017-06-14 at 10:33 +1000, Benjamin Herrenschmidt wrote: > > On Tue, 2017-06-13 at 15:08 +1000, Benjamin Herrenschmidt wrote: > > > Now, what I observe is that when the mass storage gets bound to the > > > UDC driver: > > > > > > - First the endpoints are properly allocated by my match callback, > > > ie, epautoconf is called to allocate EPs to the function. > > > > > > - But right away, composite.c calls usb_ep_autoconfig_release() > > > effectively releasing those 2 endpoints. > > > > I confirmed this by reverting to my old "single UDC" driver (so a more > > standard setup without all my hooks) and putting a WARN_ON(!ep- > > > claimed) in usb_ep_enable(). > > Ok, this is a global issue. Creating functions via configfs leads > to the same problem. I've added traces to epautoconf and to EP release > and reset and you can see what happens here (I also have the > WARN_ON(!ep->claimed) in usb_ep_enable): I think the problem is that you misunderstand how epautoconf is intended to work. I'm not the expert on this stuff -- Felipe is. Still, as best I understand, the idea is that a gadget driver or the composite core will attempt to allocate all the endpoints for a particular configuration at one time, during the gadget's startup. It will then release those allocations and move on to allocate the endpoints for the next configuration, and so on. At the end, all the allocations have been released. When the time comes to actually enable the endpoints (that is, when the gadget receives a Set-Config or Set-Interface request), there's no need to allocate anything again. The driver remembers which endpoints had been allocated originally for that config/altsetting combination and uses them. Obviously this arrangement was not designed with multiple devices below a virtual hub in mind. Perhaps you can figure out how to adapt it to your needs. 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
