Hi,
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
