On Thu, Jun 27, 2013 at 11:56:13PM +0200, Tim Sander wrote: > 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. If you don't have a console, than you couldn't write to the debugfs files your kernel driver created, so you are out of luck anyway :) Just stick with Alan's userspcae code, all should be fine, less kernel code is best. thanks, greg k-h -- 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
