Hi, On Fri, Jul 12, 2013 at 04:20:04PM +0800, Victor Yeo wrote: > >> However, the USB-2 spec says (section 9.2.6.4) that devices should be > >> able to carry out requests with no Data stage (such as Set-Config) > >> within 50 ms. Does your gadget really take longer than that to handle > >> the exception? > >> > >> To find out, collect a usbmon trace showing what happens when your new > >> driver is plugged into a Linux host. > >> > >>> I have set the NAK and > >>> stall the endpoint 0 after receiving Set-Config request, however, > >> > >> That doesn't make sense. Stalling the endpoint means sending a STALL > >> packet. You can't send both a STALL and a NAK. > >> > >>> Get-Config request is still sent out by USBCV host immediately. > >> > >> There should be at least a 50-ms delay, unless the UDC driver is doing > >> something wrong. > > > > The latest usbmon trace is attached. From the trace, the timing is > > within 50ms from Set-Config request to the next request. > > > >> Does your gadget really take longer than that to handle the exception? > > Yes, i think there is a delay before gadget calls the > > handle_exception() routine. So the problem is before > > handle_exception() of Set-Config request is called, the next request > > is sent out already by the host. So if the next request is Get-Config, > > it will not return the latest config value. > > As can be seen in the gadget driver log below, after Set-Config > request is received, another two more requests are received before > handle_exception() is called. If there is a way to call > handle_exception() immediately after Set-Config request, it would be > very helpful.
this is clearly a bug in your driver, host wouldn't send you more requests unless you acknowledge the previous one. You should be naking those extra requests until you're ready to ack. Frankly, we have quite a few UDC drivers passing all USBCV tests. -- balbi
signature.asc
Description: Digital signature
