Alan,
You are right w.r.t a gadget driver stalling an endpoint. Agreed that
a properly written drive may not stall an endpoint with inflight and queued
request's.
While working on DaVinci and other platforms that are utilizing the
Mentor controller and the Linux MUSB stack we faced the following issues.
1. In-correct cancellation of CSW request in the context of the
associated EP being stalled. This is leading to the USB device being reset.
This happens in the context of MSC gadget.
2. When WHQL tests are run against a RNDIS-CDC gadget the Halt Endpoint
tests fail on a BULK IN EP. This is due to the fact that that BULK-In EP had
in-flight IO's and the original gadget driver was returning failure status to
the Halt Endpoint request coming from the host (FIFO being full).
Your explanation would take care of the "first" scenario that I have
described as the MSC application ensures that it aborts all the outstanding
IO's before stalling the EP. Can we rely on application developers following
this model ??
It does not however take care of the second scenario. This will result
in the WHQL exception. Customers demand that their requirement for full
WHQL/DTM compliance as being critical for their product. I am in the process
of submission of the patch for addressing this beyond the current patch.
The submitted patch ensures that even if the application does not take
care of ensuring that the IO's are aborted or when the Host sends the request
to stall the EP (which has queue requests) the underlying driver puts in the
recovery mechanism from its end making it more robust.
Appreciate your feedback. Thanks.
Regards
Swami
> -----Original Message-----
> From: Alan Stern [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 05, 2008 10:18 PM
> To: Sergei Shtylyov
> Cc: Gupta, Ajay Kumar; Subbrathnam, Swaminathan; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [email protected]
> Subject: Re: [PATCH 3/3] MUSB : Fix for STALL handling in musb gadget code
>
> On Fri, 5 Dec 2008, Sergei Shtylyov wrote:
>
> > His initial patch, while fixing the incorrectly aborting the
> requests
> > queued *after* halting EP, is not able to *properly* abort an in-flight
> > request. And I doubt that the fact of sending a STALL over USB should
> play a
> > role in aborting the in-flight requests on halted EP.
>
> It's worth pointing out that this discussion is entirely academic. No
> properly-written gadget driver will stall an endpoint that has
> outstanding requests. The controller's behavior when such a thing
> happens is not specified by the gadget API, and it certainly would not
> be consistent among different controllers.
>
> In other words, it doesn't matter much what you guys do since this case
> should never come up. Your driver would be fully justified in failing
> the set_halt request with -EAGAIN -- see the documentation for
> usb_ep_set_halt. Then none of this complication would be needed, and
> the driver's memory footprint could shrink accordingly.
>
> Alan Stern
>
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
