Hello.
Gupta, Ajay Kumar wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sergei
Shtylyov
Sent: Friday, December 05, 2008 6:31 PM
To: Subbrathnam, Swaminathan
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[email protected]
Subject: Re: [PATCH 3/3] MUSB : Fix for STALL handling in musb gadget code
Helo, I wrote:
Hello.
Felipe Balbi wrote:
On Wed, Dec 03, 2008 at 07:50:46PM +0530, ext Swaminathan S wrote:
Fixes the SENTSTALL handling code to look for EP busy status before
returning the request. If EP is not busy do not giveback the
request and
restart the request in the context of CLEAR STALL feature from the
host.
Eacactly this restaring thing is *wrong*.
For example, the USB storage driver on the host side will expect CSW
to be received after STALL, but your code will continue to send data
if it had a data transfer still in progress at the time when the
endpopint was halted. Moreover, let's refer to USB 2.0 spec, section
5.3.2 "Pipes":
If a non-isochronous pipe encounters a condition that causes it to
send a STALL to the host (refer to
Chapter 8) or three bus errors are encountered on any packet of an
IRP, the IRP is aborted/retired, all
outstanding IRPs are also retired, and no further IRPs are accepted
until the software client recovers from
the condition (in an implementation-dependent way) and acknowledges
the halt or error condition via a
USBD call. An appropriate status informs the software client of the
specific IRP result for error versus halt
(refer to Chapter 10). Isochronous pipe behavior is described in
Section 5.6.
The similar word are repeated several times thtuout the spec. IOW,
host doesn't expect the STALLed transfers to be restarted.
IMO, much more consistent behavior would have been to abort the
current request once the endpoiont is halted, not waiting for the host
to poll the endpoint and get a real STALL from it.
This can be another solution
This is not just another solution, it's the only correct solution.
Consider the case of mutiple request being queued at the time endpoint
gets halted (not likely to happen but then agan Alan has told as that
all this is purely academic issue :-). After first getting a STALL
token, host is likely to stop polling the endpoint altogether. But
having gotten only one SENTSTALL interrupt, we'll abort only one
request, the others will continue to be queued. Now, after the endpoint
halt is cleared, we have them still queued and the first one programmed
into hardware. But the host does *not* expect this data already. The USB
storage driver expects CSW which is queued *behind* the data requests.
So, unless the endpoint halt serves as a barrier between the requests
queued before and after it, with the former ones being retired at this
point, the endpoint halt handling isn't consistent.
Do I make sense here? :-)
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
