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 :( > 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. > 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 :) 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
