> > Yes, otherwise, the device which the udc is probed deferral and the
> > gadget driver is build-in will never work. If we skip fixing it, this
> > problem will exist for more than 2 years, it is too long.
> >
> > I have a support request from android team that usb peripheral
> > function never
On Mon, 16 Jun 2014, Peter Chen wrote:
> On Fri, Jun 13, 2014 at 10:19:36AM -0400, Alan Stern wrote:
> > On Fri, 13 Jun 2014, Peter Chen wrote:
> >
> > > OK, we can keep our g_xxx gadget driver just support the basic feature.
> > > But
> > > the bug that causes gadget driver load fail due to udc
On Fri, Jun 13, 2014 at 10:19:36AM -0400, Alan Stern wrote:
> On Fri, 13 Jun 2014, Peter Chen wrote:
>
> > OK, we can keep our g_xxx gadget driver just support the basic feature. But
> > the bug that causes gadget driver load fail due to udc is probed deferral
> > should
> > be fixed, do you thin
On Fri, 13 Jun 2014, Peter Chen wrote:
> OK, we can keep our g_xxx gadget driver just support the basic feature. But
> the bug that causes gadget driver load fail due to udc is probed deferral
> should
> be fixed, do you think so, we can't wait until configfs has total been ready.
That problem h
>
> > > 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?
> >
> > Yes
> > > > 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
On Thu, Jun 12, 2014 at 03:02:12PM +0800, Peter Chen wrote:
> On Wed, Jun 11, 2014 at 02:36:27PM -0500, Felipe Balbi wrote:
> > On Wed, Jun 11, 2014 at 11:29:57AM +0800, Peter Chen wrote:
> > > On Tue, Jun 10, 2014 at 11:35:07PM -0500, Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Tue, Jun 10
On Thu, 12 Jun 2014, Peter Chen wrote:
> > 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 th
On Wed, Jun 11, 2014 at 02:36:27PM -0500, Felipe Balbi wrote:
> On Wed, Jun 11, 2014 at 11:29:57AM +0800, Peter Chen wrote:
> > On Tue, Jun 10, 2014 at 11:35:07PM -0500, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote:
> > > > > Let's take USB peri
On Wed, Jun 11, 2014 at 03:27:13PM -0400, Alan Stern wrote:
> 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, w
On Wed, Jun 11, 2014 at 11:29:57AM +0800, Peter Chen wrote:
> On Tue, Jun 10, 2014 at 11:35:07PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote:
> > > > Let's take USB peripheral as an example, there is a device for
> > > > udc, and a device driv
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 s
On Wed, Jun 11, 2014 at 11:23:23AM +0800, Peter Chen wrote:
> On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote:
> > On Wed, Jun 11, 2014 at 10:14:40AM +0800, Peter Chen wrote:
> > > Hi Greg,
> > >
> > > Currently, we can't disable auto probe function during booting
> > > if both device and
On Tue, Jun 10, 2014 at 11:35:07PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote:
> > > Let's take USB peripheral as an example, there is a device for
> > > udc, and a device driver for usb gadget driver, at default, we want
> > > the device to be bou
On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote:
> On Wed, Jun 11, 2014 at 10:14:40AM +0800, Peter Chen wrote:
> > Hi Greg,
> >
> > Currently, we can't disable auto probe function during booting
> > if both device and device driver register code are built in due
> > to .drivers_autoprobe i
Hi,
On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote:
> > Let's take USB peripheral as an example, there is a device for
> > udc, and a device driver for usb gadget driver, at default, we want
> > the device to be bound to driver automatically, this is what
> > we have done now. But if ther
On Wed, Jun 11, 2014 at 10:14:40AM +0800, Peter Chen wrote:
> Hi Greg,
>
> Currently, we can't disable auto probe function during booting
> if both device and device driver register code are built in due
> to .drivers_autoprobe is a private value for bus core and this
> value can only be changed b
Hi Greg,
Currently, we can't disable auto probe function during booting
if both device and device driver register code are built in due
to .drivers_autoprobe is a private value for bus core and this
value can only be changed by sys entry.
It causes we can't implement feature that the user can cho
18 matches
Mail list logo
