Re: [PATCH v7 0/4] usb/gadget: independent registration of gadgets and gadget drivers

[Peter Chen]

On Thu, Dec 10, 2015 at 11:13:24AM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Balbi <balbi@xxxxxx> writes:
> > Felipe Balbi <balbi@xxxxxx> writes:
> >> Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> writes:
> >>> Hello,
> >>>
> >>> This is a resurrection of the patches initially submitted by Ruslan
> >>> Bilovol in the following thread: https://lkml.org/lkml/2015/6/22/554
> >>>
> >>> The changes since the original submission (v5) includes rebase onto
> >>> latest linux-next branch, simplification of the code requested by Alan
> >>> Stern and Felipe Balbi, removal of a patch, which deleted __init/__exit
> >>> attributes (this change has been already merged) and fixes of the
> >>> checkpatch issues.
> >>>
> >>> This feature is urgently needed, because it is not longer possible to
> >>> use workaround to avoid deferred probe in UDC drivers due to
> >>> not-yet-probed i2c regulator drivers (for more information see
> >>> https://lkml.org/lkml/2015/10/30/374 ).
> >>>
> >>> This patchset has been successfully tested on Odroid XU3 boards with
> >>> DWC3 UDC driver being deferred by missing regulator drivers.
> >>
> >> there is one problem with this patchset. If I try to statically link
> >> gadget drivers, only one can be chosen, even though I can enable both
> >> dwc3 and dummy_hcd just fine. And, actually, this brings another
> >> problem. How do we handle systems which have 2 USB peripheral
> >> controllers (say, 2 instances of dwc3) and choose which gadget driver
> >> will bind to which controller ?
> >
> > We also seem to have issues with Kconfig. If I try to make gadget driver
> > built-in, when compiling I'll get asked again if I want gadget drivers
> > built-in.
> >
> > Another one: I just tried dummy_hcd built-in, g_zero built-in, dwc3 as a
> > module. I can never load anything to dwc3 ;-)
> 
> In all fairness, none of these are regressions. Can we agree to look at
> these during v4.5-rc so maybe v4.6 has a final solution ?
> 
> cheers
> 

Hi Felipe,

To support all of these, it will let legacy gadget driver usage as same
as configfs. If the user wants these relative new features, why not let
they use configfs. For legacy gadget drivers, it is better to keep the
main structure unchanging, then the user will not be surprise.

Here, we just want a solution for known issue, but not new features.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/