On Fri, 12 Jul 2013, Victor Yeo wrote: > Hi, > > > 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. Indeed, the Set-Config request completes after only 314 us, much less than 1 ms. Of course, that doesn't mean the gadget actually ran handle_exception() that quickly. More likely, the UDC told the host that the request had completed before it really was finished. > > 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. No -- the problem is that the UDC completes the Set-Config request before it should. In other words, it sends the DATA1 packet when it really should send a NAK packet. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
