Uwe Bonnes wrote: > Jim> Unfortunately, the existing ftdi_determine_type considers anything > Jim> with bcdDevice >= 0x0900 to be a FT232H, which means that the > Jim> baudrate generation is incorrect if we just add a VID/PID. Would > Jim> this still be appropriate for -stable? Or maybe a stripped down > Jim> version with just the bare minimum to get it working (new VID/PID, > Jim> and force FT232RL chip type when bcdDevice == 0x1000)? > > Adding a seperate code path is a better i.m.h.o. That's easier if some > subtile problems surface later. Agreed, I was just wondering if combining the types would make more sense for -stable. Greg indicated that it doesn't (at least for now). > But how do you keep e.g. a FT20x from being handled as USART? I added a > quirk in my approach, looking for the string "FT23" in the device product > description . More explanations in the code... That part was intentional -- I think _all_ the FT-X chips should be handled as a USART. What else would they be treated as? They're not capable of being an I2C or SPI master, and no I2C or SPI details are ever exposed to the USB host -- they are only slave interfaces, and allow some other device to read and write into their FIFO using a protocol other than RS-232. The host side interface looks the same regardless of which chip you're using. They're essentially like the FT245BM in that regard. .. > Signed-off-by: Jim Paris <bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> Not sure what happened with the name there. Thanks, -jim -- 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
