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 > > What's a bsp? Its a Board Support Package, its a common three letter acronym in the embedded space. And in the bad old times the vendors where not mainlining their stuff but giving you a codedump. But fortunatly times are changing... > > 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? > > Having a standard test program should be about as good as using a > shell. > > > > 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. > > Attached is a simple "porttest.c" program I just wrote. I haven't > tried it out, but any problems should be easy to find and fix. After > compiling it, you use the program by giving it the name of the hub's > device file, the port number, and the test mode number. For example, > if the hub is device 2 on bus 1, and you want to put port 3 into test > mode 5, you would type: > > ./porttest /dev/bus/usb/001/002 3 5 > > A big advantage of using this program is that it will work with > external hubs as well as with root hubs. And of course, it doesn't > require any changes to the kernel. So its as simple as an ioctrl. I am kind of stumped that i haven't found more while searching for it. Only some dead end discussions. Thanks for your effort! I hope i can give it a spin tomorrow. > > 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? > > Triggering particular behaviors when a device is plugged in is what > udev does. Yes but actually this code is an hardware driver and normally the hardware for a specific device is bound within the kernel driver infrastructure. Why should that be different for this little esoteric kind of hardware. UDev acts on the hardware later on. Besides beeing in embedded space sometimes you don't have udev or even a console in extreme cases. That is where this driver comes in handy. Besides making it easier for the hardware guys gives less clumsy hardware in the end. 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
