Re: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Alan Stern <stern@rowland.harvard.edu>]

On Sun, 8 Feb 2015, Ruslan Bilovol wrote:

> Hi Alan,
> 
> On Thu, Jan 29, 2015 at 5:56 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Thu, 29 Jan 2015, Ruslan Bilovol wrote:
> >
> >> Change behavior during registration of gadgets and
> >> gadget drivers in udc-core. Instead of previous
> >> approach when for successful probe of usb gadget driver
> >> at least one usb gadget should be already registered
> >> use another one where gadget drivers and gadgets
> >> can be registered in udc-core independently.
> >>
> >> Independent registration of gadgets and gadget drivers
> >> is useful for built-in into kernel gadget and gadget
> >> driver case - because it's possible that gadget is
> >> really probed only on late_init stage (due to deferred
> >> probe) whereas gadget driver's probe is silently failed
> >> on module_init stage due to no any UDC added.
> >>
> >> Also it is useful for modules case - now there is no
> >> difference what module to insert first: gadget module
> >> or gadget driver one.
> >
> > It's possible to do all this much more simply.  In fact, I posted a
> > patch some time ago to do exactly this (but I can't find a copy of it
> > anywhere).
> 
> Unfortunately I didn't find your patch.

> > You don't need all this stuff.  What's the point of keeping track of
> > names?  If there are any unbound gadget drivers pending, a newly
> > registered UDC should bind to the first one available.
> 
> It's because gadget driver may be bound to usb_gadget in two ways:
>  - standard way - in this case any available udc will be picked up
>  - by name of udc, in this case only matching udc will be picked up

Where did this "by name" feature come from?  You did not mention it in 
the patch description.

Why bother matching by name?  Why not simply take the first available 
UDC?

> Main feature of my path is not only deferred binding of gadget driver,
> but also possibility to register/unregister udc at any time.
> This is useful for user who can load, for example, udc module
> if needed and unload it safely, not touching gadget driver.

We can already do that with the existing code.  There's no need for a 
patch.

Also, it's not clear that the existing gadget drivers will work 
properly if they are unbound from one UDC and then bound again to 
another one.  They were not written with that sort of thing in mind.


On Mon, 9 Feb 2015, Peter Chen wrote:

> In fact, both I and Robert Baldyga posted patches to try fix this
> problem.
> 
> http://marc.info/?l=linux-usb&m=139287784610046&w=2
> http://lwn.net/Articles/601839/

That's right.  The patch I wrote was a lot like Robert's patch (the 
marc.info URL above).  His approach can be simplified a little; the 
"attached" field isn't needed if the driver_list holds only unbound 
gadget drivers.

> I tried to use Robert's solution (fix some bugs) in internal tree, but
> the mass storage gadget still has problems to work if unload udc first.
> The possible reason should be: it has two places to call
> usb_composite_unregister.

The mass-storage gadget driver can be fixed, if necessary.

Alan Stern