Hi, >> >> >> Ok, rephrase the question, is this the flow for bulk transfer? >> >> >> >> >> >> 1) data is received by Usb mass storage HW, the UDC driver ISR is >> >> >> called to read the data to usb_request buffer >> >> >> 2) bulk_out_complete() in gadget driver, is called to set buffer state to full >> >> >> 3) get_next_command() in gadget driver, is called to read the CBW. >> >> >> 4) do_scsi_command() to process SCSI command encoded in CBW >> >> >> 5) send_status() sends the CSW to host >> >> > >> >> > Something like below: >> >> > >> >> > OUT Token -> ISR -> giveback() -> bulk_out_complete() -> >> >> > get_next_command() -> do_scsi_command() -> usb_ep_queue() -> OUT/IN >> >> > Token -> ISR -> bulk_out_complete() -> send_status() >> >> >> >> For the IN Token, i will just write the data to the HW buffer, and the >> >> flow will go to send_status(). >> >> >> >> I use a different USB cable, now the USB gadget is able to receive >> >> bulk transfer data from host PC. I am working on the bulk transfer >> >> code. Thank you for the very useful answers. >> > >> > np >> >> In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and >> intr_in. Why is the intr_out endpoint not defined? > > because it's not needed. Read the USB Mass Storage Class specification > from usb.org Ok. In the gadget driver, it keeps on receiving the same bulk_out data, maybe because the data is not processed. The get_next_command is not called. g_file_storage gadget: bulk-out, length 31: 00000000: 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 00000010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C g_file_storage gadget: bulk_out_complete --> 0, 31/0 Is it because the bh->bulk_out_intended_length is 0? 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
