> > 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
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
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 is probed
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 works from
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
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 think so, we
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
>
> > > 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?
> >
> >
> > > > 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
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
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 know it can
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 has
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
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
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
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,
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, we can't
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 peripheral as an
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 that the
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, 2014 at
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
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
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 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 device driver
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
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 driver for usb
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
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
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
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
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 by sys
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 there are
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 is a
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 bound to
34 matches
Mail list logo
