RE: Disable bus's drivers_autoprobe before rootfs has mounted

[Peter Chen]

> > > > I am just worried if we change the behaviour of using gadget
> > > > driver, can it be accepted by user? If you think it can be
> > > > accepted if we can have some docs, we can implement manually
> > > > binding for gadget driver from now on.
> > >
> > > user shouldn't have to deal with direct module insertion/removal
> > > (unless he's a developer and actually *wants* to do that). Docs are
> > > already in tree. The entire configfs interface has been documented,
> > > it's based on those documents that Matt started writing libusbg.
> > >
> > > --
> > > balbi
> >
> > Yes, gadget-configfs is a good direction.
> >
> > I would like to know your plan for other gadget drivers
> > (g_mass_storage, g_webcam, etc)
> 
> they can be built dynamically too. We only provided a version of
> g_mass_storage in order to avoid regressions. We can't simply remove that
> driver from the kernel.
> 
> > All functions will be supported by configfs in future, and current
> > driver will be deleted?
> 
> I don't think we will be able to delete legacy drivers, but they're all
> supported through configfs. I guess only webcam is missing.
> 
> > - If yes, how to cover the user who still use the old file system?
> > - If no, which binding way for udc and gadget driver will be used?
> 
> going forward, we want to stick with configfs.
> 

ok, then, what's the plan for current bug for legacy gadget driver (eg, we
can't load gadget driver before udc is ready)? I know this bug is existed
from 3.10, we may need to at least 1 year for switch to configfs, it
includes lots of user habit problems. The user will complaint this problem
for more than 2 years. 

If you think we should fix this bug before we totally switch to configfs, I will
continue to enhancement my gadget bus implementation,
and let it support configfs and legacy gadget driver well.

Peter
 
--
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/