On Fri, 2017-06-09 at 14:08 +0300, Felipe Balbi wrote: > > I was originally thinking of having some device-tree construct > > assigning fixed number of EPs from the pool to the various devices, but > > that sucks... > > > > I'm trying to figure out if I can do something more dynamic. > > > > My idea is to not put the EPs in the gadget ep_list at first, but > > provide a match_ep() callback that effectively "allocates" an EP from > > the pool. > > but that's how the framework is implemented. Endpoints are kept in the > ep_list but they aren't allocated until an endpoint match happens. I think you didn't understand the structure of the HW, let me try to explain better: The HW provides a "top level" virtual hub with its own EP0 and EP1 (EP1 is partially HW managed, it's the hub status change interrupts). It then provide 5 "devices" (ie, gadget slots if you want) each with its own EP0. So I my driver effectively creates 5 gadgets. However those share a single global pool of "generic" EPs for all the non-0 endpoints. Those generic EPs can be of any type (bulk, iso, int), any direction, and can be assigned to any EP number (EP address) of any of the 5 devices. Thus I have 5 different EP lists, and I can't link my EPs to more than one at a time :) So I want to be able to "assign" (or "allocate") EPs from that global pool to the gadgets based on the needs of the functions bound to them, roughtly at bind() time since that's a good place to fail if necessary (much better than doing it at endpoint enable()). My idea is to override match_ep (which is easy since my endpoints support all types) so that it picks up an EP from the generic pool, and returns it after adding it to that gadget's list. > > It looks from a cursory glance at the code that it might work, with a > > reasonable failure mode since running out of EPs would typically make > > functions fail at bind() time. > > > > However we're missing a "free" :-) > > We don't need a free. Once a function is unbound, endpoints *must* be > free. No, I need it in order to return the EP to the global pool (and take it out of the gadget's list). > > I *think* (please correct me if I'm wrong) that adding a callback for > > that and plumbing it this way would work, let me know what you think. > > I'm not entirely sure you need it. How else can I deal with my issue ? Cheers, Ben. -- 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
