On Sun, May 16, 2010 at 05:48:09PM -0700, Greg KH wrote: > On Mon, May 17, 2010 at 02:05:27AM +0300, Matti Aarnio wrote: > > Hi, > > > > People are aware of FTDI's FT232 serial port chips, and FT245 printer port > > chips, but they are actually more generic devices. There are serial port devices, > > and there are generic FIFO devices. (www.ftdichip.com) > > > > Worst of all, they all use default ID pair 0403:6001, which is now handled by > > the ftdi_sio driver. (Dual and quad versions have different IDs, handled by > > same driver - lattest bunch has very peculiar capabilities: JTAG, and SPI on > > serial port, same pins also serve as generic data FIFO...) > > Unfortunately a non-zero number of vendors are outputing hardware that use > > the hardware default ID pair :-( > > > > A distinguisher in between the devices with same ID codes could be USB device > > descriptor's iProduct string. That one is usually defined by the hardware > > vendor to be their actual product name. > > > > This relates to recent _audio_device_ case, where device maker apparently has > > used FTDI FIFO chip, and then just hacked things at Windows driver for it. > > Ugh, you are kidding me. That's just horrible :( You wish... I happen to have hardware that behaves like this. I do have even an old Linux driver for it. (Getting it to compile on modern Linux was a bit of work in itself..) http://ham.zmailer.org/oh2mqk/linux-sdriq-usb-driver.c Source for the driver is on Linrad package, which is GPL licensed, but getting sign-offs from original authors may not be easy... "lsusb -v" output is at the end of this email. > > Getting hardware makers to fix their device firmware is usually not an option, > > as much as one would like to. > > > > So, how to really separate devices that are treatable as serial ports, and > > at ID level identical devices that are something else entirely? > > The driver can, and does, match on device id, then can look at > endpoints, and any number of other things (query the device, look at the > strings, match the serial number, etc.) If anything doesn't look good, > it can always fail to bind to the device. OK. Then we can teach ftdi_sio about "bad iProduct strings", so that it will not bind on this one, and teach this one to bind only if the iProduct string is correct one. (For the ID pair 0403:6001.) > > Maybe this needs some new infrastructure, but I would consider at least > > following approaches: > > > > - Let multiple device drivers be bound on same ID pairs > > At device setup time do see if driver A can handle it, but > > if it says "not me", then try driver B, etc. > > We do that today. > > > - Bind device drivers on more than just the ID pair, like use > > also iProduct string, iSerial string, etc. > > See above, in your probe callback, you can do whatever you want. If you > don't think this is really a device you can control, just fail the > probe call and the driver core will move along and call the next > matching driver. > > Have you tried this out and seen some failures? Perhaps we need to be > more strict within the usb-serial ftdi_sio driver to abort on some of > these crazier devices? If so, patches are always gladly accepted :) I have plugged the device in and seen that it gets bound by ftdi_sio. Naturally it does not work. The sdriq driver bound OK when I had disabled ftdi_sio manually, but I prefer stable solutions over temporary hacks, and had other projects to do before continuing on this. (I have also forgotten the exact status of the "sdriq driver" in my last tests.) > thanks, > > greg k-h Best Regards, Matti Aarnio Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 6.00 iManufacturer 1 FTDI iProduct 2 SDR-IQ iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 400mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 SDR-IQ Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) -- 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
