On Tue, 22 Oct 2013, Victor Yeo wrote: > Hi, > > > It looks like you didn't add the dump_stack() call to the UDC driver's > > queue function. You need to add it. > > The attached is the log of dump_stack() call in the UDC driver queue > function, for the last few USB request in the USBCV "device descriptor > test � addressed state". From the log, after Set-Config request is > received, the UDC driver queue function is not called. That function > is called after Get-Config request is received. Interesting. This means the UDC hardware sent the DATA1 packet for the status stage even though the driver did not tell it to do so. Could this be a bug in the hardware? An alternative possibility is that the UDC driver doesn't do the right thing after calling fsg_setup. Perhaps when fsg_setup returns, the UDC driver always tells the hardware to send the DATA1 packet? > >> I also share the pseudo code of the setup data valid processing, i > >> suspect it may be related to the problem: > >> > >> receive setup data valid interrupt > >> find out the usb request field (bmRequestType, bRequest, wValue, > >> wIndex, wLength) > >> if (USB_CLEAR_FEATURE_REQUEST) > >> call usb_ep_queue() > > > > Don't you need to handle this in the hardware, just like > > USB_SET_FEATURE_REQUEST? > > USB_SET_FEATURE_REQUEST is handled in software. How come USB_SET_FEATURE_REQUEST is handled in software but USB_CLEAR_FEATURE_REQUEST is handled in hardware? That seems very strange. Why aren't they both handled the same way? 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
