On Tue, 26 Mar 2013, victor yeo wrote: > Hi, > > >> >> In the log file, is there any invalid request received on endpoint 0? > >> > > >> > In the usbmon file there is. It is this line: > >> > > >> >> f4ae6f40 1217192721 S Co:2:018:0 s 21 ff 0000 0000 0000 0 > >> > >> ok, i will add code to UDC to instruct hardware to send NAK upon > >> receiving invalid request on endpoint 0. Does it mean that UDC driver > >> has to check for invalid request on endpoint 0? > > > > No. The UDC driver has no way to know whether a request is valid or > > not. Read the description of the "setup" member of the > > usb_gadget_driver structure in the header file. > > > > I read that. The "setup" member of the usb_gadget_driver structure is > pointing to fsg_setup, in file_storage.c. The fsg_setup() function > handles the request on endpoint 0. So how could UDC driver know when > to send NAK? When an invalid request is received, the gadget is supposed to send STALL, not NAK. See the last two lines of the "setup" description: * USB byte order. Called in_interrupt; this may not sleep. Driver * queues a response to ep0, or returns negative to stall. "Driver ... returns negative to stall." That's how the UDC driver knows whether to send a STALL packet -- if the setup callback returns a negative value. Also, it looks like you didn't read this paragraph in the description of usb_ep_queue(): * Control endpoints ... after getting a setup() callback, the driver queues * one response (even if it would be zero length). That enables the * status ack, after transferring data as specified in the response. Setup * functions may return negative error codes to generate protocol stalls. * (Note that some USB device controllers disallow protocol stall responses * in some cases.) When control responses are deferred (the response is * written after the setup callback returns), then usb_ep_set_halt() may be * used on ep0 to trigger protocol stalls. Depending on the controller, * it may not be possible to trigger a status-stage protocol stall when the * data stage is over, that is, from within the response's completion * routine. Notice especially the fourth line. 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
