FTDI chips like the FT2232H are USB peripherals that are typically used as serial ports (UARTs with the RS232 standard RTS/CTS/etc lines), but can also be used as parallel ports, I2C or SPI drivers as well as as GPIOs.
On Linux, there are two implementations of the USB protocol used by them: libftdi and the Linux kernel version (the page was last touched in 2010, but seems to be up to date; the mailing list is still useful; the code lives in the linux kernel).
The FTDI library offers comparatively comprehensive support (enhanced by libmpsse? Not sure how much which library does) in a platform-independent way.
The kernel driver only supports the serial interface.
Applications built for accessing hardware behind FTDI chips need to decide which interface to use, based on the following criteria:
1) libftdi is platform independent; the software can run on other OSes as well. (Even other POSIX systems deal with GPIOs differently).
2) Kernel device are hardware independent; the software can run no matter whether the hardware is connected to an FTDI chip, a native bus or an MCP2210.
3) If the application is a kernel driver, it can only use kernel devices.
4) The required features (GPIO, SPI) might force the decision.
5) Using kernel devices is the True Linux Way (or so they say).
For many applications, hardware independence (item 2) is not that much of an issue, because devices are built as a unit containing the FTDI chip (arbitrary example). It becomes an issue, however, when using extensible hardware platforms (eg. mikroBUS native vs. USB).
Item 3 is relevant in those situation when there is already a kernel driver for a hardware module (eg. mrf24j40 for the BEE click / MOD-MRF24J40, or exploring the ENC28J60 driver).
Personally, I also appreciate a standardized interface in embedded systems development (developing lwIP drivers natively and then switching the SPI backend from Linux to native would be nice), but that's even more niche than the above.
Adding SPI/GPIO support to the Linux FTDI driver.
This seems to be the cleanest solution.
The reactions to previous approaches show that this is supported by the kernel community, but needs to be executed right.
(A note on the kernel driver being only a convenience thing made me doubt it's the right way, but the LKML threads convinced me otherwise.)
Using a library to abstract away kernel-native or FTDI GPIO/SPI.
This would help with hardware independence, but not with kernel drivers.
Implement a userspace interface for providing SPI (I2C, GPIO) devices.
This could be implemented either in a symmetrical way like USBIP (where the kernel can both share a device and use a provided one), or asymetrically (like with uinput) where the kernel provides a device-consuming interface, and a userspace process shares a device (which could, using the above library, be either a kernel SPI device or an libftdi managed one).
This would be the largest solution workload-wise, but might be beneficial in unrelated applications. (USBIP is advertised for virtualization; fake I2C or SPI devices could be useful in regression tests; new possibilities for remote debugging / boundary testing may arise).
One additional benefit is that mechanisms could possibly be developed with all the amenities of userland programming, and then migrated into the kernel. (Did I mention that I'm a fan of the concept of microkernels?)
Device discovery
This primarily affects use with other kernel drivers; device tree / MFD seems to be the way to go. (How do user space applications use that?)
Pluggability of GPIO devices
I remember having read of difficulties Linux faces when dealing with hot-plugged (or rather hot-unplugged) GPIO devices, but can't find the reference any more -- none of the recent approaches mention any of these difficulties.
The topic of enhancing the FTDI driver pops up regularly; conculsions from the last iterations:
Philipp Hachtmann's 2014 FIFO and CBUS support
Sasche Silbe's 2014 GPIO support
Stefan Agner's 2015 GPIO support
Ben Maddocks' driver appears to be comprehensive, but shows no signs of intended mainlining (making it unusable outside special deployments).
Except for Sascha Silbe's approach, there has been followup interaction on those submitted, but I haven't found any second round of patches.
None of this has made it into mainline as of 2015: the latest functional changes to the ftdi_sio driver, as of 4.3-rc3, date to 2011, when in f6c259a39, baud rate precision was enhanced cover new features of the FT232H chip. (Everything else looks like new USB IDs, bug fixes, kernel infrastructure adaptions or the introduction of a new chip without new features).
For the MCP221, ther is an out-of-tree linux driver. The author faces a similar situation (there is a pre-existing more featureful userspace implementation), but focuses on performance and self-configuration in the rationale.
Unsure; I've been almost at git checkout -b ftdi-gpio, but asking around and
further research have shown that the most promising approach is probably to see
where (and why) exactly the previous approaches stopped or failed.
--chrysn 2015-09-21, with updates up to 2023-06-27
This page is part of chrysn's public personal idea incubator; go up for its other entries, or read about the idea of having an idea incubator for more information on what this is.