On Thu, 2017-06-15 at 14:13 +0300, Felipe Balbi wrote:
> > 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.
Dunno... overall everything else is quite separate in the HW..
As it is, my driver works with only that patch adding the EP dispose
callback (I've sent an RFC for you to look at). The only 2 "quirks"
related to the multi-port aspect are the EP allocation issue and the
sysfs layout that made me add an intermediary device per port. All
quite trivial things.
> Something like:
>
> struct usb_gadget_port {
> struct list_head list;
.../..
> 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.
I suspect it's not a great solution. My feeling is that that would be
adding complexity to the framework which really doesn't need it.
I like keeping the grouping away from the core. Take ethernet for
example: a multi-port ethernet driver exposes multiple ethernet
independent interfaces to the networking stack. If they happen to have
shared internal resources, that's something the driver deals with, if
needed with the help of hooks here or there. (I've wrote one a few
years back that had a shared NAPI for example bcs the interrupt masking
was global).
Same goes with most things really. You don't want to blow up the
core/composite/... for that.
I think it makes much more sense to improve the lifetime handling of
EPs and maybe the sysfs layout a bit (though the latter could cause ABI
issues so we can leave that alone for now and just require what I do in
my driver now which is to create sub-devices per port).
At this stage, I would suggest just taking my EP dispose patch or
something similar, which addresses the problem in a rather simple way,
and look into it again later if more drivers start having similar
issues. However, it feel like the pair match_ep/ep dispose is
sufficient to deal with special cases.
The disposal happens at composite unbind time which matches the fact
that all the claiming happens at bind time, so it's rather clean.
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
