On Wed, 11 Jun 2014, Greg KH wrote: > We can't break existing systems, so I don't understand the issue here. > Just don't configure your kernel for a system you don't have / want, > right? > > > > > From what I read code, we can't implement above feature, but I may > > > > be wrong, if you have some solutions, give me some hints please. > > > > If there is no solution for above feature, do we agree with exporting > > > > .drivers_autoprobe for bus driver or something similar? > > > > > > I don't understand what you mean by this, care to show me with code? > > > > I mean the individual bus driver can't change bus->p->drivers_autoprobe? > > bus->p->drivers_autoprobe is handled at drivers/base/bus.c. > > > > If the individual bus driver can change bus->p->drivers_autoprobe, we > > can disable autoprobe (auto-binding) during booting. > > No, that's a core only thing.
Peter, correct me if this is wrong. It sounds like you want to have a way for the user to control which gadget driver gets bound to which UDC driver when everything is compiled into the kernel, nothing is built as a separate module. Is that the basic idea? This shouldn't be a problem if you use configfs or libusbg. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
