Hi, Alan Stern <[email protected]> writes: >> > 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. >> >> Yes, you are right and part of the confusion comes from the comment >> next to the release call saying that set_alt or a future bind will set >> "claimed" again since that's not going to happen. >> >> My latest message clears that up and proposed various options to handle >> this for me. I've also sent an RFC patch adding a hook that I've tested >> with simple configs and works. I'll do more testing tomorrow with more >> complex setups. > > I don't have a clear idea of the best approach for this problem. > Perhaps Felipe will suggest something.
I wonder if introducing the idea of "gadget ports" would be better
here. It might be simpler to implement a single gadget controller with N
ports, rather than multiple gadget controllers sharing the same endpoint
list.
Something like:
struct usb_gadget_port {
struct list_head list;
struct usb_udc *udc;
struct device *dev;
struct usb_gadget *gadget;
struct work_struct work;
[...]
};
struct usb_gadget {
struct list_head ports;
struct list_head ep_list;
struct usb_gadget_ops ops;
[...]
};
The difficulty here would be to teach the framework about the difference
between ports and gadgets. But at least we don't need to talk about
sharing endpoints among several gadgets.
--
balbi
signature.asc
Description: PGP signature
