On Wed, Sep 23, 2015 at 05:40:58PM +0200, chrysn wrote:
Hallo Stefan, hallo Philipp, hello Johan and Greg,
On Tue, Sep 22, 2015 at 12:02:03PM -0700, Greg KH wrote:
On Tue, Sep 22, 2015 at 06:28:47PM +0200, chrysn wrote:
Is support for alternative operation modes in FTDI chips something that is welcome and (easily) feasible in the kernel?
This comes up every other month or so on the linux-usb mailing list. See the discussions there about how to do this properly in a way that will be accepted by the USB maintainers if you wish to do this work.
I've overlooked your two recent approaches when looking for existing approaches towards extending FTDI support in the kernel (probably due to me being too focused at SPI).
Stefan and Philipp, has any of your patch sets received updates in the meantime that have not been sent to the mailing list?
It seems that one issue that needs to be solved for either of those to continue is the decision of whether to base the FTDI driver on the MFD infrastructure (which would probably be a first step then before even implementing any of SPI, GPIO or I2C interfaces). There have been conflicting opinions on this in different threads ([1], [2]); my impression is that it would be a good idea, given that many of the more recent FTDI devices can be switched to half a dozen configurations, and that they are also shipped in products[3] where several of them would be used in a coordinated fashion similar to the shields of widespread embedded systems.
Johan and Greg, can you reconcile your opinions on that? Or whom is that question best discussed with? devicetree? linux-usb? linux-gpio / -spi / -i2c?
That would be linux-usb. These devices are serial device and there's no need to use MFD when implementing support for controlling any additional pins that can be used for GPIO. Just hang the gpio controller off the usb-serial device (i.e. the USB Interface). If these devices can be programmed to be used in other modes, then we'd need a way to detect that and refuse to bind the serial driver at probe. A dedicated I2C or SPI driver could then be allowed to bind instead. Thanks, Johan