Re: Oddity with EP configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2017-06-14 at 12:00 +1000, 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'm not having the stinking feeling that this is somewhat done on
purpose. ..

Since only one config is active at a time an the EPs are only
"enabled" when the config is activated (well set_alt really),
the same sets of EPs can be re-used for different configs and
that's pretty much what the code tries to do...

So an EP being "claimed" only matter within a single invocation of
usb_add_config() to sort out between the interfaces in that config...

Now if that's the case then it will of course not work for me as
I need to allocate from my global pool of EPs accross several gadgets
and thus several configs.

That leaves me with few solutions, what do you recommend:

 - The grossest one ... have the DT specify statically how many EPs
from the pool are assigned to each of the 5 gadget slots.

 - A better one but with nasty failure mode ... create a whole lot 
(all 15 ?) EP structs for each gadgets and internally allocate the HW
EPs in the enable() callback. That means it can fail at annoying times
such as when the host does a set_configuration etc...

 - Continue allocating EPs in match_ep, but release all the EPs for a
given UDC in a new UDC hook udc->gadget->ops->unbind() (or an EP op
"unbind" called for all EPs in the ep_list by the core at unbind time).
This means that we'll cleanup on unbind properly. We still end up
over allocating if, before bind, we create configs and delete some.

 - A variant of the above where we add tracking of the gadget and
#configs owning the EPs. That allows the cleanup to be done (via a new
EP unbind/release callback) from composite.c when a config is deleted,
by properly refcounting how many configs are using an EP. That's harder
as it's a bit more invasive on the overall core.

Any recommendation ? I'm happy to provide patches. I'll experiement
with the above approaches while waiting for your replies.

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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux