Hi, On Wed, Jan 23, 2013 at 11:20:56PM +0800, victor yeo wrote: > Hi, > > >> Here are the last two setup data and CBW data received. the > >> get_next_command() is not called when CBW data is received. the > >> bulk_out_complete() wakes up the thread, however, get_next_command() > >> still sleeps. i do not see where req->length is checked in gadget > >> driver. > >> > >> g_file_storage gadget: ep0-setup, length 8: > >> 00000000: 00 09 01 00 00 00 00 00 > >> g_file_storage gadget: set configuration > >> g_file_storage gadget: ep0-setup, length 8: > >> 00000000: a1 fe 00 00 00 00 01 00 > >> g_file_storage gadget: get max LUN > >> g_file_storage gadget: ep0-in, length 1: > >> 00000000: 00 > >> g_file_storage gadget: bulk-out, length 31: > >> 00000000: 55 53 42 43 a8 48 ed 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 > >> g_file_storage gadget: bulk_out_complete --> 0, 31/0 > > > > file_storage uses bulk_out_intended_length. > > > > You're on your own, to be fair, using a really old kernel, you never > > posted your UDC driver for review, so you need to fix it all up by > > yourself. > > > > Read the code, add prints, look at other UDC drivers. g_file_storage is > > next to perfect and proven to work with many, many different setups. > > Here is my UDC driver code. I use a kthread to poll the hardware > register EP0 and EP1 interrupt. I removed the HW register access code. you should an interrupt handler to handle interrupts from your device. Also, there are way too many mistakes on your driver, run checkpatch.pl, compile it with sparse, don't hardcode addresses, don't reimplement a bunch of infrastructure the kernel already gives you and check your list_head usage! Also, you shouldn't requeue the request yourself, gadget driver owns the request. -- balbi
Attachment:
signature.asc
Description: Digital signature
