Hi,
>> >> > Is there any way to to further debug into why do_scsi_command() is not
>> >> > called?
>> >>
>> >> usbmon, printk(), trace_printk(), kernel function tracer, there are many
>> >> ways choose one and spend some time debugging, I'm sure you'll find the
>> >> bug.
>> >
>> > It sounds like the UDC driver now works okay for control transfers but
>> > not for bulk transfers.
>> >
>>
>> Some code in file_storage.c that i cannot understand. In
>> ep0_complete(), the code snippet:
>>
>> if (req->status == 0 && req->context)
>> ((fsg_routine_t) (req->context))(fsg);
>>
>> Does the UDC driver provide the context pointer to file_storage.c?
>
> That belongs to the gadget driver. file_storage.c maintains that
> req->context.
>
>> Another gadget question: get_next_command() is receiving command from
>> host PC, UDC HW isr routine is also receiving data from host PC. What
>> is the difference between these two?
>
> hmm... ISR receives data and bounces it back to gadget driver. What do
> you mean ?
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
i see this code snippet in fsg_main_thread(), i cannot understand it,
please tell me what the purpose of this code is. is handle_exception()
tries to process error condition?
if (exception_in_progress(fsg) || signal_pending(current)) {
handle_exception(fsg);
}
thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
