Hi, >> >> >> g_file_storage gadget: ep0-setup, length 8: >> >> >> 00000000: 80 06 00 01 00 00 40 00 >> >> >> g_file_storage gadget: get device descriptor >> >> > >> >> > For example, right here we should see the device descriptor data that >> >> > was sent back to the host. >> >> >> >> I checked the log again, the dmesg log did not contain that info. May >> >> i know which part of the gadget code will print out the device >> >> descriptor data that was sent back to the host? >> > >> > ep0_complete(), where it calls dump_msg(). >> >> My Usb gadget hardware was broken for 2 weeks, i am sorry for the late >> reply. Today i check the ep0_complete() function, it is not called >> during Usb mass storage gadget enumeration with host PC. I am not sure >> which part of file_storage.c called ep0_complete(). Please kindly >> point out to me. Thanks. > > ep0_complete() should be called by your UDC driver. Seriously dude, read > the documentation and read other drivers to figure out how things should > be called. A quick look in the storage drivers would have shown you that > ep0_complete() is passed in as req->complete() through the usb_request > structure. That structure (well, a pointer to it) is passed to the UDC > driver through usb_ep_queue(). All you had to figure out is "when it > req->complete called". ANY UDC driver would have given you the answer. > > Likely your UDC driver is still buggy, if you don't call ->complete(), > you're starving your usb_request queue. > Yes, ep0_complete() is called in UDC driver queue function, i just added it in and ep0_complete() is called now. The dmesg output is below. handle setup GET_DESCRIPTOR, 80, 6 index 0 value 100 len 40 g_file_storage gadget: ep0-setup, length 8: 00000000: 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor g_file_storage gadget: ep0_complete --> 0, 0/18 the req->actual is 0, so dump_msg() in ep0_complete() is not called. My UDC driver is still buggy. 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
