Hi,
>> The CV log is attached (Dev_desc_test-Address state.html). Is it helpful?
>
> It doesn't help very much. Can you get a more verbose log, one that
> lists all the transfers?
>
> It looks like the problem could be that the host and the gadget don't
> agree on what packets have been sent and received. If that's true,
> you may need to use a USB bus analyzer to diagnose it.
Unfortunately, that USB 2.0 command verifier is not able to generate a
more verbose log.
>> The "g_file_storage gadget: in handle_exception loop" is from the DBG
>> that i added in fsg_main_thread(). I also attach an updated gadget log
>> file, which corresponds to the CV log. I cannot figure out this part
>> of the code about handle_exception(). Is a signal received and
>> handle_exception() is supposed to perform some action?
>>
>> if (exception_in_progress(fsg) || signal_pending(current)) {
>> handle_exception(fsg);
>> DBG(fsg, "in handle_exception loop\n");
>> continue;
>> }
>
> Okay, now I understand. The "in handle_exception loop" line in the log
> is from an exception that happened earlier, before the
> Get-Config-Descriptor request. The exception was caused by the
> preceding request, Set-Config: The USB_REQ_SET_CONFIGURATION case in
> standard_setup_req() calls raise_exception(). The handle_exception()
> routine then does the real work of changing the configuration, by
> calling do_set_config(). The Get-Config-Descriptor request just
> happened to arrive before your DBG line was executed.
Thanks a lot. i understand this part now. Do you notice the Set
Address request is not seen by the gadget driver? The Set Address
request is handled by the hardware. Could it be the root cause? As
gadget driver may expect the address information from the host, and
for now UDC driver just ignore the Set Address request ?
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
