lkml.org 
[lkml]   [2014]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early
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 first. In that case, the delayed
> > > status request is a response for a stale transfer, so it must not be
> > > sent to the host.
> > >
> > > Do dwc3 and composite.c handle this case correctly?
> > >
> > So the situation you describe is that we get the STATUS XferNotReady
> > event, but gadget queues a status request when control transfer already
> > failed.
>
> 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 setup function returns DELAYED_STATUS.
>
> After a few seconds, the host gets tired of waiting and
> sends a Get-Descriptor request
My understanding is dwc3 will return NYET to host for this
Get-Descriptor request transaction, as dwc3 is still in STATUS phase,
there's no buffer to receive anything in ep0-out. And your below
comments is not applicapable to dwc3.
>
> The gadget driver finally submits the delayed request response
> to the Set-Configuration request. But it is now too late,
> because the host expects a response to the Get-Descriptor
> request.
>
> > dwc3 can't move to SETUP phase until the status request arrives,
> > so any SETUP transaction from host will fail. If status request
> > eventually arrives, it already missed the first control transfer, and
> > I don't know how the controller will behave. If we still can get a
> > STATUS XferComplete event without actually transfer anything on the
> > bus, then we can move back to SETUP PHASE which will remove the stale
> > delayed status request and start the new SETUP transaction. But I think
> > in this situation, the host should already lose it patience and start
> > to reset the bus.
>
> My point is that the UDC driver can't handle this. Therefore the
> gadget driver has to prevent this from happening.
>
> That means composite.c has to avoid sending delayed status responses if
> a new SETUP packet has been received already.
>
> > Per my understanding, it's impossible for dwc3 to send a stale STATUS
> > request for a new SETUP transaction.
>
> dwc3 won't know that the status response is stale. It will think the
> response was meant for the new transfer, not the old one.
>
> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html


\
 
 \ /
  Last update: 2014-05-08 06:41    [W:0.079 / U:0.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site