Hi Alan > > I have just written a ehci testing driver which enables the testing modes > > used for hw testing via a file in debugfs. This patch is for 3.4.47 not > > any usb branch. But if this driver is ready for mainline i will be happy > > to port it to whatever branch you wish. > > It's not clear why this patch is needed. Why can't the existing code > do what you want? > > > The only problem with the patch is that it is currently working on hw > > registers as the usb control msg in this patch is not working. For the > > time beeing i just commented out the usb_control_msg call and fiddled > > with the registers directly. This is one thing which might not be > > mainline compatible? > > Why do you want to have a debugfs file in the first place? What's > wrong with using usbfs or libusb? Uhm, we came from a vendor bsp where this functionality was available for the Freescale I.Mx35. After we where using the mainline kernel this functionality was missing and i was not aware how to trigger this stuff via libusb or usbfs? Also skimming over the library documentation i couldn't find any function to trigger the test modes. Besides having an easy way with a shell and a running kernel to trigger test modes is good to have hw vendors test their stuff? > > The call not working is: > > status = usb_control_msg(hub, usb_sndctrlpipe(hub,0), > > > > USB_REQ_SET_FEATURE, > > USB_RT_PORT, > > USB_PORT_FEAT_TEST, > > i << 8 | hub->portnum, > > NULL, 0, 1000); > > ^^^^^^^^^^^^^^^^^ this > > might be wrong? > > The hub->portnum part certainly isn't right. It is always equal to 0. > You need to put a real port number in there. That's why this function > call doesn't work. > > I have the strong suspicion that the marked agument is wrong? The direct > > manipulation of the portsc register works as expected. > > If what you expect is to enable test mode for port 1. What about the > other ports? Mh, which other ports ;-). The i.MX35 i was testing on had only one so actually i haven't thought of this. > > The testmodes array is magic in a way that the offset of the values > > corresponds directly with the PTC field (Bits 19-16) of the Port Status > > Control register. > Where did the FORCE_ENABLE_FS and FORCE_ENABLE_LS values come from? > They aren't in my copies of the USB or EHCI specs. Probably they are from the i.mx and could be dropped if not conforming to spec. > > Also there is a driver which does the tests with a special usb test plug: > > http://code.google.com/p/bricked/source/browse/drivers/usb/misc/ehset.c > > Its also sending these usb_control_msg but these are also not working. > > > > So if this usb_control_msg is working it would also be nice to get this > > driver mainlined. Any hints whats needed to get this into mainline? > > As far as I can see, there is no reason for this to be merged because > it doesn't do anything that can't be done already, using the existing > facilities. Do you have any pointer for me? If i would have found an easier way i would have choosen this one. As for the referenced driver: http://code.google.com/p/bricked/source/browse/drivers/usb/misc/ehset.c This is functionality which is not available within the kernel in a way that an external test device plugged triggers some test which in some cases even need interaction from the driver? Best regards Tim -- 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
