On Tue, May 13, 2014 at 10:05:34AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, May 13, 2014 at 09:45:51PM -0400, Zhuang Jin Can wrote:
> > Hi Balbi,
> >
> > Do you have any comment for this patch?
>
> do you have an easy test-case which I can use to validate on my end ?
The issue was reproduced
Hi,
On Tue, May 13, 2014 at 09:45:51PM -0400, Zhuang Jin Can wrote:
> Hi Balbi,
>
> Do you have any comment for this patch?
do you have an easy test-case which I can use to validate on my end ?
--
balbi
signature.asc
Description: Digital signature
Hi Balbi,
Do you have any comment for this patch?
Thanks
Jincan
On Wed, May 07, 2014 at 05:53:44PM -0400, Zhuang Jin Can wrote:
> A delayed status request may be queued before composite framework returns
> USB_GADGET_DELAYED_STATUS, because the thread queueing the request can run
> on a differen
On Thu, 8 May 2014, Paul Zimmerman wrote:
> > That doesn't handle the problem I described above. When the dwc3
> > driver gets the late delayed status response, it will think it is a
> > response to the new SETUP packet, and so it will carry out a bogus
> > transfer. It won't know that the statu
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, May 08, 2014 2:18 PM
>
> On Thu, 8 May 2014, Paul Zimmerman wrote:
>
> > > When the host already timed out the control transfer and started a new
> > > one. Here's what I'm talking about:
> > >
> > > Host sends a Set-Confi
On Thu, 8 May 2014, Paul Zimmerman wrote:
> > When the host already timed out the control transfer and started a new
> > one. Here's what I'm talking about:
> >
> > Host sends a Set-Configuration request.
> >
> > The UDC driver calls the gadget driver's setup function.
> >
> > The
On Thu, May 08, 2014 at 03:06:48PM -0400, Alan Stern wrote:
> On Thu, 8 May 2014, Paul Zimmerman wrote:
>
> > Just FYI, the DWC3 core is designed to always respond to SETUP packets.
> > It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up
> > properly according to the databook. I
On Thu, May 08, 2014 at 06:56:02PM +, Paul Zimmerman wrote:
> > From: linux-usb-ow...@vger.kernel.org
> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Paul Zimmerman
> > Sent: Thursday, May 08, 2014 11:42 AM
> >
> > > From: linux-usb-ow...@vger.kernel.org
> > > [mailto:linux-usb-ow.
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, May 08, 2014 12:07 PM
>
> On Thu, 8 May 2014, Paul Zimmerman wrote:
>
> > Just FYI, the DWC3 core is designed to always respond to SETUP packets.
> > It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up
> >
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern
> Sent: Wednesday, May 07, 2014 9:59 AM
>
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
>
> > > A similar problem can occur in the opposite sense: The thread queuing
> > > the delayed status
On Thu, 8 May 2014, Paul Zimmerman wrote:
> > Just FYI, the DWC3 core is designed to always respond to SETUP packets.
> > It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up
> > properly according to the databook. If the buffer fills up, then
> > further SETUP packets will get l
On Thu, 8 May 2014, Paul Zimmerman wrote:
> Just FYI, the DWC3 core is designed to always respond to SETUP packets.
> It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up
> properly according to the databook. If the buffer fills up, then
> further SETUP packets will get lost, but
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Paul Zimmerman
> Sent: Thursday, May 08, 2014 11:42 AM
>
> > From: linux-usb-ow...@vger.kernel.org
> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern
> > Sent: Thursday, May 08, 2014
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern
> Sent: Thursday, May 08, 2014 10:40 AM
>
> On Thu, 8 May 2014, Felipe Balbi wrote:
>
> > > The dwc3 driver should always prepare a buffer for the next ep0 SETUP
> > > packet as soon as it
On Thu, 8 May 2014, Felipe Balbi wrote:
> > The dwc3 driver should always prepare a buffer for the next ep0 SETUP
> > packet as soon as it retrieves the information for the current SETUP
> > packet from the buffer.
> >
> > Otherwise, as you described it, if the gadget driver never sends its
> >
On Thu, May 08, 2014 at 11:22:36AM -0400, Alan Stern wrote:
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
>
> > > dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does not
> > > allow it. A device must always respond to SETUP with ACK.
> > It true that device can not return NYET to a
Hi,
(using private email as I'm having issue with company's VPN, will get
that sorted out by tomorrow hopefully)
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
> > > dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does
> > > not
> > > allow it. A device must always respond to SETUP
On Thu, 8 May 2014, Zhuang Jin Can wrote:
> > dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does not
> > allow it. A device must always respond to SETUP with ACK.
> It true that device can not return NYET to a SETUP packet.
> A device must always respond to SETUP with ACK _if_ t
On Thu, May 08, 2014 at 10:25:46AM -0400, Alan Stern wrote:
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
>
> > > When the host already timed out the control transfer and started a new
> > > one. Here's what I'm talking about:
> > >
> > > Host sends a Set-Configuration request.
> > >
> > > T
On Thu, 8 May 2014, Zhuang Jin Can wrote:
> > When the host already timed out the control transfer and started a new
> > one. Here's what I'm talking about:
> >
> > Host sends a Set-Configuration request.
> >
> > The UDC driver calls the gadget driver's setup function.
> >
> > The
On Wed, May 07, 2014 at 12:59:06PM -0400, Alan Stern wrote:
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
>
> > > A similar problem can occur in the opposite sense: The thread queuing
> > > the delayed status request might be delayed for so long that another
> > > SETUP packet arrives from the host
On Thu, 8 May 2014, Zhuang Jin Can wrote:
> > A similar problem can occur in the opposite sense: The thread queuing
> > the delayed status request might be delayed for so long that another
> > SETUP packet arrives from the host first. In that case, the delayed
> > status request is a response for
On Wed, May 07, 2014 at 11:03:42AM -0400, Alan Stern wrote:
> On Wed, 7 May 2014, Zhuang Jin Can wrote:
>
> > A delayed status request may be queued before composite framework returns
> > USB_GADGET_DELAYED_STATUS, because the thread queueing the request can run
> > on a different core in parallel
On Wed, 7 May 2014, Zhuang Jin Can wrote:
> A delayed status request may be queued before composite framework returns
> USB_GADGET_DELAYED_STATUS, because the thread queueing the request can run
> on a different core in parallel with the control request irq.
>
> SETUP XferComplete IRQ
A delayed status request may be queued before composite framework returns
USB_GADGET_DELAYED_STATUS, because the thread queueing the request can run
on a different core in parallel with the control request irq.
SETUP XferComplete IRQ fsg_main_thread
--
25 matches
Mail list logo
