FTDI FT_* support compatible with FTD2XX.DLL

Files: Please note: this is two hours hack! It took me more time to write the text below than the above files! The code needs cleanup, some additional checks, etc. test.c will become a replacement of ftd2xx library (I already have some parts done, but bound to Windows drivers). For API description see this pdf

Why this ?

FTDI is a company providing USB-serial (and FIFO,JTAG,SPI,...) connectivity solution chips. Linux kernel supports this "platform" natively in the kernel and via libusb userspace drivers. Unfortunately the kernel driver has no support for extended functions (such as configuring devices, selecting channel(s), reading burned-in ChipID security protection number, etc), which limits use only to generic serial port. Libusb-based libftdi (and binary-only libftd2xx from FTDI) provide this "extended" functionality, but is not very useful because of speed (latency) and lack of real file handle (required for some Win32 applications running under Wine).

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?

Why should this be part of ftdi_sio ?

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

IOCTL advocacy

>  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.

Current drivers

Question:
> 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: