Hi,
>> Yes, UDC driver has bug. After modifying it, it can receive Set-Config
>> request with a config value of 0. However, the "device descriptor test
>> - addressed state" still fails.
>>
>> Please see the attached log. The Set-Config request with a config
>> value of 0 is the second last USB request sent from the host. The last
>> USB request is Get-Config, which still returns config value of 1.
>
> This looks like another bug in the UDC driver. It performs the Status
> stage of the Set-Config request before the gadget driver has finished
> carrying out the request.
>
> Notice that the USB_REQ_SET_CONFIGURATION case in standard_setup_req()
> returns DELAYED_STATUS. As a result, fsg_setup() does not call
> ep0_queue(), and so usb_ep_queue() doesn't get called. The UDC driver
> is not supposed to ACK the Status stage of an OUT control transfer
> until usb_ep_queue() is called.
May i verify my understanding of Set-Config request packet flow?
Host Device
------Setup Packet---->
------Data0 Packet---->
<-----Ack Packet-----
------ In Packet ---->
<---- Data1 Packet ----
----- Ack Packet ----->
----- Out Packet ---->
----- Data1 Packet ---->
<---- Ack Packet -----
"ACK the Status stage of an OUT control transfer", is it referring to
the Third ACK packet? So UDC driver should ACK only after Data1 packet
is sent via the usb_ep_queue()?
>> In gadget driver, do_set_config(), if new_config is 0, the new_config
>> is not processed. So config value of zero will never be saved by
>> gadget driver. Isn't it?
>
> Look at do_set_config():
>
> /* Disable the single interface */
> if (fsg->config != 0) {
> DBG(fsg, "reset config\n");
> fsg->config = 0;
> rc = do_set_interface(fsg, -1);
> }
>
> /* Enable the interface */
> if (new_config != 0) {
> ...
> }
> return rc;
>
> So if new_config is 0, fsg->config remains set to 0 and the
> deconfiguration is processed by the do_set_interface() call.
Understand now. Thanks.
victor
--
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
