Hi Greg <snip> > > > > 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. Alan userspace driver is a good replacement for the debugfs approach (If working that is, what i am expecting at this point.). So my patch is not needed no discussion about that. This tool covers then: http://www.usb.org/developers/compliance/USB-IF_USB_2_0_Electrical_Test_Spec081005.pdf the steps needed on the device to manually (by commandline) to enable the testmodes. But i am talking about this driver over here: http://code.google.com/p/bricked/source/browse/drivers/usb/misc/ehset.c There is a special usb debug device which can be switched to different "magic" usb id's which are supposed to set the driver into a testing mode. So the idea is that you just plug in this special and overpriced hardware and have your port in the configured testing mode on the device. The detailed procedure is detailed over here: http://www.usb.org/developers/onthego/EHSET_v1.01.pdf; So this is official functionality defined by the USB-IF. Keep in mind that an embedded linux device has no possibility to install the Intel USB Windows test suite and this is not needed with a *working* ehset driver in kernel. Also this enables testing the ports without access to the commandline. As i said this is a hardware driver which should IMHO live inside the kernel and should be implemented to fullfill the test procedures laid out by the USB-IF. 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
