Hello Alan, I need again Linux USB community help, in resolving certain problems experiencing with the max3420 SPI USB driver. I am trying to run g_zero on the target side, and this runs successfully. This all in order to run testusb user space application which uses usbtest driver, in order to try to pass 16 tests proposed @: http://www.lpclinux.com/Blogs/Linux_USB_tests_using_Gadget_Zero_driver Excuse again for my ignorance in this area, as I explained earlier. I interpret data as much as I can with my modest USB domain knowledge. When I'll try to do Test Case 14: "Request vendor-specific control this test scenario sends ep0 messages by varying the size of the control message by the values the user application indicates. Internally, the test uses usb_control_msg to perform these control requests. The control message uses the USB compliance's vendor-specific control request parameter, such as 0x5b, 0x5c" I must admit: I experience severe problems with test 14. Everything is OK up to the sizes of 64B, with explicit command: ./testusb -a -c1000 -v1 -s64 -g32 -t14 /proc/bus/usb/002/028 test 14, 26.491822 secs If I issue explicit command: ./testusb -a -c1000 -v1 -s65 -g32 -t14 The target system crashes. I have some clues what is happening here. The ep0 (control I/F) is set to run up to 64B of data, at once. Once a packet size goes above, after target receiving 64B it should issue NAK to the host. I think this is done automatically by HW. Along that path, somewhere on target there is some packet corruption going on... I my opinion, ep0 should be able to handle lengthy packets up to test limit (0 to 512B). The proper behavior is: if testusb tries to pass packets to the ep0, and ep0 is full, the max3420 sends a NAK to the host telling it that it's not ready to receive more packets. Once the CPU has read all of the packets off the ep0, then it signals the max3420 device to let the host know that ep0 is ready for more. Does anybody experienced in The Past such problems, and what might be root cause(s) for such scenario to fail, as described above?! Thank you, Zoran Stojsavljevic -----Original Message----- From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] Sent: Friday, January 27, 2012 4:34 PM To: Stojsavljevic, Zoran Cc: linux-usb@xxxxxxxxxxxxxxx Subject: Re: USB Gadget Framework?! On Fri, 27 Jan 2012, Stojsavljevic, Zoran wrote: > Hello Alan, > > As I already outlined, I am new to this area, USB goodies, never had to deal with > these before. > > As I am diving more to the code, it is NOT only the gadget driver one supposed to > write, he also need to deal with the whole framework in order to make his own > driver to work! > > So, there are mandatory changes in other files, rather than just adding new > gadget driver files and modifying Kconfig and Makefile! > > It is not only to add to the gadget_chips.h, but to modify also epautoconf.c! > > [tbrymer@localhost projects]$ diff -abBu linux-2.6.34.10/drivers/usb/gadget/epautoconf.c MoonCreek/shadow-linux-2.6.34.10/drivers/usb/gadget/epautoconf.c > --- linux-2.6.34.10/drivers/usb/gadget/epautoconf.c 2011-06-26 09:47:42.000000000 -0700 > +++ MoonCreek/shadow-linux-2.6.34.10/drivers/usb/gadget/epautoconf.c 2012-01-27 00:00:06.480025575 -0800 > @@ -283,6 +283,19 @@ > if (ep && ep_matches (gadget, ep, desc)) > return ep; > #endif > + > + } else if (gadget_is_max3420 (gadget)) { > + if ((USB_ENDPOINT_XFER_BULK == type) || > + (USB_ENDPOINT_XFER_INT == type)) { > + if (USB_DIR_IN & desc->bEndpointAddress) > + ep = find_ep (gadget, "ep2in-bulk"); > + else > + ep = find_ep (gadget, "ep1out-bulk"); > + } else > + ep = NULL; > + > + if (ep && ep_matches (gadget, ep, desc)) > + return ep; > } Yes, that's normal for constrained hardware. > After adding this, I started seeing much better results than before: > > T: Bus=02 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 21 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs= 2 > P: Vendor=0525 ProdID=a4a0 Rev= 2.27 > S: Manufacturer=Linux 2.6.34.10-WR4.3.0.0_standard with max_udc > S: Product=Gadget Zero > S: SerialNumber=0123456789.0123456789.0123456789 > C:* #Ifs= 1 Cfg#= 3 Atr=e0 MxPwr= 2mA > I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbtest > E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > C: #Ifs= 1 Cfg#= 2 Atr=c0 MxPwr= 2mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver= > E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > The question here: Am I missing something else here? Do you have some guidelines > how to write gadget drivers, and how to properly modify USB framework to adjust to > new added gadget driver? No guidelines, only the files that are present in the kernel source tree. But it looks like you have solved your problems. Alan Stern -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 -- 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
