On Sat, 21 Apr 2007, Hamish Moffatt wrote: > I'm working on a driver for the Philips/NXP ISP1362 device controller, > for the gadget API. I've started with Wolfgang Denk's work in his > linuxppc_2_4_devel tree and I'm adapting it to linux 2.6, my board etc. > (The 1362 has both a dedicated host port and a host/device/OTG port; I'm just > trying to get the latter working as a device only.) > > It's working well enough that g_zero loads, and is detected by the host > which then loads the usbtest module. I'm now trying to run through the > test suite in usbtest, using the testusb program. > > The ISP1362 is USB 2.0 but full/low speed only, so I have not defined > CONFIG_USB_GADGET_DUALSPEED. It appears that the correct handling of > this case is for the device to simply not respond to a request for the > device qualifier descriptor, which is what g_zero does.
The correct handling is to fail the request with a STALL (which is different from not responding). And _this_ is what g_zero does. > Test case 9 (chapter 9 control tests) is failing immediately on the test > for the device qualifier descriptor. The code checks for and tolerates > an EPIPE return from the USB core; > but on my system usb_get_descriptor is returning -ETIMEDOUT instead. > -ETIMEDOUT then gets compared with sizeof(...) which fails. (I'm using > an EHCI host. No you're not. EHCI runs only at high speed (except for a few oddball implementations with root-hub TTs), which your device doesn't support. Check the host's kernel log and you'll see. >) The kernel log says > > usbtest 2-3:3.0: TEST 9: ch9 (subset) control tests, 1000 times > usb 2-3: testusb timed out on ep0in len=0/10 > usb 2-3: testusb timed out on ep0in len=0/10 > ohci_hcd 0000:00:03.1: urb d74d6ac0 path 3 ep0in 5fd60000 cc 5 --> status -110 > ohci_hcd 0000:00:03.1: urb d74d6ac0 path 3 ep0in 5ec20000 cc 5 --> status -110 ^^^^ Like I said, you're using OHCI, not EHCI. > usbtest 2-3:3.0: get dev status --> -110 > > > I'd appreciate any advice on the following questions; > > 1. Why would I be getting ETIMEDOUT instead of the expected EPIPE? It > looks like this will affect a lot of tests in case 10 too. ETIMEDOUT means that the gadget didn't reply to the request. That is, it kept sending NAKs instead of sending STALL. Your driver isn't halting endpoint 0 when it should. > 2. If we know the speed (udev->speed == USB_SPEED_HIGH?), why fetch the > descriptor when we know it's not appropriate? First of all, udev->speed is USB_SPEED_FULL, not USB_SPEED_HIGH. Secondly, there's no reason a device running at full speed can't have a device qualifier. Just because it's running at full speed now doesn't mean it can't also run at high speed. > I changed it to accept ETIMEDOUT. Now I get a timeout every time > through this test, but it does pass. However, testusb's default is > to run 1000 iterations, which will take a long time with a 5 second > timeout each. You shouldn't subvert the test, you should fix your driver. Obviously. > 3. udev->speed is actually an unknown value (not _LOW, _FULL or _HIGH) > for my device apparently. I haven't researched this yet; is there an > obvious reason? What on earth are you talking about? It must be USB_SPEED_FULL. Have you tried printing out the value to see? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
