I have modified the ftdi_sio kernel driver so as it provides one new IOCTL, which allows to use the ftdi_sio driver for other devices and unlocks all functions of FTDI chips (for example see http://www.ftdichip.com/Support/Knowledgebase/index.html?ft_setbitmode.htm)
I had a discussion about this topic with greg k-h (maintainer of usb-serial linux drivers). He doesn't like adding ioctls to the usb-serial for obvious reasons. I agree with him, but as I don't see any better solution (see our conversation below), I think the modified driver should be part of Linux kernel.
What has to be done before pushing this to kernel?
> How about a separate driver entirely? Would it make sense to not be a > serial device at all, and just use ioctls to control the rest of the > chip in this manner? If so, a new driver would make sense for the > device, right? I think that having it part of usb-serial is good idea for many reasons: 1) FT232 is serial port in almost all cases ... 2) FT245 is FIFO port, but has same interface as above chip 3) both chips have same VIP/PID 4) all blank FT devices use default VID/PID which is handled by ftdi_sio (and it's necessary to use FT_VendorRequest to re-program the internal EEPROM) 5) There is many applications (mostly under Windows) which use default VID/PID device, but they need FT_VendorRequest for enabling BitBang mode and other functions (i.e. ChipID feature) 6) FT3232C is double (!!) serial port, but also JTAG interface, etc. This is configured via FT_* functions. And with default VID/PID handled by ftdi_sio. So I think it should be part of your usb-serial drivers. Using libusb is not a solution, because of performance reasons and second, Win32 apps (under wine) require real file handle for serial port, not some imaginary number (i.e. select, read, write, close must work on all FT_HANDLEs).
> I'm just loath to add a bunch of new ioctls to an existing serial > driver, especially when the ioctls have nothing to do with a serial > port, as you can imagine. I understand this, but from my point of view it's bad for Linux if FT_* functions are not available (some applications cannot be ported, for example our automotive diagnostic software), and its' even worse to split drivers, because it's duplicate work, etc. > > I have browsed other drivers and I think ezusb is another candidate > > for having an ioctl to write to MCU memory (this would allow someone > > to write Wine native DLL that will bring some other applications using > > TI's USB devices to Linux world!). > Why would the ezusb driver need this? It's just there for downloading > firmware to a type of hardware. I don't insist on this, but we were playing a lot with TI's USB solutions before we decided to use FTDI, and this is required for development. Again, it would allow users to use TI's tools under Linux when someone creates Linux native emulation DLL for Wine (which should not be a problem at all!). What would you say about adding two IOCTLs implementing a) SIO_VENDOR_INFO request, which would return vendor-related information about device with some common structure for all usb-serial devices (currently would be used only by FTDI driver and maybe also EZUSB) b) SIO_VENDOR_REQUEST, which would allow some special functions like FT_* from FTD2xx.DLL and maybe EZUSB internal MCU direct access (firmware development and upload). I will also implement emulation of FTD2xx.dll for Wine, which will allow users to run FTDI-based applications under Linux. There is a lot of USB chips that behave as serial ports, but have *a lot of* other functions like GPIO, reconfiguration, special modes (parallel, bitbang, ...) etc. This will not be just for FTDI, but possibly also others. Change your mind please, I think that added value to the Linux community will be quite big. When there are no real-world apps for Linux, it will never be widely used. And FTDI is very popular IMHO.
> I don't understand why this shouldn't be done using libusb from > userspace? What distro problems are you having? libusb works fine on > all arches that Linux supports.At the moment there are 3 drivers under Linux: