Hi Greg, Thanks for your message. I'm always impressed by just how many drivers you manage to be involved with. On Thu, Dec 24, 2009 at 11:08:51PM -0800, Greg KH wrote: > On Thu, Dec 24, 2009 at 04:40:51PM -0500, Forest Bond wrote: > > I have a device that works well with the usbserial generic driver. > > Ick, never use the generic driver for a "real" device, please add the > device id to the proper "real" driver instead. Sorry, my knowledge of this is very limited. I assume when you say "real" driver, you mean a driver that is specifically designed for this device (or at least this class of device). No such driver exists, as far as I'm aware. > > However, I can't seem to get it to work on a system that also has a > > USB-serial converter attached. > > > > I've tried this: > > > > modprobe usbserial vendor=1d5f product=1004 > > > > ... which worked well on other systems. > > > > I've also tried this: > > > > echo '1d5f 1004' >/sys/bus/usb-serial/drivers/generic/new_id > > > > ...but that doesn't seem to work. > > Why not, what happens? Well, nothing happens. No /dev/ttyUSBn device appears, so I assume the device is not claimed by the driver. Perhaps you can suggest the correct way for me to determine what the driver is doing and where things are going awry. > > I've tried all of the above with ftdi_sio (the module for the USB-serial > > converter) unloaded. > > > > Poking around generic.c seems to indicate that it can only be used for a single > > device at a time. Is this true? > > No, not at all. Okay, I must have misunderstood the code or the context it runs in (both of which are very likely). > > Could the presence of an extra USB-serial converter make the generic driver > > unusable for my other device? > > It should not. That's what I would think. That may not be what is causing the problem. > > I got desperate and gave the option module a try: > > > > modprobe option > > echo '1d5f 1004' >/sys/bus/usb-serial/drivers/option1/new_id > > > > That seems to work. Is there any reason not to use the option module for a > > generic USB-serial device (i.e. will I see problems when I'm actually > > transferring data)? > > What type of device is this that you are trying to use the generic > driver for? You should use the real driver instead, so if it would be > controlled by the option driver, use it like you just did. This is a ViVOtech credit card payment device that provides two USB interfaces: bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None I assume the HID is for the touch screen on the device. I'm not currently interested in that functionality. As I understand it, the user space application wants a standard serial interface to the payment processing features of the device, so I need to expose a /dev/ttyUSBn device for that purpose. An engineer at ViVOtech said the following: It is a composite driver, supporting HID (class 3) and serial USB (class 2). For the USB serial (class 2), the data to be sent to the reader is transmitted directly over the USB connection with no encapsulation. As I said, both the generic usbserial driver and the option driver appear to be able to communicate with the device (based on my very limited testing that simply pings the device). My suspicion has been that the generic driver is more appropriate, but the impression I'm getting from you has called that into question. In short, there is no "real" driver. I suppose it would be fairly easy to create one that at least provides access to the USB-serial functionality, and I may be willing to do this when time permits. However, I'd like to have this running sooner rather than later. Do you think it is safe to use the generic or option drivers in the meantime? Why do you think the generic driver is not binding to the device on some systems? I should mention that the cdc-acm driver wants to claim the device but fails to do so with: /build/buildd/linux-2.6.24/drivers/usb/class/cdc-acm.c: Zero length descriptor references cdc_acm: probe of 1-1:1.0 failed with error -22 Thanks for your help. -Forest -- Forest Bond http://www.alittletooquiet.net http://www.pytagsfs.org
Attachment:
signature.asc
Description: Digital signature
