Thank You Michal, I am testing now the unchanged usb.c example (www.linux-usb.org/gadget/usb.c) as user space application on my ARM Cortex A5 with atmel_usba_udc driver. When I run the Command Verifier, all Tests up to "Interface Descriptor Test" are passed. "Endpoint Descriptor Test - Configured State" fails while the application usb.c does not give output til the Test "Suspend/Resume" Test. This is the output during "Suspend/Resume" Test: fd 5, unclaimed = 0 fd 4, unclaimed = 0 reset source fd: No such device reset sink fd: Bad file descriptor ... protocol stall 01.0b ep0 stall: Identifier removed DISCONNECT CONNECT high speed SETUP bReqType 00 bReq 09 value 0003 index 0000 length 0 CONFIG #3 simple_sink_thread start -1234979728 fd 4 simple_source_thread start -1226591120 fd 5 The following tests "Remote Wakeup Test - Enabled" and "Remote Wakeup Test - Disabled" both are passed fine as are all the others. But when I repeat the tests, at some point, I always get simple_sink_thread open ep2 error 16 (Device or resource busy) simple_source_thread open ep1 error 16 (Device or resource busy) while the Tests are still marked as "passed" excpept for the "Halt Endpoint Test". That one results in udc: ep0: Invalid setup request: 82.00 v0000 i0081 l2, halting endpoint... udc: ep0: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint... on the serial console output. I thought the usb.c example was user space application that would be "conform" so the Command Verifier Tests would all pass? Where Is my mistake here? Thanks in advance for any hints! I'm really stuck on this issue since I don't really know the origin of the failure. On Fri, Jan 3, 2014 at 4:32 PM, Michal Nazarewicz <mina86@xxxxxxxxxx> wrote: > On Fri, Jan 03 2014, Marco Zamponi wrote: >> Thank you Roshan for the patch and thank you Michal for the discussion! >> Appearently I am not as familiar with USB as you guys are. But what I >> understood from the discussion is, that if I apply the patch from Roshan to >> f_fs.c and composite.c, the CV Test should not fail? > > That may be true, but it will change the behaviour of f_fs.c and thus > may fail existing user space code, so it's better to actually fix user > space code that uses f_fs.c with incorrect assumptions. > > -- > Best regards, _ _ > .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o > ..o | Computer Science, Michał “mina86” Nazarewicz (o o) > ooo +--<mpn@xxxxxxxxxx>--<xmpp:mina86@xxxxxxxxxx>--ooO--(_)--Ooo-- > > -- 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