On Friday 20 April 2007 8:15 am, Alan Stern wrote: > 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
... it seems that maybe this driver isn't yet reporting protocol stalls when the gadget driver tells it to do so. But it's odd that there's no error diagnostic for that qualifier test. > > 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 ... and that's not the device qualifier test that's failing. > > > > > > 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. And yes, it will affect lots of things. Being able to properly handle ep0 protocol stalls is very important. (And for test #10, being able to do it even given the various races that appear with back-to-back messages.) > > 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. Ah, that's why there was no message for failing the device qualifier test. > > 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? It would seem that his driver isn't setting it to FULL speed when the device reset finishes. (It should be set to UNKNOWN on disconnect.) - Dave ------------------------------------------------------------------------- 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
