On Thu, 4 Jul 2013, Victor Yeo wrote:
> Hi,
>
> > Than either there is a bug in the UDC (or the UDC driver), or else the
> > host doesn't wait for the Set-Config request to complete before sending
> > the next request. What were the values of fsg->ep0_req_tag and
> > exception_req_tag?
>
> From the printk added, the values of fsg->ep0_req_tag and exception_req_tag are:
>
> fsg->ep0_req_tag 163, exception_req_tag 161
> fsg->ep0_req_tag 168, exception_req_tag 167
> fsg->ep0_req_tag 176, exception_req_tag 173
This means the host sent 2, 1, and 3 (respectively) control requests
before the first request was finished.
> Yes, this should be the root cause. For the setup stage of Set-Config
> request, the UDC driver can handle it well. But for the status stage
> of Set-Config request, somehow it is not handled correctly. When UDC
> driver receives the endpoint 0 IN token, it only clears the interrupt
> request. It will not send the Data1 packet unless usb_ep_queue() is
> called.
And yet it _does_ send the packet before usb_ep_queue() is called.
> > When your UDC driver calls the gadget driver's .setup() function, how
> > does it handle the return value?
>
> The code is as below:
>
> status = dev->driver->setup(&dev->gadget, &usb_ctrlrequest);
> if (status < 0)
> {
> dev->protocol_stall = 1;
> }
> else if (status == (DELAYED_STATUS))
> {
> /*NAK the IN packet from host*/
> }
Th "else if" part is wrong; it should just be an "else". As long as
status >= 0, the value doesn't matter.
In fact, the UDC driver shouldn't even know what DELAYED_STATUS is.
DELAYED_STATUS is supposed to be private, internal to the
file_storage.c file.
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
